Mobilized software: the developer's new challenge

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.

---

by Andrew Binstock, principal analyst, Pacific Data Works LLC. Intel Corp.

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:

1. 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.
2. 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.