With AIR 2 Beta and the upcoming AIR 2 release, you can now use the command-line tool “screencapture” that comes with Mac OS. Nothing extra needs to be bundled with the application for this to work on a Mac, but on Windows, you need an additional piece of code to execute the screen capture process.

The process of doing a screen capture is pretty easy. You first create a File object that points to the location of the “screencapture” command line on the Mac:

Then create a NativeProcessStartupInfo object that will be used when we start the NativeProcess.The arguments property of the NativeProcessStartupInfo takes a list of arguments that will be passed to the command line tool when its started. For a complete list of arguments used by the screencapture command line tool, type “screencapture –help” in the terminal window. For this example I wanted to push out a file named “screencap.png” to the desktop from a selection of the screen. Optionally, you could capture the image to the clipboard and paste it directly.

Now we can start the native process:

The screencapture command tool will be launched and you will see the selection cursor on your screen. After you make a selection, the file will automatically be saved to the desktop as “screencapture.png”.

Here is the complete project code:

To get something like this to work on Windows, you need to know a little bit of C or C# so you can call your own service and launch the screen print functionality on Windows. For more about using the NativeProcess in AIR 2 for both Windows and Mac, you check out this Adobe article.

Adobe AIR 1.5.3 Update

Luckily with AIR 1.5.3 you now have a grace period of 6 months to renew your certificate and still be able to publish an update to your application that users can install over the previous application. The down side is that it’s is not easy to update your certificate once you update to 1.5.3. You can read more about the Adobe AIR 1.5.3 update and changes to certificate migration here:

Release notes for Adobe AIR developers
Adobe AIR 1.5.3 Now Available

Updating Flex Builder 3 for AIR 1.5.3

First off, grab and install the latest and greatest AIR 1.5.3 from Adobe’s download site. You will also need to download the Adobe AIR 1.5.3 SDK to install within your Flex Builder 3. If you just change the descriptor file and not update the SDK to use AIR 1.5.3, you will receive the following error when compiling the project from the IDE:

invalid application descriptor: descriptor version does not match runtime version

or

EncryptedLocalStore may not use publisher IDs passed in from ADL

The instructions for updating Flex Builder 3 to use AIR 1.5.3 are not really clear, at least not for me. The best way to upgrade on the MAC is to download the AIR 1.5.3 SDK and manually drag the files to your Flex Builder 3 SDK folder. When you download the AIR 1.5.3 SDK and expand it, you can see the following folder structure:

You can just drag the folders one-by-one ( or the contents of the folder to be more careful ) to your Flex Builder 3 application directory inside the sdks folder. Now restart your Flex Builder 3 and create a new dummy project. If all goes well, your new project will have the 1.5.3 namespace already in the descriptor file. Now for existing Flex Builder 3 projects, you need to manually update your application’s namespace to 1.5.3 and add a new descriptor tag for publisherID (you don’t need to do this for a new AIR application, only if you are updating an project to AIR 1.5.3):

The publisherID is a combination of your application name and the publish id for the application. You can find the publisherID manually by looking at your currently installed application directory on MAC (Windows users can find it in the release notes):

The long number after the application name is the publisherID, copy this and add it to your application descriptor file. You can also get the application publisherID from the NativeApplication:

It should be noted that bye adding the …. to the descriptor file will create an error when compiling your application using Flex Builder 3:

invocation forwarded to primary instance

So this must be commented out of the descriptor file until you are ready to publish. If you leave this commented out when you publish the application, you won’t be able to migrate the application. So I am not sure how tracing the publisherID is going to be a help to you from the IDE when testing. You should also update the debug version of your Flash Player to the latest (10.0.42.34) before compiling your application. Now you can test your application from the IDE and it should work.

Migrating Expired Certificate

Now your application should run from the IDE and you can prepare to publish the application using your renewed certificate. Publish the application as normal using the renewed certificate to create the AIR compiled application. Now you will need to migrate your previous expired certificate using the ADT migration tools. The instructions for migrating certificates using the ADT migration tools can be found here:

http://www.insideria.com/2009/04/migrating-air-application-cert.html

Once you successfully migrated your previous expired certificate, your compiled AIR application is ready to update your previous version of the installed application on your system. If things didn’t go correctly, you will get an error that an application already exists with the same name, and you need to install the application in a different directory. That would be bad, and you probably missed one of the delicate steps and need to go through it all again. If you do get an update option to replace the existing application, you can no celebrate.

My Opinion about Certificates

In my opinion, using 3rd party certificate vendors (and paying for them) like Thawte, Verisign, ect. is total nonsense and just way to cumbersome. Adobe could easily provide a way to authenticate the authors of AIR applications with minimal cost to developers. This is especially important when you just want to publish an application for free and distribute it through the Adobe market place.

Adobe could borrow some ideas from Android Market, especially since Adobe plans on allowing developers to create more and more Flash/Flex content for mobile devices. Developers don’t need some complicated and expensive system in place to review code and authorize updates (i.e. iPhone app store), we simply need a way to verify to the end user that the author is who she says she is and the application is protected from someone else writing an application with identical name.

The renewal process for a certificate and the above steps to migrate certificates is a total pain, and I think an unnecessary barrier for Adobe AIR application developers. Anything Adobe could to do to lower the barrier for the average AIR developer to create certified applications would be greatly appreciated. There are also other ways to freely publish and distribute your application freely as described on this post at polyGeek.com:

http://polygeek.com/862_flex_deploying-trusted-air-apps-without-certification-for-free

-Mister

* Please note that Jesse is dude that looks about 17 and I am the older more distinguished gentleman.

Problem with ApplicationUpdaterUI

Indeed, that “mofo eats mad RAM” is putting it lightly. It turns out that the ApplicationUpdaterUI consumes about 14MB of RAM within the application. Furthermore, for the ApplicationUpdaterUI to even check for available updates, it must loads the entire UI in memory even if not displayed. So just by using the framework, you end adding 14MB to your application that won’t be garbage collected. Granted, in most cases 14MB of RAM is not that big of deal. However, for smaller applications you might want to consider an alternative approach.

There happens to another class file called ApplicationUpdater. This class basically gives you all the benefits of the ApplicationUpdaterUI framework without any of the visible elements. This means you have to build your own user interface. This might actually be a benefit in the long run as you may want to customize your application updater to match your application. The other benefit is that you can use the ApplicationUpdater class to check for updates without loading any user interface. The interface only needs to be loaded if there is an actual update available.

Custom Updater Interface with ApplicationUpdater

In building my own custom updater interface, I thought it might be nice to have the same look and feel of the ApplicationUpdaterUI along with some of the more polite features (like postpone update until restart). Building your own updater using the ApplicationUpdater turns out to be a little more involved than I had originally thought. However, when you start attacking a problem you persevere until the end, no matter what the pain.

I did find some available information in the Adobe AIR 1.5 Cookbook, which has a basic custom updater example. This helped with some of the basic stuff, but I still needed a little more detail to make something similar to the ApplicationUpdaterUI. I found another good example by Jens Krause, but this example is for Flex 4. I needed something that would work for Flex 3. So here is what I built based on these examples:

The application consists of one class file and one MXML dialog for displaying all the user interface elements. I borrowed some of the icons from the ApplicationUpdaterUI which is available in the AIR SDK (I hope Adobe doesn’t mind). The update dialog UI is only loaded when needed, all checks for application updates happen using the ApplicationUpdater. The update dialog is only displayed when the user wants to manually update or the periodic update check finds a new application update.

The Good and the Bad

The good news is the updater only consumes about 2MB of RAM when you load the update dialog box, part of that is the ApplicationUpdater itself running in the background. The other good news is that you can yank out or customize any part of the this example to meet your own needs. The bad news is that even though I tried my best to fully remove the update dialog and have garbage collection clean it up, it doesn’t fully unload from memory (go figure). I don’t feel this is a huge issue as the application is most likely restarted after you install an update. Below is the code followed by a zip file containing the full application.

UpdateManager.as

UpdateDialog.mxml

Main.mxml

I packed up the Flex project. You would use this basically the same as you would use the ApplicationUpdaterUI framework. You need to create an update version of your AIR file and place it and update.xm file on a server. You can test it from the local IDE if you replace the server url with “app:/”. Just remember you can not actually update an AIR application from the IDE, it has to be installed and running on your machine to update, and the update files have to be accessible just like when you use the ApplicationUpdaterUI.

The code is free to use, hose, rip apart, just post back any fixes or enhancements you make.

Source Files

UpdateTester.zip

Update

Don’t forget to add a closing event handler to the dialog box that calls the destory() function. This was not in the original code and there needs to be a way to handle users clicking on the close box of the Window for the update dialog user interface. I also added a change that if you don’t want to show the check for update now option, the “no update available” dialog does not appear either, here is the updated code for statusUpdate function in UpdateManager.as (not in the downloaded zip):

-Mister

As it turns out, I ran into just a small confusing snag that initially prevented the added application menu bar item from firing a select event. I eventually reached out to the Adobe AIR Tight discussion group and Jesse Warden had a quick fix. It turns out that if you do not use strong item references, they are swept away by Garbage Collection (GC) before you actually use the items. For example instead of creating the NativeMenuItem within the scope of the function, I had to create it within the scope of the class or in this case, the WindowedApplication.

In my application I only needed to add a single menu bar item. So instead of blowing away the entire application menu and then creating all my own menu items (as many of the examples show). I just wanted to add a single item to the exiting application menu bar. On Mac OS, you get 4 application menu items: YourAppName, File, Edit, and Window. YourAppName would be your applications name or if you are running in the Eclipse IDE, just simply “adl”. In my case I wanted to add a “Preferences” option under the YourAppName. You can do this by accessing the NativeMenuItem representing the YourAppName. Something like NativeApplication.nativeApplication.menu.items[0] will return a NativeMenuItem with that reference. Using that reference you can then add a new NativeMenuItem to the submenu of the referenced NativeMenuItem. In addition to adding items to the submenu, you can also detect when the new item is selected.

In any event, here is the complete application code example:

That’s it, so now you can have a new item under your application name in the application menu bar to fire whatever function you desire.

-Mister

Issue Context

The first image is a TextField with one HTML link. The link fires a TextEvent which is handled by a function which replaces the text. The original TextField out put is in the image below withe the “more” HTML link at the end:

The second image shows the result when the “more” link is clicked and the text is replaced. You can see that when the mouse is over the text the entire text becomes a “more” link even though the new content has no HTML links. The rollover style on the TextField underlines the text.

Below is the complete AIR application code that shows how I setup the application and changed the TextField content.

Code

Workaround

I can’t remember where in my web travels or blog reading I found this, but there seems to be a need to reset the TextField.htmlText value before setting the TextField.text value within AIR applications to clear the previous content. I couldn’t find any official bug that reported this issue. However, doing this will eliminate the bug and reset the TextField content properly. So in the event handler for TextEvent, just before setting the content of the TextField, do the textMessage.htmlText = “”:

The issue could be with setting the styles of the link tags of the TextField. However, I could not reproduce this issue with Flex in a browser, this only occurs within an AIR application. If anyone can explain why this works or point me to the bug report for this particular issue, please pass it on, thanks!

-Mister

By capturing this event and testing for InovokeReason.LOGIN, you can keep your application invisible and only show the windows docked in the system tray. If a users starts the application it will be InvokeReason.STANDARD and you can then show the application as normal. I find it annoying to have a ton of windows popping up on my screen when I restart my computer.

I usually set up an InvokeEvent when a users clicks on the system tray icon to activate the application and bring it to the forefront. I initially set WindowsApplicatoin visible=”false” so the application is invisible on start. If the the InvokeEventReason is “LOGIN”, I keep the application invisible, in other cases I activate the application and bring it to the forefront.

It should be noted that the InvokeEvent fires on application start up as well as from running the the application from the IDE (so you can’t test it fully unless you install the application and login again). Also, because of timing of events at start up, the application is invisible even when you set it to active, so it will blink if the InvokeEventReason is STANDARD. To avoid this behavior, I use the “windowComplete” event of the WindowedApplication to add the InvokeEvent listeners. So the code might look something like the following:

- Mister

If I call a function that creates a NativeMenu from a button click everything works great. If I call the same function to create the menu from an event (like receiving data from a service call), the menu is not created and the application crashes upon subsequent attempts to create the menu. In addition, trying to create a NativeMenu popup on “createComplete” of the application also causes a crash.

So let’s say you have an application that you want to show a NativeMenu as a popup on startup of the application so you run the following:

This will cause an immediate crash of the application. But if you create an non-poppup NativeMenu, it works:

This works just fine. Initially I assumed this is some kind of timing issue or a possible undocumented bug. After a ton of research and much wasted time, I did find a possible bug mentioned by Marco Casario in his book “The Essential Guide to Flash CS4 AIR Development book is oriented to Flash developers “. Here is a snippet from his chapter on creating NatveMenu’s:

The display() method of the NativeMenu class only works properly on Microsoft Windows systems. Flash Player doesn’t work properly on Mac OS X systems, and displays the pop- up menu on the cursor of the mouse instead of at the specified coordinates. This occurs if the call to the display() function happens as a consequence of an event of the MouseEvent class . If the call happens in response to other events, the application doesn’t display the pop- up menu at all.

This limitation was not mentioned in the Adobe Documentation and as it happens, I was trying to create a NativeMenu popup for my AIR application on a Mac. I hate when you find these things out the hard way and waste a bunch of time tracking down obscure undocumented issues. If this is a limitation, it should clearly be presented as such when you look at the examples in the Adobe help. I think this is a Flash player on Mac issue, but so far I can’t find any official documentation on the problem nor could I track down an actual bug report. If anyone has any suggestions, please pass them on, thanks!

-Mr

I have to be clear about this part, because first you might think that the fonts are rendered differently on each machine because we didn’t embed the font within the application. So you would see different fonts on a Mac or from one PC to another. That would be a good guess, but you would be wrong. I have running on my Mac three copies of our AIR application (app_1.air, app_2.air, app_3.air), running side-by-side at the same time on the same screen. All three applications compiled form the same exact code base, but from different machines (two PC’s and one Mac).

One version of the application shows clearly readable fonts, the others two applicaions show thinner more jaggy fonts with some color differences. The most significant differences are displayed with italic text and text on fonts. I couldn’t believe it myself, but I have a screen shot to prove it. Below you can see all three applications. The screen shot was taken of the applications side-by-side and then changed in Photoshop for better display on the blog page (vertical instead of horizontal). You will notice that one has better looking text, thicker, richer colors, and just more readable. The other two are crap, well, not as readable, especially the button text and the italic text.

Image

The middle application clearly has the best displayed fonts, even though they are all running on the same exact machine, there is noticeable display differences. The only difference is the machine that compiled each AIR file. The font on the tabs is thicker for the middle one, the button fonts are clearer and thicker for the middle one, and the italic font is more readable. I don’t know how to fix this issue, embedding fonts did not work, installing the same fonts on each machine didn’t work, nothing helped! Why do some machines produce a better quality AIR file while others produce jaggy text? I couldn’t find any information on this problem, so please let me know if anyone has any solution.

UPDATE

If you run your AIR package on a Windows machine with “clear type” turned on, then it actually produces better fonts. This makes all three applications look identical on a PC, but with clear type off, then only one of the applications looks good. The application generated on the Mac, and generated on the PC with clear Type on, still look the degraded when compared to the middle application.

The best solution I could find to have a consistent look for the AIR application when created from different computers is to embed fonts within the application. Still does not solve the reason why there was a difference, but it does offer a temporary solution. For more information on embedding fonts check out Adobe docs on the topic.

- Mister

I did some searching around and found one example from the Adobe AIR cookbook that stores and retrieves an value object from the ELS, casting the object as a value object when retrieved. However, I really wanted to store a whole AC of value objects and retrieve them. So I did a little more searching and found one blog post that outlines the same issue I was having: “when I read the object from disk back into my application, the type of objects from Array Collection is lost.”

Ok, cool, so the blog post lists a generic function to solve the solution by transforming the objects stored in the AC back to a proper value object. I wanted to make a little demo that combines the AIR cookbook example with the solution for storing/retrieving AC from the ELS with a slight modification of the generic function.

The first step is to create our Contact value object similar to the cookbook example:

Contact.as

Now we create a function that creates an ArrayCollection of Contact value objects and stores those in the EncryptedLocalStore:

Ok, now we have stored out ArrayCollection of Contact VO’s in the EncryptedLocalStore, now we need to write a function that retrieves the AC and transforms all of the VO’s back to something that we can utilize within Flex:

The above serializeContacts function takes a Class file (VO) and an ArrayCollection pulled from the EncryptedLocalStore using the retrieveContacts function. The VO is our Contact VO that we want to use to transform our ArrayCollection of objects. This generic function is pretty much what Mihai Corlan used on his blog post, but I changed” xml..value.@name;” from the example he posted to “xml..accessor.@name;” in my example in this post because the dump using the describeType() utility method the node we want is “accessor”. (The describeType() method returns an xml dump of the details about the object that is passed into the method. This is a pretty cool function that I previously didn’t know about.) Here is the dump of our Contact value object when I trace out the “xml” value from the above serializeContacts function:

xml:

We are interested in the name property of accessor node, and we store those names in an XMLList called “properties”. This XMLList will be used later to assign the values of the Contact properties within the serializeContacts function. So this gives us a legitimate Contact value objects stored in the ArrayCollection, which we can then use in our application without any errors or null values.

Here is the complete sample application code that can be copied and used in an AIR application:

Main.mxml:

Now we can store and retrieve ArrayCollections from the EncryptedLocalStore without dealing with the hosed object in our application. Many thanks to Daniel Dura and Mihai Corlan who helped tackle this problem in their contributions to the community. Sweet!

Update

I recently read a way to persist typed objects when storing them to the ELS, method outlined on Sönke Rohde’s blog.

-Mister