Crafting A Customized-By-Admin Mobile AIR App

One of my customers is having me develop a Tablet app for use in a sort of enterprise context. The app needs to be customized by my client, then handed off to their customer which will further distribute the tablets. It's essential that the end users aren't able to muck with the configuration of the app.

What I wanted was some way to parameterize the app at distribution or run time. That is, have a standard app that gets deployed to every enterprise, but when it's installed, provide something resembling command line arguments to the app so that it can be tweaked on the fly. From the little research I've done, I've come to the conclusion this isn't possible.

This left me with two other options:

1. I could make each Enteprise's app their own apk file. I already build my apk files using GNU make, so it would actually be fairly trivial to write some rules that build custom binaries on the fly. But, the thought of having to manage one binary for each organization my client sells it to makes me awfully nervous. That's got maintenance nightmare written all over it.

2. I could make a back door admin section. In this scenario, I'd build a single app for all organizations, but have some super secret menu that only my customer would know how to access. They could then use the facility to configure the app and send it on its way. This gets me the single app I want to manage, but I'm not in love with building in a back door. I don't want to give end user something they can fiddle with, and I'd rather not invest a whole bunch of time into an admin tool set that will only be used once.

After further analysis I came up with option 3. I rigged the app so that the first time it starts up it detects if its ever been run. If it is the first execution, a series of questions are shown to the admin allowing for them to configure it. Once the questions are answered the app exits. After that, when the app is started up it detects its configuration and goes right into end user mode. There's no other entry point to get back to the configuration screen, so there's nothing the end user can do. If the admin ever needs to reset the configuration, they need only re-install the app and reconfigure it.

I've got my single app instance to maintain and no backdoor control panel waiting to be knocked on.

The Adobe AIR implementation of this model is surprisingly easy. I used the EncryptedLocalStore as a mechanism for storing whether I've ever been run/configured before. To make this object easier, I wrapped it in a utility class: LocalConfigurationOps:

In the activation code of my first View I say something along the lines of:

 var cfg:Object = LocalConfigurationOps.get();
 if(cfg == null) {
   navigator.pushView(ConfigurationView);
 } else {
   appCtx.localConfiguration = cfg;
 }
 ..

ConfigurationView then becomes the panel admins use to customize the application the first go around. In the click handler for the Save and Exit button I have something resembling the following:

  function onSave():void {
    var cfg:Object = collectConfiguration();
    LocalConfigurationOps.set(cfg);
    NativeApplication.nativeApplication.exit();
  }

Time will tell how well this solution works out. But given the simplicity, ease of implementation and promise of maintainability, I've got high hopes.