12 Replies Latest reply on Mar 3, 2008 11:27 AM by Oliver Goldman

    Need better alternative to Adobe AIR Application Installer

    Paul J. Lucas
      In order to build a double-clickable desktop application, apparently one has to use the Adobe AIR Application Installer. This is bad for a few reasons:

      • It's not scriptable.
      • It hard-wires the name of the swf file to load into the generated binary.

        For Mac OS X, the "swf launcher" should be a simple "launcher stub". The name of the swf file to load should be read from the Info.plist file. If it did this, then the stub could be the same for all applications. For Windows, there could be a simple XML config file in the same directory as the app that serves the same purpose as Info.plist on the Mac.

        I hope Adobe addresses this soon.
        • 1. Re: Need better alternative to Adobe AIR Application Installer
          Oliver Goldman Adobe Employee
          These statements regarding scriptability and hard-wiring are incorrect. But rather than just explain how it actually works, can you first describe what you're trying to accomplish? Then perhaps we can help you make that happen.

          Oliver Goldman | Adobe AIR Engineering
          • 2. Re: Need better alternative to Adobe AIR Application Installer
            Paul J. Lucas Level 1
            I'd prefer you explain how it works. I want a way to generate a launcher from the command-line so I can stick the instructions into an Ant build file. I never want to have to use any GUI application.

            For the record, I want to build a standard Mac OS X application bundle. I then want to inject my own resources into the Resources subdirectory and also replace the generated launcher with my own launcher (that will ultimately call the original launcher after it does other things first).

            My application has a client a server as separate executables. So I inject my Server.app into Resources, and use my own Info.plist to have it launch my launcher first. My launcher launches the client and server via fork/exec. Only the client is an Air application.
            • 3. Re: Need better alternative to Adobe AIR Application Installer
              Oliver Goldman Adobe Employee
              Interesting, although you still haven't explained *why* you want to do that. Have you considered having your launcher and the AIR application just be separate apps?

              Regardless, the way bootstrapping the applications works is an implementation detail and subject to change. We deliberately avoid documenting that kind of stuff to discourage people from depending on it.

              Oliver Goldman | Adobe AIR Engineering

              • 4. Need better alternative to Adobe AIR Application Installer
                Paul J. Lucas Level 1
                quote:

                Interesting, although you still haven't explained *why* you want to do that. Have you considered having your launcher and the AIR application just be separate apps?

                Because we want the user to download one thing, double-click one thing, and go. The fact that it's implemented as a client and server is irrelevant to the user. This is an application for ordinary users, not geeks who know what clients and servers are. The user shouldn't have to double-click the server to make sure it's running before they click the client. My launcher launches the client and server. When the client quits, the server does also.

                quote:

                Regardless, the way bootstrapping the applications works is an implementation detail and subject to change. We deliberately avoid documenting that kind of stuff to discourage people from depending on it.


                Then you should just pick one flexible way and stick with it. Having a simple stub and looking in Info.plist is perfectly reasonable. This is exactly the same way the "JavaApplicationStub" on Mac OS X works (for example)
                • 5. Re: Need better alternative to Adobe AIR Application Installer
                  mattkane Level 1
                  How about creating your native launcher app with the whole AIR client in the Resources folder. When you launch your app it launches your server executable, then after its done its stuff it launches the AIR app . e.g a directory structure like:

                  MyLauncher.app/Contents/MacOS/MyLauncher
                  MyLauncher.app/Contents/Resources/theServerExecutable
                  MyLauncher.app/Contents/Resources/AirClient.app

                  You could make the launcher app itself headless so you don't get two dock icons.
                  • 6. Re: Need better alternative to Adobe AIR Application Installer
                    Paul J. Lucas Level 1
                    quote:

                    Originally posted by: mattkane
                    How about creating your native launcher app with the whole AIR client in the Resources folder. When you launch your app it launches your server executable, then after its done its stuff it launches the AIR app.
                    You could make the launcher app itself headless so you don't get two dock icons.


                    • This doesn't address the need to have a non-GUI alternative to the Air Application Installer so builds can be completely automated.
                    • It definitely breaks the drag-and-drop of a file onto the application's icon.
                    • I never said I have 2 Dock icons. (I already solved that problem by making the server "faceless" by setting LSUIElement to 1 in the server's Info.plist.)

                      Why do I want completely automated builds? Aside from the ease of just being able to type "ant" and press Return, any real development group has things such that a "build machine" automatically rebuilds the app (on all platforms) after ever developer check-in to check for accidental build breakage. Those builds also become available to QA for them to test.

                      Ever time some new development tool comes out where the authors provide a GUI tool (presumably because they think GUI = easy), I have to wonder, "What were they thinking?" If the authors are themselves developers, how can they not see how crippling not providing an all-command-line tool-chain is? Don't all non-trivial development groups do automated builds as described above? The only answer I can think of is that some PHB somewhere thought it would be a "neat idea" to have an "easy-to-use" GUI application (because that sells to other PHBs).

                      As to drag-and-drop: presumably, the swf launcher that gets generated properly handles drag-and-drop of files onto the application's icon and Does The Right Thing when it happens (where "right thing" usually means simply opening the document dropped onto the icon). Now, since my launcher gets launched instead, that breaks drag-and-drop unless I implement that functionality myself. The way I've implemented my launcher is such that, after the fork(), it's the parent process that exec's itself into the client thus keeping the original process ID. The hope is that Launch Services on the Mac, when handling and drag-and-drop event, will send said event to the original process -- which is now the client -- and everything Just Works. I have yet to get around to testing this (I'm busy with other things at the moment); but, if it turns out that my hope isn't fulfilled, well then I can fall back to keeping my launcher running to get and forward the OpenDoc AppleEvents from my launcher to the swf launcher.

                      So, anyway, back to my original plea: Adobe, please just give us a command-line replacement for the Air Application Installer (preferably just a launcher stub that reads Info.plist). Thanks.
                    • 7. Re: Need better alternative to Adobe AIR Application Installer
                      Paul J. Lucas Level 1
                      quote:

                      Originally posted by: Oliver Goldman
                      These statements regarding scriptability and hard-wiring are incorrect.

                      I'm happy to be wrong in this case. So please point me to the documentation on how to script it and not use hard-wiring. Thanks.
                      • 8. Re: Need better alternative to Adobe AIR Application Installer
                        Oliver Goldman Adobe Employee
                        Paul,

                        Clearly you know what you're doing to have gotten as far with this as you have. Unfortunately, what you're trying to accomplish isn't supported in 1.0. Even if I gave you off-the-record information about how to hack this together, I don't know if it would work, since we've never tested these scenarios. You could file a bug if you ran into trouble, but frankly it wouldn't get serious consideration since it's for an unsupported scenario...

                        I know this answer isn't going to make you happy, but the best thing to do here is to give us a use case that we can consider for a future release. Just to be clear, "running a server app" is not a use case. We want to know *why* you want to run that app. (Maybe running a server app isn't the only way to accomplish that...)

                        This is a good time to send use cases in for 2.0. Perhaps you are doing something unique here, in which case we may even ask you to participate in the pre-release program for 2.0. That'd be a decision made based on the use case you provide, of course.

                        regards,
                        Oliver Goldman | Adobe AIR Engineering

                        • 9. Re: Need better alternative to Adobe AIR Application Installer
                          Paul J. Lucas Level 1
                          quote:

                          Originally posted by: Oliver Goldman
                          I know this answer isn't going to make you happy, but the best thing to do here is to give us a use case that we can consider for a future release. Just to be clear, "running a server app" is not a use case. We want to know *why* you want to run that app. (Maybe running a server app isn't the only way to accomplish that...)

                          We want do run our application as a client/server for a few reasons:

                          • The server does some pretty heavy-lifting in terms of image-processing where there's highly-performance-tuned native C code. This is called via JNI since the server itself is written in Java which does everything else such as image metadata parsing, indexing, etc. All the things that the server does are beyond the capabilities of what an Air application can do both easily and with good performance. We're using Flex/Air for what they're good for: making cross-platform, sexy UIs. (With some effort, one can make a sexy UI using Swing -- we've done it -- but the Java coding necessary to make it all work gets ridiculously complicated. In contrast, using Flex/Air makes doing sexy UIs stupid simple.

                          • Although I've been talking about a desktop application, we're also planning a web-based version of the same application. This is a nice thing about Flex/Air -- the same UI runs in a browser. The server part will be sitting on some other computer across the internet doing the heavy-lifting, e.g., Amazon's EC2.

                          • We also want to keep the client application "dumb" doing only the UI so it's small and light-weight. This would allow us to develop other kinds of client applications, or platform-tuned versions of the same Air client, quickly and easily. For example, it's probably just a matter of time before Flash, Flex, and Air are made to run on the iPhone. We'd like to have an iPhone client some day -- and we wouldn't have to touch a line of server code.

                          • The reason for wanting a desktop version of the app (as opposed to web-only) is so the user can work on local files disconnected from the internet -- not to mention there's no latency of transmitting images over the 'net. In short, we want the performance of a desktop application, but the option of giving users the ability to use our application on the road anywhere there's a web browser.

                            How's that for reasons?

                            But still: the fact that I'm doing client/server has nothing to do with the desire for a command-line alternative to the existing Air Application Installer. I bet there are lots of other developers out there who want this. I applaud Adobe for providing as much command-line stuff as they already have -- even custom Ant tasks! So why just not provide everything command-line?
                          • 10. Re: Need better alternative to Adobe AIR Application Installer
                            Oliver Goldman Adobe Employee
                            Paul,

                            Thanks for the reply. We'll definitely be considering this use case for 2.0.

                            regards,
                            Oliver Goldman | Adobe AIR Engineering
                            • 11. Re: Need better alternative to Adobe AIR Application Installer
                              Paul J. Lucas Level 1
                              quote:

                              Originally posted by: Oliver Goldman
                              Thanks for the reply. We'll definitely be considering this use case for 2.0.

                              Thanks, but what about providing a command-line alternative to the Air Application Installer? You do see that the use-case for my application has nothing to do with providing a command-line tool, right? What I really want are completely scriptable automated builds from start to finish.
                              • 12. Re: Need better alternative to Adobe AIR Application Installer
                                Oliver Goldman Adobe Employee
                                Paul,

                                We'll consider it for 2.0. I do understand your interest in the command line tool and it's been on the master feature list since we started 1.0. Since it didn't make 1.0, however, 2.0 is the next opportunity to release this feature.

                                In the meantime, you might want to take a closer look at how the stub executable locates the initial SWF content. For example, you might want to compare the stubs of two different installed applications.

                                Oliver Goldman | Adobe AIR Engineering