software for mobile
Maybe you should start by selecting the best development environment. Is it Sun’s J2ME (Java), Qualcomm’s BREW, or perhaps Microsoft’s .Net Mobile? Or maybe it would be better to begin with the development process itself. After all, an interactive wireless-cellular application is developed differently than an ordinary desktop-PC, client-intensive application. But exactly how is it different?
You might start by going to the typical resources for answers: Steve McConnell’s “Software Project Survival Guide,” the Software Engineering Institute’s (SEI) Web site, or maybe just a book on extreme programming. While all of these are excellent resources for generic software-development activities, they don’t adequately confront the unique constraints found in wireless systems.
In frustration, you search the Internet for resources on wireless development. One listing immediately catches your eye. It is a book by Mark Beaulieu titled, Wireless Internet Applications and Architec-tures: Building Professional Wireless Applications Worldwide (Addison-Wesley, 2001). After a quick visit to Amazon.com, the book arrives on your desk the next morning. It contains all of the nitty-gritty information that you need to successfully create your “killer app.”
In an effort to appreciate the differences and similarities between application development in a wired versus a wireless environment, you put together the following comparisons starting with Mark Beaulieu’s basic outline for wireless development:
“Study the mobile user. Successful developers take time to characterize a persona, introduce themselves to mobile users, and become familiar with their patterns of work.” This is roughly the equivalent of the process that leads to the operational concept document (OCD) in generic software projects.
“Create a mobile database with content. Build a database with real content first. Content is the stuff that users gather, send, and receive.” This is equivalent to rapid prototyping—an approach that serves both as proof-of-concept and as a means to flesh out requirements and system constraints early in the development process.
“Design a logical application. The logic of the way the content is or will be used comes next. This involves techniques for creation, access, navigation, and ordering of the application and its content.” Having understood the problem in general via the OCD and decomposed the high-level-objective requirements into actual specifications, the developer can now write code. The focus here is on the application that resides on the mobile device. But as Mark Beaulieu points out, the back-office application that manages the mobile user’s content on the server cannot be forgotten. Simulators are needed because mobile devices are quite different from desktop PCs in terms of processor speeds, memory sizes, and power consumption.
“Use a real wireless network and device. Exactly how the content is styled and how the interface is physically controlled are refined at the end of the development process.” This is the same as the system validation and verification (V&V) stage of a typical software-development project. Yet the wireless environment presents many challenges—perhaps the two biggest being network drops and bandwidth fluctuations. In the real mobile world, wireless networks constantly disconnect from the device. Similarly, fluctuating bandwidths cause the request/response drive applets of many wireless applications to be intermittently non-responsive.
One quickly realizes that developing a wireless application is a unique process. It’s more akin to client-server database applications (or in Mark Beaulieu’s words, “field-application and back-office administrative applications”) than to pure client-side, PC-based software. The wireless environment itself provides several constraints, such as limited power consumption, clock cycles (yes, the two are related), and application/memory space. Yet despite the challenges faced by developers, success still depends on a sound engineered approach—just as with any software project.