Engineering Wireless Mobile Applications - unibzricci/MS/Material/engineering-wireless...Engineering...

Int. J. of Information Technology and Web Engineering, 1(1), 59-75, January-March 2006 59

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc.is prohibited.

Engineering WirelessMobile Applications

Qusay H. Mahmoud, University of Guelph, Canada

Zakaria Maamar, Zayed University, United Arab Emirates

ABSTRACT

Conventional desktop software applications are usually designed, built, and tested on a platformsimilar to the one on which they will be deployed and run. Wireless mobile applicationdevelopment, on the other hand, is more challenging because applications are developed onone platform (like UNIX or Windows) and deployed on a totally different platform like acellular phone. While wireless applications can be much smaller than conventional desktopapplications, developers should think in small terms of the devices on which the applicationswill run and the environment in which they will operate instead of the amount of code to bewritten. This paper presents a systematic approach to engineering wireless application andoffers practical guidelines for testing them. What is unique about this approach is that it takesinto account the special features of the new medium (mobile devices and wireless networks),the operational environment, and the multiplicity of user backgrounds; all of which pose newchallenges to wireless application development.

Keywords: mobile technologies; process design; screen design; software design; testingactivities; testing issues; wireless technologies

INTRODUCTIONThe general mobile computing model

in a wireless environment consists of twodistinct sets of entities (Figure 1): MobileClients (MCs) and fixed hosts. Some ofthe fixed hosts, called Mobile Support Sta-tions (MSSs), are enhanced with wirelessinterfaces. An MSS can communicate withthe MCs within its radio coverage area

called wireless cell. An MC can communi-cate with a fixed host/server via an MSSover a wireless channel. The wireless chan-nel is logically separated into two sub-chan-nels: an uplink channel and a downlink chan-nel. The uplink channel is used by MCs tosubmit queries to the server via an MSS,whereas the downlink channel is used byMSSs to disseminate information or to for-

IDEA GROUP PUBLISHING

This chapter appears in the publication, International Journal of Information Technology and Web Engineering Volume 1, Issue 1edited by Ghazi Alkhatib and David Rine © 2006, Idea Group Inc.

701 E. Chocolate Avenue, Suite 200, Hershey PA 17033-1240, USATel: 717/533-8845; Fax 717/533-8661; URL-http://www.idea-group.com

ITJ3052

60 Int. J. of Information Technology and Web Engineering, 1(1), 59-75, January-March 2006


ward the responses from the server to atarget client. Each cell has an identifier(CID) for identification purposes. A CIDis periodically broadcasted to all the MCsresiding in a corresponding cell.

A wireless mobile application is de-fined as a software application, a wirelessservice or a mobile service that can be ei-ther pushed to users’ handheld wirelessdevices or downloaded and installed, overthe air, on these devices.1 Such applica-tions must work within the daunting con-straints of the devices themselves:

• Memory: Wireless devices such as cel-lular phones and two-way pagers havelimited amounts of memory, obliging de-velopers to consider memory manage-ment most carefully when designing ap-plication objects.

• Processing power: Wireless devicesalso have limited processing power (16-bit processors are typical).

• Input: Input capabilities are limited. Mostcell phones provide only a one-hand key-pad with twelve buttons: the ten numer-

als, an asterisk (*), and a pound sign (#).• Screen: The display might be as small

as 96 pixels wide by 54 pixels high and 1bit deep (black and white). The amountof information that can be squeezed intosuch a tight screen is severely limited.

In addition, the wireless environmentimposes further constraints: (1) wirelessnetworks are unreliable and expensive, andbandwidth is low; (2) they tend to experi-ence more network errors than wired net-works; and (3) the very mobility of wire-less devices increases the risk that a con-nection will be lost or degraded. In order todesign and build reliable wireless applica-tions, designers need to keep these con-straints in mind and ask themselves, whatimpact do wireless devices with limited re-sources have on application design?

The motivation for this paper is pro-vided in part by the above characteristicsthat form some of the foundations for per-vasive computing environments. Such char-acteristics pose several challenges in design-ing wireless mobile applications for mobile

Figure 1. Mobile computing model

��

��

��

� ��

� ��

��

� ��

��

��

��

� ��

��

��



computing. This paper provides a detailedtreatment of the impact of these character-istics on engineering wireless mobile appli-cations and presents a systematic approachfor designing them. In addition, it offers prac-tical design techniques for wireless applica-tion design and development.

WIRELESS APPLICATIONSWireless applications can be classi-

fied into two streams (Beaulieu, 2002;Burkhardt, Henn, Hepper, Rintdorff, &Schack, 2002):

1. Browser-based: Applications developedusing a markup language. This is similarto the current desktop browser modelwhere the device is equipped with abrowser. The Wireless Application Pro-tocol or WAP (http://www.openmobilealliance.org) follows this approach (OpenMobile Alliance, 2005).

2. Native applications: Compiled applica-tions where the device has a runtimeenvironment to execute applications.Highly interactive wireless applicationsare only possible with the latter model.Interactive applications, such as mobilecomputer games, are a good example.Such applications can be developed us-ing the fast growing Java 2 Micro Edi-tion (J2ME) platform (http://www.java.sun.com/j2me), and they are known asMIDlets.

Another stream is the hybrid applica-tion model that aims at incorporating thebest aspects of both streams above. Thebrowser is used to allow the user to enterURLs to download native applications fromremote servers, and the runtime environ-ment is used to let these applications runon the device.

WAP Might be Dead,but What Did We Learn?

WAP and J2ME MIDP solve similarproblems but each can learn a couple ofthings from the other. There are specialfeatures that are available in WAP but notin MIDP and vice versa. These featuresare summarized as follows:

• MIDP provides a low-level graphicsAPIs that enable the programmer tohave control over every pixel of thedevice’s display. This is important forentertainment applications (such asgames) in a wireless environment.

• MIDP is the way to go for games. Thenature of MIDlets (they exist on thedevice until they are explicitly removed)allows users to run them even when theserver becomes unavailable (support fordisconnected operations).

• WML provides tags and possible pre-sentation attributes, but it doesn’t definean interaction model. For example,WML defines a SELECT tag for pro-viding a list. Some WAP-enabled devicesinterpret the SELECT tag as a popupmenu list while others interpret it as amenu that can be used for navigation.Therefore, there is no standard interac-tion model defined for this element. If adeveloper uses it, the application mayrun well on some devices and poorly onothers. MIDlets, on the other hand, pro-vide a clearly defined standard for in-teraction using commands.

A Micro Browser is NeededMIDlets combine excellent online and

off-line capabilities that are useful for thewireless environment, which suffers fromlow bandwidth and network disconnection.Integrating WAP and MIDP opens up pos-



sibilities for new wireless applications andover the air distribution models. Therefore,WAP and MIDP shouldn’t be viewed ascompeting but rather as complementingtechnologies. In order to facilitate down-loading wireless applications over the air,there is a need for some kind of an envi-ronment on the handset that allows the userto enter a URL for a MIDlet Suite, for ex-ample. This environment could very wellbe a WAP browser as shown in Figure 2.

Similar to Java Applets that are inte-grated into HTML, MIDlets can be inte-grated into a WML or an XHTML page.Such a page can then be called from a WAPbrowser, and the embedded MIDlet getsdownloaded and installed on the device. Inorder to enable this, a WAP browser isneeded on the device. Another alternativeapproach for over-the-air provisioning is theuse of a Short Message Service (SMS)which has been done by Siemens wherethe installation of MIDlets is accomplishedby sending a corresponding SMS. If theSMS contains a URL to a Java ApplicationDescriptor (JAD) file specifying a MIDletSuite, then the recipient can install the ap-plication simply by confirming the SMS.

DESIGN CHALLENGES ANDPOSSIBLE SOLUTIONS

In this paper, we are more concernedwith native interactive applications that can

be developed using the J2ME platform ora similar technology. J2ME-based wirelessapplications can be classified into local(stand-alone) and network applications.Local applications perform all their opera-tions on a handheld wireless device andneed no access to external data sourcesthrough a wireless network. Examples in-clude calculators and single-player games.Network applications, on the other hand,consist of some components running on awireless device and others running on anetwork, and thus depend on access toexternal resources. An example would bean e-mail application with a client residingon a wireless phone interacting with aSimple Mail Transfer Protocol (SMTP)server to send/receive e-mail messages. Amajor difference between local and net-worked applications is in the way they aretested. Local applications are easier to testthan network applications. For example, acalculator application can run on a wire-less device even when it is not connectedto any network, but an e-mail client will notwork without a connection to e-mail serv-ers.

ChallengesThe constraints discussed earlier pose

several crucial challenges, which must befaced in order for wireless applications tofunction correctly in the target environment.

• Transmission errors: Messages sentover wireless links are exposed to inter-ference (and varying delays) that canalter the content received by the user,the target device, or the server. Appli-cations must be prepared to handle theseproblems. Transmission errors may oc-cur at any point in a wireless transac-tion and at any point during the sending

Figure 2. Combining WAP and J2ME

�



or receiving of a message. They canoccur after a request has been initiated,in the middle of the transaction, or aftera reply has been sent. While wirelessnetwork protocols may be able to de-tect and correct some errors, error-han-dling strategies that address all kinds oftransmission errors that are likely to oc-cur are still needed.

• Message latency: Message latency, orthe time it takes to deliver a message, isprimarily affected by the nature of eachsystem that handles the message, andby the processing time needed and de-lays that may occur at each node fromorigin to destination. Message latencyshould be taken into account and usersof wireless applications should be keptinformed of processing delays. It is es-pecially important to remember that amessage may be delivered to a user longafter the time it is sent. A long delay mightbe due to coverage problems or trans-mission errors, or the user’s device mightbe switched off or have a dead battery.Some systems keep trying, at differenttimes, to transmit the message until it isdelivered. Other systems store the mes-sage then deliver it when the device isreconnected to the network. Therefore,it is important to design applications thatavoid sending stale information, or atleast to make sure that users are awarethat it is not up-to-date. Imagine the pos-sible consequences of sending a stockquote that is three days old without warn-ing the user!

• Security: Any information transmittedover wireless links is subject to inter-ception. Some of that information couldbe sensitive, like credit card numbers andother personal information. The solutionneeded really depends on the level of

sensitivity. To provide a complete end-to-end security solution, you must imple-ment it on both ends, the client and theserver, and assure yourself that inter-mediary systems are secure as well.

Possible SolutionsHere are some practical hints useful to

consider when developing mobile applications.

• Understand the environment. Do someresearch upfront. As with developing anyother software application, we must un-derstand the needs of the potential us-ers and the requirements imposed by allnetworks and systems the service willrely on.

• Choose an appropriate architecture.The architecture of the mobile applica-tion is very important. No optimizationtechniques will make up for an ill-con-sidered architecture. The two most im-portant design goals should be to mini-mize the amount of data transmitted overthe wireless link, and to anticipate er-rors and handle them intelligently.

• Partition the application. Think care-fully when deciding which operationsshould be performed on the server andwhich on the handheld device.Downloadable wireless applications al-low locating much of an application’sfunctionality of the device; it can retrievedata from the server efficiently, thenperform calculations and display infor-mation locally. This approach can dra-matically reduce costly interaction overthe wireless link, but it is feasible only ifthe device can handle the processing thatthe application needs to perform.

• Use compact data representation. Datacan be represented in many forms, somemore compact than others. Consider the



available representations and select theone that requires fewer bits to be trans-mitted. For example, numbers will usu-ally be much more compact if transmit-ted in binary rather than string forms.

• Manage message latency. In someapplications, it may be possible to do otherwork while a message is being pro-cessed. If the delay is appreciable —and especially if the information is likelyto go stale — it is important to keep theuser informed of progress. Design theuser interface of your applications tohandle message latency appropriately.

• Simplify the interface. Keep theapplication’s interface simple enough thatthe user seldom needs to refer to a usermanual to perform a task. To do so: re-duce the amount of information displayedon the device; make input sequencesconcise so the user can accomplish taskswith the minimum number of buttonclicks; and offer the user selection lists.

AD-HOC DEVELOPMENTPROCESS

An ad-hoc development process forwireless applications comprises three steps:

1. Write the application. Several IntegratedDevelopment Environments (IDEs) areavailable for developing Java-basedwireless applications, for example, Sun’sJ2ME Wireless Toolkit, and MetrowerksCodeWarrior.

2. Test the application in an emulation envi-ronment. Once the application compilesnicely, it can be tested in an emulator.

3. Download the application to a physicaldevice and test it. Once the application’sperformance is satisfactory on one ormore emulators, it can be downloadedto a real device and tested there. If it is

a network application, it is tested on alive wireless network to ensure that itsperformance is acceptable.

It is clear that many important soft-ware engineering activities are missingfrom this ad-hoc development process. Forexample, there is no formal requirementsanalysis phase, and so following an ad-hocdevelopment process may lead to buildinga product different from the one custom-ers want. Also, testing an application with-out knowing its requirements is not an easytask. In addition, issues related to the oper-ating environment such as network band-width should be considered during the de-sign so that the performance of the appli-cation will be satisfactory.

WIRELESS SOFTWAREENGINEERING

While wireless application develop-ment might appear to have less need forthe coordination that a process provides,aspects of development, testing, evaluation,deployment, and maintenance of a wire-less application have to be integrated in thedesign process throughout the full devel-opment life cycle. We have put forward asystematic approach to developing wire-less applications, which is compatible withthe Rational Unified Process or RUP(Jacobsen, Booch, & Rumbaugh, 2000) inthe sense that it is iterative and responsibil-ity-driven. We have developed this system-atic approach based on our experience de-signing and building wireless applications.We recognized that the development of awireless application is not a one-shot task,and testing wireless applications is morechallenging than testing conventional desk-top software applications; therefore, an ad-hoc development process cannot be used.



Development ActivitiesOur software engineering approach to

wireless application development consists ofa set of manageable activities that, if fol-lowed properly, leads to reliable and main-tainable wireless applications. The activitiesof our approach are shown in Figure 3.

Planning. This iterative process be-gins with a planning phase, which is an ac-tivity that identifies the objectives of thewireless application and specifies the scopeof the first increment. In addition, the costsof the overall project are estimated, therisks are evaluated, and a tentative sched-ule is set.

Mobile user analysis. First, wemust understand the audience of the appli-cation and the environment in which it willoperate. As an example, if the applicationis a wireless network-aware applicationsuch as a multi-player game, the study willinclude the users of the application and how

they plan to use it. The output at the end ofthis phase is a wireless application plandocument that serves as the mobile end-user requirement.

Scenario analysis. This phase is simi-lar to conventional software requirementsanalysis, and therefore concepts and prin-ciples of requirements analysis can be ap-plied here (Pressman, 2005). In this phase,the mobile end user, an interaction designer,and a developer sit together to come upwith a complete scenario analysis modelthat takes into account the following typesof scenario analysis:

• Screen and interaction analysis: Thebasic unit of interaction between the userand the mobile device is the screen,which is an object that encapsulates de-vice-specific graphic user input. There-fore, the content to be displayed on thescreen is identified. Content may includetext fields, menus, lists, and graphics.

Figure 3. Wireless application development activities



Interaction analysis specifies how theuser interacts with the application. Inorder to find out how the user will inter-act with the application, UML (Boochet al., 2000) use cases are developed.

• Usage analysis: The use case modeldeveloped during screen and interactionanalysis is mainly related to how usersinteract with the application through thescreen. The whole functionality of theapplication should be described with usecases.

• Environment analysis: The environ-ment in which the application will oper-ate should be described in detail. Thisincludes the different wireless networksand back-end systems used. In addition,target mobile devices such as cellularphones and PDAs on which the appli-cation will run should be described indetail.

The output of this phase is an infor-mation analysis model document producedby the interaction designer and developerthat outlines the functional requirements ofthe application and the constraints of theenvironment. This document is reviewedby developers and other stakeholders andmodified as required.

Architectural design. This phase isconcerned with the overall architecture (orstructure) of the wireless application. Ar-chitecture is very important for any appli-cation, and no optimization techniques willmake up for an ill-considered architecture.Design patterns can be used in this phaseto reuse experience in order to come upwith an extensible, high-performance ar-chitecture. Some of the most importantdesign goals should be to minimize theamount of data transmitted over the wire-

less link, and to anticipate errors and handlethem intelligently. Other design and archi-tecture issues include:

• Application partitioning. Designersneed to think carefully when decidingwhich operations should be performedon the server and which on the wirelessdevice. J2ME allows designers to locatemuch of an application’s functionality onthe device; it can retrieve data from theserver efficiently, then perform calcula-tions and display information locally. Thisapproach can dramatically reduce costlyinteraction over the wireless link, but itis feasible only if the device can handlethe processing your application needs toperform.

• Message latency. In some applications,it may be possible to do other work whilea message is being processed. If thedelay is appreciable — and especially ifthe information is likely to go stale — itis important to keep the user informedof progress.

The outcome of the architectural de-sign phase is a design document that de-tails the system architecture.

Navigation and user interface de-sign. Once the application architecture hasbeen established and its components iden-tified, the interaction designer preparesscreen mockups and navigation paths thatshow how the user moves from one screento another to access services. Figure 4shows a simple example where the userwill have to login before she is able to checkher messages.

The user interface is the face of theapplication to users. A poorly designed user-interface will scare the user away, and a



well-designed user interface will give a goodfirst impression and improves the user’sperception of the services offered by theapplication. The user interface must bewell-structured and easy to use. Here aresome guidelines that can help in designingsimple yet effective user interfaces formobile devices with tiny screens.

• Keep the application’s interface simpleenough that the user seldom needs torefer to a user manual to perform a task.

• Reduce the amount of information dis-played on the device.

• Make input sequences concise so theuser can accomplish tasks with the mini-mum number of button clicks.

• Offer the user selection lists.• Do not depend on any specific screen

size.

The output of this phase is a usermanual that describes the screen mockupsand the navigational paths.

Implementation. In this phase de-velopment tools are used to implement thewireless application. There are several toolsavailable for building wireless applicationssuch as Sun’s J2ME Wireless Toolkit. Wewould recommend using a tool that allowsinstalling the application in various emula-tion environments. Conventional implemen-

tation strategies and techniques such ascoding standards and code reviews can beused in this phase.

Testing. Software testing is a sys-temic process to find differences betweenthe expected behavior of the system speci-fied in the software requirements docu-ment and its observed behavior. In otherwords, it is an activity for finding errors inthe software system and fixing them sousers can be confident that they can de-pend on the software. Errors in softwareare generally introduced by people involvedin software development (including ana-lysts, architects, designers, programmers,and the testers themselves). Examples oferrors include mismatch between require-ments and implementation.

Many developers view the subject ofsoftware testing as “not fashionable,” and,as a result, too few of them really under-stand the job software testers do. Testingis an iterative process and should start fromthe beginning of the project. Software de-velopers need to get used to the idea ofdesigning software with testing in mind.Some of the new software developmentmethodologies such as eXtreme Program-ming (XP) (Beck, 1999) stress incremen-tal development and testing. XP is ideallysuited for some types of applications, de-pending on their size, scope, and nature.

Figure 4. Screen mockups



User interface design, for example, ben-efits highly from rapid prototyping and test-ing usability with actual users.

Wireless applications, like all othertypes of software, must be tested to en-sure functionality and usability under allworking conditions. Testing is even moreimportant in the wireless world becauseworking conditions vary a lot more than theydo for most software. For example, wire-less applications are developed on high-enddesktop machines but deployed onhandheld wireless devices with very dif-ferent characteristics.

One way to make testing simple is todesign applications with testing in mind.Organizing the system in a certain way canmake it much easier to test. Another impli-cation is that the system must have enoughfunctionality and enough output informa-tion to distinguish among the system’s dif-ferent functional features. In our approach,and similar to many others, the system’sfunctional requirements (features that thesystem must provide) are described usingthe Unified Modeling Language (Booch etal., 2000) to create a use-case model, thendetailing the use cases in a consistent writ-ten form. Documenting the various uses ofthe system in this way simplifies the taskof testing the system by allowing the testerto generate test scenarios from the usecases. The scenarios represent all expectedpaths users will traverse when they use thefeatures that the system must provide.

Deployment. Deploying and runningapplications in an emulation environment isa very good way to test the logic and flowof your application generally, but you willnot be certain it will satisfy users until youtest it on a real physical device connectedto a wireless network. Your application’s

performance may be stunning in the emu-lator, which has all the processing powerand memory of your desktop machine atits command, but will it perform well onthe handheld device, with its limitedmemory and processing power, low band-width, and other constraints? In this phase,the application is deployed on a live net-work and evaluated.

Customer Evaluation. Once the ap-plication has been deployed, it is ready tobe downloaded by users for evaluation andusage. In this phase, users start using thedeployed application and report any prob-lems they may experience to the serviceprovider.

Maintenance. Software mainte-nance encompasses four activities: errorcorrection, adaptation, enhancement, andreengineering (Pressman, 2005). The ap-plication will evolve over time as errors arefixed and customers request new features.In this phase, users report errors to andrequest new features from the service pro-vider, and developers fix errors and en-hance the application.

TESTING ISSUES ANDTESTING ACTIVITIES

The wide variety of mobile devicessuch as wireless phones and PDAs re-sults in each device running a differentimplementation of the J2ME environment.Varying display sizes add to the complex-ity of the testing process. In addition, somevendors provide proprietary API exten-sions. As an example, some J2ME ven-dors may support only the HTTP proto-col, which the MIDP 1.0 specification re-quires, while others support TCP socketsand UDP datagrams, which are optional.



Here are some guidelines for testing wire-less applications.

Implementation Validation. Ensur-ing that the application does what it is sup-posed to be is an iterative process that youmust go through during the implementationphase of the project. Part of the validationprocess can be done in an emulation envi-ronment such as the J2ME Wireless Toolkit(Sun Microsystems, 2005), which providesseveral phone skills and standard inputmechanisms. The toolkit’s emulation envi-ronment does not support all devices andplatform extensions, but it allows for theapplication to look appealing and to offer auser-friendly interface on a wide range ofdevices. Once the application has beentested on an emulator, you can move on tothe next step and test it on a real device,and in a live network.

Usability Testing. In usability test-ing, the focus is on the external interfaceand the relationships among the screens ofthe application. As an example, consideran e-mail application that supports entry andvalidation of a user name and password,enables the user to read, compose, and sendmessages, and allows maintenance of re-lated settings, using the screens shown inFigure 3, among others.

In this example, start the test at theLogin window. Enter a user name and a pass-word and press the soft button labeled Login.Enter a valid user name and password. Theapplication should display the main menu.Does it? The main menu should display aSignOut button. Does it? Press the SignOutbutton. Does the application return to theLogin screen? Write yourself a note to raisethe question, “Why does the user ‘log’ in but‘sign’ out?” Now enter an invalid user name

or password. The program should display ameaningful message box with an OK button.Does it? Press the OK button. Does the ap-plication return to the Login screen?

You need to test the GUI navigationof the entire system, making notes aboutusability along the way. If, for example, theuser must traverse several screens to per-form a function that’s likely to be verypopular, you may wish to consider movingthat particular function up the screen lay-ers. Some of the questions you should askduring usability testing include: is the navi-gation depth (the number of screens theuser must go through) appropriate for eachparticular function, does the applicationminimize text entry (painful on a wirelessphone) or should it provide more selectionmenus, can screens of all supported de-vices display the content without truncat-ing it, and if you expect to deploy the appli-cation on foreign devices, does it supportinternational character sets?

Network Performance Testing.The goal of this type of testing is to verifythat the application performs well in thehardest of conditions (for example, whenthe battery is low or the phone is passingthrough a tunnel). Testing performance inan emulated wireless network is very im-portant. The drawback with testing in a livewireless network is that so many factorsaffect the performance of the network it-self that you cannot repeat the exact testscenarios. In an emulated network envi-ronment, it is easy to record the result of atest and repeat it later, after you have modi-fied the application, to verify that the per-formance of the application has improved.

Server-Side Testing. It is very likelythat wireless applications communicate with



server-side applications. If your applicationcommunicates with servers you control,you have a free hand to test both ends ofthe application. If it communicates withservers beyond your control (such asquotes.yahoo.com), you just need to findthe prerequisites of use and make the bestof them. You can test server-side applica-tions that communicate over HTTP con-nections using testing frameworks such asHttpUnit (http://httpunit.sourceforge.net),and measure a Web site’s performanceusing httperf (http://citeseer.nj.nec.com/mosberger98httperf.html), a tool designedfor measuring the performance of Webservers.

Testing ChecklistsHere we provide checklists that are

useful when testing your application, in bothemulation and live environments. Thesechecklists include tests that are usually per-formed by certification programs offeredby Nokia and Motorola (Motorola Appli-cation Certification Program).

Navigation Checklist. Here aresome items to check for when testing thenavigational paths of wireless applications:

• Successful startup and exit: Verify thatyour application starts up properly andits entry point is consistent. Also makesure that the application exits properly.

• Application name: Make sure your ap-plication displays a name in the title bar.

• Keep the user informed: If your appli-cation does not start up within a few sec-onds, it should alert the user. For largeapplications, it is a good idea to have aprogress bar.

• Readable text: Ensure that all kinds ofcontent are readable on both grayscale

and color devices. Also make sure thetext does not contain any misspelledwords.

• Repainting screens: Verify that screensare properly painted and that the appli-cation does not cause unnecessaryscreen repaints.

• Soft buttons: Verify that the functional-ity of soft buttons is consistent through-out the application. Verify that the wholelayout of screens and buttons is consis-tent.

• Screen navigation: Verify that the mostcommonly used screens are easily ac-cessible.

• Portability: Verify that the applicationwill have the same friendly user inter-face on all devices it is likely to be de-ployed on.

Network Checklist. Some of theitems that should be inspected when test-ing wireless applications are:

• Sending/Receiving data: For network-aware applications, verify that the ap-plication sends and receives data prop-erly.

• Name resolution: Ensure that the ap-plication resolves IP addresses correctly,and sends and receives data properly.

• Sensitive data: When transmitting sen-sitive data over the network, verify thatthe data is being masked or encrypted.

• Error handling: Make sure that errormessages concerning network error con-ditions (such as no network coverage)are displayed properly, and that whenan error message box is dismissed, theapplication regains control.

• Interruptions: Verify that, when the de-vice receives system alerts, SMS mes-



sages, and so on while the application isrunning, messages are properly dis-played. Also make sure that when themessage box is dismissed the applica-tion continues to function properly.

PROVISIONINGWIRELESS APPLICATIONS

Developers usually build, test, andevaluate an application on a platform simi-lar to the one on which it will be deployedand ran. Development of wireless applica-tions is more challenging because they typi-cally are developed on one platform (suchas Solaris or MS Windows) but deployedon a totally different one (such as a cellphone or PDA). One consequence is that,while emulators enable developers to dosome of their testing on the developmentplatform, ultimately they must test andevaluate the application in the very differ-ent environment of a live wireless network.

Wireless applications fall into twobroad categories:

• Local applications perform all their op-erations on a handheld wireless deviceand need no access to external datasources through a wireless network.Examples include calculators and single-player games.

• Network applications consist of somecomponents running on a wireless de-vice and others running on a network,and thus depend on access to externalresources. An example would be an e-mail application, with a client residing ona wireless phone that interacts with anSMTP server to send messages.

Although these two types of applica-tions are different, they are deployed in thesame way. The big difference shows up

later: Local applications are easier to testthan network applications. For example, acalculator application can run on a wire-less phone even when it is not connectedto any network, but an e-mail client won’twork without a connection to the SMTPserver that actually transmits the messages.

Over the Air ProvisioningFor some time, wireless portals in

Europe such as Midletcentral have allowedcustomers to download applications directlyto their phones, over the air. Over-the-airprovisioning of wireless applications (OTA)is finally available in North America. Nextelcustomers, for example, can download net-work-aware wireless applications withoutan update data cable. OTA is the deploy-ment of wireless Java applications (MIDletsuites) from the Internet to wireless devicesover a wireless network. Users need notconnect their devices to the desktop with adata cable or visit a service center to installor upgrade software. To take advantage ofOTA, you must equip your handheld devicewith a mechanism to discover MIDlet suitesavailable for download, using the device’sbrowser (such as a WAP browser) or a resi-dent application written specifically to iden-tify downloadable MIDlet suites. The pro-cess of downloading MIDlets over the air isillustrated in Figure 5.

RELATED WORKThe explosive growth of the wireless

mobile application market raises new engi-neering challenges (Morisio & Oivo, 2003);what is the impact of the wireless Interneton engineering wireless mobile applicationsfor the new wireless infrastructure andwireless handheld devices? Due to the lim-ited experience with wireless technologiesand developing wireless applications, little



work has been in the area of wireless soft-ware engineering. We found a special is-sue in the IEEE Transactions on SoftwareEngineering on “Software Engineering forthe Wireless Internet” (Morisio & Oivo,2003). However, out of the six papers ac-cepted in the special issue only two papersdeal with the development process.Ocampo, Boggio, Munch, and Palladino(2003) provided an initial reference processfor developing wireless Internet applica-tions, which does not differ significantlyfrom traditional iterative process models butincludes domain-specific guidance on thelevel of engineering processes. Satoh(2003) developed a framework for build-ing and testing networked applications formobile computing. The framework is aimedto emulate the physical mobility of portablecomputing devices through the logical mo-bility of applications designed to run onthem; an agent-based emulator is used toperform application-level emulation of itstarget device.

More recently, Chen (2004) proposeda methodology to help enterprises develop

business strategies and architectures formobile applications. It is an attempt to for-mulate a life cycle approach to assistingenterprises in planning and developing en-terprise-wide mobile strategies and appli-cations. This methodology is more con-cerned with business strategies rather thantechnical details, and thus it is targeted atmanagers rather than developers. And fi-nally, Nikkanen (2004) presented the de-velopment work of a browser-agnosticmobile e-mail application. It reports on ex-periences porting a legacy WAP productto a new XHTML-based browser applica-tion and offers guidelines for developingmobile applications.

Our work is different in the sense thatwe provide a detailed treatment of the im-pact of the characteristics of mobile de-vices and the wireless environment on en-gineering wireless mobile applications; wediscuss the challenges and offer practicalsolutions for developing mobile applications.We present a systematic approach for de-signing wireless mobile application. Ourapproach is iterative just like in Ocampo et

Figure 5. Over-the-air provisioning



al. (2003), but differs in the sense that ourprocess has more focus on requirementselicitation and more importantly scenarioanalysis. We do not provide a testingframework, but our testing strategy andchecklist is more practical than using justan emulated environment. Finally, unlike thework reported in Chen (2004), our method-ology is targeted at developers and research-ers rather than managers. And, unlike thework in Nikkanen (2004), our guidelines andsystematic approach is not limited to WAP-based applications, but can be applied toengineering any wireless application.

CONCLUSION ANDFUTURE WORK

As the wireless Internet becomes areality and software developers becomecomfortable with the methods and pro-cesses required to build software, we rec-ognize that the methods developed for con-ventional systems are not optimal for wire-less applications. In particular, wirelessapplication development doesn’t always fitinto the development model originated tocope with conventional large software sys-tems. Most wireless application systemswill be smaller than any medium-sizeproject; however, a software developmentmethod can be just as critical to a smallsoftware project success as it is to that ofa large one. In this paper, we have pre-sented and discussed a systematic approachto wireless application development, andpresented practical guidelines for testingwireless applications. The proposed ap-proach takes into account the special fea-tures of the wireless environment. We havesuccessfully used the approach presentedto develop various wireless applicationsranging from a stock portfolio management

application to a mobile agent platform formobile devices (Mahmoud, 2002). Our fu-ture work includes evaluating the effective-ness of the proposed methodology, docu-menting wireless software design patterns,and building tools to automate the task oftesting wireless applications.

There are several interesting researchproblems in the emerging area of wirelessmobile applications and services. Some ofthese research issues include: novel mo-bile services in the area of m-commerceand health care; security and privacy is-sues; mobile agents for mobile services;discovery and interaction of mobile services;enabling roaming of applications and pro-files between different wireless standards;and location-aware and context-awaremobile services. We are currently address-ing some of these research problems, andresearch results will be presented in futurearticles.

ACKNOWLEDGMENTSThe authors would like to thank the

anonymous reviewers for the many help-ful suggestions for improving this paper. Thefirst author was supported in part by theNatural Sciences and Engineering Re-search Council of Canada (NSERC) Dis-covery Grant No. 045635.

REFERENCESBeaulieu, M. (2002). Wireless Internet

applications and architecture. Boston:Addison-Wesley.

Beck, K. (1999). Extreme programmingexplained: Embrace change. Addison-Wesley.

Booch, G., Rumbaugh, J., & Jacobsen, I.(2000). The Unified Modeling Lan-guage user guide. Boston: Addison-Wesley.



Burkhardt, J, Henn, H., Hepper, S.,Rintdorff, K., & Schack, T. (2002). Per-vasive computing technology and ar-chitecture of mobile Internet applica-tions. London: Addison-Wesley.

Chen, M. (2004). A methodology for build-ing mobile computing applications. In-ternational Journal of ElectronicBusiness, 2(3), 229-243.

Jacobsen, I., Booch, G., & Rumbaugh, J.(2000). The unified software develop-ment process. Boston: Addison-Wesley.

Httperf. Retrieved January 13, 2005, fromhttp://www.hpl.hp.com/research/linux/httperf

HttpUnit. Retrieved January 13, 2005, fromhttp://httpunit.sourceforge.net

Mahmoud, Q. (2002). MobiAgent: Anagent-based approach to the wirelessInternet. Journal of Internet Comput-ing, special issue on Wireless Internet,3(2), 157-162.

Morisio, M., & Oivo, M. (2003). Softwareengineering for the wireless Internet[Guest Editor’s Introduction]. IEEETransactions on Software Engineer-ing, 29(12), 1057-1058.

Motorola Application Certification Program.(n.d.). Retrieved February 10, 2005,from http://qpqa.com/motorola/iden

Nikkanen, M. (2004). User-centered de-velopment of a browser-agnostic mobilee-mail application. In Proceedings ofthe Third Nordic Conference on Hu-man-Computer Interaction, Tampere,Finland (pp. 53-56). New York: ACMPress.

Ocampo, A., Boggio, D., Munch, J., &Palladino, G. (2003). Towards a refer-ence process for developing wirelessInternet services. IEEE Transactionson Software Engineering, 29(12),1122-1134.

Open Mobile Alliance. (2005). Retrievedfrom March 15, 2005, http://www.openmobilealliance.org

Pressman, R. S. (2005). Software engi-neering: A practitioner’s approach(6th ed.). New York: McGraw Hill.

Satoh, I. (2003). A testing framework formobile computing software. IEEETransactions on Software Engineer-ing, 29(12), 1112-1121.

Sun Microsystems J2ME. (2005). Re-trieved from http://java.sun.com/j2me

Sun Microsystems J2ME Wireless Toolkit.(2005). Retrieved from http://java.sun.com/products/j2mewtoolkit

ENDNOTE1 We use the terms wireless application

and mobile application interchangeablythroughout this article.



Qusay H. Mahmoud ([email protected]) earned his PhD in computerscience from Middlesex University (UK) in 2002. Currently, he is an assistantprofessor in the Department of Computing and Information Science, University ofGuelph, and associate chair of the Distributed Systems and Wireless &Telecommunications Systems Technology program at the University of Guelph-Humber. His research interests include wireless computing, agent technology, andWeb-based systems.

Zakaria Maamar ([email protected]) earned his PhD in computer sciencefrom Laval University (Canada) in 1998. Currently, he is an associate professor inthe College of Information Systems, Zayed University (Dubai, UAE). His researchinterests lie in the areas of mobile computing, Web/mobile services, and softwareagents.

Engineering Wireless Mobile Applications - unibzricci/MS/Material/engineering-wireless...Engineering...

Documents

Transcript of Engineering Wireless Mobile Applications - unibzricci/MS/Material/engineering-wireless...Engineering...