Platform Parity and Scalability

Confession: We’ve made a bit of a mess for ourselves in the application descriptor.

(For those not familiar with the application descriptor, it’s a short XML document that’s a required part of any AIR application. It provides essential information like the application’s unique ID and version, plus a variety of optional settings covering everything from screen orientation behavior to application marketplace filtering. It’s roughly analogous to Info.plist on Mac OS and iOS, and AndroidManifest.xml on Android.)

In AIR 1.0, we strived to keep this descriptor purely cross-platform. We almost achieved that goal, but compromised a bit with the <programMenuFolder> setting. That setting allows an AIR app to control, on Windows, where it appears in the Start Menu. Customers told us it was essential.

When we added iOS support in AIR 2.0, we realized that there was a host of options, accessible via the iOS Info.plist file, that we wanted developers to have access to and yet didn’t have any cross-platform analogue. That was hardly surprising at the time, since iOS was the first mobile platform we supported.

So, we decided to add an escape hatch: the <iPhone> element. (Why not <iOS>? Because this was before iPhone OS became iOS.) It contains iOS-specific settings, including arbitrary additions to the Info.plist file.

When we added Android support, we extended this in the obvious way, adding an <android> element with similar capabilities.

Now, about this time was when we realized we had a problem. Our list of supported platforms is continuing to grow, but adding new elements to the descriptor for each one isn’t a scalable approach. In particular, it requires that Adobe modify the descriptor schema each time a new platform comes online, rather than enabling our platform partners to make these additions on their own. Our partners don’t want to have to wait for us for such a change, and we don’t want to have to make them wait, either.

As we worked with RIM to bring AIR to the PlayBook, we asked RIM to help us fix this and store PlayBook-specific settings in a separate file, outside the application descriptor. This approach is easily scalable, as it’s trivial for each platform to add its own file. And it’s easier to use then open-ended extensions in the application descriptor itself, which can get tricky when storing XML in one schema inside XML in another schema.

At the moment, the unfortunate result of this mess is that PlayBook might appear to be a second-class citizen, in that it doesn’t get its own element in the descriptor. This is not at all the case. On the contrary, PlayBook is the first platform to move to our preferred mechanism. It’s iOS and Android that are stuck with the older, more awkward mechanism.

Although I can’t speak to the timing, as it’s not yet determined, we will be moving platform-specific settings for all platforms, including iOS and Android, to external files in the future. Then we’ll finally be where we should have been heading from the beginning: Parity between platforms, in a scalable fashion.

5 Responses to Platform Parity and Scalability

  1. maliboo says:

    Why not use xml namespace instead?

    • Oliver Goldman says:

      Namespaces allow mixing type definitions from different origins, but one still has to define how those types can be mixed. That’s worthwhile if it’s valuable to have everything in one file. In this case, there’s no real advantage to a single file approach. That makes multiple files, one per platform, easier to define and easier to use.

  2. creacog says:

    Makes sense. However I’d suggest the problem is slightly wider than described and might benefit from a more sophisticated approach than simply adding one file ‘per platform’.

    From the developer’s point of view, in a multi-target project

    * Some AIR properties will hold the same value for all targets
    * There are target specific properties to manage (per runtime host)

    But in addition:

    * There will be some air properties to vary per target
    * Platform specific properties to vary per target ( e.g. per form factor)

    In a Microsoft environment, analogous is the issue of having to vary web.config properties depending on the build target (production, staging, local). So their approach of using a central file plus a transformation file per target seems to me elegant and flexible? It certainly means there is no need for maintaining duplicate property values across multiple files.

  3. I’m totally agree with that. I like the option to add an additional XML descriptor for each platform, and also I think is better for new programmers to learn about descriptor files, it’s more clear.
    Maybe for AIR 3 could separate iOS and Android to external files? 😉

    Thank you for this description.

  4. Igor Costa says:

    I guess

    The best suit of this problem is to have only two descriptions to simplify things.

    desktop.xml – Overall AIR configuration for desktop.

    mobile.xml – Overall AIR configuration file for N devices blocking by category.

    Each vendor with each description file, will still make a lot of mess.

    My $2 dollar on that behavior.