Mobilized Software: The Developer's New Challenge

by Andrew Binstock


Introduction

With the purchase of notebook computers consuming an ever-widening portion of corporate technology budgets, it is clear a new concept of mobility is entering the work place. Highly mobile power users, often termed "road warriors," and many professionals who work both at home and the office, are forcing enterprises to view access to enterprise applications in a new light. Specifically, IT departments are reconsidering client end-points in the context of intermittent or occasional connectivity. This development is further heightened by the growing use of handheld computing devices and smart phones by employees and, especially, by customers.

This new trend in connectivity will assume an even greater impetus, according to several analysts, as wireless technology, specifically Wi-Fi 802.11a and b, gain wider acceptance. Already today, "hot spots" in coffee shops, hotels, and airports deliver wireless connectivity to applications through 802.11a. As this capability becomes routinely available in office buildings and homes, users will constantly be moving in and out of connectivity zones. And-here's the important part-applications will need to be able to stay up with them regardless of the duration of the interruption or where the application left off. This is the challenge of mobilizing software.


The Elements of Challenge

To provide an effective solution to this challenge, developers should recognize the distinct elements that together constitute the overarching problem. These are:

  • Form factor: At Intel's developer conference in February 2003, the principal theme was the convergence of computing devices and communication. Intel predicted that in the near future "all computing devices will communicate and all communication devices will compute." If notebooks can place phone calls and cell phones can browse the Web, then developers are challenged with not knowing with which device a given application will interact. Hence, locking in the design of the interface to a specific format and form factor will mean that some users will be unable to use the application.
  • Maintaining state: If a user disconnects temporarily from an application, how will the application appear when the connection returns? In traditional always-connected applications, the developer knows when a user encounters a certain dialog box, let us say, as the result of a previous menu selection. Consequently, the developer has state information-that is specific data about the path the user employed to reach this point. If the user is intermittently connected, however, the path might suddenly need to resume in the middle of a form. If the application does not save state, the users cannot pick up where they left off; rather they will be forced to begin the transaction anew. This type of imposed behavior will shortly not be a viable option for software. Therefore, state needs to be saved. A great challenge in this regard is to know whether the client or the server should maintain the last known state. Each choice has specific implications.
  • Errant interactions: Suppose a user with a handhel d wireless PDA is sending a transaction to a corporate server. The transaction ends with a tap of the stylus on the button marked "OK" or "Send." In theory, once the transaction is received, the server sends back some indication confirming receipt. If a delay occurs on the server, and the handheld device receives no confirmation within 30 or 40 seconds, what happens? Invariably, the user will tap the Send button again. In fact, a frustrated user might tap the button numerous times. The server must be able to recognize these events for what they are: not a sequence of transactions, but a single transaction confirmed several times.

    This problem occurs frequently in fully connected environments, especially on the Internet. Consider that almost all consumer-facing Web transactions today have in common the final screen of the transaction. This screen generally is the one in which the customer reviews the order and the credit card information. When all is satisfactory, the user clicks or taps "Send." Usually, a message pops up informing the user that the order is being processed-therefore, do not click "Send" again-or the order will be duplicated. In the current environment, this is still tolerated, simply because it is ubiquitous. But as the world moves to mobilized software, imposing the penalty of duplicates will no longer be acceptable.
  • Off-line computing: Many applications currently expect the user to be online at all times. If the user goes off-line while the application is active, processing stops. Users won't tolerate this kind of enforced hiatus in their productivity. Increasingly, they will expect to be able to keep working. A common example of off-line work is the ability of business travelers to respond to email while in flight. Today's applications need to embrace this model whereby actions and data can be queued for upload and synchronizing at a future point. This change requires not only the use of queues, but a revised perspective on the need to compel user responses.

 

These four issues constitute the basic challenge of mobilizing software. Undeniably, other issues-such as security (especially, identification, authorization, and access control)-exist as well, but they typically are not mobile-specific.


The Elements of the Solution

The last two issues listed previously-off-line computing and errant interactions-are best addressed through the use of message queues. These queues accumulate data inputs-generally in the form of messages-which are stored until the client device reconnects. Once a connection with the server is established, the queued messages are uploaded and new messages are downloaded.

For computing to occur without network connectivity, however, these queues need to store more than a large blob of data for eventual upload. They must also record and save individual user actions, such as mouse clicks. For example, a user might download a catalog of merchandise. If the user then orders some merchandise from the catalog, each data field should be filled in, and every relevant button click should be placed into queues. The program itself needs to run the user interface as if it is connected-presenting in sequence all the screens the user needs to pla ce the order. When the user finishes and confirms the order by clicking "Send," this action too needs to be recorded.

Queues that are properly set up will recognize multiple clicks of a "Send" action. If these clicks follow each other immediately, they can presumably be collapsed into a single click. If they are separated by other actions, a dialog should appear to confirm how many actual transactions were placed. By capturing all actions and resolving duplicates, queues enable disconnected computing and removal of errant interactions, thereby surmounting two principal challenges of mobilizing software.

Queue management has significant implications. In the simple example just given, the user's ability to progress in the application is dependent on the client-side software to verify data, record it, and put up the next screen. Today, these functions are typically performed by the server (generally a Web server with an application server behind it). Moving this logic to the client so that the experience can be simulated through queuing has important consequences for small form-factor client devices, which often labor under tight memory constraints.

Queue synchronization is also an important issue. When the user returns to connectivity, the message queues must synch with the server. To do this, they need to ascertain security and authorization. As the message queues begin uploading the transaction data, they must use a roll back mechanism, so that if the connection to the server drops during the update, it can be restarted from the beginning at a later date. Likewise, the server must recognize the disconnection and roll back the transaction. The server, ultimately, must be able to distinguish what data the client should roll back and restart when a disconnection occurs, and which can resume from the point of interruption. Many applications will fall between these two points-that is, they can be resumed for some defined period of time after the disconnection. Past that window of opportunity, the whole transaction must be re-started.

Saving State is a challenge that, like queues, affects nearly all aspects of client-facing software. Today, Web servers are the most common example of stateless interaction with clients. Web servers are asked to deliver a page. No specific context for that page is handled by the server: it simply delivers the page, as if each delivery were a one-off event. To maintain state, Web sites have relied on two primary mechanisms: cookies and encoding state information in URLs. By the latter means, sites can keep track of the fact that a particular page is part of a sequence. Google*.com, for example, changes the URL of each page as users scroll through data to track which set of links to display next. While URLs contain state information between pages, cookies contain state information between sessions, such as the customer name.

Mobilized software requires similar measures. If, for example, a customer is disconnected in the middle of data manipulation, state information needs to retain where the action stopped, so that upon re-connection, work can continue from the point of interruption. This aspect has far-reaching consequences that are not obvious. Consider, for example, most desktop software with GUI front-ends. In designing these programs, developers have an implic it knowledge of state at any given moment. For example, if the user can only come to a specific checkbox after making a series of menu selections, then the developer knows the client is an employee with a 401k plan who wants to change her investment allocation. Now, if mobilized software users can drop into this same screen because in a previous session they left off there, the application must keep track of what is already known about the client, else the transaction will be meaningless, or worse, the wrong transaction will take place.

Accordingly, developers will need to record what they know about the client as interaction occurs with the software. This means some form of constant logging must occur and that information must be transmittable in a useful manner. The overarching question is who transmits it to whom: the client or the server? Both endpoints offer compelling advantages. Ultimately sites will work out what is easiest for them: Web applications are likely to continue using client-side state management, while other software may opt for server-side.

Form Factor awareness is a distinct issue. Client-side software should always start by dynamically discovering the form factor of the device on which it is running. By form factor we mean what are the capabilities (memory, proccessing, storage) of the device. Once the form factor is ascertained, the software must dynamically reconfigure itself. Consider how several years ago when cellular phones began to support Web browsing, there was a belief that Web sites would offer smaller-sized Web pages for quick downloading to these devices. However, this practice was never widely embraced and, as a result, Web navigation on PDAs and cell phones never took off. As users become more mobile, however, they will begin to gravitate to competitors who offer sensitivity to form factor limitations. This will eventually be true for Web sites, but it will occur first-according to some analysts-on downloadable software. Software that does not account for limited screen sizes, stylus-based writing, or thumbs-based typing will be abandoned quickly, especially if a better alternative is available. The form factor constraints go beyond user-oriented I/O. Memory consumption and processor power are equally important factors, as is the absence of peripherals, (such as a printer) that software today expects. (For example, how many Web sites today still require users to print their own receipts rather than e-mailing them a document?) Form factor is probably the area of mobilized software that will be most apparent to users immediately. Even though users can surmount form-factor challenges better than any other discussed in this article, they will also be most sensitive to competitors who solve the problem more elegantly.


Conclusion

Mobilizing software promises to transform the way software is written and accessed. For this reason, companies that begin preparing for these changes early on will enjoy a distinct competitive advantage over their competitors. Unfortunately, all the technology and best practices for mobilizing software have not yet been established: which queue mechanisms work best? How should transaction state be saved? What are the specific design constraints of different form factors? These questions, however, are quickly emergin g to the forefront and smart developers will begin architecting software knowing that these issues will pervade their designs.

 


Additional Resources

 


About the Author

Andrew Binstock is the principal analyst at Pacific Data Works LLC. He was previously a senior technology analyst at PricewaterhouseCoopers, and earlier editor in chief of UNIX Review and C Gazette. He is the lead author of "Practical Algorithms for Programmers," from Addison-Wesley Longman, which is currently in its 12th printing and in use at more than 30 computer-science departments in the United States.


For more complete information about compiler optimizations, see our Optimization Notice.
Tags: