by Alan Zeichick
Introduction
I'm not a mobile user. My primary PC is a dual-processor desktop with a huge 23-inch display. I have a laptop, but mainly I use it while making a once-a-month business trip to the East Coast. My cell phone does not have Java* or BREW*, I don't have a Blackberry* or pager, and my PDA gathers dust in a drawer. And I'm not in field sales, field service or field anything.
So, like many of you, I've found the mantra "Build Mobilized Applications" a little, well, impractical. Mobility conjures up the image of the UPS driver scanning bar-codes on my Amazon.com purchase, or the guy from Sears using a special radio-equipped notebook while he fixes my fridge, or the waitress at 'The Waterfront' who uses a spiffy handheld to radio my gin-and-tonic to the bar. It also brings to mind all those comments about field sales people using mobile devices-but do you know what? My own company's field sales people use their laptops to do presentations, not to process transactions.
So, while I've written about the principles recommended for building mobilized applications (see "How Mobility Will Impact Your Applications Development"* and "The Four Critical Issues for Mobile Apps Developers"*), for the most part they didn't seem to apply to me, or to the types of applications that I rely upon daily.
But that's not right. Let's move beyond the terminology: The principles of mobilized application design are actually a set of best practices for designing general-purpose client-centric applications.
For example, take e-mail. My e-mail client is Qualcomm's Eudora* 6.1 for Windows*. Generally, Eudora runs on my desktop PC, described above, or on my laptop while wired into our New York office's LAN. But sometimes I use it while in Starbucks on WiFi, in a hotel room or motel, or on an airplane totally disconnected. (Those cross-country flights are perfect for cleaning out messages and catching up with old friends.) And sometimes my home-office's cable modem goes down.
Turns out that Eudora offers several features that happen to empower mobilized users, although they're not marketed as such. (Many e-mail clients offer the same features.) For example, all outgoing messages go into a queue. The software seamlessly adapts to changing network conditions: If there's a network connection, Eudora will send them out; if not, they'll just sit there. So, I can write and send messages at 35,000 feet, exactly the same way that I do while in my office.
Eudora has other features that are good for mobility-and for ordinary users. It can be told to check e-mail only when it's running on AC power, but not on battery, in order to extend battery life. (I don't use that setting.) It can be told to download only the headers for messages above a user-selectable size, so as to stop a 4MB attachment from hogging the 28.8kbps modem. (That's a setting that I use while in broadband-free hotels, but not otherwise.)
But while Eudora does a good job handling the transition between connection and disconnection, it's not perfect. There's no awareness of the quality of a network connection, and therefore, no way to set policies that leverage that quality. For example, it would be nice if it would automatically turn on that headers-only mode when I'm on narrowband, but not when on broadband.
Also, I cannot prioritize activities in order to leverage limited bandwidth. Currently, I have seven different POP3 accounts that Eudora manages automatically. When sending or receiving mail automatically, Eudora opens all seven connections simultaneously in different threads, sharing the bandwidth between them. It would be nice if I could tell it, "When on narrowband, open my family-personal account and standard business account first, process their incoming and outgoing transactions first. After those are complete, then send and receive e-mail on the other five accounts."
Not Always Adaptive
Still, Eudora gets points for trying. It does a better job than many applications. Windows Update, for example, tries to download fixes no matter the bandwidth conditions. I have Windows Update configured to automatically download patches, but only apply them when/if I say so. But I get really annoyed when I dial up from that hotel room (my favorite inn in New York hasn't gone broadband yet), and it tries to grab a Windows security fix or a new graphics-card drive. That can wait until tomorrow, when I'm in the office! Ditto for when Acrobat* looks for updates during startup. Not now! Later! Bandwidth is sometimes a precious commodity.
Why, oh why, don't applications adapt to bandwidth? Why don't they automatically queue network transactions, the way Eudora does with its outgoing mail?
In other words, why aren't they mobilized?
I'll give you another example of an application that could be mobilized-but isn't. I maintain several Web sites using different tools, and there are a couple that I work on using Microsoft's FrontPage* 2002. When I'm not catching up on my correspondence, I use travel time to noodle around with some of my Web sites, cleaning up the content, changing the pages around. One of the Web sites is focused on my family, and I use trips to post new photographs.
But of course, I can't publish those site updates, not from 35,000, and not from that 28.8kbps hotel room either. So, on my to-do list I have to write, "In office, publish such-and-such site." That means launching FrontPage, loading the site, and pressing the "publish" button. Why can't I tell FrontPage, "publish" while I'm at 35,000 feet, and have it queue the transaction, to be performed automatically when I'm reconnected with broadband (preferably after my e-mail's all been retrieved)? Sorry, that feature does not exist.
I'm sure that bloggers, newsgroup posters, and others can relate to that concept of queuing network transactions.
The Eudora example covers several of the key aspects of developing mobile applications that I think should be considered as general-purpose design practices. The full list: Being able to work both online and offline; be able to adapt to changing network conditions; store data locally; tune for hardware utilization; and leverage threading and processes. Let's look at those, with some examples of how they might work.
Work Both Online and Offline
Examples abound of network-centric applications that can work online and offline. Eudora again provides a good example: When I'm disconnected, I can still read my already-downloaded e-mail and compose new mail. That part of the application is completely network-ignorant. The only part that relies upon the network is the communica tion with the POP3 (or IMAP4) and SMTP servers.
Look at your applications, both commercial and home-grown. Many aspects of their functioning can be logically separated between communications and non-communications. Updating your applications with service patches, for example: There's the part that checks for and downloads patches, and the part that installs them. Those separations should be implemented into the architecture-and careful consideration given to the automatic behavior of the network-aware piece.
Would you want it to pre-fetch often-required data from a network, for example? Even for a LAN-based user, pre-fetching data will improve perceived user performance, because loading data locally is generally faster than retrieving from a LAN or Internet server. The same is true of posting new data. Can that operation be saved to a queue, and then posted separately by a different process? Printing is a good example there: Windows provides a local print queue. When I get home and plug back into my LAN, my laser printer goes crazy. That's exactly how it should be. Can you leverage that principle?
Another aspect of being able to work online and offline is to automatically reconnect after a network disconnect. AOL Instant Messenger*, for example, sometimes does a good job handling a break in communication, but sometimes it doesn't, and I have to tell it to reconnect. (I don't know about you, but I find the AIM server to disappear and reappear several times a day.)
Adapt to Changing Network Conditions
Windows in general does not understand the quality of a communications link, and neither do applications like Eudora. Either you're on a network connection, or you're not. But there's a huge difference between narrowband and wideband, and even on a wideband network, quality of service can vary moment to moment. I've certainly seen that while using public WiFi hot spots.
Heck, I've even noticed that on my home-office cable modem: After dinner, for example, when the neighbors are all home, it slows to a crawl. It would be good if my system would adapt: For example, I listen to a lot of Internet streaming audio feeds. When my bandwidth is "challenged," how about dropping the quality automatically?
In the Eudora example there would be limiting downloads of large messages to headers-only when on narrowband, or processing individual POP3 accounts serially, rather than in parallel. Software updates, LAN-based backups, and other processes should also be aware of network conditions and dynamically configure themselves accordingly.
Store Data Locally
The idea of a local data store is implicit for enabling off-line operations. Eudora, for example, needs a place to store that outgoing mail. Windows Update needs a place to hold those downloaded patches and fixes.
If you get in the habit of coding a local data store for network transactions, you'll find many benefits. Of course, having applications write to a local repository, rather than to the network directly, lets you easily implement offline operation. You can also write the logic that links that repository to the network to be exploitive of network quality, including performance, reliability and quality-of-service (i.e., jitter and delay). Local data stores don't have to be elaborate. It might just be a flat file that contains outgoing SMTP me ssages. On the other hand, it might be a complex application-specific database that's pre-populated by a rule-based system that fetches data that the user's going to require. Anything you can do to make an application more responsive is a good idea-whether that application is on a modem-equipped laptop or a dual Intel® Xeon™ workstation. And a local data store is often a great way to speed up system response time.
Tune Hardware Utilization
In general, your applications should try to use as little electricity as possible. Electricity costs money, generates heat, and can shorten battery and component life. They should also use as little CPU power as necessary, not just to save electricity, but to be good multi-tasking citizens.
Frankly, except when you are building applications for specialized mobile platforms, there's little that you can do to directly affect power and processor utilization. Most of the PCs that we use have fixed clock speeds and hard drives that never stop. Applications cannot (and should not) be able to control the hardware. But even so, you should be aware that your application might be in an environment where hardware utilization can make a difference.
For example, my desktop is buffed up with a gig of RAM. Yet, many applications don't seem to know it exists. Take playing music CDs or movie DVDs, which I do often (you've gotta love a 23-inch panel!). The media player keeps the disc spinning the whole time. That sucks up a lot of juice, and is fairly inefficient. Why doesn't it build an in-memory cache? There's plenty of RAM to spare, especially when I'm watching a movie. Spinning down the disc would save power (and on a laptop, lengthen battery life). Or even cache some of that content on the hard drive, which is always turning, so that the CD player could stop.
My laptop uses the Intel® Pentium® M Processor and Intel® 855 chipset, which have some aggressive power-management characteristics. Do any of my applications exploit those? Do they give the system hints to tune its power management? Not as far as I know. But considering that my battery dies halfway through my SFO-JFK flight, I wish they would.
Use Threads and Processes
If you are going to separate the user interface logic from the network communications, the best way to do that is often by using separate processes. If you are going to implement caches and local repositories, threads help make those efficient and easier to manage.
For many developers, especially those who work on the client-side business and productivity applications, threads remains somewhat of a mystery, and don't seem very important. But bear in mind that separate processes and threads can operate asynchronously-something that's very important if you want to have your UI remain responsive to your users, while adapting your communications to be responsive to your network (or lack thereof).
Multi-threaded applications can also exploit multiprocessing. Multiprocessing, on a client? Increasingly, yes. Intel® Hyper-Threading Technology (HT Technology) can be found on most new desktops and many new mobile systems, and you can expect that technology to become more pervasive. Also, dual-core proces sors are right around the corner. So, using threads and processes is a good idea, even for mobile clients-and is an excellent best practice for all desktop applications.
Beyond Mobility
I'm not in field sales, or trying to transfer my desktop applications to work on a PDA.
But from the perspective of an applications designer, I am a mobile user-even when using my big honkin' desktop PC.
So, don't think about the best practices for building good mobilized applications as being for building mobilized applications. They're bigger than that-in general, they're a good idea for all applications.
Related Links
About the Author
A former mainframe software developer and systems analyst, Alan Zeichick is principal analyst at Camden Associates, an independent technology research firm focusing on networking, storage, and software development.