An Updater Framework for Native Application Installers

In an earlier post about native application installers, I mentioned that implementing an updating mechanism for applications that use this deployment option is currently an exercise for the user, as the updater framework included in the AIR SDK does not support native application installers.

Fortunately, Adobe Platform Evangelist Piotr Walczyszyn has written just such a framework. If you are adopting native application installers, it’s worth a look.

With respect to my earlier comments about securing these updates, it’s worth noting that secure use of Piotr’s framework currently requires hosting HTTPS downloads for the installers.

10 Responses to An Updater Framework for Native Application Installers

  1. Dear Oliver,

    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

    • Oliver Goldman says:

      Many great comments and questions here. I’m working on some follow-up posts to address these; nothing I could cram into this comment field would really do your query justice.

    • Oliver Goldman says:

      I’ve been thinking about your comments and, while I think you make a number of valid points, I can’t agree with your final conclusion. The difference may be entirely in the framing, that is, how much of this problem is AIR supposed to solve?

      Our approach with AIR has always been to fit into existing tools to the greatest extent possible, rather than building a set of AIR-specific tools. So while you’re correct that the “standard” AIR deployment capabilities are insufficient for the enterprise, they weren’t intended to be a complete solution. Instead, they’re intended to integrate with existing enterprise solutions. I have a number of posts on this topic.

      You mention services discovery as a specific issue, and here again our goal has been to leverage existing facilities. I’ve posted more about this and other configuration issues just now, and look forward to your reply on that topic.

      Two places where you and I agree we can improve:

      (1) Modular applications. As you know I’ve also posted about modular applications recently. You’ve raised some interesting issues with these approaches, and we know this is a hot topic for enterprise customers. We’re actively exploring what we can do to better support this application model.

      (2) Side-by-side application installs. While our current simple model has some benefits, it’s ultimately rather limiting. You can work around it by packaging variations of your application with different application IDs. (Yes, I know that’s painful.)

      Finally, regarding the requirement for admin rights for installation: We’ve yet to talk to an enterprise admin who didn’t want AIR to work this way. It’s a pain, but it’s a reality.

      • Hi Oliver, thank you for taking the time to answer my questions on this interesting topic.

        I agree with some of the arguments, however, even without asking the AIR platform to provide all the described services, I clearly see some design *choices* that are actually preventing developers from creating a successful solution without leveraging external tools: cannot install side-by-side application, cannot use badge to install/update applications packaged with native installers, cannot use native processes without packaging the app in a native installer (I can’t find a rationale for this), administrative privileges required even for a simple application upgrade (I could agree with you about first installation).

        So, as far as I understood, the currently supported enterprise distribution model is:
        – deploy AIR runtime and the application on the client machines using SMS, SCCM, or TPMX
        – deploy the application upgrades with the same software distribution system
        – use a modified application id for non-production packages to allow side-by-side installation
        – let the application find configuration data externally (e.g. deploying it in a well-know location on each client or storing it in AD)

        The problem I see with this solution is that we can’t simply “roll-out” a new version documenting a well-defined upgrade path that just works for all customers, but we must work with each of them to support the creation of packages specific for their software distribution system (and, the first time, each customer have to sign a redistribution agreement with Adobe for the runtime).. moreover, the access to external configuration data could also be specific to each customer environment (custom packages for non-production releases also create some validation issues, as explained in my previous comments).

        In other words, in my opinion the suggested strategy could be fine if you have an enterprise application targeted to a *single* enterprise customer.. I fear that this scenario is not so comfortable when you need to distribute your application to, let’s say, 10 or 15 enterprise customers. Also, chances are that this is the first AIR application that they are installing so, as software developers, we have to explain and defend this technology choice. What if a customer asks me “why don’t you just build a classic Flex/JEE web application and avoid all of this complex installation activities?”

        A good modularization technology could, on the other hand, change the game: we could distribute/install an “application runtime” once on each client machine, and then manage our software and configuration delivery in-house, including transparent upgrade and side-by-side versioning, in the same way for each customer. Currently, I found that this is almost impossible to create with the current AIR/AS3 technology in a clean manner and avoiding memory leak (support for module unloading). I hope that future evolutions could change this: I’m very curious about the public release of Gravity technology, as explained in the Adobe MAX session “Realizing Great Customer Experiences with Adobe® LiveCycle® ES3” by Craig Randall ( Do you know when a preview it is going to be released by Adobe?

        Thank you
        Cosma Colanicchia

  2. Hi Oliver, any news about your answer?

  3. Thanks much for information.

  4. says:

    Hi Oliver, any news about your answer?

    • Oliver Goldman says:

      I posted a comment in reply on February 17th; see the earlier comments, above.