IBM MobileFirst Foundation provides two mechanisms to manage app versions and updates. Neither requiring you to write any additional code!
The first is app versioning; MobileFirst Foundation tracks each version of an app that you deploy, and gives you the ability govern or restrict access to specific platforms and versions. App versioning applies to all apps, native or hybrid, on any platform that MobileFirst Foundation supports. The second is Direct Update, which allows you to push new HTML/CSS/JavaScript (web) resources to a MobileFirst hybrid app. Direct Update only applies to hybrid apps, but it works for any platform that MobileFirst supports.
App Version Management
When you deploy an app to the MobileFirst Foundation server, the server will automatically track versions based on the version number specified in you application-descriptor.xml file.
When you load the MobileFirst Foundation Server Console, you’ll be able to view all of the deployed app platforms and versions.
The screenshot below shows a hybrid app deployed for both Android and iOS platforms. You would also be able to see the exact same version and platform information for native apps that leverage IBM MobileFirst Foundation.
You’ll notice in the MobileFirst console that next to each platform/version you can set the status for that version. This makes it possible to set notification messages for users on specific platforms and versions, or even restrict access to specific platforms and versions.
For example, look at the screenshot above… Version 1.0 on Android is active. Version 1.2 on iOS is active. Version 1.1 on iOS is notifying, and Version 1.0 on iOS is disabled.
There are 3 statuses that can be set for each platform and version combination.: Active, Active Notifying, and Access Disabled.
When you set the status of a platform/version, this status is only for that specific platform/version pair. This enables you to selectively notify users of specific versions, or even block access to specific versions if they are outdated and no longer supported.
“Active” means that the application is active. Services to this version will operate normally, and no messages will be presented to the user.
“Active Notifying” means that the application is active, services will continue to work, but a message will be presented to the user when the app becomes active, or when a service request is made to the MF server.
This can be used to send any text-based message to the app users. This could be a deprecation notice, service maintenance notice, or any other general notice.
Within the app, the user will see a message when the app becomes active, or when a request is made to the server. This message can be dismissed, and the app functionality is not impacted in any way.
“Access Disabled” means that access to the application is disabled. In this state, a notification message will be presented to the user, and access from the app version will be disabled. The user will also be presented with an “Upgrade” button, which will redirect the user to any URL, which presumably will be for an updated version of the app.
In this state, the app will not be granted access to the MobileFirst/Worklight server. So, if your app requests data from a data adapter, all requests to the adapter from this platform/version will be blocked. If your app initialization code is inside of the Worklight client’s connect:onSuccess handler, then this can prevent your app from loading at all.
Again, When you set the status of a platform/version, this status is only for that specific platform/version pair.
You can learn more about managing applications through the MobileFirst/Worklight Console using the Administering Worklight applications with Worklight Console online documentation.
Direct Update
MobileFirst hybrid applications leverage Apache Cordova plus MF-specific APIs as a foundation to deliver hybrid apps. Apache Cordova enables developers to build natively-installed cross platform apps using web technologies.
Direct Update is a feature for MobileFirst hybrid apps, which enables you to push updated app content (HTML, CSS, & JavaScript) without the user having to deploy a new version of the app through the app store.
Direct Update is considered an additional security feature b/c it enforces users to use the latest version of the application code. However, when an app uses Direct Update, it *only* updates the web resources. No native changes or version # changes will be applied. However, it should not be abused. In particular this will bypass the Apple’s app store approval process. You should not overhaul the entire UI and break Apple’s Human Interaction Guidelines, otherwise you could be kicked out of the app store.
By default, the update’s user experience is a modal overlay that shows download and installation progress. The updater’s UX can be configured to use silent updates that do not block the user’s experience, can be a completely custom user experience, or can be disabled altogether. Updates can also be paused or resumed using the JavaScript API so that it does not block the user from performing a critical task, however this would require a custom UI – the default UI does not enable pause/resume.
Updates in the current version of Worklight (6.2) are complete updates containing the entire application (www) code, however MobileFirst Foundation 6.3 (coming this month) will have a Differential Direct Update feature that includes only the changed files. More detail will be posted once this is available.
Direct Update can also be disabled if you don’t want your hybrid apps to update automatically.
For more information on Direct Update, be sure to check out these additional resources:
Additional note: If you’re wondering by I interchange MobileFirst and Worklight in this post, it’s because Worklight is now MobileFirst Platform Foundation.