+

Search Tips   |   Advanced Search

Guidelines for testing hybrid MobileFirst applications

When we test hybrid applications, take into consideration several scenarios in which unexpected behaviors can manifest themselves.


Feature-specific scenarios

Certain features of a MobileFirst application, if not handled correctly, can cause unexpected behaviors. These behaviors, in turn, create unpleasant user experience. The features are:

While the approach described in the coming sections relates to specific features, IBM recommends you embrace the methodology for all aspects of the app. In so doing, we can verify the integrity of the app over the course of its lifecycle, as well as during runtime.

Remote Disable

Whenever an application is started, returns to the foreground, or sends an adapter request to the MobileFirst Server, a check for the Remote Disable state is first performed by the MobileFirst client-side framework against the MobileFirst Server.

If the MobileFirst Server determines that a request from an application must be blocked, a dialog is displayed to the user, by default. This dialog presents an OK button that upon tapping, returns the user to the application. Any further attempt to perform an operation that requires access to the server again displays the dialog. A possible scenario where this can cause annoying user experience is when the application performs an adapter request at the same time that the application is started, or returns to the foreground, expecting to display the result of the request. If access to the server is blocked, no response is received by the application, possibly leaving the screen blank and preventing the user from using the application.

The problem can be remedied either by avoiding dead-end scenarios such as the one just described, or, if required, by creating a custom Remote Disable behavior. See this blog post.

Adapter requests

Most MobileFirst applications use adapters to retrieve data from back-end services. Using an adapter can cause connectivity errors such as timeouts that are caused by slow networks. To prevent such scenarios, take the following actions:

  • Define a larger timeout value for the WL.Client.invokeProcedure() method.

  • Use the onSuccess option to do data processing.

  • Use the onFailure option to provide appropriate error messages.

Sometimes, even though a response was provided by the back end, processing may still fail. For more information on handling adapter invocation responses, see this blog post.

Direct Update

There are two implementations of Direct Update:

  • Default: The MobileFirst framework is responsible and controls the Direct Update lifecycle.

  • Custom: The developer is responsible and controls the Direct Update lifecycle.

Whether you choose the default or custom implementation, it is important to test that updates to be deployed in future to the MobileFirst Server do not break the application. In addition, when implementing a custom Direct Update, the developer is responsible to verify the following outcomes:

  • The way in which the update is presented to the end user

  • The success condition of the update

  • The failure condition of the update

See Customize the direct update interface and process.

Authentication flow

Authentication can be performed in various ways, from form-based and custom-based authentication through to device provisioning. For all types of authentication, we must verify the following:

  • That the authentication form takes failure, timeout, and logout conditions properly into account and handles them.

  • When and how failure, timeout, and logout conditions should be applied.

  • That the user does not experience a malformed or non-functional UI on failure, timeout, or logout.


Network-specific scenarios

Most applications require a reliable Internet connection. This dependency makes apps prone to errors such as timeouts that are caused by slow networks or to complete breakdowns in connectivity. The issue can manifest itself at some point during the application runtime: when connecting to the MobileFirst Server, or when invoking adapters. To solve this problem, define a larger timeout value for any of the following:


General error condition scenarios

In general, by implementing proper error conditions in the logic of the app, you protect it from crashes and other unexpected behaviors.


Parent topic: Develop hybrid applications