Skip to content


Working with AIR2.0 beta and nativeProcess – walkthrough

Like I mentioned in my previous post I decided to wrap up what I’ve learned working with AIR2.0 and share it with community. Air2 beta was released 2 days before I was told to research on a scenario of running a native application along with AIR app. There are a few solutions available that can already do it and you don’t actually need to use AIR2 nativeProcess if you have similar requirement but I decided to look into AIR2 a bit closer.
Because the app is not going to be publicly available and it is going to be installed manually along with runtime (not over the web) the risk of the app misbehaving or not working at all is massively reduced. That’s only IF. The big IF was if the application is going to behave as expected and after putting a few lines of code I must admit that it does. If it hasn’t I would have probably gone with Shu or Zinc. But luckily I didn’t have to thanks to nativeProcess fuctionality available in Air2.

So, what can you do with nativeProcess? You can run any native process on user’s machine (exe for Win users, dmz for Mac).
In my case I was porting an online app to work offline and the problem was that app was heavily reliable on external services and making it work without those simply wasn’t going to work. I had to have services running on localhost and serving whatever the live service would have served. Thank God it only had to work on Windows but I will explain why later.

Prerequisites
In order to get anything done and actually to be able to test anything there are some prerequisites like I mentioned in previous post, which is getting the runtime and overlaying Flex SDK with AIR SDK. The next step is to change descriptor namespace to

xmlns="http://ns.adobe.com/air/application/2.0beta"

. The next thing in order to get access to nativeProcess is to set up one more parameter in the descriptor.

<supportedProfiles>extendedDesktop</supportedProfiles>

.
This was a really gotcha because I found one article not stating anything about it, second one stating it should already be there and doing more research I discovered it has to be added manually. That’s all what’s required to take advantage of a nativeProcess

I would expect those descriptor changes to be included in final release of AIR2. I assume the xml namespace will be generated automatically and supportedProfiles is going to be commented out like the rest of params you can set in the descriptor file.

Using nativeProcess
First thing to do is worth checking in native process is available by checking if

NativeProcess.isSupported

returns true.
If it does, the rest should look like this:

private var file : File;
private var nativeProcessStartupInfo : NativeProcessStartupInfo;
private var nativeProcess : NativeProcess;

private function preinitializeHandler(event:Event):void
{
    if (NativeProcess.isSupported)
    {
        trace("NativeProcess.isSupported");
        //get the directory
        file = File.applicationDirectory;
                // point to the file
        file = file.resolvePath("bin/mynativeProccess.exe");

                //define process startup information
        nativeProcessStartupInfo = new NativeProcessStartupInfo();
        nativeProcessStartupInfo.workingDirectory = File.applicationDirectory;
        nativeProcessStartupInfo.executable = file;
       
                //instatiate the process
        nativeProcess = new NativeProcess();
                // start the process
        nativeProcess.start(nativeProcessStartupInfo);
    }
}

Setting the workingDirectory on nativeProcessStartupInfo to be application directory is required if you need the process to know where the files are. Running the exe standalone was showing the process folder to be where it was called from, but running it through AIR was changing it to C://Documents and Settings/user folder for some strange reason.

That was it for me. I didn’t have to write any data to the process directly because my service was doing it for me. However if you need to communicate with the process you can do it.
Here is an article on how to do it:
http://www.adobe.com/devnet/air/flex/quickstart/interacting_with_native_process.html

Other thing worth mentioning is the fact that AIR will kill the process you have started when you exit the AIR application. There is no need for additional handler to kill it. You can also stop the native process anytime you like by calling

nativeProcess.exit()

.

Packaging it all up
At this stage everyting seems to be working as expected so it is time to release the app. Because I am using Eclipse with FlexBuiler plugin (3.0) I would normally do Project -> Export Release Build from the navigation, but when you are wrapping a native process this option is not available to you. You need to use ADT in order to achieve this (more on ADT here).

First thing to do would be to add FlexSDK+AIRSDK/bin folder to PATH in Environment Variables. This will allow you to type “adt” in any folder or your machine from the command line. I recommend checking you have the correct version by typing

adt - version

to see if you are using the right version of ADT. If you get “2.0.xxxxxx” you are good to go. I only realised that after a couple of attempts and I was getting really frustrated by ADT misbehaving. I was pointing to ADT in a different SDK and version of it was 1.5. This version of ADT didn’t quite understand what it had to do.

Moving forward was getting the certificate. You need it for ADT to publish an app and the easiest way to get it is simply by publishing the application through Project -> Export Release Build. There is an option there to publish certificate as well. I think that’s the easiest and quickest way to get one.

With all those tasks done, the next step is to finally run ADT and get the actual AIR application. So, from the command line, go to your bin folder of your project where your descriptor.xml and application.swf is located along the all the files you want to include (your should have your native process there) and run:

adt -package -storetype pkcs12 -keystore yourCertificate.p12
-storepass yourPassword -target
native yourApplicationName.exe
yourDescriptorFile.xml yourApplication.swf
yourFolderToInclude1 yourFileToInclude2 ...

Make sure it’s all in one line as well.

This should result in ADT spitting out yourApplicationName.exe which is a native AIR installation file. Good enough for me. I am working on a PC, I get an exe I can run, it’s all good. Hold on, what if I wanted to release it for a Mac as well? That simply wouldn’t work, it turns out I would need a mac to do it!

In my case this wouldn’t work anyways, because my nativeProcess is a service build on Microsoft .NET, but hypothetically I could have had someone written the same functionality of my native process for a Mac. Then I could do a simple check of system capabilities and launch appropriate native process dependent on that. This scenario shows how with using native process you loose the key AIR feature, which is AIR being cross-platform. “Loose” is maybe a bit too strong, but making it harder and more confusing for a developer to develop cross platform. I wonder why this is done in such a weird way without the ability to publish to multiple platforms. If you have Flex+ AIR SDK installed on your machine it means you actually have both runtimes: Win and Mac. They both sit in SDK/runtimes folder and this is what ADT needs, unless there is something else that needs including and is probably licensed. I don’t see any other explanation for this. Also worth mentioning is the fact that Adobe doesn’t mention anything on how to run a native process on Linux.

Conclusion
New features of AIR 2 are really impressive. I am particularly interested in multitouch and gestures. Native applications have also a great potential. But I am a bit concerned about security here, especially if a developer has bad intentions. Imagine you had a worm packaged with your air app or any other form of malicious crap. It does sound scary. Apart from that I don’t see anything else that would do more harm than good. The same applies to beta apart from the fact it’s only a beta.

Releasing the app as AIR2 beta app is not something I would recommend unless you will have control over the machines it will be installed on. If you release your app as Air2 beta it will only work on a machine with this specific runtime installed. The runtime will not update itself from 1.5 to 2.0 beta, like it has for example from 1.4 to 1.5 when application needed it. In order to take the advantage of those new features in 2 beta the runtime needs to be installed manually. According to Developer FAQ runtime will upgrade itself automatically only to final 2.0 runtime when it’s released but it’s got nothing to do the same with beta. Also Air 2 beta will expire.

Because you can only have 1 runtime installed if you decide to go with this beta you put at risk all other AIR apps a user can be running. I have had the beta runtime installed for over 2 weeks now, I am running a few AIR apps almost the whole time (BBC iPlayer, TweetDeck) and I haven’t noticed anything wrong with the runtime. None of the applications have never crashed or anything like it, but the fact it is only a beta proves Adobe still isn’t totally confident with it.

If you want to play with it I would highly recommend checking out release notes:
http://labs.adobe.com/wiki/index.php/AIR_2:Release_Notes
for what’s new, what the known bugs are, etc. and reading the Developer FAQ:
http://labs.adobe.com/wiki/index.php/AIR_2:Developer_FAQ

You will notice some inconsistencies in the documentation, but if you have time and enjoy investigating, it might actually be loads of fun. I really enjoyed it.

Any questions, problems, suggestions just give me a shout.

Posted in development.

Tagged with , , , , , , .


5 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. Sjaakie says

    Thanx dude, nice explanation!

  2. Theo Denovan says

    It is a shame that the deployment build process isn’t cross-platform; however virtualising windows is fairly painless for those of us running macs. I think it’s a fair decision by adobe; it’s reasonable to assume that you’ll be running the OS targetted by the native process if for no other reason than to test it.

    Great article by the way.

  3. Roger Howard says

    Since the AIR runtime is cross-platform, I’m surprised/confused that you can’t simply check the platform in your AS code and conditionally load the right native binary via nativeProcess – I would have expected to build an AIR app containing both Win and Mac binaries so one could still ship a single, x-platform AIR app. Did I miss something here?

  4. admin says

    Hi Roger,

    I realised my post might be a bit confusing, let me clarify.
    You can check the platform the application is running on and conditionally load the right nativeProcess, but you won’t be able to ship it as a single app.
    If you are including a native process you have to package it up as a native OS application: exe for Win, dmz for Mac. To make things even worse, you can only package your app to an exe on Win or to dmz on a Mac. Which means you need to have a machine with each operating system you want to publish to. At least for now.

  5. guwanyuan says

    hi man!
    I try to use ADT package my AIR2.0 in FLASH BUILDER 4
    but can not working in my PC!



Some HTML is OK

or, reply to this post via trackback.