Debugging applications

improve this page | report issue

Overview

In this tutorial, various approaches to debugging (the web resources of) a MobileFirst application will be explored - before running the application in a device and and while running in a device. Debugging of MobileFirst adapters will be explored as well, and tools available to the developer's disposal in order to conduct the debugging effort.

The available debugging options are:

Debugging

Debugging is a process that consists of finding the cause of defects in the application code and UI.

  • MobileFirst applications consist of web-based resources and optional native code (such as Java, Objective-C and C#).
  • Native code can be debugged by using standard tools that are provided by the platform SDK, such as XCode, Android LogCat/ADB or Microsoft Visual Studio.

Debugging on a desktop browser

Modern browsers, such as Chrome, Firefox, Safari or Opera, provide an easy and convenient way to debug web apps.
As seen in the previous tutorials, during development you can preview applications in a desktop browser by using the MobileFirst Console.

missing_alt

There are many web tools for debugging on various desktop browsers, for example:

  • FireBug
  • Chrome Developer Tools
  • Internet Explorer Developer Tools
  • Dragonfly for Opera
  • Safari Web Inspector
missing_alt

In early application development stages these tools can be used to debug the application just like a regular website. It is not required to install them in a mobile device.
Changes to HTML and CSS can also be previewed in real time by modifying the values in the inspector.

missing_alt

Debugging with the Mobile Browser Simulator

The Mobile Browser Simulator can also be used to preview and debug MobileFirst applications.
To access it, click on the 'eye' icon beside an environment row in MobileFirst Console.

missing_alt

The Mobile Browser Simulator has several added values over Preview as Common Resources, for example:

  • Preview environment-specific resources
  • Emulate different devices and skins
  • Emulate some Cordova features such as access to sensors and other hardware
missing_alt

Debugging with iOS Remote Web Inspector

Starting in iOS 6, Apple introduced a remote web inspector for debugging web applications on iOS devices. In order to debug, make sure the device (or simulator) has “Private Browsing” turned off.

To enable Web Inspector on the device: Settings > Safari > Advanced > Web Inspector.
missing_alt

To start debugging, connect the iOS device to a Mac, or start the simulator. Safari 6.0 or higher is required.
In Safari, go to Preferences > Advanced, and select the Show Develop menu in menu bar checkbox.

missing_alt

Now in Safari, select Develop > [your device ID] > [your application HTML file].
The DOM can now be inspected. It is also possible to alter the CSS and run JavaScript commands, just like in the desktop inspector.

missing_alt

Debugging with Chrome Remote Web Inspector

With Google Chrome it is possible to remotely inspect web applications on Android devices.
This action requires Android 4.4 or later, Chrome 32 or later and IBM MobileFirst Platform Foundation V6.2.0 or later.

Additionally, in the AndroidManifest.xml file, targetSdkVersion = 19 or above is required.
In project.properties, target = 19 or above is required.

Start the application in the Android Emulator or a connected device. Then, in Chrome, enter the following URL: about:inspect and then press on "Inspect" for the relevant application. All the features of the Chrome Inspector can now be used to inspect the Android application.

missing_alt

Debugging with Weinre

Weinre stands for Web Inspector Remote.

Weinre is a debugger for web pages, like Firebug or other Web Inspectors, except that Weinre is designed to work remotely.
Weinre can be used to inspect and debug web resources such as HTML, JavaScript, CSS, and network traffic on mobile handsets.

The Weinre architecture includes the following components:
missing_alt

The Weinre debug server requires a node.js runtime.
Instructions to install Weinre can be found at: http://people.apache.org/~pmuellr/weinre/docs/latest/Installing.html

Debug server
When the Weinre server is installed, the following command will run it:
weinre --httpPort 8888 --boundHost -all-

This command starts a Weinre server on a default (changeable) port 8888.

Target
The Weinre server must be accessible from the device that will be used for debugging. To make it accessible, add the following code line to the web application:

<script src="http://a.b.c:8888/target/target-script-min.js"></script>

Where a.b.c is the hostname or IP of the Weinre server.

Client
Before you can start debugging, make sure that the application is open and loaded on the browser with this URL:

missing_alt

Debugging with IBM MobileFirst Logger

IBM MobileFirst Platform Foundation provides a WL.Logger object that can be used to print log messages to the log for the environment used.

Two of its methods are WL.Logger.debug() and WL.Logger.error().
These APIs are multi-platform. The output destination changes according to the platform on which that application runs on:

  • Developer console when it is running on a desktop browser
  • LogCat when it is running on Android device
  • Visual Studio Output when it is running on a Windows Phone 8 device and Windows 8 App
  • XCode Console when it is running on an iOS device

WL.Logger contains more methods.
More information is available in the IBM MobileFirst Platform Foundation user documentation topic for WL.Logger.

Testing the adapter procedures

It is possible to test adapter procedures by using MobileFirst Studio.
Testing a procedure is done by right-clicking an adapter folder and selecting Run As > Invoke MobileFirst Procedure.

missing_alt

After selecting to invoke a procedure, the adapter and procedure are selected, followed by optionally entering comma-separated parameters.

missing_alt

Adapter invocation result:

missing_alt

Debugging with WireShark

Wireshark is a network protocol analyzer that can be used to see what happens in the network.
Filtering is available to follow only what is required.

For more information, see http://www.wireshark.org/

missing_alt
Last modified on November 09, 2016