For up-to-date product documentation, see the IBM MobileFirst Foundation Developer Center.

Update Cordova client apps directly

With direct updates, you deliver updated web resources directly to deployed client applications.

Subject to the terms and conditions of the target platform, organizations are not required to upload new app versions to the app store or market. By using the Direct Update feature, we can quickly update application web resources (HTML, JavaScript, and CSS) without going through the vendor (Apple/Google) app store review process.

Direct Update is activated automatically when web resources are deployed in the MobileFirst Server. Once activated, it will be enforced on every request to a protected resource. When we use the Direct Update feature and the web resources checksum feature is enabled, a new checksum base is established with each Direct Update.

Direct Update is not intended for updating native code.

Supported platforms

Direct Update is available only for iOS and Android Cordova apps.

Prerequisites

If the MobileFirst Server was upgraded by using a fix pack, it continues to serve direct updates properly. However, if a recently built Direct Update archive (.zip file) is uploaded, it can halt updates to older clients. The reason is that the archive contains the version of the cordova-plugin-mfp plug-in. Before it serves that archive to a mobile client, the server compares the client version with the plug-in version. If both versions are close enough (meaning that the three most significant digits are identical), Direct Update occurs normally. Otherwise, MobileFirst Server silently skips the update. One solution for the version mismatch is to download the cordova-plugin-mfp with the same version as the one in your original Cordova project and regenerate the Direct Update archive.

Incremental and full Direct Update

Client applications built on IBM MobileFirst™ Platform Foundation V8.0.0:

• Receive an incremental update if the web resources of the application are only one build behind those in the application that is now being deployed. Only the web resources that were changed since the last deployment are downloaded and updated.
• Receive a full update if the web resources of the application are more than one build behind those in the application that is now being deployed.

Secure and non-secure Direct Update

For secure Direct Update to work, deploy a user-defined keystore file in MobileFirst Server and include a copy of the matching public key in the client application. If the client is not configured with a public key, MobileFirst Server uses the default server keystore to sign Direct Update but does not enforce signature matching.

If secure Direct Update was enabled and the archive signature was compromised, the client halts the update. Failures such as these are reported in the server logs.

Note: Failures such as these might also prevent correct adapter invocation.

For more information about implementing secure Direct Update, see Implementing secure Direct Update on the client side.

Direct Update in development, testing, and production

For development and testing purposes, developers typically use Direct Update by simply uploading an archive to the development server. While this process is easy to implement, it is not very secure. For this phase, an internal RSA key pair that is extracted from an embedded MobileFirst self-signed certificate is used.

For the phases of live production or even pre-production testing, however, it is strongly recommended to implement secure Direct Update before you publish your application to the app store. Secure Direct Update requires an RSA key pair that is extracted from a real CA signed server certificate.

To implement secure Direct Update, deploy a user-defined keystore to the MobileFirst Server and copy the matching public key to the client application. For more information about implementing secure Direct Update, see Implementing secure Direct Update on the client side.

Note: Take care that you do not modify the keystore configuration after the application was published, updates that are downloaded can no longer be authenticated without reconfiguring the application with a new public key and republishing the application. Without performing these two steps, Direct Update fails on the client.

For more information, see The Direct Update lifecycle.

Direct Update data transfer rates

At optimal conditions, a single MobileFirst Server can push data to clients at the rate of 250 MB per second. If higher rates are required, consider a cluster or a CDN service.

For more information, see Serving Direct Update requests from a CDN.

• The Direct Update lifecycle
  Package and upload updated web resources to the MobileFirst Server. Deployed client Cordova apps can then download them with Direct Update.
• Create and deploying updated web resources to MobileFirst Server
  To make modified web resources available to deployed client Cordova applications, you package and upload them as an archive (.zip file) to the MobileFirst Server.
• Implementing secure Direct Update on the client side
  We can configure client applications to validate the authenticity of a Direct Update package that is downloaded from the MobileFirst Server or CDN.
• Default Direct Update user interface
  Learn about the default user interface of the Direct Update feature.
• Serving Direct Update requests from a CDN
  We can configure Direct Update requests to be served from a CDN (content delivery network) instead of from the MobileFirst Server.
• Customizing the Direct Update user interface and process
  We can change the default user interface for the Direct Update dialog boxes and the messages that are displayed to the user.

Parent topic: Develop applications