Updating Enterprise Android Applications

24 03 2011

In my previous entry, I discussed the shortcomings of Android in relation to the Enterprise and how it’s not ready. Several commenters on stated we could get around this issue by adding this functionality to the application; being self-aware of application updates. My team had discussed adding this sort of functionality before my blog entry, so we decided to go ahead and pursue this. Close to 2 weeks ago, my team began gathering requirements and implementing a solution that would provide this self-awareness of application updates into our Android application. An installation problem still exists if your carrier blocks installing from external sources, but we’ll ignore that for this exercise.

Keep in mind, the original goal of creating the application was to become more familiar with Android, the APIs, the tools, documentation, etc. available for development. The application was just a proof of concept, not a necessity required by organization. All of our requirements come internally from our own team. First, we identified our requirements:

  1. Server component(s) will exist to provide latest version information as well as to store application apks.
  2. The application should be able to ping a server to determine if a newer version is available.
  3. The server should be able to inform the application if they are current, a new version is available, or if an update is to be “forced”. Other information provided from the server is location of new apk and the new version number.
    • Forced install doesn’t mimic true Android Market functionality, however we determined there would be a need to push critical application updates upon the user, even if they don’t want them.
  4. The application should auto check for app updates on launch, but only do so every 7 days.
    • We wanted to prevent unnecessary network traffic if a person launches the app several times a day.
  5. Once it has been identified a newer version exists, the check is no longer made.
    • The user is notified upon launch (every 7 days) if an update is available.
  6. The Update Check can also be made on demand whether a check has been made in the last 7 days or not.
    • Once an update has been identified the on demand Update Check becomes an on demand Install Update
      • On demand install launches a browser intent with the apk URL
      • The user must click the downloaded apk to install.
  7. If an update is forced, the user is notified of the required update.
    • A browser intent is fired to launch the Browser with the apk URL.
    • The user must click the downloaded apk to install.
    • The user is not allowed to open the app until the install is completed.

Implementing and testing this solution from an Android standpoint took about 2 weeks of spare time (read evenings and weekends) for myself. The server side component was handled by another team (ok, one person). Implementing this solution involved updating our SQLLite database, our ContentProvider, adding new menu items, creating some new AsyncTasks, updating all of our activities, etc. I consider this a significant effort. If you have multiple enterprise applications that need this same functionality, you’re going to have build time into your schedule. Some of these components could be built into a shareable library, however you’d still need to weave this into each specific application via resource descriptors, activities, etc. FYI, the patch file to support all of this was 1823 lines long.While this solution is fairly robust, an easy way out would be to provide a simple check to see if a version exists and to notify the user. This would require significantly less time to design, develop and test, but at what cost? When do you perform that check? When the user launches the app? What if the user spends a majority of their time off network and only launches when they have no connection? If you provide a manual check, you’re going to have to visit some of the requirements set out above and now you’re back to investing significant time into the SDLC.

In conclusion, you can provide this functionality inside of the application itself. You can make it as basic as possible to “just get by”, but it’s going to have its shortcomings. You could create a library to reduce development effort to integrate this into each application, but it’s still going to require time to weave it into the application and test. Why do this though when the Market is almost already there, it just needs some fine tuning? That or the Android OS needs to support enterprise deployment in a more robust manner. I still hold my belief that Android isn’t quite ready for the enterprise for this reason (among several others).

Advertisements

Actions

Information

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




%d bloggers like this: