Optimizing MobileFirst applications for use over slow networks

Optimizing MobileFirst applications for use over slow networks

If the MobileFirst applications are meant to run under limited network conditions, we can follow these guidelines to build the applications and improve performance.
The data transfer rates, in places where the Internet is accessed through GSM, GPRS, or EDGE, might be a few hundred of kilobits per second. The networks with such limited connectivity are considered as slow networks.
When mobile devices, running a MobileFirst application, access the server over a slow network, it is important to reduce the amount of data transfer between the device and the server. This reduction ensures faster interaction with the user. Even when the amount of data transfer is minimized, it is equally important to keep the user apprised of the estimated time to complete an operation over the network. Use the following guidelines in MobileFirst applications development to optimize the mobile user experience over slow networks.

Use compressed response

From IBM Worklight v6.0 on, it is possible for MobileFirst applications to request data in a compressed format in response to the invokeProcedure calls. Because the data is returned by the MobileFirst Server in JSON format, compressing the adapter responses greatly reduces the amount of data that is transferred. The time to complete a response is reduced, too.
The following code snippet demonstrates how to request a compressed response from the server in a hybrid application.
var invocationData = { 
  adapter : 'adapter-name',   procedure : 'procedure-name',   parameters : [],   compressResponse : true
}
WL.Client.invokeProcedure(invocationData, options);
Configure adapter timeout

By default, each invokeProcedure call that is made by the device times out after 30 seconds. If the invokeProcedure call expects a large amount of data from the adapter over a slow network, we must increase the timeout.
The following code snippet demonstrates how to set the adapter timeout to 60 seconds.
var invocationData = { 
  adapter : 'adapter-name',   procedure : 'procedure-name',   parameters : [],   compressResponse : true
}
var ONE_MINUTE = 60 * 1000; 
var options = {  timeout : ONE_MINUTE,   
  onSuccess : sucessCallback, 
  onFailure : failureCallback     
}; 
WL.Client.invokeProcedure(invocationData, options);
Response time from the adapter

Another factor that influences the invokeProcedure timeout on the device is the actual time that is taken by the adapter to respond. If the adapter takes a significant amount of time to fetch data from the back end, consider this factor in the timeout value set during the call to the procedure.
In general, make sure the following equation applies:
(invokeProcedure timeout) >= (Adapter response time) + (Transmission time over the network)

Adapt application behavior to timeout

Slow networks are often unpredictable in terms of the speed and reliability. To take this fact into account, build resilience to timeout within the applications. For example, the applications can try again a timed-out operation with a larger timeout value.
The following code snippet demonstrates a typical JSON response from the MobileFirst Server when a timeout occurs. This response can be accessed in the onFailure callback.
{
  "invocationContext" : null,   "errorCode" : "REQUEST_TIMEOUT",   "errorMsg" : "Request timed out for <REQUEST_URL>. Make sure the host address is available to the app (especially relevant for Android and iPhone apps)."
} 
Use of Application Center

The Application Center provides a mobile client used to download and update applications. Delivering application updates through the Application Center provides the devices with capabilities such as resumable downloads and automatic reload of broken downloads. These features are useful especially for the devices that install and update applications over slow networks.

Direct update consideration

Successful direct update of applications over slow networks depends on sustained reliability of the mobile network over a large period while the update is being downloaded. Frequent loss of signal, network congestion can lead to direct update failure. We must keep the application footprint as small as possible to minimize risks of direct update failure. IBM MobileFirst Platform Foundation sends a compressed version of the update file to the client to minimize data charges and to increase chances of a successful direct update over slow networks. When direct update fails over slow networks, the user must be advised to resume the direct update when a better network, such as WiFi, is available.
User is prompted with an error message when the direct update fails as a result of network troubles.

Turn on compression by default

MobileFirst Server provides the compress.response.threshold configuration property. The responses to an invokeProcedure call from a device that are above this threshold are automatically compressed by the server. This setting ensures that network performance is optimal even when a client application does not request compressed data, due either to ignorance or underestimation of the payload size. The default value of the compress.response.threshold property is 20480 bytes. See Miscellaneous Settings.

Parent topic: Optimizing MobileFirst applications