creacog

When using the Adobe AIR Update Framework for the first time, you will be stepping through the associated documentation. You will probably initially decide to use a configuration XML file to govern the update process. The documentation presents the following line to inform the framework of the location of your config file:

Point the configurationFile property to the location of that file: as in the following ActionScript:
appUpdater.configurationFile = new File("cfg/updateConfig.xml");

If you are familiar with the File class, you will see that this is likely to generate a run-time-error, especially when testing in adl…

ArgumentError: Error #2004: One of the parameters is invalid.
at Error$/throwError()
at flash.filesystem::File/set nativePath()
at flash.filesystem::File()

If you are like me, you’ll probably want to place the updateConfig.xml file within the application directory next to the *-app.xml file. If so, the line of code you need can be written:

appUpdater.configurationFile = new File( File.applicationDirectory.resolvePath( "updateConfig.xml" ).nativePath );

or more compactly, using the “app:/” url scheme:

appUpdater.configurationFile = new File( "app:/updateConfig.xml" );

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!

A little while ago I got around to building my version of an alert tool sampler, using it as an exercise to learn Cairngorm. (The documentation for which I have found particularly poor with the exception of a few gems such as David Tucker’s excellent Cairngorm ‘Getting started’ tutorials.)

Typically AIR developers will all want to take advantage of the Update capability, but in it’s original form requires some work. Rich Tretola’s UpdateManager did the job, but I wanted more programmatic control, interception of events and a slightly different UI work-flow, and set about creating my own.  Just as that phase of the work is completed, I find Adobe’s Update Framework on labs which although beta, does a much better job. I wish it was there a week ago.

Also, I just took the opportunity to update to AIR 1.1. Unfortunately updating Flex to use the new AIR is a little messy (in that it requires manually copying some files rather than running an installer) and means moving to the 3.0.2 stable build of the Flex SDK. However it is not difficult and the instructions to follow are here.

If you are using DataGrid in a Flex/AIR application, the chances are you will at some stage hit the following RunTime error…

TypeError: Error #1010: A term is undefined and has no properties.

.. with a traceback indicating the error occurred within DataGrid.as. At which point you will stare at your own code for a while and wonder why.

In my circumstance I pinned this down to clearing the contents of the data provider and repopulating when there is an item renderer active on the DataGrid. A use-case that probably doesn’t come up that often in web-based Flex apps, since if the user clicks another control to trigger an update, the item renderer is exited at that point and the edit committed prior to the dataprovider changing.

In an AIR app, we have native menus available to us. When the user employs native menu selection, the item editor remains active. If that menu option triggers a repolpulation of the data provider (use-case example File>Open), we then get the error.

The workaround is pretty simple. A call needs to be made to destroyItemEditor() on the DataGrid instance before repopulating it’s data. In a simple application this is no great problem. But if you’ve gone to the effort of using something like the PureMVC framework to separate Data Object from View Components, the data object isn’t supposed to have any knowledge of the view. So in my case thefix is quite crude - when issuing the open command, a notification to destory item editors will be issued so any view component that uses them may destroy their editor prior to the repopulation.

My contention is that it should be the responsibilty of the DataGrid to destroy the item editor if the dataprovider updates.

I have this logged as a bug with Adobe (SDK-15280), along with sample code demonstrating the issue. Feel free to review and vote for the bug if you are in agreement with my point and comment further therein if you disagree or have better suggestions to offer.

When you come to build your first Flex/AIR application that needs a native menu (Application menu on a Mac, or Window menu on a Windows PC), you’ll probably find your way to the “Windows, menus, and taskbars” section within the documentation. From there you’ll navigate to “Working with native menus” and spend some time studying “Creating native menus” before going on to view the example code. At this point you’ll probably have a shock at how much AS3 code needs to be written to implement such a simple menu. Not at all what you are used to in Flex.

If you are thinking there must be a way to do this using a component. You’d be right, but it is documented in the “Using the Flex AIR components” “About the FlexNativeMenu control“section not the “Windows, menus and taskbars” section.

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]

1. 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.
2. 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.
3. 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

• <mx:states>
• <mx:transitions>

which then become

• <comps:states>
• <comps:transitions>

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:

1. [Thurs 21-Feb-2008] LFPUG - Thermo Special presentation from Adobe
2. [Mon 25-Feb-2008] Adobe sponsored Pokercoder Tournament II  - you need to be a professional user of Adobe products to join in
3. [Thurs 28-Feb-2008] LFPUG - presentations on ‘Successful Flash Games’ and ‘Practical Particle Effects with Flint’
4. [Wed 5th March] FLUG - Beer, presentations and chat about Flex

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.

• The fix isn’t available to me until the final version is released.
• I can’t continue to use my application compiled against Beta 2 as the install process for AIR currently demands Beta 3 of AIR
• Beta 3 AIR  demands Flex Beta 3 SDK.

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.

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…

• AMF3 Specification
• Blaze DS - Free LGPL Remoting and Messaging for Java (ok not three, but free!)
• Flex 3 Beta3
• AIR Beta 3

A good start-point to read more (a brief paragraph on each) is Ted’s OnFlex blog, and of course the Adobe labs site.

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…

• the font is huge, and only 49 lines fit on an A4 page
• if you have a background colour set to your code window, it gets printed - decimating your ink-tanks
• printing is a two dialogue process - you have to go through Page Setup each and every time.

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…

• Name: enscript
• Location: /usr/bin/enscript
• Arguments: -2rT4v -DDuplex:true -diP5000 ${container_loc}/${resource_name}

Obviously you’ll need to tweak the arguments according to your personal print configuration.