Really haven’t spent enough time ‘finenessing’ Flex based UIs recently, so especially looking forward to a something of a fast-track on Flex Effects in Tink‘s presentation.
Always good to hear how others work with their clients too in the “ActionScript in Commercial Environment”session.
Full details: London Flash Platform User Group 25th Sept 2008
When researching ActionScript libraries to include in a project, it is tempting to simply look to see that it has an open-source license and just use it. However closer reading may often reveal that the license burdens the developer with responsibilities which may make use of the code irreconcilable with the project requirements. Grant Skinner has published a valuable plain English summary and comparison of the common source code licenses. My take from it, is that if the source you are hoping to use is published with any license other than MIT, chances are you are not going to like some of the license conditions and you certainly need to research them.
Over the past few months I’ve been getting my head around the likes of Cairngorm, PureMVC and better use of design patterns in general. So looking forward to tonight’s LFPUG to see what the Slide Framework For Flex adds to the mix. The other stuff on large datasets looks pretty good too!
I’ve just been trying to delete a node and all its descendants from an XML object selected on the value of an attribute. Having read the “ECMAScript for XML (E4X) Specification” (PDF) as linked to from the Flex documentation I expected to be able to write the following…
delete theXMLObject..*.(@id=="theIDtoDelete");
however the above code will generate the following Flash Player runtime error…
TypeError: Error #1119: Delete operator is not supported with operand of type XMLList
The solution is simple if not obvious. The above code should be rewritten to ensure a single node is returned rather than a list…
delete theXMLObject..*.(@id=="theIDtoDelete")[0];
Distilled from this actionscript.org thread.
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:
Again it looks like a couple of really interesting subjects on 31 Jan:
More information is on the LFPUG site
I looked at using PureMVC previously for a simple tennis game, but left it aside in favour of building MVCish classes independent of any ‘framework’. I look forward to seeing if this decision saved or cost me time.
I haven’t got around to the obligatory 3D stuff yet. Personally I’ve always found it a bit of a red-herring, and one where the cost:benefit often falls short. So I’ll be particularly interested in seeing examples of good use.
I expect Ted’s “Player 9 installs” counter is going to go nuts.
The final release of Flash Player 9 update 3 is released (previously code-named MovieStar) enabling H.264 support for Windows, Macintosh and Linux platforms from www.adobe.com/go/getflashplayer.
I’ve just been working on an small piece of pure ActionScript3. Essentially the migrating from the large horrible Twitter Widget that I had in the right column, to the text-only representation now overlayed on the header image above.
I use SWFObject to embed the SWF in the page. I set the dimensions of the SWF to 780×45. Within the main function of the SWF I prevent the stage from scaling and set it to align top left. I then use the stage.stageWidth and stage.stageHeight properties to draw a semitransparent background within which to position a TextField then trot-off to get the Twitter feed.
All is well on Safari and Firefox. But when I test on Internet Explorer 6, strange things happen. The first time a page loads, it displays ok. But reload the page, or navigate to another within the blog where the SWF is loaded from cache, and the layout is quite messed up. Testing showed that this is because the stage’s stageHeight and stageWidth are returning value 0 in this circumstance. Further testing shows that although the stage’s initial size is 0x0, it does get resized at some point.
The solution I’ve implemented is to listen for and handle resize events. Mildly frustrating as I didn’t plan on dealing with resize. The only reason my application is structured like this is to allow the SWF to adapt to the dimensions set via SWFObject. Not to allow the SWF fluid resizing through it’s life.
Simply moving the positioning code to the resize handler solved the ie6 problem, but for the other browsers that render at the correct size from the off, no resize event fires. So from our main function we have to put a manual call in to the resize handler (with null as the argument), and then only modify positioning if the stage dimensions are something other than 0x0.
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: