Techniques for rapid mobile solution development

A progressive fulfillment approach for small design and development teams

Enterprise mobile users' data access and sharing needs aren't being met by conventional content-management systems and file systems. Fortunately, quick implementation of a multidevice content-access solution is well within reach — even for small in-house design and development teams — via an efficient development process that leverages reusable technologies. Find out how the IBM CIO Lab Mobile Innovation team rapidly piloted an internal solution that enhances users' productivity by giving them easy, flexible file sharing across all their approved platforms.


Tom Cook, Senior Technical Staff Member, IBM

Thomas Cook is a Senior Technical Staff Member at IBM responsible for leading teams of designers and developers in creating innovative mobile solutions. His work at IBM has included mobile solutions, embedded systems, game systems, virtual worlds, and operating systems.

Charisse Lu, Software Engineer, IBM

Charisse Lu has been working in web technologies and 3D virtual spaces and — most recently — as a technical team leader in the IBM CIO Lab Mobile Innovation area creating mobile solutions for IBM employees.

John Reddin, Software Engineer, IBM

John Reddin is a Software Engineer who has been working with IBM since the summer of 2009. He joined IBM as an Extreme Blue intern, subsequently worked on IBM Connections, and is now with the CIO office on mobile innovations. John studied computer science at Trinity College Dublin. His main interests are in scalable software architectures, mobile development, and computational music, an area in which he has previously published.

Emil Varga, Software Engineer, IBM

Emil Varga is a Software Engineer in IBM Dublin since 2008. He worked in the Lotus Connections Wikis team on Lotus Connections 2.5 and 3.0 before joining the CIO Mobile Innovations Lab at the beginning of 2012. He completed his MSc and BSc degree in Computer Science and Engineering at the University of Belgrade, Serbia. He loves machine learning, Linux, Web development, and functional programming languages.

15 May 2012

Also available in Chinese Russian Japanese Spanish

The CIO Lab Mobile Innovation team at IBM develops internal solutions to help IBM employees be more productive and secure using their mobile devices. In late 2010, employees were having difficulty sharing files across their laptops, mobile phones, and tablets. Access to classic content-management systems or shared file systems from mobile devices was limited and cumbersome. Without a full complement of plug-ins, certain files would not render or function when transferred. Also, files were not easily portable between desktop and mobile devices.

Our team needed to give employees a portable solution for accessing IBM internal content via approved devices. We decided to develop a pilot solution that would act as a window into their full data and would also provide a small cache of transportable data. The transportable data would be morphed into compatible formats to help users better consume content on various platforms. We called the project MyMobileHub. With only a small team and a few months, we needed to show a proof of concept with enablement across Android, BlackBerry, and iOS platforms. And a few months after that, we would need a functional native pilot.

Many of the rapid-development concepts we used in the pilot and discuss in this article are well known in the mobile-development space. Take a look at how we put them together to develop a multi-device, end-to-end internal solution, and you can get an idea of how quickly you can do the same for your next mobile pilot or project.

Planning a rapid-development pilot

Innovation pilots are generally an iterative process: quickly develop a usable solution and share it with a set of close colleagues and early adopters. Then expand functionality along with the user base, taking comments and suggestions as navigation aids. This is common protocol for exploring a new solution.

For a successful pilot in the rapidly evolving mobile arena, we needed a decidedly different approach to development. We explored a number of reusable technologies that could help us. We chose a combination of open source technologies and internal IBM tools that fit the criteria of rapid development, cross-platform support, and cutting-edge capabilities.

On the server side, we chose the Play framework, a RESTful stateless Java framework based on the Model-View-Controller (MVC) concepts of Ruby on Rails. For client-side development, we chose PhoneGap, Dojo, and Dojo Mobile for a consistent look-and-feel and user experience across all clients. (See Resources below for links.)

Because the small cache of files that we planned to morph would need to be grouped together, we decided to use a simple database instead of a file system. We selected Apache CouchDB, a schemaless, document-oriented noSQL database that supports document storage with simple and quick views based on MapReduce.

CouchDB and Play work well together and enabled us to move quickly. We used Apache ActiveMQ to manage the various messages and tasks that comprise the document-conversion pipeline. Finally, an Apache HTTP Server front end gave us some additional controls and load balancing. Again, in this pilot, we were exploring the viability of the solution as well as gaining an understanding of the user requirements and usage patterns. The key components, concepts, and designs that we may want to reuse are easily moved to other platforms when ready for production.

To keep current with the ever-expanding set of mobile devices, we leveraged an internal tool to help us identify mobile-device specifications from the WURFL project (see Resources for a link), a repository where information such as smartphone functionality and screen size is readily available. The tool helped us easily determine how to best display the application content to fit the capabilities of the device.

The value we derived from our pilot was not only the overall internal product (code) itself but also an understanding of how people use our pilot. More importantly, we gained the experience of solving problems for the mobile and tech-savvy user. Our early adopters were not shy about telling us whether we solved a particular problem, matched their workflow, or met their expectations for ease of use and productivity. If we were not fulfilling our mission to make users more productive and secure, we reinvented the solution to approach the problem from a new angle.

MyMobileHub in a nutshell

Our solution provides an easy way for users to share files with themselves. Instead of emailing themselves files that they want to open on mobile devices, they can drag and drop files from their desktops onto their browsers with MyMobileHub. We upload the file to our server through the browser. A user can connect to the same server from a mobile device — but we present them with a different UI, where they can view the file regardless of its original format. We also take advantage of the mobile camera and voice capabilities to enable users to easily create and upload multimedia content.

Laptop and desktop view

For the laptop and desktop space, we support only drag-and-drop-capable browsers. Users drag bookmarks, documents, or other files into the browser window, as shown in Figure 1. For documents whose formats we can understand, we provide previews and create PDF versions that are easily consumable on mobile devices. We have plans to convert other files types, such as converting audio files to text files.

Figure 1. MyMobileHub features
Screenshot of MyMobileHub

Desktop browsers provide a convenient way to upload and organize files. A preview image is generated automatically for each file. Users can select a list view or grid view to manage their files visually. Dynamic color-coded labels help them organize their files without the inconvenience of a classic file-system hierarchy. File and label filters, along with an instant-search feature, makes finding files quick and easy.

Mobile web apps

The browsers on smartphones and tablets are quite advanced. Using Dojo Mobile and JavaScript, a rich application can be served through the browser. Internal device identification services check the device type and help us select the right reusable combination of code, HTML, and CSS to download to the device. Depending on the device capabilities, we serve the page that's best for the display. On a device such as the iPad, the web app page is very similar to the web app page for the desktop browser, thereby providing a seamless user experience. As you can see from Figure 2, the user experience is more application-like than web page-like. Users can request that the file be downloaded, request that the PDF version be downloaded for viewing and insertion into the bookcase, or launch a bookmark to a web page.

Figure 2. MyMobileHub mobile web app
Screenshot of MyMobileHub mobile web app

Mobile native apps

The native MyMobileHub applications look similar to the web apps that run in the mobile browser but have the added capability to upload content generated from the device itself. Users can record audio or video, take a picture, or select a picture from their gallery. All can be uploaded right from MyMobileHub.

Figure 3. MyMobileHub native app
Three screenshots of MyMobileHub native app

Where efficiency starts: Methodology, approach, and design

Before doing any coding work, we researched various technologies. Tool selection was a careful process that started us on the right path. We brought the user-experience and user-interface designers together. We gathered the developers together (both of them). We pulled in our expert web developer (who lives in Brazil). Each group was responsible for educating the others on the efficiency of the various sets of tools, such as graphics design, HTML5, CSS, UI widgets, and server capabilities. By cross-educating one another, we shared pain points and efficiency techniques.

We also made some command decisions not to support certain operating-system levels and browser levels. By focusing on serving HTML5-capable browsers, we were able to simplify our development process. It paid off to recognize the relevant technology trends and anticipate their growth in both software and hardware. For example, about three months after we decided to focus on HTM5-capable browsers, all the mobile devices supported HTML5.

Single data / multiple CSS

One of our first major design decisions from a mobile perspective was to push as many of the UI and formatting items to CSS and HTML5 as possible. By doing this, we gained not only simplification of code but also unification of code across all mobile platforms.

We needed to support iPhone, iPod Touch, iPad, BlackBerry, Android phones, and Android mid- and full-sized tablets, as well as Mac, Linux, and Windows desktops. Each line of custom code spread across each platform increases reliability exposure and complexity. Our single data / multiple CSS model enabled us to use the same JavaScript Object Notation (JSON) data source to create completely different UIs for these platforms with only a small subset of custom CSS for each.

To achieve this, we wrote custom CSS modules for each of our platforms. In the case of our web applications, when a device requests HTML from our server, we detect what sort of device it is and dynamically load the appropriate custom CSS module. For native applications, we already know the platform type that can load the application, so we can limit our customizations further to things like screen size and OS version. An example of this is in the iPhone and iPad applications, which share about 99.9 percent of the same code, but — thanks to the power of dynamic CSS — have the right look and feel for the screen size.

Listing 1 shows the CSS module for the iPhone and iPad:

Listing 1. CSS module for the iPhone and iPad
.loginScreen {
    background-image: url(../images/splashBG.png);
    background-repeat: no-repeat;
    background-size: 320px;

.loginScreeniPad {
    background-image: url(../images/splashBGiPad.png);
    background-repeat: no-repeat;
    background-size: 768px;

Adding a level of efficiency with PhoneGap

Our extended team included developers who are experts at developing custom applications for most mobile platforms. Ordinarily, we might have asked each mobile-platform expert to get involved and develop a custom app. But because of our short time frame and the relatively simple UI we envisioned, we took a different approach. By working diligently to push as much of the function of the web apps to HTML5 and CSS, we were able to use PhoneGap to wrap the HTML5 and CSS into native applications.

Tools like PhoneGap are simple in concept. You start with a mobile web app written using JavaScript, HTML, and CSS technologies. PhoneGap then packages it as a native application whose primary task is to launch an internal browser to view only that web app (a WebView). Native APIs — such as for the device's camera — can now be accessed through JavaScript calls that link the web app to native code. The JavaScript code to access the camera is the same on every device, again reinforcing the goal of a single code base for multiple platforms. The code snippet in Listing 2 shows how an image can be captured on a device using only a simple JavaScript function:

Listing 2. Capturing an image using a simple JavaScript function
mmh.phonegapActions.captureImage = function() {
		dojo.partial(mmh.phonegapActions._captureSuccess, "image"), 
            mmh.phonegapActions._captureError, {limit: 1});

Using a tool like PhoneGap has certain drawbacks. It certainly is not as efficient and fast-running as an application written in native code. Some heavy execution tasks, such as complex graphics animations, would still require native executions to be responsive. The debugging and testing tools are still in their infancy, although this situation is improving with the emergence of tools like Ripple and WEINRE (see Resources). You don't get as much control of the hardware layers as you would with a native app out of the box. (You can overcome this drawback by writing custom PhoneGap plug-ins. And many plug-ins are becoming available for specific tasks.) However, in our case, the benefits of significant reuse outweigh PhoneGap's drawbacks.

Another consideration for using PhoneGap is that the design of the app should be native-centric. Knowledge of different mobile platforms helps app developers achieve the native feel without writing native code. In our current innovation cycle, the speed at which we can take well-designed web apps and move them to native apps is working well enough. Using PhoneGap, we turned the Android web app into a native app with support for audio/video/image recording, the native notification window, and hardware menu/back/home buttons in less than two days. We were also able to reuse that code for BlackBerry.

Cascading changes efficiently

Sometimes even if you've done a great job working with your user-experience designers and UI designers to come up with what you believe is the best possible UI, your users complain they can't figure out how to do a simple task. (How did you miss it?)

So you come up with a change that simplifies the user experience, and now you need to cascade it across all web apps and native apps. Without a high level of reuse across platforms, your developers must touch each specific platform and make the change multiple times. Multiply that by the number of test cases you must rerun, and small changes turn into monster changes. Again, by leaning on HTML5 and CSS formatting, you can make most of the changes at a lower level. Coding changes with the single data / multiple CSS direction become less disruptive. After the web apps are tested, you can roll the changes into the PhoneGap native-app solutions, and you are done.

An example we encountered is the inclusion of a Refresh button to give users the confidence that they can rescan data that they think may be out of sync. We developed and tested this feature on Android, and then reused the same code on all platforms with a high degree of confidence. Small CSS tweaks helped get the right look and feel across devices, and the feature is done.

Using this reuse method, we estimate that it takes about 10 percent of development time to have a new feature work on all platforms after the initial 90 percent of feature development. Clearly, though, this would not be case if the same feature had to be rewritten using different APIs, languages, and frameworks for each native platform.

This reuse method also applies to bug fixes. If a bug is found in the UI of the iPhone web app, it is likely that same bug exists in the apps for iPad, Android, and BlackBerry too, because they share 99 percent of the same code. By fixing the bug on one platform, we fix all web apps. In addition, it is easy to pinpoint the source of bugs on the native versions.

We also have a set of sprites for all the graphics, but with some CSS and Dojo Mobile, we have the right look for the device without much additional work.

Not a perfect process

We continue to develop and streamline our process so that we need to do less customization with better support across all platforms. An example of this is in native navigation across devices. iOS devices do not include hardware Back or Menu buttons, whereas BlackBerry and Android devices (up to Android 4.0 at least) do. Moreover, Android and BlackBerry menu buttons work in different ways. To overcome this disparity, we separated our JavaScript code into widgets that can be inserted or modified to suit each platform with little or no disruption to the rest of the code. It's important not only to separate code from CSS, but also to modularize components so that code can be easily reused or replaced.

We've succeeded in minimizing the amount of special-case coding by following our single data / multiple CSS policy.

Web apps vs. native apps

Is it better to deploy web apps or native apps? In our experience in the CIO Lab Mobile Innovation area, the answer is: both. Thanks to the recent improvements in the browsers of smartphones and tablet computers, web apps on mobile devices work well. Native apps do provide more access to native hardware features at this time.

However, the decision isn't only about which is better. We find that users who are test-driving our solutions are hesitant to install a native application. Some are simply not ready to commit to our solution. They want to test-drive it before they install a native application. And native apps do require some maintenance and updates.

By supporting both web apps and native apps, we can maintain a zero-install policy for our innovation. Also, users cycle through more devices than you might expect. When they get a new device, they test-drive it first with our web app before they install a native app. There are always trade-offs among function, design, and time to deploy.


Piloting a solution using the model we describe helps teams like ours explore the core value of their ideas. The process starts with thoughtful research on the best tools — open source and internal — available to solve the problem. Then you can analyze the trade-offs of function and design. Sometimes understanding the value of speed to market versus completeness of function might be what's needed to achieve a successful pilot. After the core value is articulated through user feedback and adoption, the process of turning the pilot into a production service or product can start.

We hope this article gives you some techniques for your next project that will help your team — and, ultimately, your solution's users — be more efficient and productive. Our pilot involves plenty of changes in requirements from users, but we are confident that our small team can keep up with users' change requests. We have streamlined design and developed a process that cycles every few weeks, thanks to the efficiency of the methodology we selected at the beginning.



Get products and technologies

  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.


  • Get involved in the developerWorks community, and connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.


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.

Dig deeper into Mobile development on developerWorks

Zone=Mobile development,
ArticleTitle=Techniques for rapid mobile solution development