Adobe MAX Video: Explore Deployment and Distribution Options for Adobe AIR Applications

Adobe AIR team member Oliver Goldman presented a session titled "Explore Deployment and Distribution Options for Adobe AIR Applications" at Adobe MAX last week. This is an excellent session for IT administrators, developers or architects that are interested in learning more about the distribution and deployment options for AIR. Oliver also previews some of the new capabilities we are working on related to native installer support in AIR 2 (see 38:30 if you are interested in this specific topic).

2 Responses to Adobe MAX Video: Explore Deployment and Distribution Options for Adobe AIR Applications

  1. Adam J Nowak says:

    Hey, this page throws up an #1033 error followed by a bunch of #1065 errors.

    The error bubbled up through an rss feed on my web site, it then throws up this error when my users open up the page that has your feed in it.

  2. Dear Rob,

    I would like to post a question to you regarding deployment doubts that we are trying to address.

    My company is working on the new version of our primary application previously built as a J2EE application with some reporting functions with Flex, and we want to use AIR in order to leverage its possibilities:
    • Seamless integration with existing application functionalities (implemented as standard JEE web application pages) thanks to the integrated HTML capabilities
    • Improved integration of the user interface with the desktop
    • Native processes to provide additional functionalities

    Our application is targeted to pharmaceutical industry, subject to FDA regulations, and it affects more than 5000 users for each customer, so we have some specific requirements affecting the deployment and distribution of the software:
    • Allow to run multiple versions of the software on the same client machine (to support test and acceptance activities in addition to the production environment)
    • Minimize the effort of the initial setup on each client
    • Manage the version upgrades without manual activities on each client
    • Keep the test/acceptance and production environments strictly aligned to improve effectiveness of formal validation (ideally, an application once validated should be transported in production without any source code modification, recompilation or repackaging)

    The current browser-based strategy is perfectly fit to these requirements, and in the shift towards a desktop-based strategy we need to continue satisfying them as much as possible. We evaluated the standard distribution strategy of Adobe AIR applications, and noticed several attention points in this scenario.

    The first issue we encountered is the back-end services endpoint discovery problem. Simply hardcoding a server URL in the packaged application could be a viable solution for public internet-accessible applications, but we need to support multiple customers in their intranet, and each one typically requires multiple environments for the application (acceptance, production, etc.). Maintaining dozens of different packages of the AIR application to support all these customer environments clearly is not the solution. Neither we want to force thousands of different users to enter and maintain the correct server location in their local preferences.

    So, we thought to use a badge hosted in the back-end application to run the local AIR application: using the underlying API, we could activate the application specifying also the network location of the back-end services. We could also rely on the badge to install the application (and the AIR runtime if necessary)… however, application packaged as native installers cannot be installed, upgraded, or launched by the badge API (and we need to package ours as native to use native processes).

    We also noticed that multiple versions of an AIR application cannot be installed side-by-side in a client machine, and that the installation and upgrade of the application can be performed only when the local user has administrative rights on the machine (using standard or native packages), forcing us to rely on external software distribution systems in some customer scenarios (introducing additional complexities in the release cycle)

    At this point, in our opinion the standard deployment strategies of Adobe AIR applications are unfit for enterprise environments. In the enterprise world, many of the applications have migrated to a completely browser-based solution, while others enhanced their client layer to comply with the requirements, for example installing only a thin portion of the client code and allowing to connect to multiple server versions/environments with it (e.g. the SAP GUI universal client). Without smarter deployment and distribution tools, AIR applications currently are a step back compared to web applications in terms of manageability.

    So, we are trying to develop a solution to address these problems, with some concepts similar to JStart: install on the client machine a launcher application capable of being activated from a web page, dynamically locate, download and run the actual client bytecode, transparently enforce client software updates, and supporting multiple applications (and multiple versions of the same application). However, we are facing many technical problems due to internal architecture of AIR and we already spent a considerable amount of effort trying to find a solution. We are now thinking to return on the choice of AIR, going back to Flex.

    What is the position of Adobe on this argument? Is Adobe aware of these issues and are there any plans on this topic? Any advice?

    Thank you in advance