Nate's Code Vault

Merapi and AIR in a production environment

I have been using Merapi for about six months now and so far I have been very pleased. However, in the project I have been working on there were two issues that we needed to solve that were not really addressed by Merapi or other members of the community. They were:

Installing Java and AIR with one installer
Managing the Java and AIR sides of the application

Installation

This post is for Windows installers, for Mac-based installers, see my more recent Mac installer post. For the installation, the plan we came up with was that our installer would unpack 2 executables. The first EXE would start the Java part of our application and would be the one that users would use to start the application (i.e. Shortcuts to this executable in the Quick Launch, Program Files, and the Start Menu). The second EXE would be for the installed AIR application, and would be hidden from the user. The jist of the plan was that the Java executable would start the AIR application.

Here are the installation steps I took to accomplish this plan.

Get the Adobe AIR Runtime for distribution
Create an EXE to start the Java side of our application
Package both the AIR and Java runtimes into an installer
Figure out how to silently install the AIR runtime and our AIR application

Get the AIR Runtime

First, we obtained a license to distribute the Adobe AIR Runtime by applying here. Once this was approved, we downloaded the Runtime, a sidecar installer, and some documentation from Adobe. After evaluating the sidecar installer, we decided to create an NSIS installer for Windows instead.

Create an EXE to start the Java-side

Second, I created an EXE file out of our Java-side Jar file. I used Launch4j to do this. Launch4j allowed me the ability to reference the Merapi jar as well as other jars we are using for the project, and it allows you to reference the location for a Java Runtime that we could bundle in our installer. We decided to package the JRE because it would give us more control over the version that all of our users had on their computer.

Package AIR and Java runtimes

Third, I had to package the Java and AIR runtimes in our installer. This part was pretty easy. Using NSIS, I bundled the JRE and AIR runtime into the installer. The only trick was to make sure that my Launch4j configuration referenced the JRE installation directory.

Silently install AIR runtime and AIR app

Finally, after packaging all of the necessary files into the installer, I had to instruct the installer to silently install the AIR runtime and the AIR-side of our application. This was actually surprisingly easy to do. The command to do a silent install from the Windows command line is:

^?View Code NSIS

1	ExecWait '"$INSTDIR\resources\AIR_Win_installer_files\Adobe AIR Installer.exe" -silent -location "$INSTDIR\resources" "$INSTDIR\resources\MyAirApp.air"'

$INSTDIR is a variable for the installation directory in NSIS. The nice thing about this is that the user only needs to specify this directory one time. Then, you can reference the Adobe AIR Installer.exe path in the installation directory. The -silent option makes it so the user has no idea the AIR Runtime is being installed. The -location option allows you to specify where the AIR application file should be installed to. Finally, you can specify the location of the AIR file and the silent installer will automatically install it immediately following the silent install of the AIR Runtime. Pretty sweet!

Managing Java and AIR

With the installation under control, we turned our attention to figuring out how to manage both sides of the installed application. Our plan for this was that Java would immediately start the AIR application as soon as the user ran the Java executable. Then, when AIR closed, it would send a message through Merapi to the Java-side telling it to close itself. As a fail-safe, we also decided to include a kill switch for the Java-side in the event that somehow the AIR application had an exception and was unable to send a close message.

Here was the process in a nutshell:

Start the AIR-side application from Java
Kill the Java-side of the application when AIR closes
Stop the Java-end if the AIR-side has an exception and is unable to tell Java it is closing

Start the AIR application

First, I figured out the path to the AIR executable by using the following line of code in Java:

^?View Code JAVA

1	String[] path = {System.getProperty("user.dir") + "\\resources\\MyAirApp\\MyAirApp.exe"};

The System Property: “user.dir” is the path of the Java executables installation location. I used this to locate the AIR application’s executable. Then I was able to start it by using:

^?View Code JAVA

1	Runtime.getRuntime().exec(path);

Kill Java-side when AIR closes

Second, to close the Java-side after AIR has closed, all I had to do was register an event handler to the close event on the Windowed Application in Flex. In that handler, I sent a message to Java via Merapi to tell it to close itself.

Java Auto-Kill

Third, I built in an auto-kill switch on the Java process in the event that AIR closed without being able to dispatch a kill message to Java. To do this, I used a Timer that would count down from 120 seconds. Every time a message was received through Merapi, I would reset the Timer. If that 120 seconds expired, I sent a ping to the AIR-side. If AIR received a ping, it would immediately respond back to Java. If Java didn’t hear back from AIR after 3 pings, it would close itself.

I hope this information is helpful for those who like to create an AIR app, but can’t rely on AIR alone. Hopefully some of the shortcomings of AIR (starting/closing another programs, interacting with hardware, etc.) can be addressed and we won’t have to worry about having to integrate AIR with other technologies like Java.

Skip to comment form »

junmin said on May 13, 2009 at 2:42 pm

do you want the nsis command to just install the air app:

I have the following in the header script:

^?View Code NSIS

1	Exec "$INSTDIR\templateManager.air"

but it doesn’t work for me. it doesn’t install the air app for me.

thanks.

junmin said on May 15, 2009 at 11:05 am

also if i understand your blog correctly, it only shows how to make installer for windows. my question is that: how do you make installer for Mac or linux? thanks

Creating a bundled AIR / Java Installer on a Mac | Nate's Code Vault said on May 15, 2009 at 8:31 pm

[...] few weeks ago, I wrote a post detailing how to use Merapi in a Production Environment. That tutorial was primarily written to address managing Java and AIR on a Windows Platform [...]

Nate said on May 15, 2009 at 8:39 pm

@junmin

For your first post, here is the NSIS command I used to install the AIR application

^?View Code NSIS

1	ExecWait '"$INSTDIR\resources\AIR_Win_installer_files\Adobe AIR Installer.exe" -silent -location "$INSTDIR\resources" "$INSTDIR\resources\MyAirApp.air"'

This make the installer run silently, and passes it the location where the AIR application will be installed. Finally, I give it the path to the AIR application. The installer installs the Adobe AIR Runtime if it doesn’t exist on the machine, and then installs your AIR Application.

For your second comment, I just finished writing a post on a Mac installer. Check it out here

Confluence: BCBA003 - TAS said on June 2, 2009 at 10:03 am

Merapi……

Merapi…

ekz said on June 4, 2009 at 9:02 am

Great post. Very thorough, yet to the point. This is very helpful.

Question: How does one handle AIR app updates? When the java app launches the AIR app, and it detects and wishes to fetch a new version to be installed, can this be done without impacting the order of things? ie: Will the AIR app be aware of its location and drop all the new AIR bits in the precise place they should be… or is the NSIS installer the only guy that knows the folder structure?

-ekz

ekz said on June 4, 2009 at 9:29 am

I’ve got one other question… say this package was to be distributed in an office where users did not have admin rights on the machine; would this still work?

thanks again!

-ekz

whoover said on June 16, 2009 at 3:31 pm

I was able to download Adobe Air on the fly with the following:

^?View Code NSIS

!define AIR_VERSION "1.5.1"
!define AIR_URL "http://airdownload.adobe.com/air/win/download/${AIR_VERSION}/AdobeAIRInstaller.exe"
Function GetAIR
  GetDllVersion "$COMMONFILES\Adobe AIR\Versions\1.0\Adobe AIR.dll" $R0 $R1
  IntOp $R2 $R0 / 0x00010000
  IntOp $R3 $R0 &amp; 0x0000FFFF
  IntOp $R4 $R1 / 0x00010000
  IntOp $R5 $R1 &amp; 0x0000FFFF
  ; StrCmp $R2 "0" +3 0
  #StrCpy $1 "$R2.$R3.$R4.$R5"
  StrCpy $1 "$R2.$R3"
 
  StrCmp $1 ${AIR_VERSION} End InstallAir
 
  InstallAir:
    Call ElevateToAdmin
    MessageBox MB_ICONINFORMATION "$(^Name) uses Adobe Air ${AIR_VERSION} (found $1), it will now be downloaded and installed."
    StrCpy $2 "$INSTDIR\AdobeAIRInstaller.exe"
 
    ; use http://nsis.sourceforge.net/Inetc_plug-in
    inetc::get ${AIR_URL} $2
    Pop $0
    StrCmp $0 "OK" dlok
        MessageBox MB_OK|MB_ICONEXCLAMATION "http upload Error, click OK to abort installation" /SD IDOK
        Abort
    dlok:
        ExecWait $2
    #Delete $2
 
  End:
    ; end
FunctionEnd

The only problem is detecting the Adobe Air version is not working I did find an interesting link regarding detecting the version .

junmin said on June 18, 2009 at 7:55 pm

hey, thank for the blog again.

Similar to my question about Mac installer, could you give more details about how to bundle the JRE. For example, where can I download the JRE exe? How can I silently install JRE like you show for the AIR runtime exe?

Nate said on June 20, 2009 at 8:24 am

@junmin

Download the JRE you want from Sun’s site. There are several versions to chose from there. Note that the JRE is just a bunch of directories and files, not an EXE. For my installer, I used NSIS to package all of the JRE files and then unload them into a subfolder within Program Files on the user’s computer. Something like C:/Program Files/MyApp/Resources. That will get the files on the user’s computer.

In order to make sure that your Java application will use the JRE you placed on the user’s computer, check out Launch4j. It is free, it can be used for commercial purposes, and it is very handy. If you package your Java application files into a .JAR file, you can have Launch4j wrap the .JAR into an .EXE. Also within Launch4j, there is an option to give a path to the JRE directory that your Java application will use. We used this because our software required JRE 6 Update 11 in order to work properly.

In short, here are the steps I took:

1. Download the JRE to my computer.
2. Tell NSIS to package the JRE files within the installer.exe
3. Tell NSIS where I want to unload the JRE files on the user’s computer (C:/Program Files/MyApp/Resources/jre_1.6.0_11 or relative Resources/jre_1.6.0_11 if your EXE is placed in the C:/Program Files/MyApp directory).
4. Compile a .JAR file from the Java-side of my app.
5. Tell Launch4j where the .JAR file is and where to expect the JRE on the user’s computer (Resources/jre_1.6.0_11).
6. Create an .EXE using Launch4j.
7. Tell NSIS to package the .EXE I made within the installer.exe.
8. Create the installer.exe using NSIS.

Nate said on June 20, 2009 at 8:26 am

@whoover

Thanks for posting the script for downloading the AIR Runtime. That is a nice alternative to packaging the AIR Runtime in a distributable installer. If you figure out how to detect the AIR Runtime version, please let us know. Thanks!

Nate said on June 20, 2009 at 8:48 am

@ekz

I have not been able to find a way to support the Auto-Update feature in AIR because NSIS is the only one that knows the directory structure like you mentioned. As an alternative, I wrote a service which checks the version of the application against the latest version stored on our remote server. If an update is available, we prompt the user to visit our website to download a new installer. Each installer that we use checks for previous versions of the app and then removes them completely, so we have a fresh new version of the application.

As far as your second question regarding administrator rights. I believe the AIR Runtime requires you to have these rights from what I can tell here. However, I’m not sure if that is just for the standard AIR Runtime installer, or for the redistributable Runtime as well. The application I wrote requires Admin rights anyways for other reasons, so I am not entirely sure because I haven’t had a reason to look into it yet.

whoover said on July 9, 2009 at 2:26 pm

@admin
The previously posted nsis script does detect the version if you change

!define AIR_VERSION “1.5.1″

!define AIR_VERSION “1.5″

see: http://wildwinter.blogspot.com/2008/12/air-15-registry-key-changes.html

whoover said on July 14, 2009 at 9:49 am

Uninstall Air Application w/o OSID.air:

I also found that uninstalling the air application can be a pain. Even using the OSID air application (get link when signed up for a license to distribute) you have to know your air app id (in main-app.xml), the publisher id (in META-INF/AIR/publisherid of your app install dir), and then run the OSID air app. If your using NSIS I found a solution using the following snippet:

# Search for the air application and uninstall it… see: http://nsis.sourceforge.net/Registry_plug-in and http://forums.winamp.com/showthread.php?postid=2489342

^?View Code NSIS

${registry::Open} "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" "/K=0 /V=1 /S=0 /B=1 /N='DisplayName' /T=REG_SZ" $0
    StrCmp $0 0 0 loop
    MessageBox MB_OK|MB_ICONEXCLAMATION "Unable to find uninstall directory" /SD IDOK IDOK close
    StrCpy $R0 ""
    StrCpy $R9 ""
    loop:
        ${registry::Find} "$0" $1 $2 $3 $4
        ; need to track first find to prevent infinate loop
        ${If} $3 == "YOUR_AIR_APP_NAME_HERE"
            ReadRegStr $R0 HKLM $1 "UninstallString"
            MessageBox MB_OKCANCEL "$(^Name) is already installed. $\n$\nClick 'OK' to remove the previous version or 'Cancel' to cancel this upgrade." /SD IDOK IDCANCEL close
            ExecWait '$R0 /qb /quiet'
        ${Else}
            ${If} $R9 == ""
                StrCpy $R9 $3
            ${ElseIf} $R9  $3
                Goto close
            ${EndIf}
            Goto loop
        ${EndIf}
        ;MessageBox MB_OKCANCEL '$$1    "path"   =[$1]$\n $$2    "value" =[$2]$\n $$3    "string" =[$3]$\n $$4    "type"   =[$4]$\n $\n Find next?' IDOK loop
    close:
        ${If} $R0 == ""
            MessageBox MB_OK "$(^Name) is not installed." /SD IDOK
        ${EndIf}
        ${registry::Close} "$0"
        ${registry::Unload}

Nate said on July 14, 2009 at 12:18 pm

@whoover,

I did the same thing. Here is what I came up with (Just a few modifications to your script with additional comments.)

^?View Code NSIS

Function un.UninstallAIRApp
  ${registry::Open} "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" "/K=1 /V=1 /S=1 /B=1 /N='DisplayName'" $0
  StrCmp $0 0 endLoop loop
 
  # Loop through the registry looking for a registry key with a DisplayName of "MyApp"
  # $1 is the path of the key (ex. SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{B365B2A5-D2E0-2720-760C-67227F29C79F}
  # $2 is the name of the property (ex. "DisplayName")
  # $3 is the value of the property (ex. "MyApp")
  # $4 is the property value type (ex. [REG_DWORD])
  loop:
    ${registry::Find} "$0" $1 $2 $3 $4
 
    # If the property value type is an empty string, we have hit the end of the loop.
    StrCmp $4 '' endLoop
 
    # If the property value is "MyApp", we have found our key, so lets call it's uninstaller.
    StrCmp $3 "MyApp" foundEntry loop
 
  foundEntry:
    # Get the uninstall string and store it in variable $R4
    ReadRegStr $R4 HKLM $1 "UninstallString"
    # Execute the uninstall string silently (/qn)
    ExecWait "$R4 /qn"
    goto loop
 
  endLoop:
    ${registry::Close} "$0"
    ${registry::Unload}
FunctionEnd

Matt said on August 27, 2009 at 10:38 am

According to Adobe AIR’s distribution facts, a silent install is allowed, but states we can not bypass the EULA display. Was it possible with NSIS to just show that part of the AIR install process, or did you simply include a copy of the EULA in the shell installer process?

Nate said on August 27, 2009 at 5:35 pm

@Matt
I actually just had a conversation with an Adobe rep about that exact thing a few days ago. If the AIR installer is run with a command-line option of -eulaAccepted, then the EULA is not supposed to show. However, even if I do not specify that option (which I am not doing), a license still does not appear.

Adobe has logged this as a bug and will fix it in a future release. I also asked them if I should display the additional AIR license in the NSIS before installation and they said to not worry about it. In the meantime, they put our application on the AIR Marketplace even with this limitation.

Paras said on August 28, 2009 at 4:17 am

Brilliant.

We don’t have to worry about the EULA screen any more when it happens in the silent mode then. Awesome.

Thank you.

Nate said on August 28, 2009 at 5:32 am

@Paras,
Yeah… that seems to be the case at least for now.

Matt said on October 2, 2009 at 11:05 am

(First off, thanks Nate for your reply to my EULA question)

I absolutely love this tutorial, but any idea how to use the “command-line args:” option in JCreator, or if it even works? I’m trying to include SSL in the java portion of my application. When I call my class with command-line, I simply include “-Djavax.net.ssl.trustStore=… -Djavax.net.ssl.trustStorePassword=…” and the program runs perfectly. But I’ve tried various syntaxes to get it to work in JCreator to no avail. I was even sure to copy my certificate to the JCreator folder as well as my .exe’s folder when compiling/testing, but still no luck.

- Matt

Confluence: Rich Internet Apps said on November 27, 2009 at 5:20 am

Merapi…

Objetivo Merapi is a technology that can be used as a messaging bridge between applications that run in the Adobe Flash player or Adobe AIR and applications written in Java….

Raghav said on March 7, 2010 at 8:26 am

Hi. This is really great article and this is something I was looking for. Unfortunately I couldn’t get the NSIS script right and my end.
It will be great if you post you complete example, including NSIS script and the Java + AIR files.
Like me many will really appericate that.

Thank you once again for the article.

Nate said on March 7, 2010 at 9:09 am

I wish I could submit the NSIS script and the Java/Air files I used but unfortunately it is all proprietary. The NSIS command I mentioned above was all I needed to get the Air app to install properly. The rest of my script dealt with registry keys and other stuff not directly related to installing the app. If you are having problems with your script ask questions on the NSIS forums. There are already tons of solutions available on the forum and the community will answer any questions you have much better than I will be able to .

I also cannot include the Air distributable runtime. You have to fill out a form and receive approval from Adobe before they will give you access to the runtime. As far as the JRE is concerned, I just downloaded one from Sun.
- Nate

Sri Harsha said on April 26, 2010 at 1:45 am

Hi,
Good Blog , currently me also developing a small application using merapi and Air,i followed the example which u explained,But here its not able to install the air application ,Its able to execute(AdobeAIRInstaller.exe) but unable to install Air(myProg.air) i mean its not able to get exe from air,Generally while i double click on Air automatically it will create a exe and will be showing the shortcut on desktop.But when i use NSIS me not able to get exe to be generated when i kept the option to silent.

Merapi and AIR in a production environment

Installation

Get the AIR Runtime

Create an EXE to start the Java-side

Package AIR and Java runtimes

Silently install AIR runtime and AIR app

Managing Java and AIR

Start the AIR application

Kill Java-side when AIR closes

Java Auto-Kill

Skip to comment form »

Leave a comment

RSS feed for comments on this post.

TrackBack URI

Entry Details

Light Reading

Comrades

Flex Resources

Latest Posts