27 June 2014
PDF (1028 KB)
author photo

Chris Brealey

Senior Technical Staff Member, IBM Rational, mobile solutions

Chris on developerWorks
@cbrealey on Twitter
Follow me on G+

Sign up for IBM Bluemix
This cloud platform is stocked with free services, runtimes, and infrastructure to help you quickly build and deploy your next mobile or web application.

In this new world of mobile, the reputation and health of a business can blossom or crumble on the quality of its mobile channel. As people on the go, we expect mobile apps to be slick, quick, and easy to use; to have the features we need; to function properly; to be stable; to be secure; to be elegant. The business needs an engaging mobile presence on as many platforms, devices, form factors, and carrier networks, as possible. In this article learn how IBM® Mobile Quality Assurance helps businesses deliver higher-quality mobile apps sooner, and helps businesses detect and respond to issues with their mobile apps faster.

WATCH:Webcast: Continuous Quality for Mobile Apps—Reduce Your Time-to-Feedback

I don't know about you, but with the exception of writing "Hello World," I hardly ever get my code right the first time.

Despite best efforts, bugs happen. Even if I am lucky and skilled enough to write a functionally perfect app, there is no guarantee that people will like it. Users might dislike my app because it lacks elegance, or doesn't perform well, or feels insecure, or doesn't have a feature they were expecting. In the new world of mobile, the reputation and health of a business can blossom or crumble on the quality of its mobile channel. If I'm building a new mobile app, how do I make sure it will give folks a great first impression? If I already have a mobile app that suffers from poor reviews, how do I get to the root of the problem and deliver "version.awesome"?

To answer these questions, I thought it would be fun to write an imperfect mobile app, and show how a new service called IBM Mobile Quality Assurance, or MQA for short, helps to discover those imperfections quickly.

WATCH:Short video of MQA in action

About the app


To keep my app simple but not too simple, I started with Scott Rich's article on how to Build a Twitter sentiment analysis application with Node.js, complete with a pointer to his web application running on the Bluemix. Maybe I could add a mobile face to Scott's application. The app would let a user enter a phrase, and find out how people are feeling about the phrase on Twitter.

I decided to build an Android mobile app. This was simply a personal preference, since Android apps are written in Java™ (which I know), and the Android development tools are based on Eclipse (which I also know).

The story is pretty straightforward. As shown in the diagram below:

  1. The user enters a phrase into the app.
  2. This action calls Scott's application to get and show the prevailing sentiment about the phrase.
  3. With the help of the MQA SDK library, the app also calls MQA when the user reports a bug or when the app crashes.
  4. Bug reports, crash reports, and other valuable data are presented in MQA's dashboard in the browser.
  5. The user monitors the dashboard.

Workflow: user to SDK, to MQA, and back to browser

Want to try this yourself? What do you need?


That depends on the mobile platform. I chose Android, so you will find lots of Android references in this article. If you're into Apple iOS and Objective-C, or if you would rather build a Microsoft Windows Phone app with Microsoft Visual Studio, go for it. The essence of this article applies to those platforms too, although the tools and programming languages will differ.

If you go with Android, about the only thing you need is a development workstation with your favorite operating system and a Java Run-time Environment (JRE). The Android SDK relies on some classes found specifically in the Oracle Java platform. You can try a different JRE, but the Android SDK might be unable to build your app. If you don't already have a JRE, you can get one at http://java.com.

Because you are developing an Android app, you will spend much of your time within the Android Development Tools (ADT). The first step is to download the ADT via this article's appendix and set it up, unless you already have it.

Part 1. Create and run a basic Android app


A simple Android app is easy to come by. Just create a new Android project! The Android IDE does a nice job of giving you a project with a Hello World app that's ready to run.

Create a project

  1. From the ADT main menu, select File > New > Android Application Project to open the New Android Application wizard, as shown in the figure below.
  2. Enter an Application Name (for example, Analyzer). The wizard provides a reasonable Project Name (for example, Analyzer) and Package Name (for example, com.example.analyzer).

New Android Application window

Click to see larger image

  1. Select Next >, then Next >, then Next >, then Next >, then Finish. That's right. You can simply Next your way through the rest of the wizard and finish it, accepting all defaults as you go.
  2. The wizard closes after a few seconds, leaving you with a new Analyzer project in the ADT Package Explorer, as shown in the figure below. It also opens a couple of editor tabs for two of the most important files in an Android project: activity_main.xml and MainActivity.java. More on those later.

Analyzer project with two editor tabs on two files

Click to see larger image

Let ‘er rip

  1. In the emulator, click, hold, and drag your virtual device's lock icon to the right and drop it on top of the unlock symbol.
  2. In the ADT, right-click the Analyzer project (the top-most folder in the Package Explorer) and select Run As > Android Application.
  3. It might take several seconds to a few minutes for the app to open the first time in the emulator.

    While you are waiting, from the ADT main menu, select Window > Show View > Other..., then select Android > LogCat, then select OK. The LogCat view is where log messages from the ADT, the emulator, and your apps are displayed. It's a good view to keep around for debugging purposes.
  4. Eventually the app opens in the emulator, as shown in the figure below. If there is no sign of it after waiting a few minutes, the ADT might have timed out. Try Run As > Android Application again. Patience and a sufficiently large timeout value are a virtue. Generally speaking, once the emulator is warmed up and has loaded your app the first time, subsequent Run As actions tend to finish within seconds, instead of minutes.

Hello world message on Analyzer

Part 2. Now for some real code


"Hello World" is all well and good as a rite of passage, but it's time for some real code. There are three PNG image files to place into the folder analyzer/res/drawable-ldpi/, and four files in the Analyzer project that you need to edit:

  • strings.xml Information in folder analyzer/res/values/
  • activity_main.xml Information in folder analyzer/res/layout/
  • MainActivity.java Information in folder analyzer/src/com/example/analyzer/
  • AndroidManifest.xml Information in folder analyzer/

PNG image files


The app uses images to represent sentiment: excited, angry, or content (neutral).

  1. Save these three image files to a temporary location.
  2. In the Package Explorer, expand Analyzer > res.
  3. Right-click on folder drawable-ldpi and select Import... > General > File System.
  4. Browse to the folder containing the downloaded image files, select the angry.png, content.png, and excited.png files on the right size of the wizard, then select Finish.

angry imagecontent imageexcited image



This file is where the human readable stuff lives. Let's add some strings.

  1. In the ADT's Package Explorer view, expand folder Analyzer > res > values, then double-click on the file strings.xml to open it in the Android Resources editor.
  2. Most editors in the ADT offer graphical and source code views. This one is no exception. At the bottom you see two tabs: resources for graphical editing and strings.xml for source code editing. Click on the strings.xml tab at the bottom of the editor.

Note: This exercise sticks to source code editing. It includes lots of code snippets, and the easiest way to grab them is by copy and paste.

  1. You see some XML, including three (give or take) <string> elements. Replace the entire contents of the file with the contents of this strings.xml file. Did you spot the spelling mistake lurking inside the fourth string? It's supposed to be there. Remember – this is not a perfect app – so don't change that string!
  2. Select File > Save from the main menu, or press Ctrl+S to save the file.
  3. Just to make sure you are on track, click on the Problems view in the lower area of the ADT as shown in the following diagram, and confirm there are no errors present.

Problems view shows no problems.

  1. Right-click on the Analyzer project in the Package Explorer, and select Run As > Android Application. After a few moments, the app opens in the emulator as shown in the following diagram, just with different text than at the end of Part 1.

Message: What phrase do you want to analyze?



This file is where you specify and lay out the controls that make up the user interface of the app. Use the following steps to add some controls.

  1. In the Package Explorer, expand Analyzer > res > layout, then double-click on the file activity_main.xml to open it in the layout editor.
  2. This editor also has graphical and source views. The Graphical Layout tab is very useful for designing the look and feel of an app. For this exercise however, let's get straight to the source of the matter. Click on the activity_main.xml tab at the bottom of the editor.
  3. You see a dozen or so lines of XML, including a lonely <TextView> element, which takes care of rendering the "Hello World!" text in the app's UI. Replace the entire contents of the file with the contents of this activity_main.xml file.
  4. Select File > Save from the main menu or press Ctrl+S to save the file.
  5. Check the Problems view to make sure there are no errors.
  6. Run the Analyzer app again. This time you see more substantial changes to the app's user interface – still fairly simple, and in one spot, downright silly. As shown in the following diagram, the app shows some text, followed by an entry field and an Analyze button. At the bottom of the app is a Report a bug button and an Induce a crash button (that's the silly bit). Play with the controls all you like. They won't do anything... yet!

New buttons Report a bug and Induce a crash



You need some code to bring those controls to life. MainActivity.java is where it goes.

  1. In the Package Explorer, expand Analyzer > src > com.example.analyzer, then double-click on the file MainActivity.java to open it in the Java editor.
  2. The implementation generated by the ADT is pretty simple. To beef it up some, replace the entire contents of the file with the contents of this MainActivity.java file.
  3. Select File > Save from the main menu or press Ctrl+S to save the file.
  4. Check the Problems view to make sure there are still no errors.
  5. Run the Analyzer app, as shown in the following diagram. After it opens in the emulator, click Analyze. You should get a message within the app that tells you that something nasty happened. This proves two things. First, the code is working. Second, you are not finished yet.

Message: 'Something nasty happened'



So if the code is right, what went wrong? Have a look at the LogCat view, and, as shown in the following figure, you see a security exception about a missing android.permission.ACCESS_NETWORK_STATE.

Exception occurred message in the LogCat view

This error reveals a key feature of the Android platform. It won't do anything without permission. The Android Manifest is where the operating characteristics and constraints of the app reside. You need to add a couple of XML elements to this file that tell the Android platform to permit the app to use the network.

  1. In the Package Explorer, expand the Analyzer project, then double-click on the file AndroidManifest.xml to open it in the manifest editor.
  2. Click on the AndroidManifest.xml tab at the bottom of the editor to flip it to source mode. Replace the entire contents of the file by the contents of this AndroidManifest.xml file. The difference is the addition of two <uses-permission> elements, necessary to permit the app to determine if a network connection is active, and to use it.
  3. Check the Problems view. There should be no errors, although you might see a warning about the <uses-sdk> element not targeting the latest version of Android. This warning is OK, but if it's really bothering you, try changing the value of the android:targetSdkVersion property from 18 to match the value of the API level of your AVD in the Android Virtual Device Manager.
  4. The Analyzer app should be ready to go. Run it.
  5. In the emulator, enter a phrase, and then tap Analyze. The app asks Scott's application to start monitoring for tweets about the subject phrase. The app will wait a couple of seconds, then call the application again to get some early results, and show them to you. If you tap Analyze again, you will get even more results. If you change the phrase and tap Analyze, this will reset Scott's application to start monitoring the new phrase.

Pick a hot topic, or you might not get any tweets. It was the middle of the 2014 Winter Olympics when I wrote this little app, so I entered Olympics, and the tweets were coming in at around 180 per minute!

Results from analyzing phrase 'Olympics'

Part 3. Register with Mobile Quality Assurance (MQA)


You probably noticed that our app has a couple of bugs. There is at least one spelling mistake inside strings.xml that makes the app look shoddy, and there is a crash just waiting to happen should the user tap Induce a crash. These are completely contrived of course, but pretend you didn't know they were there. How do you find them, ideally before your users do? MQA to the rescue!

MQA is a cloud-hosted, multi-tenant service designed to collect and present information about the quality of mobile apps. For MQA to give you insight into the quality of your app, it needs to know about two things: you, and your app.

WATCH:this tutorial video to get a feel for the kinds of things the rest of this exercise gets into.

Register yourself

  1. Point your browser to http://ibm.biz/mobilequalitycloud, then click TRY IT.
  2. If this is your first time at MQA, click Sign up to register yourself. After you finish the Sign up form, check your incoming email for a memo from Quality4Mobile (no-reply@quality4mobile.com). Inside the memo is a link you need to follow to complete the registration process. Follow that link.
  3. Now that you are registered, return to the MQA dashboard and log in.

Register your app

  1. On the MQA home page, click Add new app.
  2. Under Choose a platform, select Android.
  3. Under Name your application, enter Analyzer. Do not activate user sentiment integration. This is a very cool feature of MQA that we will explore in a later article.
  4. Don't invite any collaborators. For this exercise, you are playing the roles of developer and tester.
  5. Click Register App. As shown in the following figure, the overview page for your app opens. Because it is a new app, you will not see any bug reports, crash reports, sessions or other statistics yet. You will see a couple of crucial bits of information: a link to where you can download the MQA SDK and the application key that uniquely identifies your app.

Overview page for application

Click to see larger image

Part 4. Set up the MQA SDK


This part and the next part are a condensed version of a tutorial found in the MQA online documentation.

Download the SDK

  1. From the overview page, click Download the SDK, then click Android SDK.
  2. Two libraries are available: a pre-production library for use by apps under development and testing, and a production library for use by apps deployed to real users. You can read about the differences between the libraries on the Android SDK web page. This exercise is all about developing and testing a mobile app, in-house. Click Pre-Production Library and save the ZIP file to a temporary location.
  3. Extract the contents of the ZIP file to a temporary location.

Add the SDK to your ADT workspace

  1. As shown in the following figure, from the ADT main menu, select File > Import > Android > Existing Android Code Into Workspace.
  2. Browse to the top folder of the extracted ZIP file.
  3. Check the option Copy projects into workspace.
  4. Click Finish.

Import Projects: directory and project to import

Add the SDK to your Analyzer project


Link the MQA SDK project as a dependency into the Analyzer project. Otherwise, the app is not able to call any MQA API.

  1. Right-click on the Analyzer project and select Properties.
  2. As shown in the following figure, on the left side of the Properties for Analyzer dialog, select Android.
  3. Under Library, click Add, and then choose the library project you just imported.

Properties for Analyzer, library project imported

Click to see larger image

Part 5. Add a dash of MQA code


Remember those four files you edited? You need to make a few more changes to two of them.


  1. In the Package Explorer, expand Analyzer, and then open AndroidManifest.xml in the editor.
  2. The MQA SDK isn't just an API. It also contributes user interface goodies to an app, such as the activity and its views for filing a bug report. Add this new <activity> element inside the <application> element:
  1. The MQA SDK needs permission to access context information from the device. Add these two <uses-permission> elements to the file:
<uses-permission android:name="android.permission.READ_PHONE_STATE"/>
<uses-permission android:name="android.permission.GET_TASKS"/>

The MQA SDK also needs android.permission.INTERNET, but you added that earlier.

  1. Verify that the complete AndroidManifest.xml file looks like this AndroidManifest.xml file, then select File > Save or press Ctrl+S to save it.



There really isn't much code required to put MQA to work.

  1. Add some code to the end of the onCreate(Bundle) method to configure and initialize the SDK. The method should look like this, except for the [PUT YOUR KEY HERE] string, which you should replace with the key you got when you registered your app back in Part 3.
protected void onCreate(Bundle savedInstanceState) {
	Configuration configuration = new Configuration.Builder(this)
		.withAPIKey("[PUT YOUR KEY HERE]")
	Apphance.startNewSession(MainActivity.this, configuration);
  1. Implement the onStart() and onStop() framework methods so that the SDK gets a tap on the shoulder whenever your app's activity starts up or shuts down.
protected void onStart() {

protected void onStop() {
  1. In the reportBug(View) method, add a call to Apphance.problem().
public void reportBug(View view) {
	Log.i(TAG, "In reportBug(View)");
  1. Verify that the complete MainActivity.java file looks like this MainActivity.java file, then select File > Save or press Ctrl+S to save it.

Part 6. Run the app


Ok. Enough of this coding business (not that we added all that much.) The vast majority of the app is still business logic, with just a few lines of boilerplate XML and a few lines of Java to hook the power of MQA into the app. Let's try it out.

In this part of the exercise, you are changing roles from developer to tester.

Run it!

  1. Run the app, and then keep an eye on the emulator.
  2. The first new thing you notice as the app starts up is the message Contacting MQA server. Please wait.... Then you will see a dialog inviting you to select a name – either your identity in MQA, or Anonymous. Here's the deal. All sessions, crashes, and bugs reported to MQA from the app, identify the originator (the tester). This is your opportunity to decide if you want to be identified by name or to remain anonymous. In my case, I picked me, since I am the sole developer and tester of the app, and I have nothing to hide from myself.

Make your selection. As shown in the following figure, the message dialog closes, and your app opens.

List of testers to choose from

Shake it!


Take a look at the following figure. A typo, front and center in the entry field – how unprofessional. To submit a bug report from a real device, you can simply give the device a shake to activate the bug reporting view. The call to withReportOnShakeEnabled(true) from inside the onCreate(Bundle) method enables this. Unfortunately, you cannot shake the stock Android emulator, so instead, the app includes a Report a bug button and a call to Apphance.problem() to open the bug reporting view.

  1. Tap Report a bug.

    As shown in the following figure, the Screenshot Editor view opens, primed with a snapshot of the view that was showing when you tapped the button (or shook the device). The pen tool, lower left, is used to draw freehand lines on top of the screen shot. The spray can tool, also lower left, is used to mask areas of the screen capture, such as might contain sensitive information you would rather not have transmitted back to MQA. The eraser tool, lower right, erases all your freehand lines and digital spray paint, returning the screen capture to its original state.
  2. Tap the pen tool if it isn't already selected, then use your mouse (or your finger on a real device) to draw a circle around the misspelled word.

Screenshot Editor with pen tool and spray can

  1. Tap the checkmark icon, upper right.

    As shown in the following figure, the Report a Problem view opens with plenty of room to explain the problem, make a suggestion, or express your opinion of the skills of the developer in the nicest possible terms.
  2. Enter a problem description.

Report a problem. Send screen captures and notes.

  1. Tap the arrow icon, upper right, to submit the bug report.

The bug reporting dialog closes, and control returns to the app.

Crash it!


Most apps don't offer a button that makes it crash, but this app does. How ridiculous is that? As shown in the following figure, tap Induce a crash to force the app to crash.

Message: Analyzer has stopped

Part 7. Visit the MQA dashboard to see what's up


You just reported a bug and crashed the app. Time to change roles. Take off your tester hat and put on your developer hat, and have a look at the MQA dashboard.

  1. Return to the MQA dashboard in your browser.
  2. From the MQA Home page, under Your apps, click Analyzer.
  3. Provided you copied your app key accurately into MainActivity.java, you find that the message You are ready to start using MQA... is long gone from the app overview page. As shown in the following figure, if you scroll down a little, you see evidence of both the bug report you filed and the crash you triggered just moments ago.

List of bugs, crashes, and sessions

Click to see larger image

  1. Click the outer frame of the bug report to be taken to a web page with detailed information about the session from which the bug report was filed, including the duration of the session, the user who filed the report, the version of the app, details about the Android SDK, network status, battery status, screen size and orientation, and more.
  2. Click the browser's Back button until you return to the app overview page.
  3. Click anywhere in the crash summary to be taken to a web page with detailed information about the session that crashed, including the stack trace of the crash.

What's cool about this?


As a tester, if I see something amiss with the app, all I have to do is shake the device, highlight the issue, tap in some text, and submit the problem – in seconds, all from within the app wherever I may be. I don't have to seek out a web browser, log in to a bug reporting system, and spend time manually entering as much detail as I can remember about the problem. If the app crashes, I can rest assured that a crash report will be delivered automatically to the MQA service and directly into the hands of the development team.

As a developer, the MQA dashboard gives me direct, real-time insight into bugs and crashes as they happen. Each bug and crash report is packed to the rafters with screen shots, stack traces, session details and context information about the device, app, and user – everything I need to understand and resolve the problem, quickly, and accurately.

Where do we go from here?


In many ways this article is just a teaser, showing a couple of the key features of MQA and how easy it is to tap into them. There are lots of nifty ideas and capabilities of MQA that we haven't explored here. Stay tuned for articles on some of these topics, or do some exploring on your own:

  1. Add MQA to an iOS app or a Windows Phone app.


READ:MQA SDK for Windows Phone

  1. Send logging events to MQA.

MainActivity.java calls the Android SDK's Log API so that log events flow back to the Android ADT. MQA also supports logging so that log events also display in the MQA dashboard. All you need to do is replace import android.util.Log; by import com.apphance.android.Log; in MainActivity.java.

  1. Use over-the-air distribution.

With MQA you can upload and distribute Android (.apk) or iOS (.ipa) mobile app builds directly to the test team, adding efficiency and predictability to the development and test hand-off.

READ:Build distribution

  1. Tap into review feedback on the app stores.

You can see how MQA collects quality data directly from an app. It can also analyze comments and ratings in the public app stores and provide insight into user sentiment about your app. This article skips this feature back in Part 3 under Register your app, but you can turn it on any time. From the main menu of the Analyzer app's overview page in the MQA dashboard, select Management > User Sentiment, and then follow your nose. The Analyzer app isn't published, so you will have to pick some other app in the app stores as a source of sentiment information. But that's fine for demonstration purposes.

READ:User sentiment

  1. Integrate with IBM® Rational Team Concert™.

You can set up MQA to automatically open work items in a Rational Team Concert project in response to incoming bug reports and crash reports. The Rational Team Concert project must be reachable on the network from the MQA public cloud service. DevOps Services (JazzHub) projects are perfect for this capability.

READ:Rational Team Concert integration

WATCH:How to create work item reports in Rational Team Concert

  1. Go into production.

Not with this app, of course, but maybe you have a real app that you plan to ship into production, or that you already have in production. You can swap the production SDK library in place of the pre-production SDK library as you build and deliver your app into production. With the production library in place, you can monitor crashes and gather in-app feedback directly from the field – all to help detect and resolve issues before people start flaming your app on the app stores.

READ:Differences between the pre-production and production libraries on the Android SDK web page

  1. Oh... and don't forget to fix that spelling mistake and that divide-by-zero error!

About my setup


Here are the operating system, JRE and ADT versions I used:

  • Operating system: Microsoft Windows 7 Professional Service Pack 1
  • JRE: 32 bit, Java full version "1.7.0_51-b13"
  • ADT: 32 bit, build v22.3.0-887826



Thanks to Scott Rich for adding a couple of REST calls to his simple sentiment analysis Node.js application. Thanks to Leigh Williamson for recording the two excellent MQA videos referenced by this article.

BLUEMIX SERVICE USED IN THIS TUTORIAL:The Mobile Quality Assurance service enables mobile app testing, user validation, and streamlined quality feedback with sentiment analysis, over-the-air build distribution, automated crash reporting, in-app bug reporting, and user feedback.

Add a comment

Note: HTML elements are not supported within comments.

1000 characters left

developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Zone=Mobile development, Rational, Cloud computing
ArticleTitle=Build a mobile app that isn't perfect