« Updating AIR 2.0 Flex 4 Apps | Main | Adobe AIR: Passing arguments into native executables »
AIR 2.0 Native Installer Concerns
| By Rich Tretola | November 19, 2009 | |
| 3,303 views |
I love the fact that you can now create native installers for your AIR 2.0 applications (see my 1st post on the subject here) as I feel this will lead to a larger potential audience for your applications whether or not you are actually using any native processes. However, while reading an article titled “Interacting with a native process” on the ADC by Jeff Swartz, I was very unhappy to see the following quote.
“You must run ADT on the same operating system as the target installer application. To generate a DMG file, run ADT on Mac OS. To generate an EXE installer file, run ADT on Windows.”
So, what does this mean? If you want to distribute your application for Mac (.dmg), Windows (.exe), and Linux (.rpm), you better be running OS X with a couple of virtual machine or you are apparently out of luck. If you are running Windows as your main OS, you can compile a Linux distribution with a VM but you can’t compile a Mac installer. This just seems wrong to me, your thoughts?
Topics: Adobe AIR | 21 Comments »
November 19th, 2009 at 8:45 am
True. I had the same feeling when I heard about having to compile to DMG, EXE and such to use native processes. I don’t really see the solution, but as I’m using a macbook pro, this shouldn’t be a problem for me.
Reply to this comment
November 19th, 2009 at 8:45 am
Looks like you’ll need a mac in order to generate all 3… 2 with VMs. I think the bigger question will be how to update an app once it’s installed.
Reply to this comment
November 19th, 2009 at 8:45 am
[...] This post was mentioned on Twitter by Rich Tretola, Romain Pouclet. Romain Pouclet said: Blogged: AIR 2.0 Native Installer Concerns http://bit.ly/1SoMED (via @richtretola) // answered! [...]
November 19th, 2009 at 8:46 am
I agree it’s BS, but I imagine it’ll be fixed with 2.0 final. If not, I’ll run a web service, charge people $20 to encode it for all 3 operating systems. Everybody wins
Reply to this comment
Rich Tretola Reply:
November 19th, 2009 at 8:51 am
Nice, I like your entrepreneurial attitude!
Reply to this comment
Babatunde Adeyemi Reply:
November 19th, 2009 at 11:01 am
+1
Reply to this comment
November 19th, 2009 at 8:48 am
Is there a bug logged in the Flex SDK project for this yet ?
Reply to this comment
November 19th, 2009 at 9:00 am
This also means we can’t have our build servers do the packaging which is also a problem even if you have all three machines with Windows, Mac, and Linux.
Is this related to Flash player stand-alone version inability to create a Windows projector on a Mac? (not sure if the opposite is also true)
Reply to this comment
Jim Hayes Reply:
November 19th, 2009 at 11:24 am
I had similar issues when wanting to produce a .dmg from a windows build server – in fact I ended up doing it on a mac mini – scp the new files to the mac, run a script to produce the .dmg, scp that back down to the build machine.
Ant has tasks available to do this, and it should also work on a linux machine.
Not at all ideal, but it is do-able.
Unless the situation changes, this is what I anticipate doing for the new native installers.
Reply to this comment
November 19th, 2009 at 11:18 am
I don’t really see this as a concern. You really need to be running all 3 platforms if you want to successfully test the applications anyway.
Show me a DEV shop that’s releasing software for OS X, Windows, Linux that doesn’t have all three systems around.
This is a very minor concern is is far from a deal breaker for me.
I’m just glad we’re finally getting Native installers without doing the hacking (against Adobe’s will at that) that we had to do for 1.0 to get native install-like functionality.
Reply to this comment
Ammar Mardawi Reply:
November 19th, 2009 at 3:42 pm
Yes, if you want to develop apps that run on three different platforms, you need to test on every single one. I agree, and this is what we do.
But that does not mean we have to go throw all three platforms when packaging a release! The ideal solution is a single auto build server that even automatically uploads news builds.
It’s not a deal breaker, but a major draw back.
Reply to this comment
November 19th, 2009 at 12:58 pm
[...] This post was mentioned on Twitter by david deraedt. david deraedt said: Totally agree with @richtretola 's concerns about AIR 2.0 Native Installer http://bit.ly/3BqWZD [...]
November 19th, 2009 at 1:55 pm
How would you begin to test a native process call to an OSX process if you were to generate a dmg in Windows?
Reply to this comment
Rich Tretola Reply:
November 19th, 2009 at 2:57 pm
You can compile to native installer without necessarily needing to have any native processes defined. It would simply be for easier distribution.
Reply to this comment
November 19th, 2009 at 1:56 pm
That being said, I WOULD like to see native installers even if native processes aren’t involved just to be able to bypass the branding of the AIR installer.
Reply to this comment
November 19th, 2009 at 2:19 pm
There are no plans to change this for the final release. I don’t know all the technical details, but I know the AIR team looked at many possibilities before deciding to impose this restriction. (I agree that it’s disappointing.)
I believe it has to do with the availability (or lack of availability) of certain files and packaging tools on various OSes. They would need to include them in the AIR SDK (or recreate them I suppose) in order to make it possible to create the installers for multiple OSes from any one OS, and it just wasn’t feasible to do that.
Paul
(Adobe AIR documentation team)
Reply to this comment
November 30th, 2009 at 1:53 pm
Hi,
I’ve got strange error when trying to package AIR file into exe native installer on TeamCity build server ( Windows machine ). Error says “AIR file at xxx could not be converted. The error was ””. Has anyone run into similar problem? Any idea?
Reply to this comment
December 1st, 2009 at 8:34 pm
Create three vm images, one for each os*. Strip them down to just the bare essentials needed to run your ant build script. Suspend/Snapshot each in a state ready to run.
Use VMware Server and a master script to resume the images, calling thier ant build scripts and grabbing their output. When done, dump all vm changes, reverting to the snapshot for next time.
No, not ideal. Not at all.
* You can make a Mac OSX Server VM image or find instructions on the web on how making a OSX client image.
Reply to this comment
December 23rd, 2009 at 10:42 pm
Welcome to buy Mbt shoes,Mbt Sport and Mbt walking shoes enjoy top quality and free shipping.
http://www.discountmbt.com/
Reply to this comment
January 6th, 2010 at 3:33 am
Mbt shoes are on promotion now,Mbt sport shoes and Mbt m walk are on sale. http://www.mbt-lami.com
Reply to this comment
January 22nd, 2010 at 7:20 pm
I think that one will keep in memory if select the the best essays writing corporation, this would be a possibility to get the very interesting issue about this topic or purchase the custom made essays corresponding with our prices. Hence, it’s very good selection. Try this here!
Reply to this comment