iii

Building Java Applications on PDA

By

Yuanli Wang

May 2002

iv

TABLE OF CONTENTS

CHAPTER I: INTRODUCTION 1

1.1 BACKGROUND ..................................................................................................1

1.2 PROBLEM ...............................................................................................................2

1.2.1 PDA as Client Side Platform...........................................................................2

1.2.2 Java Development on PDAs............................................................................3

1.3 SCOPE....................................................................................................................6

1.4 ASSUMPTIONS ........................................................................................................7

1.5 GENERAL APPROACH..............................................................................................7

1.6 OBJECTIVES ...........................................................................................................7

1.7 SEQUENCE OF PRESENTATION .................................................................................7

CHAPTER II: PROJECT DESCRIPTION AND DEVELOPMENT 9

2.1 APPLICATION FUNCTIONALITY................................................................................9

2.2 SOFTWARE ARCHITECTURE – CLASS DIAGRAM..................................................... 10

2.3 PROJECT DEVELOPMENT....................................................................................... 13

2.3.1 Development Environment ............................................................................ 13

2.3.2 Sun’s Wireless Toolkit................................................................................... 15

2.4 PROGRAMMING FOR MIDP ................................................................................... 15

CHAPTER III: CONCLUSIONS AND OBSERVATIONS 22

3.1 MIDP BUGS......................................................................................................... 22

3.2 PERFORMANCE..................................................................................................... 23

3.3 ENHANCEMENTS................................................................................................... 23

Chapter I: Introduction

1.1 Background

Since the birth of computers, the sizes of processors and storage have been decreasing

at a fast pace, while their computing and storage power have become greater and greater

each month. In the meantime, less and less electric power is needed for the same amount

of computing due to better processor designs. Driven by the above factors, sizes of

computing devices keep shrinking. Indeed, computers have become so small that people

can carry several computing devices at the same time with great ease.

Isolated computing resource along does not contribute too much to the society at large.

Connectivity holds the key to the thriving of the mobile community. Businesses are

seeking ways to utilize cutting edge technologies to improve productivity. Small mobile

devices present great potential to help further streamline workforce activities by

facilitating workflow procedures in a more flexible way. Individual activities performed

on the small mobile devices should be synchronized with the rest of the business in a

timely fashion. Such a task can only be done with the support of powerful wireless

technologies.

When the accessibility of information is greatly improved, the investment in a costly

technology-intensive information system can be rewarded with more efficient sharing of

information and better information quality. There will be tremendous saving of time and

money for a business, not to mention increased revenue, if it takes almost nothing to

access information anywhere, anytime. As all we have to do to get any piece of

information about customers or products is to get the handheld out of our pocket and

click, and the PDA will send out request to the sever running three thousand miles away

2

to retrieve some data from the database for us. That is why we say M-commerce will only

be of significance to the economy at large when it can connect from anywhere in the

world whenever it is needed.

Limited by their sizes, small mobile devices require quit different technologies to

function well on the net. Lots of infrastructure works have been done to connect small

mobile devices. All sorts of network hardware, operating systems, software, and

protocols have been developed over the years with the ultimate goal of connecting every

category of computer through the Internet. Wireless connected small mobile devices see

an overwhelming future on the horizon. We will try to develop a small application for a

small mobile device in order to better understand the pros and cons of some of the

technologies.

1.2 Problem

1.2.1 PDA as Client Side Platform

To develop the right application, first of all we need to choose the right platforms.

Three vital platforms are involved here – the device operating system, the device

programming platform, and the server platform.

Smart phones have better network connectivity than most of the Personal Digital

Assistants (PDAs), but PDAs are quickly catching up in that respect. Besides, PDAs have

many advantages over other smaller devices. The advantages of PDAs include

comparatively bigger screen, larger memory, faster processing speed, and more

convenient input methods. All of these combined give them more freedom in terms of the

applications they can host.

3

There are two major rival operation systems for PDAs on the market now. They are the

popular Palm OS and the more powerful Microsoft Windows CE. Each has its strengths

and weaknesses.

Windows CE is a more sophisticated operating system. Windows CE based PDAs,

such as iPAQ and HP Jornada, are also known as the Pocket PC. A Pocket PC is

equipped with a much faster processor (up to around 200MHz) and bigger memory (often

32MB RAM) than a Palm handheld set. Its capability to run various applications is

impressive. Besides running scaled down versions of Microsoft Windows applications,

the latest models can even play movies.

On the other hand, PDAs built upon Palm OS needs much less processor power and

memory for performing a series of nice functions that are suitable for small mobile

computing devices. For instance, a 33MHz Motorola Dragonball VZ processor and 8 MB

memory are quite sufficient for a sleek Palm 500 series or Visor Edge. The PDAs built on

Palm OS are smaller, lighter, and easier to carry in one’s jacket pocket or purse, as

opposed to those running Windows CE. In addition, they are much cheaper (ranging from

$150 to $400 versus $500 average price for a Pocket PC), and have much longer battery

life (lasting for months versus Pocket PCs 10-hour benchmark). These practical

advantages Palm PDAs have over Pocket PC are the reasons why Palm OS owns more

than half of the PDA operating system market.

1.2.2 Java Development on PDAs

Be fully aware we are still at the dawn of the wireless age. The various infrastructure

technologies are still evolving. Of all the technologies targeting at the small wireless

device market, there are a few standing out of the crowd. Wireless Application Protocol

4

(WAP) and i-Mode are among the early movers and are dividing the current wireless

world [1]. WAP and i-Mode follow special protocols respectively. Both of them also

require content to be delivered to small mobile devices be created with mark up

languages, such as WML (Wireless Markup Language) or cHTML.

Unlike the above browser-based technologies, Sun’s solution Java 2 Platform Micro

Edition (J2ME) takes a quite different approach. J2ME is the enabling technology for

Java applications running on machines with stringent memory budget and with

processors a lot less powerful than those used on typical desktop and server machines.

Although very young, J2ME has many advantages that neither WAP nor i-mode could

nearly match [1]:

J2ME applications reside on the client. The application can function on the client

device even when the device is used independently without connecting to the

network. A certain amount of data can be stored on the device before being finally

transferred to the server through wired or wireless connection at the user’s

convenience.

J2ME offers powerful client side functionalities. J2ME applications are Java

applications that make efficient use of client side computing resource. They can

provide both business logic implementation and interactive GUI (Graphical User

Interface) with much richer functions.

J2ME applications are more secure. The J2ME application developer has full

access to HTTPS for end-to-end application security.

5

J2ME applications require minimal infrastructure investment. J2ME does not

incur extra infrastructure work, such as special network protocol implementation.

It can easily utilize the existing HTTP to establish network connection.

J2ME applications are widely embraced by the industry. Nearly every handset,

PDA, and carrier has adopted the J2ME specification. Gartner Group predicted in

November 2000 that J2ME technology-enabled mobile phones and PDAs would

control 70% of the worldwide market by the end of 2004.

The J2ME platform tries to provide built-in consistency across products as its siblings

J2SE and J2EE did. It enables applications to run anywhere, any time, over any device.

Restricted by the underlying hardware and operation system, this goal is achieved by

engineering special purpose Virtual Machine called KVM (K stands for Kilo), as well as

APIs designed for different groups of devices. The J2ME virtual machine and API

specifications for specific device category are based on industrial input as required by the

Java Community Process (JCP) to make certain the specifications meet the real needs of a

given family of consumer devices.

The J2ME APIs are designed as two major building blocks – configurations and

profiles. A configuration defines a set of class libraries representing common functions

available for a broad range of devices. A profile further defines the set of APIs tailored to

particular characteristics of a particular family of devices. The best-supported J2ME

profile to date – Mobile Information Device Profile (MIDP) – is built on Connected

Limited Device Configuration (CLDC).

CLDC is a standard, portable, and minimum-footprint configuration for small,

resource-constrained mobile devices such as two-way pagers, PDAs, organizers, home

6

appliances, and point-of-sale terminals. The common characteristics of these devices are

simple user interfaces, memory above 128 kilobytes, and low bandwidth network

connection. MIDP facilitates development of Java applications that run on mobile devices

such as J2ME enabled mobile phones and entry level PDAs [2]. MIDP APIs provide

classes to be used in these areas: application, user interface, persistent storage,

networking, and timers [3]. The MIDP profile, together with CLDC, constitutes a

complete software platform for small, resource- constrained, wireless-connected mobile

information devices with the following characteristics:

512K total memory (ROM + RAM) available for Java runtime and libraries.

Limited power, and typically battery operated.

Connectivity to some type of wireless network with possibly limited bandwidth.

User interfaces with varying degrees of sophistication.

1.3 Scope

The project develops a small business application for Palm OS based PDAs using

Sun’s J2ME and J2EE (Java 2 Enterprise Edition) technologies. J2ME CLDC and MIDP

APIs are used to develop client side applications. Development environment software

such as Palm OS Emulator (POSE) and Sun’s Ktoolbar is installed and is used to test the

project. The other two major Java platforms, namely J2SE and J2EE are also utilized to

build an end-to-end business application [4]. Appropriate software architecture is

carefully designed and implemented. Efforts have been made to overcome the

performance challenge brought by programming for resource-restricted devices.

7

1.4 Assumptions

The application is meant to run on devices that satisfy the basic MIDP profile

requirements. The client device needs an HTTP connection to communicate with a

backend servlet running in a web server.

1.5 General Approach

The architecture of the project fits into the end-to-end structure promoted by Sun [4].

The application developed for the project is compose of three parts:

Client – PDAs that run on the Palm OS

Middleware – Servlet running in an Apache Tomcat web server, responsible for

business logic and database access.

Database – Stores large amount of persistent data.

1.6 Objectives

The purpose of the project is to develop a small business application to explore newly

released Sun J2ME technologies and APIs. Through the project research and

development, the developer will become familiar with the special requirements of

programming for small mobile devices with limited connectivity. The developer will also

gain greater insight into how to apply the right technologies to better address business

needs. By solving the problems that appear during the project development, the developer

will improve her programming skill and enhance her ability to think and experiment

independently.

1.7 Sequence of Presentation

At the beginning of the next chapter, the application functionality is introduced to give

the reader a better idea about the purpose and scope of the project. Next, the software

8

architecture of the project is described using a class diagram. Following the project

architecture introduction, the development environment being used in the project is

discussed. The section after that talks about how to write Java programs that result in

optimal performance, given limited processor speed and memory. Finally, chapter three

draws conclusions of the project by discussing bugs found in MIDP API, the performance

of the project, as well as the enhancements that could be made in the future.

9

Chapter II: Project Description and Development

2.1 Application Functionality

To fully explore what J2ME MIDP has to offer, a small business software system is

developed upon the platform. The system enables PDA clients to store records entered by

the user for some time and then send the data to the J2EE server when the user decides to

do so. The system has a device client user interface called ‘GoSales’. GoSales client is a

MIDlet (a MIDP application) suite that contains a group of MIDlets. Three of the

MIDlets are data entry forms that facilitate record client call, product order, and product

repair information respectively, while the last one is a simple form screen for sending

data to the back end server. The data entry forms have input fields for the user to record

the customer name, event date, sales price, sales quantity and other related information.

The data entry is then stored in different device persistent storage objects called

RecordStore, until the user decides to synchronize the data with the server database. After

the device data has been successfully sent to the server through an HTTP connection, the

synchronized data storage on the device is then deleted to free up the scarce memory for

other use. The MIDPlet suite developed in this project is meant to works on PDAs

running the Palm OS.

On the server side, a servlet is running in an Apache Tomcat web server. The servlet

receives data from PDA clients. Upon receipt of client data, it opens a database

connection to the Microsoft Access data source, and executes queries to insert the data

into the database. There are three tables in the database – Call, Orders, and Repair. The

tables are used to hold client call, order, and repair information corresponding to the

records stored on the device. After the data is saved to the database, the servlet will send

10

a message back through the same HTTP connection it gets the data from. The message

tells the device whether the sales-related data is successfully synchronized with the

database. The software architecture for the whole system is indicated in Figure 2.1 that

follows.

2.2 Software Architecture – Class Diagram

The class diagram in Figure 2.2 describes the major classes that have been used in the

project. It shows the methods of each class and the relationships between the classes.

At the heart of the diagram are four MIDlets that form the user interface. The MIDlets

are all inherited from a common parent class MIDlet found in the MIDP

javax.microedition.midlet package. MIDlet classes define several MIDlet life cycle

methods: startApp(), pauseApp(), and destroyApp(). The life cycle methods are the most

important methods in a MIDlet. They will be discussed in detail in the next section.

The MIDlets classes also implement the CommandListener interface in the

javax.microedition.lcdui package. MIDP GUI package supports an event model similar to

those supported by other GUI Java platforms such as Swing and Applet. By

Figure 2.1 Project Architecture

11

implementing the listener interface’s method CommandAction() and registering itself as a

event listener, a MIDlet is able to react to all kinds of events that happen to the GUI

objects within the MIDlet.

SalesDB is the pivotal class for storing and retrieving data to and from the persistent

storage on the device, which is represented by class RecordStore in MIDP package

javax.microedition.rms. It acts as the intermediate helper class in connecting the MIDlets

with the RecordStore. By encapsulating the underlying interaction with the RecordStore,

12

the SalesDB simplifies data storage operations for the MIDlets. Any of the four MIDlets

developed in the project can construct SalesDB instances according to its own data

storage needs. They use the SalesDB methods close(), delete(), addRecord(), getRecord()

to manage the existence of a special RecordStore on the device, as well as to store and

retrieve records.

Mobile small devices have very limited memory and processing power. They can

hardly be qualified as platforms for building sophisticated storage systems. It is neither

efficient nor secure to store large amount of sensitive data on PDAs or mobile phones for

a long time. They are quite sufficient for storing small amount of data entry generated by

users on the go. If the information is to be used by more than one person in a large

corporate environment like what the project is designed for, there should be a way to

synchronize the device data storage with the real database system.

To achieve the ultimate goal of remotely saving all the information stored temporarily

on the device to the database on the server side, a servlet is nicely fitted into the scene. A

servlet is a program running in a web server. It receives client requests from a HTTP

connection and sends back responses to its client. Servlet has full access to all Java APIs,

hence it is a powerful tool for developing web-based applications. The SaleSv is a servlet

class inherited form javax.servlet.http.HttpServlet. Two of the servlet lifecycle methods,

init() and destroy(), are overridden. In the init() method, a JDBC connection is opened to

the Microsoft Access database used as the project data source with the name GoSales.

The JDBC connection is closed in the destroy() method, and the related resources are

released. The doPost() method gets information extracted from the device storage class

13

by reading from the client HttpServletRequest. It reformats the information as records for

different kind of database tables, and inserts the records to the appropriate tables.

2.3 Project Development

2.3.1 Development Environment

The information the field sales force could collect for their company best reflects the

company’s direct interaction with customers. However, the field sales force is always on

the go. It is practically impossible to ask them to go to a desktop in an office right away

to report their activities each time any trivial job is done. Equipping every sales

representative with a laptop seems to be too expensive for the task. The size, weight, and

limited connectivity of laptops are also big barriers for them to be considered as a

lightweight field report tool. In order to enable the field force’s convenient and timely

participation in business workflow procedures, the project designs a system in which

PDA thin clients are wirelessly connected with the server servlet. The field personnel can

easily use PDAs to record any piece of information anywhere, anytime. In a similar

fashion, they can send the information to the company database via a servlet running in

the web server whenever necessary. Other parties in the company can then analyze the

information and make timely decisions accordingly.

To carry out such complex tasks as required in the above scenario, the project involves

multiple hardware platforms and operating systems. Thanks to the platform independent

characteristic of Java technologies, different systems in the project application can easily

communicate with each other. In the demanding business software market, having the

flexibility of choosing the right platforms is very important for the success of a software

product.

14

The hardware used to develop the project include:

IBM PC

Handspring Visor Platinum handheld device

The operation systems used during the development are:

Windows 2000

Palm OS

The software packages used in the project includes:

J2SE Toolkit

Palm OS Emulator

Apache Tomcat Web Sever

J2ME CLDC

J2ME MIDP For Palm OS

KToolbar (part of Sun’s J2ME Wireless Toolkit)

Palm Desktop

The target devices of the project are PDAs built on Palm OS. In order to run MIDP

applications on Palm OS, MIDP for Palm OS runtime environment should be loaded to

the device using Palm’s Hotsync function. The run time is a .prc file contained in the

MIDP for Palm OS package downloaded form Sun’s web site. MIDP for Palm OS is

compliant with the CLDC 1.0 specification and the MIDP 1.0 specifications [5].

15

2.3.2 J2ME Wireless Toolkit

The J2ME Wireless Toolkit created by Sun Microsystems is a powerful yet easy-to-use

development tool. It provides a compiling and testing environment for developing

applications for CLDC/MIDP compliant mobile phones and entry level PDAs [6].

The core component of the J2ME Wireless Toolkit is KToolbar. It comes with the

J2ME CLDC and MIDP runtime environment, documentations, and examples, so

developers do not even need to download and install the CLDC or MIDP on their own.

Using the KToolbar, developers no longer have to go through the hassle of writing

complicated batch files to compile the source code and build the device-specific

executable files. With the KToolbar, developers are also freed from loading the

recompiled code to the device each time a little change is made to the source code. It does

almost everything for you except for writing the code. Test running the application is as

easy as hitting the run button on the menu bar. Developers can test their applications on

several mobile phone models. The runtime debug information is quite clear. KToolbar

can also be configured in a way that it can find the Palm OS Emulator (POSE) installed

on the computer, and run applications on the POSE when needed.

Articles and directions can be found on Sun’s web site talking about how to install and

use J2ME Wireless Toolkit. POSE can be downloaded from both Sun’s website and

www.palmos.com.

16

2.4 Programming for MIDP

When it comes to programming for small computing devices, performance looms as a

big concern of the developer. The common characteristics of such devices are limited

memory and slower processing speed. As we all know, memory and processing speed are

the primary platform factors determining the execution speed of a computer program.

The same is true for the coding of a PDA application using MIDP.

There are books that discuss techniques for writing Java programs with better

performance. The primary things that a programmer should keep in mind when designing

the application for small devices are listed below:

Try to keep the design simple

Avoid executing computationally intensive tasks on the device (run then on the

server instead)

To save memory, certain general practices should be observed:

User scalar types wherever possible

Delay instantiation of variables

Release resource early

Reuse objects

Another very useful practice is to use the append() method of the StringBuffer class

instead of the plus sign (+) to concatenate strings. String is an immutable class in Java.

When the plus sign is used to concatenate strings, it generates a new String instance in

the memory. Using StringBuffer solves this problem. The append() operation on the

StringBuffer object only changes the value of the object.

17

For any class to become a MIDlet, first of all it should inherit from the

javax.microedition.midlet.MIDlet class. From this point on, let us take a look at the

development of a MIDlet from several different aspects. We will exam the MIDP life

cycle methods, the GUI objects, the HTTPConnection, and the persistent storage class in

the following sections. The discussion covers most of the MIDP API packages and the

critical classes in these packages.

2.4.1 MIDP Life Cycle Methods

The life cycle methods of a MIDlet is one of the most important things programmers

need to learn before they can start writing even the simplest MIDlet. Three life cycle

methods are inherited from the MIDlet abstract class. They are startApp(), pauseApp(),

and destroyApp(), all of which need to be implemented.

When a MIDlet is activated, the startApp() is executed automatically. pauseApp() and

destroyApp() can be called by the programmer from the active state, which cause the

MIDlet to enter Paused state and Destroyed state respectively. The Destroyed state means

the execution of the MIDlet program is terminated. The MIDP API does not explicitly

describe what exactly a Paused state is like and how different it is from the Destroyed

state. Actually, the pauseApp() method is rarely called in the sample MIDlet programs

developed to date.

The common practice in using the MIDlet life cycle methods is to declare objects that

belong to a MIDlet at the beginning of the MIDlet class. Instantiation of these objects is

carried out in the startApp() method. In the destroyApp() method, resources held by the

MIDlet such as a open Internet connection or a open connection to a data store should be

18

released, then the notifyDestroyed() method is called to notify the application

management software that the MIDlet has entered the Destroyed state.

2.4.2 MIDP GUI Classes

The MIDP GUI classes are in package javax.microedition.lcdui. These are GUI

components that have been optimized for the mobile information device profile. The

Display class controls the display and input process of the system. There is one instance

of Display for each MIDlet. A reference to that instance can be obtained by calling the

getDisplay() method. The Displayable class family represents various kinds of screens

upon which the visible GUI components (Items) are displayed. A MIDlet can have

multiple instances of Displayable. The Displayable and Item classes and their inheritance

structure are shown below.

Figure 2.2 MIDP GUI Class Hierarchy

ImageItem Gauge

DateField

ChoiceGroup

Item

TextField StringItem

Displayable

Form

Canvas Screen

TextBox

List Alert

19

CommandListener and other listener interfaces are the cornerstone for constructing

MIDP GUI event model. It is found in the same package as the GUI classes. A MIDPlet

implements the CommandListener interface and becomes a listener of its Command

object events. By implementing the commandAction() method of the CommandListener

interface, the MIDlet can respond to actions invoked on different command objects as

appropriate. The appearance of a Command object differs on different devices and with

different Command property. On Palm PDAs, it always looks like a button.

2.4.3 MIDP Persistent Storage Classes

MIDP API has a mechanism to store data persistently on the device. The RecordStore

class in the javax.microedition.rms package is designed for this purpose. Once created, a

record store exists even when the MIDlets are not active. MIDlets within a MIDlet suite

can create multiple record stores. Each of these record stores should have different

names. According to the MIDP API, a record store belongs strictly to the MIDlet suite

from which it has been created. That means a record stores is only accessible by the

MIDlets in the MIDlet suite that created the record store. When the MIDlet suite is

removed from a platform, all the record stores that belong to it will also be removed. A

record store can also be deleted explicitly by any MIDlet that has access to it.

Data is stored as byte arrays in the record store. Records in a certain record store are

uniquely identified by an integer number called recordId. The first record created in a

record store will have recordId of 1. Each record added later will be assigned a recordId

one greater than the record added before it. If a record is deleted from the record store,

the recordId for this record is not reused. The method enumerateRecords() is often used

to retrieve the data in a record store. The method returns a RecordEnumeration object,

20

which can be used to further process each record that has been retrieved. One more thing

the developer should be reminded about is that the record store is not actually closed until

closeRecordStore() is called as many times as openRecordStore() was called. It is

suggested that openRecordStore() and closeRecordStore() be strictly coupled in the code.

In cases in which the coupling of open and close of the record store is difficult to

implement, a while loop can be used to repeatedly perform the close record store

operation until the RecordStoreNotOpenException is thrown.

2.4.4 MIDP Internet Connection

The javax.microedition.io package includes the connection classes for devices to

communicate with the outside services. An HttpConnection to the servlet on the remote

web server is opened by calling the Connector class’s static open() method. After the

connection is established, an OutputStream and an InputStream are created to send and

receive data to and from the Internet connection.

In this project, the data sent over the Internet connection is formatted in a certain way.

The server at the other end of the connection knows the data format. It extracts records

from the stream of raw data, encodes them in SQL queries, and stores the records into the

database. After the database operation is finished, the server sends a message back

through the same connection telling the PDA client whether the synchronization process

is successful or failed.

The SyncMIDlet should try to close the HTTP connection and the input and output

streams and release the resources held by them after it finishes using the connection. In

this project, the streams are closed in the finally() part of a try catch block that

21

encompasses the data communication operations. The connection is closed right after the

streams are closed.

22

Chapter III: Conclusions and Observations

3.1 MIDP Bugs

The project software is tested with a Visor Platinum PDA and the J2ME Wireless

Toolkit. The Toolkit is based on CLDC 1.0.3 and MIDP 1.0.3 [6]. It is found that several

methods of some of the MIDP classes do not behave exactly the same way as what is

specified in the API nor as what is supposed to be according to common sense.

During the experimental phase of the project, different objects and their methods are

tested. An example MIDlet program GuiTest.java is downloaded from an article on Sun’s

web site [7] (Appendix 2). The program uses a list screen to create a menu for the other

screens. It is built into a .prc file and installed on the Visor device. The program works

fine on the device, except for that the testDate and testForm screens can only be accessed

form the menu list once. The two are both from screens. The initialization of GUI objects

in the program is scattered around in the code. After moving the initialization of all GUI

objects into the startApp() life cycle method, all screens can be accessed normally

(Appendix 3).

Another bug is subtler. A reset button is used in the MIDlets to clear all the data input

fields. A setString() function is called to clear the TextField (eg. nameFld.setString("")).

When tested on the Visor handheld set, the text display of the TextField disappears after

the reset button is pushed. However, the cursor stays where the end of the previous text

is. It even stays at the same position when the OK button is pushed and the MIDlet

changes to the next screen. After this screen, the cursor mysteriously disappears.

23

3.2 Performance

The performance of the MIDP classes is quite decent. Human observation can hardly

tell the difference between the execution speed of a MIDP application and that of the

applications that come with the device. The project centers around operations that require

intensive resource usage. For instance, the record store operations need large chunks of

memory, and network connection operations send and receive data over network

connection with limited bandwidth. Complicated IO operations are also involved in both

the data store and the network connection operations. Even those kinds of operations are

executed at a reasonable speed.

The design and implementation of the project closely follows the rules for developing

high performance applications as presented in the previous chapter. These performance-

improving methods certainly helped.

3.3 Enhancements

The application developed in this project is designed to be used in a lab environment.

In order to develop such an application into commercial software, the server side

performance should also be addressed. When hundreds or thousands of PDAs are trying

to connect to the server simultaneously, the server must have a way to avoid becoming

the performance bottleneck. Fortunately, there are patterns already existing for designing

good server side architecture. Technologies like Enterprise Java Beans (EJBs) can also

help simplify the task of developing a scalable, robust, high performance, and secure

commercial software system.

24

Reference:

1. Keith Bigelow (06/11/2001). Are Device Independent Wireless Internet

Applications Possible? Retrieved October, 9, 2001, from the World wide Web:

http://www.onjava.com/pub/a/onjava/2001/08/14/j2me_wireless.html

2. Mobile Information Device Profile (MIDP). Retrieved October, 9, 2001, from the

World wide Web:

http://www.onjava.com/pub/a/onjava/2001/06/11/device_ind.html

3. Mobile Information Device Profile (JSR-37) – JCP Specification, Java 2 Platform,

Micro Edition 1.0a. Retrieved October, 9, 2001, from the World wide Web:

http://java.sun.com/Download4

4. Consumer & Embedded Technologies: Wireless. Retrieved October, 9, 2001,

from the World wide Web: http://java.sun.com/products/consumer-

embedded/wireless/

5. MIDP for Palm OS. Retrieved November, 26, 2001, from the World wide Web:

http://java.sun.com/products/midp4palm/

6. JavaTM 2 Platform Micro Edition, Wireless Toolkit. Retrieved November, 26,

2001, from the World wide Web: http://java.sun.com/products/j2mewtoolkit/

7. MIDP for Palm OS: the wait is finally over – Developing Java Applications for

Palm OS Devices. Retrieved December, 19, 2001, from the World wide Web:

http://developer.java.sun.com/developer/…cts/wireless/midp/articles-palm