The Development Process

The Development Process

Developing mobile and wireless applications will be a new experience for most business application developers, who usually have not had experience working with limited memory and screen sizes. Moreover, most developers are used to working over reliable networks, commonly TCP/IP or HTTP, and to designing, developing, and testing their applications on the same machine. They have not had to worry about the deployment issues that arise when deploying to several machines, all with different characteristics from the one being used for development. Welcome to the world of mobile application development.

Mobile devices vary in shape and size, thereby adding new complexities for the user interface design and resource management. These devices communicate over a variety of wireless networks, often not even IP-based, let alone TCP/IP or HTTP. Finally, the application development does not take place on the target platform, so emulators are commonly used to help make the development and testing cycle more manageable.

To begin the development process discussion, we are going to take a look at the phases involved in designing a successful mobile solution, as depicted in Figure 8.1.

Click To expand Figure 8.1: Smart client development cycle.

Needs Analysis Phase

A wide variety of mobile solutions are on the market, including voice-based solutions, wireless Internet applications, smart client applications, and messaging-based applications. Which type is best suited for your current project? The answer to that question must be determined during the needs analysis phase of your mobile application development process.

Questions to Ask When Researching User Requirements

While you are researching the user requirements, the following are some questions you may want to ask yourself:

  • Who are the end users of this application?

  • What is their technical skill level?

  • What is the overall goal of this application?

  • What data integration is required? Does the user require data access at all times?

  • Does this application require wireless connectivity? If so, what type of wireless access does it require, and in which geographies?

  • What are the primary usage scenarios for this application?

Try to answer most, if not all, of these questions before beginning to research the device, operating system, and development platform you are going to use. It is very easy to focus on the device and related operating system before determining the actual needs of the end user. If you fall into this trap, be careful not to let the device determine the features of the application. A complete application analysis will lead you to a solution that will be well received by the end user.

Things to Consider

As we consider the issues inherent to gathering the application requirements, we are going to focus on those related to smart client applications. (In Chapter 12, "Thin Client Development," we will look explicitly at the requirements relevant to wireless Internet applications. In Chapter 4, "Mobile Application Architectures," we gave an overview of smart client and thin client applications and the benefits—and drawbacks—related to each architecture type.) Once we gather information about the following items, we can make an educated decision on the solution that is most appropriate, including the operating system, device, wireless network provider, and development platform.

Application Goals

Across the globe, companies are implementing mobile and wireless applications for a variety of reasons. In some cases, the goal is to increase productivity; in others, it is to reduce costs; while in still others, the reason may be simply that it seemed like the next logical thing to do, regardless of the return on the investment. Whatever the reason, it is important that the final solution satisfy the original purpose of development.

During the needs analysis stage, it is important to determine why the project is being undertaken and to produce a result that is in line with expectations. If, say, the project is being implemented to automate order entry, thereby reducing paperwork, the final application should be well suited for rapid data entry, with integration back into the enterprise system. The technical features being implemented should correspond to a business problem that it will solve. By creating a user interface that allows for rapid data entry, we are solving the order entry problem. By having enterprise integration, we are ensuring that the data entered on the mobile device will flow into the back-end system without requiring additional paperwork. These are just a few examples of how technology can help a corporation meet its business goals as it implements a mobile solution.

End User

The end users of the application play a key role in the application design and rollout. Their level of technical ability determines some of the intricacies that may be required. If the user is not comfortable setting up wireless network connection parameters, such details will need to be automated within the application. If the user does not have experience with pen-based input devices, using a device with an alphanumeric keyboard may be more appropriate. Many mobile applications fail to reach their potential because they were not developed with the end user in mind.

Data Access

Extending corporate data to mobile users is essential to many mobile solutions. If this is the goal of the application being developed, then data integration and client storage options will have to be considered. Other factors to consider are how fresh the data must be on the client, how much data should reside on the client, and how often inputted data should be sent back to the server. All of these items will factor into the decision on the data storage and synchronization systems being used.

Wireless Access

Not all mobile applications require wireless access. In fact, many applications are better off without it since real time data access is rarely a requirement. Updates can be made over wireline connections, forgoing the need for wireless access. Other reasons for avoiding wireless access include: complexity of implementation, unreliability of the networks, cost of deployment, or lack of performance.

That said, many compelling reasons do exist for incorporating wireless access into a mobile solution. For field services applications, access to updated work orders, inventory analysis, or routing information can be critical to the success of the solution. Determining the level of wireless connectivity will affect both the implementation criteria and the cost of any given solution.

Usage Scenarios

Predicting how an application will be used is not easy. Nevertheless, it should be attempted, because having some idea of possible use can prove helpful for the application design phase. If, for example, an application is going to be used constantly and is critical to the success of the user's job, then battery life of the chosen device must be considered. It would not make sense to choose a device that has a short battery life that requires constant recharging for such an application. On the other hand, if the application is used infrequently but must perform some complex logic, it might be sufficient to choose a device with better processing power but with perhaps a shorter battery life.

The same type of logic applies to the level of wireless connectivity required. If the application will be used in a fixed location, implementing a wireless LAN solution would be more manageable and cost-effective than relying on a wide area wireless network.

Design Phase

After performing the needs analysis, you will have a good idea of the characteristics the solution requires. You will have limited the number of operating systems, devices, and networks to just a handful that will meet your requirements. From these you will need to make a decision as to which solution best meets your needs and addresses your business constraints. When doing this, review your options with an open mind. Try not to gravitate toward a particular solution immediately, as it is difficult to recognize at this point what will be a successful implementation unless you have an unsuccessful solution for comparison.

One way to accomplish this is to review all the solutions that could possibly meet your requirements, without giving any weight to an individual category. So, for example, if an operating system will meet the requirements, but not perhaps as well as another OS, keep it on the list as a potential candidate. The same goes for devices, wireless networks, and development platforms. After you have gone through this process, ideally you will have two or three possible solutions on which you can concentrate.

Now you can start adding weight to the individual categories to help you choose the option that best meets your criteria. Remember to factor in some "soft" factors as well, such as costs, ease of use, and aesthetics, in addition to the core technical requirements. Once you have chosen what appears to be the ideal solution, keep the other options on file, as you may need to come back to them in the future. (Refer back to Chapter 2, "Mobile Devices," if you require a summary of the device market.)

At this point, you can start to focus on the application design, looking at such issues as what data is required on the device, how you are going to integrate to the enterprise systems, and how the user interface should be designed for maximum productivity.

Client Data Access

Enterprise data sources will contain much more data than you can hope to store on the mobile device. This is true for enterprise databases such as Oracle, Sybase, or IBM; for ERP systems such as SAP or PeopleSoft; and for CRM systems such as Siebel. The amount of data stored on the device will depend on the mobile data store solution being used, device performance characteristics, and physical limitations of the device. You may only be able to store between a few hundred kilobytes to a couple megabytes of data on the client.

When designing a smart client application, start by examining the subset of data that is required for the mobile user. This subset can be determined by looking at many factors, often depending on the type of application being developed. The subset of data that is required can have various levels of granularity. You can partition the data by its structure in the enterprise source—taking only specific tables from an enterprise database. Another approach is to base the partition on specific data, such as a userid, geography, or price range. The more layers of partitioning you add, the more specific the data on the device becomes.

Let's look at an example sales force automation (SFA) application. For such a system, the enterprise database may contain customer contact information, order history, product information, inventory levels, and supplier information. We do not need all of this data on the mobile device, so we can take a subset of it. In this case, only the contact information, order history, and inventory level tables provide a benefit on the device, so we can limit the data to those tables. To go even further, we can say that we only want data for a particular sales representative, perhaps based on a userid, to be sent down to the device. The result is that we will have a subset of the enterprise data that contains everything relevant to the mobile user, and nothing that is not.

The data access design goes beyond just evaluating the subset of data that is required. Before you can go much further, you will need to establish how you want to implement the data store on the client. If you are implementing your own solution, you will want to start laying out your data storage and management logic. If you are going to use a commercial solution, you will want to start examining how storage is implemented in it, and work on the related design issues, such as the database schema. (For more information on persistent data storage on the client device, see Chapter 9, "Persistent Data on the Client.")

Enterprise Integration

Enterprise integration is a term used to describe any communication to systems not on the device. It encapsulates integration with enterprise databases, business applications, XML data, Web content, and legacy data, among other things. For the purpose of designing your mobile solution, you will need to determine to which enterprise systems you require access. This should be based upon the data access requirements that you have already set forth in the client data access stage of the design process. There are two levels of integration that you may require: basic integration and complex integration.

Basic levels of enterprise integration include the ability to access enterprise databases using defined communication protocols. These capabilities may include the following:

  • Device communication using the standard synchronization software such as HotSync for Palm devices or ActiveSync for Pocket PC devices

  • Communication over IP-based networks

  • Direct integration with a relational database or flat-file system

  • Limited support for transactions

Usually, you can follow a well-documented API for these types of applications. This integration layer either can be developed in-house, or you can use a commercial synchronization solution. In either case, the enterprise integration is much more straight-forward than it is for larger and more complex systems.

When you start incorporating other forms of enterprise data and other communication protocols to the solution, a more sophisticated enterprise integration layer is required. The capabilities for this type of system may include the following:

  • Support for a variety of mobile clients including laptops, handheld PCs, and PDAs

  • Communication over networks that may not be IP-based

  • Support for synchronizing multiple users simultaneously to a central back-end data store

  • Communicating with systems that do not have well-defined interfaces, often requiring custom adapters

  • Synchronization of complex data models

  • Support for very large amounts of data with many transactions

  • Conflict detection and resolution

  • Administration tools to manage the entire process

If your system requires these advanced features, you should look to a commercial solution so you do not consume too many internal resources on one aspect of the overall solution. Purchasing a solution outright will result in significant cost savings, compared to the costs involved with writing, testing, debugging, and maintaining the conduit that is required to support the features listed. Even with the use of commercial software, the design requirements are much more complex than for a basic system. You will still need to worry about security, data partitioning, enterprise system access, and scalability, in addition to the usual network coverage and bandwidth issues. (Data synchronization is covered in depth in Chapter 10, "Enterprise Integration through Synchronization.")

User Interface

The user interface can account for as much as 80 percent of the total code in a mobile solution. When you have one part of the application accounting for such a large portion of the development effort, it has to be designed correctly to avoid costly changes later in the development cycle.

Be consistent with the user interface (UI). Get a feel for how standard applications that come installed on the device work and stick very closely with their UI styles. Most of these applications provide a very basic entry screen that meets the needs of most users. Typically, these UIs make more advanced functionality accessible via user selection of a button or menu item.

A couple of key items to keep in mind when designing on the user interface include screen size and human interaction. Paying attention to these items will make the application effective for the application users and help you avoid changes later in the development cycle. They are explained in the following paragraphs.

Screen Size

One of the most dramatic differences between desktop applications and those developed for mobile devices is the screen "real estate." When targeting mobile applications, you will have a one-half VGA, one-quarter VGA, or even smaller screen to work with. Using the screen to its maximum benefit is crucial for successful applications. There are many different ways to accomplish this goal, depending on the operating system you are using. Windows CE, for example, supports a tab-based interface, allowing easy navigation to multiple forms with the click of a button. Taking advantage of the menu capabilities in Palm OS applications allows more information to be displayed on a small screen.

Human Interaction

Studying human interaction with your application will prove to be invaluable in determining its overall usability. History has shown that people always interact with the system in unexpected ways. There is no way that these ways can be predicted, so testing is critical.

Before you get to the stage where you can study human interaction, there are application-specific requirements that can lead the direction of the user interface. If the application focuses on data input, then the main input screens should be easy to navigate using the input properties of the device. For example, if the device offers keyboard support, make it possible for the user to quickly tab between entry fields, rather than having to use a scroll-wheel to get there. If the only means of input is a stylus with character recognition, then including radio buttons and drop-down lists are effective ways to improve the efficiency of data input.

By focusing on the screen design and the navigation practices of the general user, you will be able to design effective user interfaces on devices of all sizes. Do not forget that spending some extra time testing the application early in the development cycle can save you much more time later on.

Wireless Connectivity

If you determine that you require wireless data access within your application, keep in mind the state of today's wireless networks. If you are planning on using a public network, keep these key points in mind during the application design:

  • Wireless coverage is not guaranteed. In fact, many areas do not have adequate coverage for data communication. This situation applies even in countries that have excellent overall wireless coverage.

  • Network penetration issues can arise even in areas that do have coverage. Network penetration can be problematical not only in obvious places like subways and tunnels but also in many corporate buildings.

  • Wireless networks operate over a variety of protocols. Some of these are not IP-based, so if your application requires IP for data communication, you may have to add an additional IP layer for connectivity. Many software vendors can provide this layer for you, if required.

  • Limit the frequency of wireless data transfer. Because there are potential problems with the reliability of wireless networks, this consideration will make the application more effective. Having suitable persistent data storage within the application will make it possible to limit the frequency of network connectivity within the application. Infrequent wireless data transfer also has a positive effect on battery life, as wireless communications require more battery power than local access.

  • Limit the amount of data transferred. This limitation is urged, once again because of the nature of the wireless networks.

Implementation and Testing Phase

The implementation and testing phase of the development cycle is what most people refer to as software development. It is during this phase that programming takes place and where developers start to see the rewards of their efforts. The preparation phases (needs analysis and design) are often overlooked because concrete results are not apparent. This does not mean that those parts of the development cycle should be minimized; it means the opposite. Having a complete design document is the best way to begin the actual application implementation. It will allow you to stay focused on the requirements; you will be spared having to figure out what is required on the fly.

The implementation of the final solution does not happen all at once. It is an iterative process that requires much testing. Figure 8.2 shows the process in flowchart format. The diagram introduces the concept of device emulators, which are programs that simulate the characteristics of a physical device using software. In order to get to a successful final product, there are some important steps you must keep in mind, the first of which is the development of a prototype.

Click To expand
Figure 8.2: Development cycle using device emulators.


Before making any critical decisions about your mobile solution, develop a prototype and do some field-testing. A prototype is a mockup of the final product that simulates the look and feel of the final application, revealing many of the complex interaction problems at an early stage in the development life cycle. It will save you many headaches during the deployment and maintenance stages of the development process.

The following list outlines some of the questions you should ask during your prototype stage:

  • Which device and related operating system is most suitable for my application?

  • Which wireless network is appropriate for my application, and does it perform as expected?

  • Does the user interface provide the most efficient way for the user to operate the application? Does it match the device characteristics?

  • Is the appropriate data available in the application? Can the client data store handle the amount of data required on the client device?

  • Does the enterprise integration layer work? Is it scalable, to meet the needs for my application?

  • Have security concerns been addressed? Are there holes where corporate data is left unprotected?

  • Does the application provide an upgrade path for new features? Will it be adaptable for new wireless networks as they arrive?

These are just a few of the questions that need to be answered during the prototype stage of the mobile application development cycle. With the short development times that are now the norm in the software industry, the prototype phase is often omitted from the development cycle. This is a mistake. Each stage of the development process is there for a reason, so avoid skipping phases. More often than not, when you skip part of the development cycle to save time and money, the problems that arise from the omission end up costing you more than if you had done it in the first place.

A prototype does not have to be the complete application. It can represent just a small segment of the overall application, which will allow you to determine some overall application characteristics. For example, to test the network connectivity and bandwidth, only a portion of the application needs wireless connectivity. The information that you gather about this part of the application will be a good representation of what you can expect from the completed product.

Many questions need to be addressed during the implementation of a prototype. In order to answer these questions, you have to actually put the prototype together. To help you accomplish this, we will provide an overview of the emulators and development tools that will aid you in this process. Included in the overview is a discussion of the stages of development as you move from testing on an emulator to a device in a cradle to a device on a wireless network.

Development Tools

Choosing which development tool to use is not a decision to take lightly. Many development tools are available for smart client applications, each with benefits and drawbacks. You need to consider many factors when making your development tool choice. Some of the more important ones include the target mobile operating system, the preferred programming language, the tool's feature set, and the tool's layout. In addition, you should also take into consideration your personal preferences. You will be using this software day in and day out, so if you are not comfortable with the chosen tool, sooner rather than later is a good time to voice your opinion.

Table 8.1 summarizes the development tool options available. Notice that some support multiple operating systems, for example, AppForge Professional, PenRight! MobileBuilder, and Metrowerks CodeWarrior. Cross-platform capability is a nice feature in a tool if you are targeting more than one mobile operating system, but it comes at a cost. Very often, these tools require additional libraries to support the cross-platform capabilities, adding additional overhead. In addition, some areas of development may be limited in functionality, as these tools often work at a lowest-common-denominator level. That said, if you are going to be doing cross-platform development, it's definitely worth your time to take a look at them.

Table 8.1: Leading Development Tools for Mobile Development




Windows CE

Microsoft Visual Studio. NET with the .NET Compact Framework


Microsoft eMbedded Visual Tools (EVT)


Microsoft Platform Builder


AppForge MobileVB


PenRight! MobileBuilder


Sybase PocketBuilder

Palm OS

Metrowerks CodeWarrior for Palm OS


AppForge MobileVB


PenRight! MobileBuilder


Pumatech Satellite Forms


PRC-Tools: GCC Development Tools

Symbian OS

Symbian OS C++ Software Development Kit


Symbian OS Java Software Development Kit


AppForge MobileVB


Metrowerks CodeWarrior for Symbian OS


JavaSoft J2ME Wireless Toolkit


Sun ONE Studio


Metrowerks CodeWarrior for Java


Borland JBuilder MobileSet

In addition to the tools listed in Table 8.1, many other vendor-specific SDKs are available; typically, however, these are optimized for a particular device, using a specific wireless technology, and therefore are not well suited for broad application development. At this time, with support for Palm OS, Windows CE, and Symbian OS, J2ME looks like the best bet for a standard API across the leading platforms. One word of caution: If you decide to go this route, be aware of the current performance limitations that Java may impose on your applications. This subject is discussed later in this chapter in the section entitled Native versus Java Applications.

Once you know to which operating system(s) you are going to deploy the application, examine each tool available, to determine if it will meet your needs. To help make the decision easier, you can create a matrix that lists your criteria; then rank each tool as to how well it meets your requirements. You might also want to separate the items into "must-haves" and "nice-to-haves." In this way, you can quickly eliminate any tool that does not meet your must-have checklist. Table 8.2 contains a few features that you may find useful when developing your mobile application.

Table 8.2: Development Tool Evaluation Questionnaire



Integration with third-party software

Does the software integrate with other third-party software that you may be using, such as mobile databases, synchronization software, and messaging clients?

Emulation environment

Does the tool provide an environment for emulation so you can quickly test applications without having to deploy them to a physical device?


Can you debug the applications? If so, how? Through an emulator, on the device, or both?

Drag-and-drop UI creation

What is the mode of user interface development? Does it provide GUI components or an API?

Multiple-platform support (Palm OS, Windows CE, Symbian OS, etc.)

Which mobile operating systems does it support? Is it limited to a single OS, or can you target multiple OSes with the same tool?

Support programs

Where do you go when you run into a problem? Can you access a developer network or newsgroups? Do the technical support packages meet your requirements?

Training programs

If you require training on the development tool, is it readily available? Is online training or classroom training offered?

Educational books

Are books widely available to help you learn about the tools and how to develop with them?

Online tutorials

Are tutorials available for the development tool? Does the tool vendor or a third-party development site provide them?

Programming language

Which programming language does the tool use? Is it a standard language, such as C/C++ or Java, or is it proprietary to the vendor? Is this language appropriate for the development team's background?

Once you have decided which development tool is best for your development efforts, you can move on to the programming part of the implementation phase. At this stage you can begin to see the benefits of your needs analysis and design efforts. When you start developing the mobile application, having a complete development environment will make your development and testing efforts go more smoothly.

In the next part of this chapter, we are going to take a look at the development effort as it progresses through various stages of testing. We will start with testing in an emulation environment, then move to a physical device with connectivity via a cradle, on to the final stage of testing on a wireless network.

Device Emulators

An emulator can be your best friend and your worst enemy—at the same time! It will be your best friend when it increases your productivity dramatically. Deploying and testing your application on an emulator is much easier than on a real device. This is especially true if you do not have all the devices for which you are building the application, which is often the case. In such a situation, the emulator allows you to get an idea of how the application will work on the physical device, while you avoid the hassle of actually configuring a real device. On the other hand, an emulator can be your worst enemy if you start to rely on it exclusively. You must never forget that it is just an emulation setup, not the real thing. There is no substitute for testing on the physical device and communicating over the real network on which you will be deploying. In the past, many developers have been embarrassed when their applications did not run properly on the real device, even though these same applications ran flawlessly on the emulator.

Emulators are available free of charge for the leading mobile operating systems. Often, they are included with your development tool; but if not, this section will give you the information you need to obtain them.

The following are some features that are available in most (if not all) of the mobile operating system emulators:

  • A window, which can be dragged anywhere onscreen, to display the device's screen, surrounding skin, a keypad, and LED indicators.

  • The PC keyboard, to enable additional key input.

  • The PC mouse, to enable pointer input.

  • A directory tree in the PC's file system, which shows the mobile OS file system.

  • The Windows runtime environment, which provides support for communications, Internet, and IrDA through the host PC.

Windows CE

The Pocket PC emulator shown in Figure 8.3 comes with the Pocket PC 2002 SDK. It allows you to test all Pocket PC, Pocket PC 2002, and Windows CE .NET-based applications from your desktop. To create applications for other versions of Windows CE, you will need eMbedded Visual Tools (EVT) along with the SDK for the platform you are developing on. These tools and related SDKs are available as a free download from the Microsoft Web site.

Figure 8.3: Windows CE emulator.

If you are using Microsoft tools, you can configure the IDE to run in emulation mode. When you run the application from within EVT, the IDE opens the emulator on the desktop, downloads the executables files to the emulator, and starts the application. At this point, you can run and test your application on the emulator just as you would on a physical CE device. The emulation environment enables you to test code more quickly than if you had to download files to a device after every compilation. It also gives you the ability to test your applications when a physical Windows CE device is unavailable.

If you are not using Microsoft tools, you can still use the Windows CE emulator. Depending on the Pocket PC SDK you are using, you can either launch the emulator from the Windows Start Menu (Pocket PC 2000 SDK) or from Microsoft Visual Studio .NET or EVT (Pocket PC 2002 SDK). All you have to do is copy your application files to the correct location in the emulation file system. If you want to change the external appearance of the emulator, you can select another "skin" for it. A skin is used purely for aesthetic purposes; it does not change the emulation characteristics in any way.

Palm OS

The Palm OS Emulator, shown in Figure 8.4, is software that emulates the hardware of the various models of Palm OS-based devices. It is extremely valuable for writing, testing, and debugging applications, as it creates "virtual" devices by running the emulator on Windows, Mac OS, or UNIX computers.

Click To expand
Figure 8.4: Palm OS Emulator with Palm m505 skin.

The Palm emulator is downloadable from the Palm Developer's site. Once you have joined the developer's program, you will need to download the emulator and ROM image (ROM is the software that controls the emulator). The emulator can be loaded with new ROMs, so you can test your application with virtual devices, including those you do not own. These can include foreign-language ROMs and debug-enabled ROMs for extra error checking and debugging features.

The emulator that you download will not include any ROM images; think of it as a computer without an operating system. To emulate a specific device, you will need to obtain a ROM image that is compatible with that device. Typically, the ROM and device must match in processor type and display color depth. In some cases, you will also require some device-specific capabilities. For example, to simulate a Palm VII device with a wireless connection, you would need the Web Clipping components, which are part of the ROM image.

As new versions of the Palm OS come out, new ROM images are released on the developer's site. When you install a ROM image, the emulator allows you to choose which device you want to emulate. Note that the ROM you use restricts the choices available. Also note that in order to make the emulator appear like the device you are emulating, you will need to download and install the appropriate skins. As mentioned earlier, a skin changes the external look of the emulator; it is not required to get an accurate emulation of the device characteristics.

With the release of Palm OS 5.0, PalmSource has also released the Palm OS Simulator. The Simulator is the Palm OS 5.0 system compiled to run natively on Intel platforms. It does not do hardware emulation like the Palm OS Emulator, but is rather the real Palm OS 5.0 running on top of a device abstraction layer. When developing applications for Palm OS 5.0 it is recommended that you test on both the Palm OS Emulator and the Palm OS Simulator. Testing in both environments is the only way that you can be ensured that your application will run correctly on a physical Palm OS 5.0 device.

Symbian OS

As part of the Symbian OS SDK, you get an emulation environment for the Symbian Quartz platform shown in Figure 8.5. The SDK gives you support for both C/C++ and Java environments. The Quartz emulator provides a full target environment, which runs on desktop Windows platforms. The emulator enables development to be primarily PC-based. You only have to worry about hardware testing in the final development stages. To compile the application code for either C++ or Java development, you are required to use a development environment such as Microsoft Visual C++ for C++ development or a Java IDE for Java development.

Click To expand
Figure 8.5: Symbian OS quartz emulator.

The Symbian emulator is an implementation of the EPOC kernel and device drivers, and uses Microsoft Windows and PC hardware to emulate a real EPOC-based device. On the emulator, the application is built as Windows dynamic link libraries (DLLs), containing x86 machine code. Symbian OS programs are rebuilt in native machine code, using the ARM instruction set, to run on a real ARM-based device.

Interpreted languages such as Java use machine-independent data formats, which do not need to be built specially for the emulator or target machine.

There are two Symbian emulator variants: release and debug. The debug emulator is most useful for development as it contains debug information that can be used for stepping though code, and it provides special key combinations for resource checking and redraw testing. This helps developers to trap memory leaks and other errors early in the development cycle.


Do not worry if the debug emulator does not come up right away, because loading it can be slow. The release emulator is much faster to load as it does not contain debug information.

In addition to the emulation environment in the Symbian SDK, many device manufacturers that support the Symbian OS also have emulators available for their specific devices. Ericsson, for example, has the Ericsson R380 emulator, which is specifically designed to test applications written for that device. Nokia also provides similar emulation environments for its devices.


In the past, many device manufacturers had device-specific emulator environments for the Java platform. More recently, these manufacturers have decided that a better solution is to integrate their devices to a standard environment, such as JavaSoft's J2ME Wireless Toolkit or Metrowerks CodeWarrior for Java, rather than support a proprietary tool. Here, we will focus on using the J2ME Wireless Toolkit offered by JavaSoft, as opposed to examining a variety of implementations. This toolkit offers a complete set of tools that provides developers with the emulation environment, documentation, and examples needed to develop Connected Limited Device Configuration (CLDC) applications using the Mobile Information Device Profile (MIDP).

The J2ME emulator allows you to see how MIDP applications operate on a variety of mobile devices. Figure 8.6 shows the default emulator that is available in the toolkit. (Note: Emulators for other devices are available from the device manufacturers as plug-ins to the J2ME Wireless Toolkit.) Similar to other emulators, the J2ME Wireless Toolkit emulator executes on your local PC so you can test your applications on the same platform you use for development.

Click To expand
Figure 8.6: J2ME Wireless Toolkit default emulator.

Some of the key emulation features of the J2ME Wireless Toolkit are:

  • Support for a variety of mobile and wireless devices. You can set up the toolkit to use emulators for devices with a variety of form factors, including smart phones, pagers, and PDAs.

  • Debugging capabilities. You can execute runtime logging of the events pertinent to your application, including garbage collection, class loading, method calls, and exceptions. You can also perform source-level debugging with your IDE as the application runs in the emulator.

The Java emulator comes with the same caution as the other emulation environments; that is, do not use emulator testing as a substitute for testing on the physical devices. The emulation environment is intended to serve only as an approximation of the user interface, performance, and other capabilities of the device. You are not running on the actual target chipset, so the emulator cannot simulate the actual runtime speed.

If you are not using J2ME on the mobile device, then you may want to look at the specific toolkit offered by the device manufacturer or Java Virtual Machine supplier. The Symbian SDK for Java offers an emulator that is not J2ME-based, and therefore has its own development environment for building PersonalJava applications.

Physical Devices

Once you have the application running correctly on an emulator, it is time to test it on a physical device. Ideally, this will be the device that you are planning to use for deployment. This is important because each device has different properties, including the type of processor it uses. For example, if you build a Pocket PC application and test it on an HP iPaq, you are testing an X-Scale processor. If you then want to deploy it to a Casio EG-800 Pocket PC, you have to rebuild it for the MIPS processor. By changing deployment processors, you are changing the behavior of the application, so make sure that you test on the appropriate devices before deployment; do not assume that all Pocket PC devices behave the same way.

Only after you have tested on the real device will you be able to accurately gauge the performance of your application. This will be the first time the application is running on the target processor, with the actual operating system. In most cases, the move from an emulator to the real device will go smoothly, but it is for the times that it does not go smoothly that testing is required.


The easiest way to test the communication of the application is through a cradle connection. In this way, you have full control over the network communication and you do not have to worry about establishing the proper wireless connections.

A variety of conduits are available for this cradle communication, including device synchronization software such as Microsoft ActiveSync or Palm HotSync. In addition, you can set up direct serial communication or connect via TCP/IP. Very often, the specific device and its related software dictate the communication method used.

If your application is not going to have wireless connectivity, this could be your final stage of testing.

Wireless Networks

If your application will provide wireless access, the final stage in your testing process will involve the use of a wireless network. Many different types of wireless connectivity can be implemented, depending on your application needs. As discussed in Chapter 3, "Wireless Networks," the two relevant types of networks are wireless wide area networks (WWANs) and wireless local area networks (WLANs).

If the application will be used in multiple areas, possibly in multiple geographies, you will want to utilize a WWAN for wireless access. But note that, currently, for this type of network, wireless communications capabilities are not 100 percent reliable. Therefore, you will want to test your application in a variety of environments and attempt to limit, as much as possible, the frequency and amount of data being transferred in the deployed application. While in the testing phase, verify wireless failure conditions to ensure the application handles wireless connectivity loss in a way that does not hinder continued use of the application.

If you are deploying the application in a controlled area, such as a warehouse or a hospital, then you may be better off using a WLAN for connectivity. A WLAN is not controlled by a wireless carrier, but by the company deploying the solution itself. Because of this, you have full control over the network, hence can often achieve better coverage reliability, while getting higher bandwidth. WLANs are TCP/IP-based, so your testing results should be similar to those over a wired TCP/IP network.

While in the testing stage of the development process, you should set up a staging server for your application. This is a server that has the same environment as your deployment server. Doing this will give you a true idea of what to expect at deployment.

Deployment Phase

Two major drawbacks commonly cited as reasons not to build smart client applications are deployment and management issues. With smart client applications, you have to physically deploy the application to the device, in contrast to wireless Internet applications that run in a browser, and therefore do not require deployment other than downloading the content by accessing a URL. This form of browser-based deployment is one of the reasons that Internet applications have been so widely adopted. Now, with the proliferation of mobile devices, IT departments again have to worry about application deployment and management, and with additional challenges, which include the following:

  • Wide range of devices that need to be supported. These can range from two-way pagers to PDAs to laptops. Ideally, a way can be found to manage all of these devices in the same manner.

  • Deployment of applications to these devices. This includes the original application as well as updates as they occur.

  • Management of mobile assets. This includes keeping an inventory of the devices in the field, as well the software on these devices.

  • Backup and recovery. Because the primary functions of many of the mobile applications are to retrieve data and to make sure the data is safe in the event of a system crash.

  • Working with wireless networks. In most cases, the rules that were developed for LAN-based applications do not apply to wireless deployment and management. The bandwidth of the wireless networks makes the efficiency of the solution a top priority.

  • End users have little access to technical assistance. Very often remote workers do not have direct access to technical support, making troubleshooting and repair difficult.

  • Participating in business analysis to determine application effectiveness. In today's economic environment, businesses need ways to determine if their mobile applications are meeting their goals of improving employee productivity and cost savings.

For smaller deployments, these concerns may not be as troublesome. In some cases, the applications