Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Heed the Siren Call of Wireless Development : Page 4

You're about to be drafted into the mobile development army. Users' and organizations' needs are outflanking IT's defenses. Why is this happening? And when the battle comes to your regiment, will you be armed for success?


advertisement

Choose Your Target Devices
A large number of devices are available already, and you can expect more to appear in the future. Nick Jones says you can expect devices to change roughly every 18 months. And these devices don't all have the same capabilities—they're targeted for different tasks. The current situation, where organizations standardize on a few desktop and laptop computers and where developers focus primarily on desktop applications, is changing. You're going to have to consider all the devices in play in your enterprise.

The low end of these devices is enhanced cell phones, which can display a few lines of text. While they may be adequate for sending and receiving text messages, most corporate developers probably won't have to get intricately involved with supporting these devices; the best choices for deployment here come from the consumer market and ISVs. The newer devices, such as smart phones, PDAs, and the newest of all, hybrids between the two, are a much more appropriate platform for running corporate applications.

/assets/articlefigs/5112.jpg

While powerful, they don't match the capabilities of desktop or even laptop machines. And they vary widely in display capabilities. So, you have to start thinking about alternate ways to input data (voice input, one-handed operation), ways to slim down your fat desktop client applications (splitting screens, eliminating rarely-used features), and ways to write applications that are conducive to intermittent connectivity (local data-caching, better error messages, fallback plans). And, of course, there are new and serious security concerns.



Alternate input brings new data types into play. Suppose, for example, your users need to fill out a form. A text-based cell phone is not an ideal medium for inputting text manually; such applications will work better with voice input. Similarly, small form-factor devices, even when equipped with keyboard input, usually work best with one-handed input. Neither is conducive to entering raw text. Instead, you need to let users select from lists and do abbreviated one-handed typing and selection.

Finally, you want these applications to run on the same back end as the current desktop applications—and users need to be able to move seamlessly between them. Therefore, the data that you collect from these mobile devices needs to be compatible with the data you already have; you need to be able to translate voice data into text data and vice versa.

As multimedia applications and location-enabled (GPS) applications come into play, you'll need to be able to translate GPS location information into an appropriate data type, for example, using an employee's location to display a map containing new route information. The point is that the proliferation of devices and their new data capabilities are causing new interoperability needs for data, as well as for applications.

Fat desktop applications just don't fit on the small screens of mobile devices. The need to separate UI from application logic is more imperative now than it ever has been. For example, displaying a grid containing the contents of a database table might be simple on a full screen desktop application, but translating that directly to a smaller screen, perhaps by breaking the display into multiple pages, simply causes problems for users. You need to think about alternate ways to preserve the functionality of the application while delivering a user interface appropriate for a smaller screen.

With wireless applications, it can be far more catastrophic when connectivity is suddenly lost—the devices often require a reboot to continue—and it's far more confusing for users to pick up where they left off.

Just as developers' techniques had to change to move from standalone computing to client server computing to Web-based computing, they are going to have to change to take wireless connectivity issues into account. First, you need to consider how your application responds when users aren't connected, and second, how your application responds when connectivity is suddenly interrupted.

Sudden loss of connectivity is not a new problem—developers had to address this issue more than five years ago when Web-based applications became mainstream, but there is a difference. Users have learned to work around failures in their wired Web applications; when connectivity is lost from a wired client browser, users generally know what's happened and what to do to proceed. With wireless applications, it can be far more catastrophic when connectivity is suddenly lost—the devices often require a reboot to continue—and it's far more confusing for users to pick up where they left off.

To do all of that, you need to understand what the devices are and how their varied capabilities affect what you write. So what devices do you need to be concerned with, as a corporate developer?

  • Smartphones
  • PDAs
  • PDA/Phone combinations
  • Wireless-enabled laptops
  • Tablet PCs
  • RIM Blackberry


See the sidebar "Inspecting the Ranks" for a representative sampling of the device marketplace today.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap