What prompted me to move my blog was price for one, but also having WordPress installed by the host as opposed to me installing my own and being responsible for upgrades. I was starting to have issues with posting new messages and getting plug-ins to work properly.

I can say this though, migrating your MySQL database and all the custom parts of my blog were a huge pain and time suck. I couldn’t recommend it to anyone, much better to find a host that already has the WordPress application.

-Mister

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.

With that work out of the way, I would like to introduce an AS3 Yammer API library that communicates with the Yammer service. The as3yammerlib is hosted on GitHub and the source code is publicly available. To use the library you will need your own consumer key and secret for the Yammer API available from Yammer’s developer site. The library is also dependent on the as3corelib for doing JSON parsing and as3-signals for broadcasting events.

I put together a Flex web-based example using Flex Builder 4 that walks you through the Oauth process and retrieves messages for the logged in user. To use the code, just create a new Flex project and paste the Main.mxml file in your main application file and create another mxml for the MessageItemRenderer file within the same directory:

Main.mxml

MessageItemRenderer.mxml

I am sure there are lots of ways to improve the library, but this one is a pretty simple start with lots of functionality. Please let me know if you find any errors and feel free to fork this version and add any improvements to the code.

-Mr

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

This solution has a couple of problems. First the application has focus the instance you click on any link within the application window. So fine, the way around that is to use some kind of timer so that your flag that says application is now active is not set until some time after the application receives focus. This leads to the second problem, at least for larger scale applications. You have to pipe the flag that says the application has no focus to every button and link through the entire application, this is a huge pain.

Today I just happened to be playing with the new FramerateThrottler class created by Grant Skinner to reduce CPU usage for AIR applications running on Mac (this is yet another gripe of mine). So on his bog there are some comments about using mouseChildren and mouseEnabled on all open AIR windows to reduce CPU. Anyways, when I was messing around with this suggestion, I happened to notice my application no longer scrolled when the application was in the background, but mouse events were still active.

So I then thought of combining my previous attempt at preventing links and buttons from being clicked on with mouseChildren and mouseEnabled. I ended up only setting mouseChildren and mouseEnabled to true if the application has focus, and after a small timer dalay of 500 miliseconds. That gives me just enough time to click on the application any where without also clicking on a link or button and activating it. So now I can click on the application to give it focus any place I like without firing off click events:

That’s it, a simple solution that was probably sitting under my nose the whole time but I never thought of it.

UPDATE

Jonnie Hallman from Adobe posted a great article that expands the idea of handling throttling and events (mouse wheel for example).

http://www.adobe.com/devnet/air/flex/articles/framerate_throttling.html

- 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

I borrowed the click event action from an example by Peter deHaan posted on his blog Flex Examples. You will need the latest build of the Flex Builder 4 SDK and some helpful instructions on how to install the latest Flex Builder 4 SDK.

Example AIR Application Output

Main.mxml

CustomToolTip

The only think I couldn’t get working for this example (the commented out section) was changing the format of the hyperlinks within the TextFlow object.

Source File

Additional Resources

http://labs.adobe.com/technologies/flashbuilder4/
http://livedocs.adobe.com/flex/gumbo/langref/spark/primitives/RichEditableText.html
http://blog.flexexamples.com/2009/08/27/creating-a-linkelement-in-a-spark-richeditabletext-control-in-flex-4/
http://blog.flexexamples.com/2009/07/13/downloading-and-installing-flex-4-sdk-builds-from-opensource-adobe-com-flash-builder-4-beta-edition/

-Mister

What I wondered was if I could do the same thing by just setting the styleName to null:

This does work for skins, but as Bernd’s comments point out, other styles such as “color, fontSize, paddingTop” don’t create memory leaks, so this method only works with skins. However, setting the styleName to null is also an effective way for marking the object ready to be garbage collected. I recommend reading the rest of his posts about garbage collection techniques. I am always searching for the holy grail of garbage collection and his posts were very insightful.

-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