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

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 uploaded the HelloWorldService.cfc file to the remote server in “C:\ColdFurion8\wwwroot\components\com\test\HelloWolrdService”. I then set up a RemoteObject with the endpoint property pointing to the remote ColdFusion server instead of the local host (since the example points to a local host):

But I got a “Security Sandbox Error” right away from the call. This usually tells me that there needs to be a crossdomain.xml file on the root of server allowing access from my specific location or completely open using the “*” value. For more on the Flash security policy, check out plenty of info at Adobe’s site.

I uploaded the crossdomain.xml file to the root with the proper security settings (completely open in my case) and gave the server a restart just for kicks (though I don’t think its required when you change or modify the crossdomain.xml file under normal circumstances (I had some other issues unrelated to this blog post, but our admin was able to unblock those, basically the server also runs an additional web server on the same box as ColdFusion which was caused problems temporarily). So I ran the example again and received this error:

This error really stumped me because I am by no means any expert at ColdFusion and it has been years since I have had to mess around with it in any fashion. I searched and searched for this error in relation to ColdFusion and Flex. I was pulling my hair out, was it the port, was it the server address, was it the location of the CFC files, what was the issue?

I was really surprised at all the examples I found, they all were setup with both Flex and ColdFusion running on the same machine. Almost nobody was running Flex locally and accessing ColdFusion CFC’s remotely, and this is what I really needed. I eventually found a post on FlashComGuru where the author had the same exact problem as me.

It turns out that my RemoteObject had a couple of issues. First, it needed to have the destination property set, in this case ColdFusion is the default name set in services-config.xml file. Second, I had to change the endpoint property from “http://myremoteserver.com/flashservices/gateway/” to “http://myremoteserver.com/flex2gateway/”, changing the default gateway of the remote server to “flex2gateway”. So my updated RemoteObject code looks like this:

Finally, the Hello World example worked great! However, when I tried the application I was working on to hit the application specific CFC files, I didn’t get the results I wanted. As I mentioned briefly before, the server is also running another web server on the same box as the ColdFusion server. So the web root of the web server is “inetpub/wwwroot/” and the application CFC’s were located under this web server’s directory. In order to get them to work for me, I had to move them to the ColdFusion wwwroot folder “C:\ColdFurion8\wwwroot\components\”.

I am sure there is a way to map the ColdFusion component directory to another server, but to save time and get myself back on schedule, I settled with placing my CFC file son the ColdFusion server instead, for now anyways.

I hope this post is at least a pointer to a very hard to track issue with using Flash Remoting with Flex and ColdFusion 8. The kind of lighthouse for those Flex developers who might find themselves in the same bind .

-Mister