Architecting Mobile Applications: Same Questions, Different Answers


Nickolas Landry and Jean Barmash

December 2007

Summary: When it comes to architecture and design, mobile applications share a lot with their desktop and server counterparts; but they also differ, in many ways. (10 printed pages)


In Experts We Mistrust
Problems with a Mobile Web Approach
The Smart-Client Approach
Critical-Thinking Questions


A utility company hired us as mobility consultants to help them architect a solution for making their field service technicians more effective.

The company already had an internal Web-based system that collected a lot of the required information. However, in the field, technicians had to fill out paper forms to collect call data and keep track of work times and mobile inventories; these were then passed to office personnel for reentry in the intranet applications when they got back to the office. This process was cumbersome. Because data had to be entered twice, it took a lot of time and was error-prone. Additionally, the process did not allow for fast turnaround or effective response to last-minute calls and emergencies.

Management decided that a mobile solution would allow field workers to enter data only once while on calls—thus, reducing errors and providing better service routes. Also, it would allow field workers to check easily if a spare part was available on their truck's inventory, at the warehouse, or even from another field worker working a few blocks away—thus, improving inventory management, too.

Because the client's IT group was staffed primarily with Web developers and experts—who had read about some of the new mobile Web standards, and how "easy" they were to use across several device types—they were excited to convert their central Web application over to the mobile Web. We tried to point out some potential problems with that approach, starting with the stable connectivity requirement, and suggested that they build their application instead as a smart client for their mobile devices. However, they insisted that we use a Web-centric approach, as this would be easier to manage, and a smart-client solution would involve more development time and a more complex system architecture.

In Experts We Mistrust

It is fun when you are being hired for a certain expertise, and then immediately are told effectively that "we know better than you"—which is actually what happened on this project. We realized that we had to prove our point, so we recommended that we first start with a simple Web-based proof-of-concept that focused only on a small subset of the functionality. We felt that the best way to convince our clients would be by doing instead of talking, and building up credibility by demonstrating the drawbacks that we knew would surface in a Web-centric mobile solution.

We spent a few weeks rebuilding some of their functionality as mobile Web pages, and then deployed the application to a subset of users as a small pilot rollout. Because of the small pilot-group size, and because we used the Web, we did not have to lock down the decision on hardware just yet; we were able to get 20 loaner devices from vendors. The proof-of-concept was designed as a dynamic Web application that was based on best practices, including adaptive rendering for mobile Web pages.

Problems with a Mobile Web Approach

The complaints started trickling in almost immediately. As expected, our prototype application was often unavailable. Either some of the areas that we needed to service were outside of the wireless coverage area, or the connection was painfully slow due to slower wireless network protocols and weak cellular radio signals. Furthermore, because of this, people would start entering some data; but, when a connection was lost at submission time, they would have to start over, which led to an inefficient process and a lot of user frustration.

Additionally, new requirements came in during development: The customer wanted the ability to send alerts to the field to notify workers of job updates, traffic incidents, or route changes. The Web application offered no good way of doing this. We could poll the server for updates at regular intervals for this information; but, to avoid overriding user inputs, this could only be done when the application was not in use. Additionally, such a mechanism would drain the device battery much faster due to excessive use of the wireless radio. The polling could also potentially incur additional bandwidth costs, depending on the type of data plan that was offered by the wireless carrier.

The customer was quickly becoming convinced that this mobile Web application was not going to be as easy to implement as they had initially hoped. They asked us to tell them again about the smart-client approach and how that would apply to their scenario.

The Smart-Client Approach

A mobile smart client is an application that is deployed locally on the mobile device that allows users to work, whether they are connected to or disconnected from the network. It maintains a local snapshot of data, and interacts with that data should the server be unreachable—thus, allowing normal user operation even when offline. When the smart client reconnects to the central corporate server, it synchronizes the changes with the server and refreshes its data snapshot with the latest data. Additionally, using local data during user operations eliminates the superfluous server roundtrips that are common to Web applications. This extends the device battery life, because of the more efficient use of the radio.

Because smart clients are not limited by the constraints of the browser, it is easier to build a rich user interface, which results in a more efficient user experience. Smart clients usually benefit from faster performance, because they use the local device resources, which include the GUI facilities, memory, local storage space, and device processor. Additionally, smart clients typically include some facilities for automatic updating and deployment of the software through bootstrapping, which has been a traditional weakness of classic rich-client applications.

In summary, smart clients strive to take advantage of both the Web and traditional rich-client features, while downplaying the disadvantages of each.

Hardware Selection

Before we could really start, however, we had to make the most important choice: hardware and the mobile operating-system platform. This choice would influence a lot of other decisions, such as in which language we would program, which databases were available, and so forth. Additionally, in the past, when applications had specialized needs—such as a global positioning system (GPS) or the ability to print out a receipt—going with consumer-level devices did not do. Fortunately, we did not have such specialized constraints here. During extensive research and evaluation, we finally narrowed down our choice to two devices: a smart phone and a PDA. Before finally selecting them, we considered the following features of the devices.

Built-In Wireless Radios

Because we needed connectivity no matter where the user was, the primary connectivity method was over cellular, using a wireless data network like GPRS, EDGE or UMTS/HSDPA, or 1X or EvDO. Wi-Fi (802.11x) was not really an issue; the coverage is too spotty, as it relies on hot spots only. Bluetooth radios are also useful for hands-free voice conversation, but the application did not require any external Bluetooth peripherals.


Because most devices today have separate allocations for RAM and storage, it was important to pick a device that had enough RAM. Having access to more RAM allows users to run other applications on the device simultaneously. For this reason, devices with 64 MB of RAM were favored over devices with only 32 MB of RAM.

Expansion Cards

Because the database file can grow and overtake all of the device's internal storage, choosing a device that supports external storage cards was a key feature.

Built-In Keyboard

Because the application required that users input a fair amount of data and updates, a built-in keyboard was required—thus, limiting the range of devices to which it could be deployed.

Screen Size

The application required a QVGA (240x320) screen that could rotate through a software setting to accommodate the UI design.


There was no big requirement here, as the application was not processor-intensive. Any device that ran at 300 MHz or more would suffice.

Development Platform

This was another important choice (see Table 1 for key development platforms). Most of the time, when selecting a hardware device's development platform, options are correspondingly narrowed. Often, the decision comes down to the skill set of the developers and whatever platform matches it most closely. For example, Java developers will favor J2ME. However, because our client did not really have experience in any of the mobile technologies, and because they had a wide variety of skill sets, this was not much of a concern. They had some good senior developers who would be able to pick up easily what they did not know, especially with us around to help out.

Table 1. Key mobile application platforms [Wikipedia, 2007]




Symbian OS

Symbian Consortium, led by Nokia, Motorola, Sony Ericsson, Samsung, and others

Highly modular and customizable operating system and development environment found on most popular phones; especially popular in Europe.

Windows CE/Windows Mobile

Microsoft Corporation

Modular operating system for embedded devices, derived from the Windows NT kernel. Windows Mobile caters more specifically to Pocket PCs and Smartphones.

.NET Compact Framework

Microsoft Corp.

Managed code execution and development environment that is based on the .NET platform, adapted specifically for Windows CE and Windows Mobile devices.

Java, J2ME

Sun Microsystems

Java Platform, Micro Edition: Application-development platform for the execution of managed code that is based on Java technologies and targeted at mobile devices.

Flash Lite


Ideal for interactive and graphics-heavy application; a lightweight version of the Adobe Flash player.

Palm OS

PalmSource/ACCESS Co., Ltd.

Lightweight operating system that is designed specifically for PDAs and well-known for its Graffiti pen-based input.


(Open-source software)

A programming language that is used by some open-source proponents to write applications for several mobile platforms. Used for prototyping and proof-of-concept application.



Web-based server-side technology that works well for lightweight functionality and works on multiple hardware (through the browser).



Binary Runtime Environment for Wireless. Application-development platform for mobile phones that is used primarily for mobile game development on the Symbian platform.

Embedded Linux

(Open-source software)

Embedded operating system that is based on Linux, targeted at mobile and consumer-electronics devices.


User Interface

As expected, we discovered during the proof-of-concept that, because the original pages packed in much more information than our small device screen allowed us to show, it was hard to convert Web pages that were designed for desktop browsers to make them mobile-friendly. Desktop Web pages often use the widescreen real estate for dynamic menus, frames, and sidebars—all elements that we simply could not afford to use on devices. We had much more flexibility with smart-client forms. We worked with the client's graphic designers and mocked-up the interface. Because we were no longer constrained by the Web and the server roundtrips, we could design a much more responsive UI that was based on simple yet effective workflows. For example, for a service-call report, we made a five-page wizard that tried to prepopulate some data that we already knew, such as the customer's address and account numbers.

Another challenge that we had was that there were two types of devices that would be used in the field. Each had a different screen size, so that we had to ensure that our GUI looked good in both. And, because the users have the ability to rotate the screen from portrait (vertical) to landscape (horizontal), we had to account for that, too, by using dynamic positioning and automatic resizing of UI elements. We used various emulators for each of our devices during testing to ensure that the screens looked right and that the UI repositioning logic worked correctly.

Storage Strategy and Data Synchronization

Because our proof-of-concept clearly showed that we could not rely on the network being available for the field technicians at all times, it was clear that our application had to be able to work both online and offline. Each mode has its own challenges. In a disconnected (offline) mode, some data has to be pre-cached and persisted locally ahead of time. Because most enterprise scenarios cannot realistically allow for a complete copy of the central database, we had to devise a way to partition the data for mobile use.

As soon as we had designed the interface, it became clearer what kind of information we would need to store on the device. Despite the use of devices with up to two gigabytes of solid-state storage space (such as SD, Compact Flash, MMC, and other types of memory cards), moving all corporate data to a mobile device over slower wireless bandwidth was simply not realistic. The potential security risk of device loss or theft meant also that we needed to target the data that we would make available to the user, to further minimize storage requirements and mitigate data-confidentiality risks. We opted to store route data for a specific user only, including a three-day history, and to store local inventory data based on the region and client base in which the technician would be working.

Our next decision was about how to store information locally on the device, and how to synchronize the data with the server. Typically, there are two main options: using a mobile database that provides the needed facilities (such as caching, server replication, and data encryption), or storing serialized relational data in XML files on the device. Because we had an existing Web services infrastructure that supported the ability to reconcile data changes with the server and resolve conflicts, we decided to store data in XML files on the device. Synchronization schemes such as merge replication compare the two datasets on the mobile client and the server, and track changes on both sides. In this way, the developer can control how the changes are made to the server, as well as automatically update the data on the client. Given that our data was meant to flow mainly from client to server, such an advanced mechanism was not required.

Reusing Existing Infrastructure

Because the mobile application was designed as an extension of existing enterprise systems, we wanted to reuse as much of the backend functionality as possible. Fortunately, the Web applications that we had to enable for the field were built on a solid distributed architecture, featuring Web services that exposed key functionality. Therefore, we could reuse many of the Web services to provide data to the field and consume it back, once it was updated. However, not being designed for mobility, some of the Web services were a bit too wasteful with regard to the amount of data that they were sending over, assuming that the typical desktop or server consumer would have memory, storage, and bandwidth to spare.

We decided to add an extra Web service layer between the mobile clients and the existing Web services—thus, enabling a proxy for our mobile client to pass the data only as needed, and minimize the bandwidth requirements by optimizing the calls for limited wireless connections. For example, one service that used to return data for all users and filter it on the calling client (which was, in fact, a Web application running on a server) now would only return data that was relevant to the current mobile user—thus, limiting the bandwidth requirements and making it more relevant.

Managing Connectivity

The PDAs that the client purchased supported several connection modes, both GPRS and Wi-Fi, which are Wireless WAN and Wireless LAN connections, respectively. We built connection-management functionality into the client application. Our client automatically detected changes in connectivity and had networking logic to perform different operations, depending on the connection quality and available bandwidth.

If the signal was weak or intermittent, the device was effectively disconnected and, thus, could not perform data-intensive operations. For example, for a weak GPRS signal, the application sent only small updates to the server, and would not initiate larger file synchronization. For data that had to be transferred to the server (such as billable time and inventory usage), we queued the saved data, so that, when a better connection was restored (like WLAN), the data could be sent to the server. We had to take special care to manage the bandwidth, so that the synchronization process did not clog the connection completely.


As part of the design process, we also did some threat modeling to identify the most susceptible security risks for our mobile application. Depending on the sensitivity of the data, different options existed. To secure the device itself (protecting the data that was stored in it, should the device be lost or stolen), password-protecting the device was a good option. This prevented access to its software.

For network-based protection, tools existed to encrypt communications—starting with the ubiquitous SSL over HTTP to secure the channel itself to encryption of Web service message contents. For data security, some mobile database products provided strong encryption of their storage files by using security standards—thus, preventing an attacker from reading it without knowledge of the password. Minimizing the amount of data that was stored on the device was another key way to minimize the information-disclosure threat, even if the device was compromised. We also automatically gained the ability to remote-wipe all device data, thanks to the built-in messaging infrastructure of the chosen mobile platform.

However, a security problem arose in reusing the existing Web services implementation on the server. Because we did not have access to the same Web service-security facilities that servers or desktops have, we had to think through some of the possible vulnerabilities, and implemented standard logon and custom authorization and encryption features.

Deployment and Manageability

There are many reasons that the client initially wanted a Web application. Ease of deployment and ease of management were at the top. Security also was a factor. Because the data and the application would be centralized, it would be easier to authenticate and manage user entitlements from a central location. All of the data also would be easily protected: Everything would be on the server; so, if the device were lost, we would not run the risk of having unaccounted-for sensitive data running loose out in the field.

Another challenge that we faced was how to deploy and update our application. Of course, with Web applications, you do not have that problem; you can control all of the changes and versions from a centralized location. We came up with two different options for our client:

· We proposed using a bootstrapper utility that would automatically detect when a new version was available on the server, and then download and install it. Of course, this would require connectivity, and significant updates would be downloaded only if the connectivity was strong and fast enough, and if the user accepted when prompted.

·The second method that we proposed involved publishing self-contained packages on a secure shared folder that was available over the Web; the users then would manually pull the appropriate packages from the Web location. As soon as they were downloaded, the packages could be run and installed/applied.

Power Management

Another feature that we implemented had to do with power management. The smart-client architecture of the application did not use the radio unless it had to contact the server, which resulted in lowered battery consumption, compared to a Web-based system. However, a typical work shift for the field workers could sometimes extend from 10 to 12 hours, which matches the device's expected autonomy. During testing, we noticed that the battery sometimes would run out during the end-of-the-day synchronization. Therefore, we built tunable logic safeguards into our application; these checked to see the remaining battery level was lower than 15 percent, below which it would not initiate large data transfers.


This project really highlighted the differences between the two main modes of architecting a mobile application. Through the smart-client approach that was ultimately used, we were able to take advantage of deployability of the Web application, as well as interactivity of the rich-client application. We were able to reuse some of the existing infrastructure, but also had to solve a lot of interesting problems that arose from a more complex distributed model. Our client came away learning much about mobile development; this even led to re-architecting some of their systems, to better support both internal applications and mobile solutions at the same time. It was especially satisfying to get an e-mail from the client at the end of the project, in which they thanked us for suggesting the original pilot study that allowed us to prove out our approach.

Critical-Thinking Questions

· How would you choose whether a Web-based mobile application or a smart mobile client is a better solution to your problem?

· What are the key advantages over true push technology versus pull-based "push" technology?

· What are the potential security threats to mobile applications?

· How is mobile application development different from traditional application development?

· How do you reuse an existing infrastructure that supports the functionality that you need in a mobile scenario? What are the considerations of which you must be aware?

· How do you synchronize with the rest of the server? Do you have synchronization on the server, or do you use replication technology?


· [Wikipedia, 2007] Wikipedia contributors. "Mobile development." Wikipedia, the Free Encyclopedia. 2007. (Cited January 12, 2007.)


Adaptive rendering—A mobile Web technique that detects the custom Web format that is supported by the calling mobile device, and automatically converts the mobile Web pages to the appropriate mode. Some examples of mobile Web formats include CHTML, DHTML, and WML.

GPRS, EvDO, EDGE—Competing cellular-data technologies. EvDO and EDGE are significantly faster than GPRS, which is an older technology.

Merge replication—Compares the two datasets on the mobile client and the server, and tracks changes on both sides.

Threat modeling—Refers to a process that tries to predict the different security threats that the application might face. In mobile development, four levels of security are examined: device, network, data, and application.

About the authors

Nickolas Landry, a senior architect in New York for Infusion Development, is a speaker at major conferences worldwide, a Microsoft Device Application Development MVP, and the Vice-President of IASA New York. Nick designs business-solution architectures using .NET, provides mentoring services, authors and teaches .NET classes, and performs system audits and business analyses. Nick has 15 years of professional experience, and he specializes in .NET mobility, OOP and SOA, architecture and design patterns, and application security. You can visit his blog at

Jean Barmash is a senior consultant/trainer at Infusion Development, where he is involved in architecture, project management, and hands-on development. As an integration consultant and technical lead for Trilogy, Jean worked on several large automotive projects. While working as principal software engineer for Symantec, he helped develop a product that focused on business-intelligence solutions for the data center. Well-versed in both .NET and Java, Jean is currently focused on Web business-intelligence solutions.


This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit