Archive for the ‘Flex’ Category.
The authors of SWFObject and UFO have been working hard on a new version released yesterday as SWFObject 2.0. The project is now on googlecode. Geoff’s announcement is here.
As stated in my earlier posts I consider use of SWFObject to be best practice for embedding SWFs in web pages.
The dark bit of sky in this blog’s header contains a simple SWF generated from pure AS3 that uses the Twitter API to collect and display my history of twitter messages. Unfortunately there is now a cross-domain policy file preventing any SWF other than those hosted actually from the twitter.com domain from accessing the feed. Apparently due to a security issue. The current suggested work-around is for me to write a proxy php script to sit on my own server to relay the feed request. Which I might do if I can be arsed, but I’m feeling grumpy today so I’m more likely to abandon Twitter all together – not that I ever over used it.
Twitter development talk on google groups has a thread that reveals some of the thinking going into solving the issue.
With today’s availability of release versions of Flex 3 and AIR 1, I’ve finally had a chance to apply the DragManager workaround that I had a moan about last month.
The flex documentation presents three configuration options for DragManager in AIR projects…
[Extract]
- Your main application file uses the <mx:Application> tag. In this scenario, you use the Flex drag-and-drop manager, and cannot drag and drop items from outside of AIR.
- Your main application file uses the <mx:WindowedApplication> tag. In this scenario, you use the AIR drag-and-drop manager, and can drag and drop items from outside of AIR.
- Your main application file uses the <mx:Application> tag, but loads the AIR drag-and-drop manager as represented by the mx.managers.NativeDragManagerImpl class. In this scenario, you use the AIR drag-and-drop manager, and can drag and drop items from outside of AIR.
Sounds all well and good. Except to use <mx:Application> within AIR, you lose functionality. For instance in my case while the window was re-sizeable, the content remained at the default size. What I really need is to use <mx:WindowedApplication>, but with the Flex DragDrop manager. A scenario not represented in the documentation.
Fortunately the workaround with files described in bug SDK-13983 so-far appears to work. However it is worth noting that in using it, a number of mxml tags change their namespace from mx to comps. In my case this affects
which then become
Possibly my reliance on this approach is due to the now legacy nature of the project – it was written in advance of the Apollo 1 alpha. However apart from this issue, very little has had to be re-written through the beta cycle of AIR.
A busy few weeks starting tonight:
I’ve just found myself caught out by this bug (SDK-13983) in Beta 3 (released December 2007), and the quite substantial change in behaviour.
My application which is only a prototype – but quite heavy, was essentially built from Oct 2006 through to April 2007 and worked happily in Apollo and in all AIR and Flex 3 releases since, until Beta 3, when the DragManagers of AIR and FLEX implementations diverged. The API remains pretty much the same, but the behaviour is quite different (documented here), and while my existing code compiles, it generates run-time error “ArgumentError: Error #2004: One of the parameters is invalid.” if the user dare drag my UI components, rendering it useless.
That it has been accepted as a bug and a fix/workaround created, and that that is visible in the public bug system is a good thing. It removes a lot of potential worry. That the fix is not available to the public (AFAIK we’ve had our last public beta before the final release) isn’t great for me as I am now in a catch 22.
It’s late, so this is going on hold until morning, at which point I need to assess the impact and time required to make the changes to adopt the AIR drag-and-drop manager, or hold on until I can force the switch to the Flex drag-and drop manager when the final release is available. Or beg Adobe for access to a build later than 191577.
This week it is a biggie with contributions from Adobe’s Serge Jespers and James Ward presenting Flex 3 AIR and Vega.
The event had reached capacity but with a new venue organised and more capacity, if you couldn’t sign-up over the last couple of weeks, you now have another opportunity.
So, the installation instructions quite clearly warn not to install this version over a previous beta. But then they include instructions how to “When using Flex Builder 3 Beta 3 with a workspace from a previous beta, please clean and reinitialize the workspace.”.
Unfortunately for me this didn’t work. I’d fully uninstalled the previous beta. But when attempting to re-use the existing workspace even with the ‘clean’ steps undertaken, the result was a broken installation of the builder. It couldn’t find any of the SDKs.
Uninstalling, getting rid of the old workspace and reinstalling then worked. Just leaving the job of manually setting up the projects again. This might be due to my configuration – I don’t keep project source files in the workspace – it only contains paths to the respective project folders on my system.
On a more positive note, the whole thing feels a bit more spritely.
Update: Actually, it is less of an issue to import projects than I first thought. In my first attempt I set my project folder and left the Project location at the default. This replicated the project files into the workspace folder. Not what I wanted. The solution, if slightly counter-intuitive, is to set the import from and the project location folder paths to be exactly the same path. This correctly makes Flex aware of the project , while leaving the files where they should be.
After the import – a quick clean then we are off!
Just as I’m about to head into hibernation for a week or so without computers or any connectivity, Adobe go and release all these goodies. Something to look forward to on my return…
A good start-point to read more (a brief paragraph on each) is Ted’s OnFlex blog, and of course the Adobe labs site.
The makers of StarCraft need have no fear, but I finally got around to implementing my first Flash based game. A simple retro tennis style game, built as a brand building exercise and integrated by my client into a Facebook application.
This was a fun project to work on and programme. To initially build a pure AS3 application, and to later integrate that with Flash CS3 when the real graphics were ready.
It was also an exercise in use of MVC. Since we did not use PureMVC nor any other other framework, using this pattern loaded the initial development with some seemingly onerous complexity. However the time invested later paid off in allowing easy adaptation of that game engine to the various graphics and controllers tried through testing.
Some links:
Continuing the theme of occasional Flex Builder hints and tips…
Occasionally I need to see code printed on paper. Unfortunately the printing capabilities of Flex Builder, or more specifically in this case, Eclipse, are a bit messy…
Of course in the actual Print dialogue, you have the standard Mac ability to change the page layout, paper handling etc, and save that detail in a pre-set. However…
The key things I want to achieve is to print 2up full duplex black and white, which gives me four pages of code per sheet of A4, and with a slightly smaller font size I get a more respectable 68 lines of code per ‘page’.
However I’ve found the following approach, once set-up, a little more convenient, and becomes a one-click print…
The Mac has a GNU enscript installed which converts text files to PostScript to send directly to CUPS. In my case I had to update the old Gimp-Print drivers to the current Guten-Print drivers in order to achieve duplex printing.
More information on Guten-Print and access to the drivers on SourceForge. The DMG contains good documentation and a simple package installer.
Once the new drivers are installed, and I’d recommend a new, additional, print queue be set up with appropriate defaults for your code printing, you need to set Eclipse to run an external script to print the currently active code window. From the menu: Run > External Tools > External Tools…
Obviously you’ll need to tweak the arguments according to your personal print configuration.
