Wireless environment for data access on a server

Copyright © 2004 by Vincent Claes, Heusden-Zolder, Belgium
ISBN : 9090180354
The names of the actual companies and products mentioned in this thesis are the
trademarks of their respective owners. Use of a term in this thesis should not be
regarded as affecting the validity of any trademark or service mark.

I
Wireless environment for data access on a server.
Vincent Claes
2003 / 2004
Table of Contents
TABLE OF CONTENTS ................................................................................................................ I
TABLE OF FIGURES .................................................................................................................. III
LIST OF TABLES ........................................................................................................................ IV
EXPRESSION OF GRATITUDE................................................................................................... V
ABSTRACT.................................................................................................................................. VI
ABBREVIATIONS ...................................................................................................................... VII
CHAPTER 1: INTRODUCTION.................................................................................................... 1
CHAPTER 2: CLIENT SIDE ......................................................................................................... 4
INTRODUCTION............................................................................................................................ 5
OPERATING SYSTEMS.................................................................................................................. 6
JAVA
TM
....................................................................................................................................... 6
Why Java
TM
technology on wireless devices? ..................................................................... 7
J2METM
................................................................................................................................. 9
Configurations .............................................................................................................................. 10
Connected device configuration (CDC) ................................................................................... 11
Connected, limited device configuration (CLDC) ..................................................................... 11
Profiles ......................................................................................................................................... 12
The Mobile Information Device Profile (MIDP)......................................................................... 13
The Personal Digital Assistant Profile (PDAP)......................................................................... 16
Java Virtual Machine .................................................................................................................... 17
MIDlet........................................................................................................................................... 18
MIDlet States................................................................................................................................ 18
The MIDlet suite ........................................................................................................................... 20
Inside the JAR ......................................................................................................................... 20
Simple manifest file.................................................................................................................. 21
Inside the JAD file.................................................................................................................... 21
Simple JAD file ........................................................................................................................ 22
SUMMARY CLIENT SIDE ............................................................................................................. 23
CHAPTER 3: XML ...................................................................................................................... 24
INTRODUCTION.......................................................................................................................... 25
XML PARSING IN A MIDP ENVIRONMENT .................................................................................... 29
XML IS THE FUTURE .................................................................................................................. 29
SUMMARY................................................................................................................................. 30
CHAPTER 4: HTTP .................................................................................................................... 31
INTRODUCTION.......................................................................................................................... 32
WEB SERVERS .......................................................................................................................... 33
HTTP IN J2METM
..................................................................................................................... 34
SUMMARY................................................................................................................................. 36
CHAPTER 5: SERVER SIDE ..................................................................................................... 37
INTRODUCTION.......................................................................................................................... 38
SQL......................................................................................................................................... 38
ACTIVE SERVER PAGES............................................................................................................. 38
SUMMARY................................................................................................................................. 40

II
Vincent Claes
2003 / 2004
CHAPTER 6: DEVELOPED PROJECT ..................................................................................... 41
INTRODUCTION.......................................................................................................................... 42
HOW IT WORKS. ........................................................................................................................ 43
SERVER SIDE CODE................................................................................................................... 48
CLIENT SIDE CODE..................................................................................................................... 51
ASPX - XML FILES ................................................................................................................... 54
CHAPTER 7: CONCLUSIONS................................................................................................... 58
CHAPTER 8: FUTURE WORK................................................................................................... 61
CHAPTER 9: ALTERNATIVE TECHNOLOGIES ...................................................................... 63
I-MODE ..................................................................................................................................... 64
WAP / WML............................................................................................................................. 66
SOAP...................................................................................................................................... 67
JXTA FOR J2ME ...................................................................................................................... 68
APPENDIX A .............................................................................................................................. 69
APPENDIX B ............................................................................................................................ 117
APPENDIX C ............................................................................................................................ 123
PDA....................................................................................................................................... 123
MOBILE PHONE ....................................................................................................................... 123
FUTURE.................................................................................................................................. 125
APPENDIX D ............................................................................................................................ 127
VITA .......................................................................................................................................... 128
REFERENCES.......................................................................................................................... 129
LITERATURE............................................................................................................................ 129
WEBSITES .............................................................................................................................. 131
MEETINGS .............................................................................................................................. 131

III
Vincent Claes
2003 / 2004
Table of figures
Figure 1: Anytime Anywhere Data Access............................................................................... 3
Figure 2: The technology stack ................................................................................................. 5
Figure 3: technology stack: OS................................................................................................. 6
Figure 4: CLDC - Profiles.......................................................................................................... 13
Figure 5: The technology stack: Java Virtual Machine......................................................... 17
Figure 6: the technology stack : MIDlets................................................................................ 18
Figure 7: MIDlet lifecycle.......................................................................................................... 19
Figure 8: XML example............................................................................................................. 26
Figure 9: XML tree..................................................................................................................... 27
Figure 10: XML definition ......................................................................................................... 28
Figure 11: HTTP......................................................................................................................... 33
Figure 12: GCF connection protocol....................................................................................... 35
Figure 13: Project overview ..................................................................................................... 42
Figure 14: Screenshot JCreator .............................................................................................. 43
Figure 15: Starting the MIDlet .................................................................................................. 44
Figure 16: Making connection ................................................................................................. 45
Figure 17: Splashscreen........................................................................................................... 45
Figure 18: MainMenu ................................................................................................................ 46
Figure 19: NewsMenu ............................................................................................................... 46
Figure 20: A NewsItem.............................................................................................................. 46
Figure 21: EventMenu............................................................................................................... 47
Figure 22: An EventItem........................................................................................................... 47
Figure 23: An event................................................................................................................... 47
Figure 24: ContentsMenu......................................................................................................... 48
Figure 25: A Content................................................................................................................. 48
Figure 26: news.aspx................................................................................................................ 54
Figure 27: events.aspx ............................................................................................................. 55
Figure 28: Contents.xml ........................................................................................................... 55
Figure 29: page.aspx?id=5....................................................................................................... 56
Figure 30: page.aspx?content=7............................................................................................. 57
Figure 31: Siemens SX1 ......................................................................................................... 126
Figure 32: PalmOne treo 600.................................................................................................. 126

IV
Vincent Claes
2003 / 2004
List of tables
Table 1 : MIDP packages .......................................................................................................... 15
Table 2 : MIDP and PDAP ......................................................................................................... 16
Table 3 : GCF protocol parameters ......................................................................................... 35

V
Vincent Claes
2003 / 2004
Expression of gratitude
I wish to express my gratitude to my parents for letting me study and letting me
go on an Erasmus exchange program to Vigo. I wish to thank my girlfriend Elise
Mues for supporting me.
Secondly I would like to thank all the teachers of the Hogeschool Limburg who
learned me how to solve engineering problems especially Ing. Frank Appaerts,
Ing. Leen Biesemans and last but not least dr. Ing. Jan Boutsen also for his
support concerning the Erasmus program and for being my promoter.
I would like to thank Anselmo Seoane for his efforts relating to the Erasmus
exchange program with the Universidade de Vigo. I want to thank all the
students and teachers of the Universidade de Vigo for giving me such a great
time in Spain.
I want to thank my promoters in Vigo: Ph.D. Luis Anido Rifón and Eng. Luis
Álvarez Sabucedo for helping me and letting me make my thesis with them.
I want to thank Ing. Herman Boyen and Joris Panis for correcting and reading
my thesis.

VI
Vincent Claes
2003 / 2004
Abstract
I have made my thesis in association with the Universidade de Vigo by the way
of an Erasmus exchange program. Because of the extra dimension which offers
internationalization to my studies, I was very motivated to make my thesis
abroad. I have had the pleasure to work under the guidance of Associated
professor, Ph.D. Luis E Anido Rifón with support of Assistant professor,
Telecommunication Engineer Luis Álvarez Sabucedo.
The mobile and wireless industry is a fast growing sector. The fast business
world where we are living in today is in need for mobile professionals that have
at anytime, at any place access to data. Secondly, there is a growing demand
for mobility in the ICT-sector. The nature of a wireless device has moved from a
simple device to a multi-purpose multimedia device that can be used for
different things. These devices must be integrated with existing information
systems.
Creating a “Wireless environment for data access on a server” is making a
client / server application, where the information that we would like to present
on our mobile device is stored on a web-server. J2METM
(Java version 2 Micro-
edition) is used for programming the mobile devices, this is the little brother in
the Java family. The main advantage of using J2METM
is that it gives full control
over the developed application. The server side has been programmed under
VB.NET, a Microsoft product. For the exchange of data between the server and
client we have opted for a HTTP connection over which we send an XML file.

VII
Vincent Claes
2003 / 2004
Abbreviations
API application program interface
ASP active server page
AWT abstract window toolkit
CDC connected device configuration
CLDC connected limited device configuration
FTP file transfer protocol
GCF generic connection framework
GPS global positioning system
HTML hypertext markup language
HTTP hypertext transfer protocol
I/O Input/output
IDE integrated development environment
IETF internet engineering task force
IP internet protocol
J2EE java version 2 enterprise edition
J2ME java version 2 micro-edition
J2SE java version 2 standard edition
JAD Java Application Descriptor
JAR java archive
JCP java community process
JSR java specification request
JVM java virtual machine
KVM K Virtual Machine
MIDlet A program programmed under the MIDP
MIDP mobile information device profile
OS operating system
OTA over the air
PDA personal digital assistant
PDAP personal digital assistant profile
PIM personal information manager
RFC request for comments
SDK software development kit
SQL structured query language
TCP transmission control protocol
UDP user datagram protocol
UI user interface
URI uniform resource identifier
URL uniform resource locator
VB.NET Visual Basic Microsoft .NET platform
WWW world wide web
XML extensible markup language
XSLT extensible style language transformation

== [ Chapter 1 : Introduction ] == 2
Vincent Claes
2003 / 2004
Chapter 1: Introduction
As a last year student I had to make a final project. I had chosen to make
a “Wireless environment for data access on a server” in the Universidade de
Vigo (see appendix D).
The last years there is very much happening in the mobile and wireless
industry. The demand for mobile technology is growing at a huge rate and
mobile devices with the latest technologies are thrown on the market in an
enormous rate. When you want access to a mobile network you just have to put
on your mobile phone and you can get access to the WWW if your mobile
phone supports this. The WWW is closer to you then some people think.
My project is about “anytime anywhere data access”. It is about that you would
like to have information, no matter where you are, on your mobile phone or
PDA. I had to make a client / server application that presents information that is
stored in a SQL database on a web-server. This database was already in use
for the ‘normal’ desktop website. So I didn’t change a thing to the database. The
regular website was written in the .NET platform (this is the newest Microsoft
platform). The site is an aspx-file (active server page), this means that when
you visit such a page it is like running ‘a small application’ that collects the
information out of the database and gets information on how the programmer
would like to present the information on the screen and shows it in your browser
on your desktop computer. The information that is presented on the screen is
dynamically, this means that the people who manage that site only have to
change the information in the database; not the layout and the information that
you get on your device is real time information, when you run this program it
gets the information out of the database that is at that moment in it. You don’t
have to download a whole new program for it. The site where my application is
written for is: Observatorio Medioambiental para PYMEs. Which you can visit on
this URL:
http://observatorioambiental.uvigo.es/Observatorio/inicio.htm.

== [ Chapter 1 : Introduction ] == 3
Vincent Claes
2003 / 2004
Figure 1: Anytime Anywhere Data Access
In order to build an application that does something like this you have more then
one option. We have made the choice to do the client programming in J2METM
(Java 2 Micro-edition). As the connection type between the client and the server
we have used a HTTP connection. The file that is exchanged between the client
and the server is an XML-file (Extensible Markup Language). The server side is
programmed in VB.NET (Visual Basic Microsoft’s .NET platform). It is actually
an aspx-site (active server page) that generates an XML file.
In the first chapters I am going to introduce you in the theoretical background of
my project. We are going to talk about the client side (chapter 2), the kind of file
that is exchanged between the client and the server (chapter 3), the connection
type between the client and the server (chapter 4) and a little bit of server side
programming (chapter 5).
In the last chapters I explain my project and the future of the technologies that I
have used to develop my application. There is also a chapter with conclusions
that I have made when my project was finished.
When you are not familiar with the terms mobile phone or PDA you can check
out appendix C which gives you an introduction to what it is.
Greetings and I hope you will enjoy reading this book.
Vincent Claes
Anytime
Anywhere
Data Access

== [ Chapter 2 : Client Side ] == 5
Vincent Claes
2003 / 2004
Chapter 2: Client Side
Introduction
The client side is the device where we would like to present our
information, that is stored in the database on the web-server, on. In the first
mobile devices all the software was hard-coded by the manufacturer. They are
also called ‘static’. With the introduction of J2METM
(Java Micro-edition) “micro”
devices no longer need to be static, we can develop our own applications for it.
In my project we need a PDA or mobile phone that is java-enabled. This means
that you can run java applications on it. You can simply download new
applications over the air (this means over the mobile network) or you can make
a connection between your personal computer and your mobile phone or PDA
with a data-cable, infrared or BluetoothTM
if this is supported. Today those java-
enabled devices are mostly used for gaming, there are several companies who
make good money out of mobile gaming. But those devices can also be used
for other purposes. For instance you can make an application where you can
communicate with a BluetoothTM
printer (if your device can handle BluetoothTM
).
Figure 2: The technology stack
J2ME MIDlets
JVM (Java Virtual Machine)
Operating system

Vincent Claes
2003 / 2004
For running Java programs we need a device where there is an operating
system and a JVM (Java virtual Machine) on. The kind of program I have written
is called a MIDlet (see later in this book).
Operating systems
Figure 3: technology stack: OS
In the wireless industry there are several manufacturers, they don’t use all the
same operating system and even some manufacturers are making different
models with different operating systems. It is like on the desktop computers you
have Windows, Linux,… platforms. The main OS (operating systems) are:
Symbian, Java, Palm, PocketPC, … and even Linux is available on some
mobile phones!
The client side is divided into 3 layers, the first layer was the Operating System
layer, the next layer are layers that come with Java technology. So first I am
going to explain what Java and J2ME means.
JavaTM
It all started with one version of Java, now known as Java 2 Standard Edition
(J2SE), and the tagline “Write Once, Run Anywhere ™.” The idea was to
develop a language in which you would write your code once, and then it would
run on any platform supporting a Java Virtual Machine, this is something that
translates the Java code into machine code. Since its launch in 1995, the
landscape has changed significantly. Java has extended its goal further than
J2ME MIDlets
Operating system

Vincent Claes
2003 / 2004
desktop machines. Two years after the introduction of Java, a new edition was
released, Java 2 Enterprise Edition (J2EE), providing support for large-scale,
enterprise-wide applications.
The most recent addition to the family is the Micro Edition (J2ME), targeting
“information appliances”, ranging from Internet-enabled TV set-top boxes,
automotive GPS systems, automotive multimedia systems to cellular phones.
Here is a summary of the Java platforms currently available:
• Standard Edition (J2SE): Designed to run on desktop and workstation
computers.
• Enterprise Edition (J2EE): This edition is aimed at server-based
applications.
• Micro Edition (J2ME): Designed for devices with limited memory,
display and processing power (‘limited horsepower’). [5][10][20][15]
Why JavaTM
technology on wireless devices?
The wireless Internet revolution will transform wireless devices from voice-
oriented communication devices with relatively static, hard-coded functionality
into extensible, Internet-enabled devices with advanced data and software
capabilities. These devices will need to support dynamic downloading of new
software and be capable of running software written not only by the device
manufacturers themselves but also by third-party software developers. Today
mostly games but soon there will be much more applications.
The Java™ programming language is ideally suited to become the standard
application development language for wireless devices. After all, the Java
platform provides a number of important benefits:

Vincent Claes
2003 / 2004
• Dynamic delivery of content. New applications, services, and content can
be downloaded dynamically over different kinds of networks.
• Security features ensure that third-party applications behave reliably and
cannot harm the devices or the networks.
• Cross-platform compatibility. Standardized language features and
libraries mean that applications and content can be transferred flexibly
between different devices, within constraints of the supported J2ME™
configuration and profiles.
• Enhanced user experience and interactive content. The standards
defined for wireless Java technology support sophisticated user
interaction and provide graphics capabilities for small devices.
• Offline access. Applications can also be used without active network
connection. This reduces transport costs and alleviates the impact of
possible network failures.
• The power of a modern object-oriented programming language.
• Large developer community. It is estimated that there are more than
three million Java software developers worldwide. The Java
programming language is rapidly becoming the most popular
programming language educated in schools and universities. The
developer talent needed for Java software development already exists
and is readily available.
• This environment can be added flexibly on top of the existing software
and hardware solutions that the device manufacturers already have. [20]
[3][13].

Vincent Claes
2003 / 2004
J2METM
The Java 2 Micro-edition (J2ME) is introduced at the JavaOne conference in
1999.
The key components of the J2ME technology stack are:
• a small device a java-enabled mobile phone or PDA
• a profile we are going to use the MIDP profile
• a configuration we are going to use the CLDC configuration
• virtual machine we are going to use KVM
J2ME is meant for devices with ‘limited horsepower’. It is especially designed
for embedded devices such as consumer electronics, cell phones and PDAs
When you have a look at the market of mobile and small devices you see that
there is a wide range of devices available with different capabilities, so it is
impossible to create a single software product that runs on all of them. J2ME is
therefore a collection of specifications that define a set of a platform, each of
which is suitable for a subset of the total collection of consumer devices that fall
within its range. The subset of the full Java programming environment for a
particular device is defined by one or more ‘profiles’, which extend the basic
capabilities of a ‘configuration’.
The configuration and profile (or profiles) that are appropriate for a device
depend both on the nature of its hardware and the market to which it is
targeted.
A particular device needs :
• one or more ‘profiles’
• a ‘configuration’

Vincent Claes
2003 / 2004
Configurations
Sun introduced configurations to support all the products that fall in the range of
J2ME. A configuration defines a Java platform for a broad range of devices. A
configuration is closely together with a Java Virtual Machine (JVM). In fact, a
configuration defines the Java language features and the core Java libraries of
the JVM for that particular Configuration. The dividing line as to what a
Configuration applies is for the most based on the display, memory, network
connectivity (or limitations of it) and processing power available on a device. [3]
[4] Following are typical characteristics of devices within the two currently
defined configurations:
• Connected Device Configuration (CDC)
• 512 kilobytes (minimum) memory for running Java
• 256 kilobytes (minimum) for runtime memory allocation
• Network connectivity, possibly constant and high bandwidth
• Connected, Limited Device Configuration (CLDC)
• 128 kilobytes memory for running Java
• 32 kilobytes memory for runtime memory allocation
• Restricted user interface
• Low power, typically battery powered
• Network connectivity, typically wireless, with low bandwidth and discontinuous
access

Vincent Claes
2003 / 2004
Connected device configuration (CDC)
CDC is there for devices with relatively large amounts of memory and powerful
processors. According to Sun's documentation, the CDC is meant for higher-
end devices such as newer PDAs, smart communication devices, and set-top
TV boxes. [3]
Connected, limited device configuration (CLDC)
The CDC requirements would make for an expensive mobile phone, IR
scanner,… The CLDC is meant for those smaller, and less expensive, devices
that can't meet the requirements of the CDC. CLDC uses a stripped-down
virtual machine designed to run in a low-memory environment. The reference
implementation of that JVM (Java Virtual Machine) is known as KVM (Kilobyte
Virtual Machine), since its size is measured in kilobytes.
The Connected Limited Device Configuration (CLDC) is the basic building block
on which the J2ME profiles for small devices, such as cell phones, pagers, and
low-end PDA’s, are built. These devices are characterized by their limited
memory resources and processing power, which make it impossible for them to
host a fully featured Java platform. CLDC specifies a minimal set of Java
packages and classes and a compact functionality Java virtual machine that
can be implemented within the resource constraints imposed by such small
devices.
Technology is constant advancing, we must consider that what today is “state-
of-the-art” tomorrow is history! Technology offers us each day more processing
power, increased memory and screen capabilities. So everyday the overlap
between these configurations will become larger.[4] [20]

Vincent Claes
2003 / 2004
Profiles
A profile is an extension to a configuration. It provides a library of code to
support a particular type, or range of devices. A profile complements a
configuration by adding additional classes that provide features appropriate to a
particular type of device. Both J2ME configurations have one or more
associated profiles.
Portability is a critical element of the J2ME value proposition for consumer
devices. Application portability requirements in the consumer space are
generally quite different from portability requirements demanded by the desktop
and server markets. In most cases consumer devices have large differences in
memory size, networking and user interface capabilities, making it very difficult
to support all devices with just one solution. In the consumer market,
applications should ideally be fully portable between devices of the same kind.
In addition, some kinds of applications, such as payment and banking
applications, are expected to be freely portable between many kinds of devices.
This is why there are profiles.
At the implementation level, a profile is defined simply as a collection of Java
APIs and class libraries that reside on top of a configuration to provide domain-
specific capabilities for devices in a specific market segment. [3] [4] [13] [20]

Vincent Claes
2003 / 2004
In CLDC we have to main profiles:
Figure 4: CLDC - Profiles
The Mobile Information Device Profile (MIDP)
The Mobile Information Device Profile (MIDP) is the first and most fully grown
J2ME profile. MIDP is based on the CLDC and is currently supported by major
device manufacturers such as Motorola, Nokia, Ericsson, NEC, PalmOne, LG
TeleCom, Samsung and Research In Motion (RIM) and by carriers like
SprintPCS, Nextel and NTT DoCoMo. Many independent software vendors also
support MIDP.
MIDP targets cellular phones and simple pagers. It provides a very simple and
abstract user interface built of simple elements. The user interface is divided
into a high-level API and a low-level API. The high-level API provides simple
elements such as lists and forms, but it offers only a very limited control over
the concrete appearance on the screen. The low-level API provides full control
over the screen, it’s mainly intended for games. The UI (User Interface) API is
not compatible with any other Java UI API such as AWT or SWING.
First there was the MIDP 1.0. At the moment we have the second version of
MIDP it is called MIDP 2.0. In addition to the MIDP 1.0 APIs for networking,
user interfaces, local persistence and MIDlet life-cycle, MIDP 2.0 adds APIs for
CLDC
MID profile PDA profile

Vincent Claes
2003 / 2004
networking, including socket (TCP) streams, UDP datagrams, serial, push-
initiated and secure connections as well as a robust security API and policy,
and APIs for sound and even gaming. MIDP 2.0 also formally includes in the
profile specification an update of the MIDP 1.0 Over the Air (OTA) User Initiated
Provisioning recommendation (originally defined as an addendum to the MIDP
1.0 specification), which describes how applications are to be discovered and
downloaded over wireless networks. The next table summarizes the packages
available in MIDP 1.0 and MIDP 2.0.[3] [4] [20]
For my project I have worked in MIDP 2.0, a program that is programmed under
the Mobile Information Device Profile (MIDP) is called a MIDlet.

Vincent Claes
2003 / 2004
Package name Description MIDP
1.0
MIDP2.0
java.io MIDP subset of system input and output
through data streams
X X
java.lang MIDP subset of the core Java programming
language
X X
java.util A small subset of utility classes X X
javax.microedition.io Networking support using the Generic
Connection Framework; MIDP 2.0 includes
new socket, UDP, serial, and secure
connection types, and push functionality.
X X
javax.microedition.lcdui MIDP user interface classes X X
javax.microedition.lcdui.game Gaming classes such as sprites, game
canvas, and layer manager
X
javax.microedition.media the The interfaces for controlling (Control) and
rendering (Player) audio – sound classes
compatible with the Mobile Media API (JSR
135) specification
X
javax.microedition.media.control Sound -control classes (ToneControl and
VolumeControl) – compatible with the Mobile
Media API (JSR 135) specification
X
javax.microedition.midlet The application (MIDlet) interface, its life-cycle
classes and its interactions with the runtime
environment, and the application manager
X X
javax.microedition.pki Public key class for certificates used to
authenticate information for secure
connections
X
javax.microedition.rms Persistence classes for storage and retrieval
of data
X X
Table 1 : MIDP packages

Vincent Claes
2003 / 2004
The Personal Digital Assistant Profile (PDAP)
Just as the name suggests, PDAP targets PDAs. PDAP is the first CLDC-based
profile created specifically for PDAs. The PDAP specification, released after the
MIDP specification, was created because MIDP lacks APIs to access the
address books, to-do lists, and other personal information management (PIM)
databases common in personal organizers. Also, PDAs tend to have more
capabilities than MIDP-based devices, necessitating APIs for access to file
storage and serial ports and to provide a richer user interface. Consequently,
PDAP was built on top of MIDP, and adds a subset of the AWT user interface
APIs, new PIM APIs, and connection protocols for serial and file I/O. PDAP
applications, also known as PDAlets, are really MIDlets that run on a PDAP-
enabled device and that use the PDAP APIs. In other words, a PDAlet is a
MIDlet that can take advantage of all the capabilities of a PDA (through the
PDAP APIs) while taking advantage of the entire MIDP framework, including the
MIDlet life-cycle, MIDP APIs, deployment style, and even over-the-air
provisioning. The next table summarizes the packages in PDAP. [4]
MIDP PDAP
Available on phones Yes No*
Available on PDAs Yes Yes
Basic UI capabilities Yes Yes
Wireless Internet access Yes Yes*
Sophisticated UI capabilities No Yes
Address book access No Yes
Calendar access No Yes
* Availability is device-dependent
Table 2 : MIDP and PDAP
Because the PDA profile is a superset of the MID profile, applications that do
not require a sophisticated user interface or PIM access should be based on the
MID profile. This is the main reason I have worked under the MIDP.

Vincent Claes
2003 / 2004
Java Virtual Machine
Figure 5: The technology stack: Java Virtual Machine
The engine behind any Java application is the Java Virtual Machine (JVM).
Once you’ve compiled your Java source code into a .class file(s), and optionally
included them in a Java Archive (JAR) file, the JVM translates the class files
into machine code for the platform running the JVM. It’s what makes your Java
programs go.
For CDC, the virtual machine has the same specification as J2SE. For CLDC
Sun has developed what is referred to as a reference implementation of a
virtual machine, known as the K Virtual Machine, or simply KVM. This virtual
machine was designed to handle the special considerations of resource-
constrained devices. The KVM is not the “traditional” Java virtual machine:
• The virtual machine itself requires only 40 - 80 kilobytes of memory
• Only 20–40 kilobytes of dynamic memory (heap) are required
• Can run on 16-bit processors clocked at only 25 MHz
This typically applies to digital cellular phones, pagers, personal organizers, and
small retail payment terminals. The KVM is Sun’s implementation of a JVM that
fits the guidelines of the CLDC. It is not necessarily the only JVM that is or will
be available.
J2ME MIDlets
Operating system

Vincent Claes
2003 / 2004
The KVM is derived from a research system called Spotless at Sun
Microsystems Laboratories. The aim of the Spotless project was to implement a
Java system for the Palm Connected Organizer. [13] [20]
MIDlet
Figure 6: the technology stack : MIDlets
A MIDlet is an application that conforms to the MIDP standard. You see the
consistency with an applet that is an application that conforms to the J2SE
standard.
A MIDlet is to a mobile device what an applet is to a web browser. But this
definition needs some qualification. While an applet runs inside a browser, the
MIDlet runs on top of the KVM embedded in the device. A MIDlet's properties
can be set in a text file that has a .jad extension. This jad file makes the midlet
known to the KVM, the java runtime environment in the device. [3] [20]
MIDlet States
MIDlets have a well-defined life cycle. A MIDlet is typically started (for example,
when the user launches it from a screen of applications available to be run), it
interacts with the user through its graphical user interface, and is then stopped
(for instance, when the user chooses a button labeled "Exit").
In general, during the lifetime of a MIDlet, it may be in one of three distinct
states, with well-defined rules that govern the transitions between these states:
J2ME MIDlets
Operating system

Vincent Claes
2003 / 2004
• Paused: A MIDlet is in the Paused state when it has just been
constructed and has not yet entered its startApp method. It can also be in
the Paused state as a result of the pauseApp method. When in the
Paused state, a MIDlet should hold as few resources as possible.
• Active: A MIDlet is in the Active state upon entry to its startApp method.
While in the Active state, a MIDlet can allocate and hold all necessary
resources for optimal execution.
• Destroyed: A MIDlet is in the Destroyed state when it has returned from
the destroyApp method. Once a MIDlet enters the Destroyed state, it
cannot re-enter any other state. The Destroyed state replaces the normal
convention of an application calling the System.exit method to terminate.
A MIDlet cannot call the System.exit method, since doing so will throw a
java.lang.SecurityException.[2] [3] [4] [6] [20]
Figure 7: MIDlet lifecycle
ActivePaused
Destroyed
new thesis()
pauseApp
startApp
destroyApp
destroyApp

Vincent Claes
2003 / 2004
The MIDlet suite
If you would like to package your MIDlet(s) and transfer it to a device that
supports MIDP, you will have to make a Java archive file (JAR). A JAR file
consists of class files and any additional resources required by your application.
Typical resources include images and application data. A MIDlet suite is a JAR
file that contains one or more MIDlets. A Java Application Descriptor (JAD) is an
optional file that can accompany the JAR when deploying your MIDlet(s). A JAD
file provides information about MIDlets within a JAR. Although not a
requirement, a JAD file may come in handy if a device is being installed in a
MIDlet suite. The JAD makes information available to the application manager,
the software on a MIDP-enabled device. With this information, the manager can
find out if the device can accommodate the MIDlet. For instance, the JAD file
contains an attribute that specifies the size of the JAR file in bytes, containing
the MIDlet. Armed with this information, the manager could peek at the memory
availability on the device to see if there is sufficient space available before
downloading the JAR.[13]
Inside the JAR
A JAR file consists of class files and any additional resources required by a
MIDlet. There is one additional file that is contained in every JAR, called the
manifest.
There are six attributes that must be in the manifest:
• MIDlet-Name -- Name of the MIDlet suite
• MIDlet-Version -- Version number of the MIDlet
• MIDlet-Vendor -- Who created the MIDlet
• MIDlet-<n> -- Information about MIDlet(s) in the suite
• MicroEdition-Profile -- What profile is required by the MIDlet
• MicroEdition-Configuration -- What configuration is required by the
MIDlet

Vincent Claes
2003 / 2004
Simple manifest file
MIDlet-Name: Observatorio Medioambiental Micro-edition
MIDlet-Version: 1.0
MIDlet-Vendor: Vincent Claes © (2003)
MIDlet-1: Project20, Project20.png, Project
MicroEdition-Profile: MIDP-2.0
MicroEdition-Configuration: CLDC-1.0
The MIDlet-1 reference has three possible parameters:
1. The name of the MIDlet (e.g. Project20)
2. The image file to associate with the MIDlet (e.g. Project20.png)
3. The name of the class file to load the MIDlet (e.g. Project)
The image reference (e.g. /images/Memopad.png) is an optional parameter.
There may be multiple MIDlets within a suite. Put the numeric value in
increments to refer to additional MIDlets. For example: MIDlet-2: NewsReader,
/images/NewsReader.png, MainNewsReader. All six attributes must exist in the
manifest file.[13]
Inside the JAD file
A JAD file provides information about the MIDlet(s) within the suite. As with the
manifest file (that is part of the JAR file) there are several required attributes
that must be included in the JAD file.
Required JAD attributes:
• MIDlet-Name -- Name of the MIDlet suite
• MIDlet-Version -- Version number of the MIDlet
• MIDlet-Vendor -- Who created the MIDlet
• MIDlet-<n> -- Information about the MIDlet(s) in the suite
• MIDlet-Jar-URL -- The URL of the JAR file
• MIDlet-Jar-Size -- The size, in bytes, of the JAR

Vincent Claes
2003 / 2004
Although the MIDP specification does not state the attribute MIDlet-<n> as
required, you may have trouble running your MIDlets without this attribute in the
JAD file. Specifying this attribute does not cause any additional overhead;
therefore, to maintain regularity, I recommend you always place this attribute in
both the manifest and the JAD.[13]
Simple JAD file
A simple JAD file may look like the following:
MIDlet-Name: Observatorio Medioambiental Micro-edition
MIDlet-Version: 1.0
MIDlet-Vendor: Vincent Claes © (2003)
MIDlet-1: Project20, Project20.png, Project
MIDlet-Jar-URL: Project20.jar
MIDlet-Jar-Size: 100
MicroEdition-Configuration: CLDC-1.0
MicroEdition-Profile: MIDP-2.0
Notice that MIDlet-Name, MIDlet-Version and MIDlet-Vendor have the same
values as the attributes with the same name in the manifest. This is a
requirement. If an attribute other than the three just mentioned is shown in both
the manifest and the JAD, the value inside the JAD will take priority. For
example, if both the manifest and JAD have a reference to MIDlet-Jar-Size, the
value in the JAD file will be used by the application manager.[13]

Vincent Claes
2003 / 2004
Summary Client Side
At the heart of J2ME are the configurations, each of which defines the basic
functionality of the Java platform for a family of devices. Two configurations
have been defined: the Connected Limited Device Configuration (CLDC) for the
smallest devices, and the Connected Device Configuration (CDC) for larger,
more powerful devices. On top of the configurations are the profiles, which flesh
out the core APIs supplied by a configuration with classes for building user
interfaces, making network connections, and controlling application life-cycles.
The CLDC-based profiles are the Mobile Information Device Profile (MIDP) and
the Personal Digital Assistant Profile (PDAP). J2ME also includes optional
packages, sets of APIs that extend profiles by adding specific functionality. In
the next chapter we will explain such an optional package that I have used for
parsing XML. The chapter you just read is one of the most important of my
project because most of the time I was programming in J2ME.

== [ Chapter 3 : XML ] == 25
Vincent Claes
2003 / 2004
Chapter 3: XML
Introduction
I have chosen to transmit an XML file between the client and the server
in my application.
Extensible Markup Language, or XML for short, is a new technology for web
applications. It is a text-based markup language just like HTML. As with HTML,
you identify data using tags (identifiers enclosed in angle brackets, like this:
<...>). Collectively, the tags are known as "markup". XML is a World Wide Web
Consortium standard that lets you create your own tags so the tags are not
predefined, this is the main difference with HTML. Maybe do you think: why do
we need XML when everyone's browser supports HTML? HTML tags are for
browsing; they're meant for interactions between humans and computers.
HTML tags describe how the information that is between the tags should look
on the screen (the visualization of the data), they don’t contain any information
about what the data is. XML was designed to describe data and to focus on
what data is (the identification of the data).
XML is on its way to become the de facto language for communications
between devices, web browsers, computers, servers and applications. In time,
any two applications will be able to exchange information without ever having
been designed to talk to each other. [22]
• XML was designed to describe data and to focus on what data is.
• HTML was designed to display data and to focus on how data looks.

== [ Chapter 3 : XML ] == 26
Vincent Claes
2003 / 2004
Let's look at a sample XML Code:
Figure 8: XML example
The first line in this XML code defines the XML version. In this case the
document conforms to the 1.0 specification of XML. From the next tags you see
that we are going to describe a product that has a barcode 45648456. The next
tags give us the manufacturer, the name, the quantity, the size, the color and
the description of this product. When we would for instance know what the color
is we can simply check the contents between the color-tags and we see that the
color is black! In my application there is not very much more that you need to
know about XML to understand it.
In XML we mean with an element the start-tag and the end-tag (for instance:
<color> </color> this is the color element). Everything between the start-tag and
the end-tag of the element is called the element’s content (for instance: black is
the content of the element color). Every XML document has one element that
does not have a parent, this is the first element in the document and the
element that contains all other elements. In my example this is the product tag.
It is called the root element of the document. Every well-formed XML document
has exactly one root element. Since elements may not overlap, and since all
elements except the root have exactly one parent, XML documents form a data
structure programmers call a tree. The manufacturer, name, quantity, size, color
and description tags are called children. They are children of the product tag.
XML elements can have attributes. An attribute is a name-value pair attached to
the element's start-tag. Names are separated from values by an equals sign
<?xml version="1.0"?>
<product barcode="45648456">
<manufacturer>Verbatim</manufacturer>
<name>DataLife MF 2HD</name>
<quantity>10</quantity>
<size>3.5</size>
<color>black</color>
<description>floppy disks</description>
</product>

== [ Chapter 3 : XML ] == 27
Vincent Claes
2003 / 2004
and optional white space. Values are enclosed in single or double quotation
marks (in my example the barcode is an attribute of the product).
Figure 9: XML tree
There is no given method for rendering XML documents. Therefore, what it
means to ‘browse'XML is open to interpretation. For example, an XML
document describing the features of a mobile phone does not carry any
information about how that information should be presented to a user. An
application is free to use the data to produce an image of the features of the
phone, generate a formatted text listing of the information, display the XML
document's markup with a pretty color scheme, or reform the data into a format
for storage in a database, transmission over a network or input to another
program.
However, even though the fact that XML documents are purely descriptive data
files, it is possible to ‘browse’ them, by rendering them with stylesheets. A
stylesheet is a separate document that provides hints and algorithms for
rendering or transforming the data in the XML document.
There are more than one stylesheet languages available for displaying an XML
file in your browser. A complex and powerful stylesheet language is XSLT, the
transformations part of the Extensible Stylesheet Language, which can be used
to transform XML to other formats, including HTML, other forms of XML, and
Product
manufacturer name quantity size color description

== [ Chapter 3 : XML ] == 28
Vincent Claes
2003 / 2004
plain text. If the output of this transformation is HTML, it can be viewed in a web
browser as any other HTML document would. Much XML content on the web is
translated to HTML on the servers. It is this generated HTML that is delivered to
the browsers. Most of Microsoft’s web site (http://www.microsoft.com), for
example, exists as XML that is converted to HTML. The web browser never
knows the difference.
When using XML, I can receive XML-tagged data from your system and you
can receive XML-tagged data from mine. None of us has to know how the
other's system is organized. If another partner or supplier works with my
organization, I don't have to write code to exchange data with their system.
• XML stands for EXtensible Markup Language
• XML is a markup language much like HTML
• XML was designed to describe data
• XML tags are not predefined. You must define your own tags
• XML was designed to carry data.
• XML is not a replacement for HTML.
XML and HTML were designed with different goals:
• XML was designed to describe data and to focus on what data is.
HTML was designed to display data and to focus on how data looks.
• HTML is about displaying information, while XML is about describing
information.[13][18][22]
Figure 10: XML definition
XML is a cross-platform, software and
hardware independent tool for transmitting
information.

== [ Chapter 3 : XML ] == 29
Vincent Claes
2003 / 2004
XML parsing in a MIDP environment
To read and update - create and manipulate - an XML document, you need an
XML parser. In my thesis I was just in need to read XML in J2ME, so on the
client side I had to implement an XML parser that reads the data out of the XML
tags.
An XML parser (also known as an XML processor) reads the document and
verifies that the XML it contains is well formed. It may also check that the
document is valid, though this test is not required. But assuming the document
passes the tests, the processor converts the document into a tree of elements.
You can use XML parsers in J2ME applications to interface with an existing
XML service. For instance, you could get news on your phone from a site that
gives you headlines and stories in XML format. XML parsers used in a MIDP
environment have to be small to meet the resource limitations of MIDP-based
devices.
In my project I have chosen for kXML (http://www.kxml.org). Because there is
the most information available on the web. But you can also use NanoXML,
TinyXML or others if you want. kXML is an open source project that is specially
written for the CLDC. [14][20]
XML is the future
It is incredible to see how fast the XML standard has been developed and how
quickly a large number of software vendors have adopted the standard.
I believe that XML will be very important in the future when concerning data
transmission and data manipulation. [13][22]

== [ Chapter 3 : XML ] == 30
Vincent Claes
2003 / 2004
Summary
So why do we need XML? XML makes it easier for two systems to exchange
data with each other. With XML your data is described using tags that explain
what each piece of data is. XML doesn't replace HTML, though; they're
designed for unlike purposes. XML is the Web's language for data interchange
and HTML is the Web's language for showing information (rendering). XML is a
non-proprietary format, not encumbered by copyright, patent, trade secret, or
any other sort of intellectual property restriction. It has been designed to be
extremely powerful, while at the same time being easy for both human beings
and computer programs to read and write. Thus it’s an obvious choice for
exchange languages.

== [ Chapter 4 : HTTP ] == 32
Vincent Claes
2003 / 2004
Chapter 4: HTTP
Introduction
HTTP (HyperText Transfer Protocol) is the protocol of the Web, by which
servers and clients (typically browsers) communicate.
In order to get the data from the web server to the client I was in need for a
connection. There are many ways to make a connection between a computer
and a mobile device (PDA / Mobile phone). You can use infrared, serial cable,
BluetoothTM
,…
When you want to visit a page on the web with a desktop computer your web
browser must ‘talk’ to a web server somewhere else. When web browsers talk
to web servers, they speak a language known as HTTP. HTTP defines how
messages are formatted and transmitted, and what action web servers and
browsers should take in response to diverse commands.
For instance, when you enter a URL in your browser, this actually sends an
HTTP command to the Web server directing it to fetch and transmit the
requested Web page.
An HTTP transaction contains ‘a request’ sent by the Client to the Server,
and ‘a response’ returned from the Server to the Client.

== [ Chapter 4 : HTTP ] == 33
Vincent Claes
2003 / 2004
Web servers
Any Web server machine contains, in addition to the Web page files it can
serve, an HTTP daemon, a program that is designed to wait for HTTP requests
and handle them when they arrive. Your Web browser of your desktop
computer is a HTTP client, sending requests to server machines. When the
browser user enters file requests by either ‘opening’ a Web file (typing in a
Uniform Resource Locator or URL) or clicking on a hypertext link, the browser
builds an HTTP request and sends it to the Internet Protocol address (IP
address) indicated by the URL. The HTTP daemon in the destination server
machine receives the request and sends back the requested file or files
associated with the request.[23]
The web server used in my project was running IIS (Internet Information
Services). IIS comes as a windows component.
Figure 11: HTTP
HTTP is used as
connection between
the client and the
server

== [ Chapter 4 : HTTP ] == 34
Vincent Claes
2003 / 2004
HTTP in J2METM
Wireless devices such as mobile phones keep their owners connected to the
outside world at anytime from any place. Network programming plays an
important role in wireless application development to take advantage of the
connectivity these devices have to offer.
For the Java 2 Standard Edition, the classes for handling network connections
are located in the java.net package. This package contains a lot of different
classes. It includes at least one class for each type of connection (HTTP, socket
connections,…) It also contains many support classes, for instance classes for
handling URLs or decoding Internet addresses. In sum, the java.net package
includes more than 20 classes, interfaces and exception classes.
The huge amount of classes and interfaces that is needed to support network
capabilities would be too much to be adopted for the Java 2 Micro Edition.
Thus, the Connected Limited Device Configuration (CLDC) takes a different
approach: instead of providing one class for each protocol like J2SE, CLDC
offers an uniform approach for handling connections, the so called Generic
Connection Framework (GCF). GCF contains only one generic Connector class.
The Connector class takes a URI as input and returns a corresponding
connection object, depending on the protocol parameter of the URI (Uniform
Resource Indicator) string. The protocol parameter of an URI is the part from
the beginning of the string to the first colon. For example, for an HTTP
connection, the protocol parameter is the leading http of an address such as
http://www.mobilealliance.org. The general form of URI strings that are passed
to the Connector class is as follows:

== [ Chapter 4 : HTTP ] == 35
Vincent Claes
2003 / 2004
Figure 12: GCF connection protocol
The syntax of the strings that are passed to the Connector.open() method
needs to follow the Uniform Resource Indicator (URI) syntax that is defined in
the IETF standard RFC2396. The complete RFC can be found under the
following URL:http://ww.ietf.org/rfc/rfc2396.txt.
The CLDC itself specifies interfaces, classes and exceptions of the GCF only.
No implementations of any concrete connection type are provided at the
configuration level.
The next table gives an illustrative view of connection types that can be
implemented by a particular J2ME profile such as the MID or PDA Profile. J2ME
profiles might include more protocols that are not listed in this table.
Protocol Sample String Parameter for Connector.open( ) Connection Type
HTTP http://www.mobile-it.be HttpConnection
Sockets socket://time-a.nist.gov:13 StreamConnection
ServerSockets serversocket://:4444 StreamConnectionNotifier
Serial comm:0;baudrate=2400; CommConnection
Datagrams datagram://127.0.0.1 DatagramConnection
File file://uvigo.dat FileConnection
Bluetooth "bluetooth://psm=1001" StreamConnection
Table 3 : GCF protocol parameters
<protocol>://<address>;<parameters>

== [ Chapter 4 : HTTP ] == 36
Vincent Claes
2003 / 2004
Whether a certain protocol is actually available depends on the device. For
example, it does not make sense to support the comm protocol on devices
without a serial port.
It is possible to create a CLDC-based device without display, implementing a
web server as a user interface. Examples might be configurable network routers
or production control hardware.[4][20]
Summary
Although HTTP is predominantly used to carry HTML from web servers to web
browsers, it is also possible to use it to carry other types of information such as
XML, images, or even binary data. Furthermore, the communicating parties do
not have to be a browser and a web server. It can also be a MIDlet who is
talking to a web server over a HTTP connection. I have used the HTTP
connection to get the XML file from the web server to the client.

== [ Chapter 5 : Server Side ] == 38
Vincent Claes
2003 / 2004
Chapter 5: Server Side
Introduction
The server side is the side where the information is stored in a database,
there was a SQL (Structured Query Language) database available with all the
information in. But I had to do some additional programming on the server side.
I had to program in VB.NET an aspx (Active Server Page) site. This aspx site
returns us an XML-file that can be parsed by the client (in J2ME by use of
kXML) so that the information can be viewed on the screen of the client.
SQL
SQL stands for Structured Query Language. It is an ANSI (American National
Standards Institute) standard computer language for accessing and
manipulating database systems. SQL statements are used to retrieve and
update data in a database. SQL works with database programs like MS Access,
DB2, Informix, MS SQL Server, Oracle, Sybase, etc.
There was little SQL code in my project so much more information is not
needed to understand it.[22]
Active Server Pages
Normal web pages contain usually a mix of text and HTML tags. Active Server
Pages (ASPs) are web pages that contain server-side scripts in addition to the
usual mix of text and HTML (HyperText Markup Language) tags. To
differentiate them from normal HTML pages, Active Server Pages are given the
".asp" extension. Server-side scripts are special commands you put in web
pages that are processed before the pages are sent from your web server to the
web browser (the client) of someone who's visiting your Web site. It is like
running a small application that collects everything that the user requests.

Vincent Claes
2003 / 2004
• When you type an URL in the address box or click a link on a web page,
you're asking a web server on a computer to send a file to the web
browser (the client) on your computer. If that file is a normal HTML file, it
looks just the same when your web browser receives it as it did before
the web server sent it. After receiving the file, your web browser displays
its contents as a combination of text, images, and sounds.
• In the case of an Active Server Page, the process is similar, except
there's an extra processing step that takes place just before the web
server sends the file. Before the Web server sends the Active Server
Page to the web browser, it runs all server-side scripts contained in the
page. Some of these scripts display the current date, time and other
information. Others process information the user has just typed into a
form, such as a page in a web site's guestbook. I have used it to get the
data out of the database and to generate an XML file.
The look of an Active Server Page depends on who or what is viewing it. To the
Web browser that receives it, an Active Server Page looks just like a normal
HTML page. If a visitor of a Web site views the source code of an Active Server
Page, they see a normal HTML page. However, the file located in the server
looks very different. In addition to text and HTML tags, you also see server-side
scripts. This is what the Active Server Page looks like to the Web server before
it is processed and used as a reply to a request. So on the client side you just
see the information that you have requested; on the server side you see the
‘code’ of the ASP page.[16][22][23][24]

Vincent Claes
2003 / 2004
Summary
I have programmed in ASP.NET. This gives build-in support for 3 programming
languages: Visual Basic, C# and Jscript. The programming is done in VB.NET
(Visual Basic - Microsoft .NET platform). When you visit an ASP page it is just
like there is running a small application on the server side that collects the
requested information and generates a HTML file that can be displayed in the
web browser on the client side with the requested information in it. I have
generated an XML file with it.

== [ Chapter 6 : Developed Project ] == 42
Vincent Claes
2003 / 2004
Chapter 6: Developed Project
Introduction
Here I give an overview of the system.
Figure 13: Project overview
You see the 2 parts of the system the client side and the server side (that is
connected to the web). The client side is Java enabled and we have written a
program in J2ME for it (remember a program made under the MIDP is called a
MIDlet). The server side is programmed under VB.NET and returns an XML file
if everything works fine. So if we start now our MIDlet it makes an information
request to the Web Server. We send a request that we would like to have the
information that is stored on the web server. We send this request over an
HTTP connection. The server looks for the information in the database where
the information is stored in and generates an XML file. This XML file is viewed
by the MIDlet that I have programmed on the client side. The client side parses
the XML file by use of kXML and displays it on the screen. So now you can see
the information that you requested on the screen of your mobile device.
Normally this would happen. If there is an error such as network down, the
server is down or so on you can not use the program.

Vincent Claes
2003 / 2004
How it works.
Until now we have been talking about the theoretical background of my project.
The first things I did for developing my project was downloading the J2SE SDK,
the CLDC and the MIDP and implementing this into my IDE (Integrated
Development Environment), I used JCreator as my IDE
(http://www.jcreator.com).
Figure 14: Screenshot JCreator
For simulating I have used the Wireless Toolkit which you can download from
Sun’s website (http://www.sun.com) but later I downloaded the Sony-Ericsson
wireless toolkit because with that you can test your application on a device that
is real sold in shops. This is all there was needed to program the client side.
I have written my XML files in XMLSPY (http://www.xmlspy.com). For
programming the server side I have used Visual Studio .NET which is a

Vincent Claes
2003 / 2004
Microsoft product. For uploading test XML files I have used SmartFTP which is
an excellent FTP client. You shall see that the screenshots I use here are made
when simulating on the Sony-Ericsson emulator. The phone I used for
simulating on is the Sony Ericsson K700 which is MIDP 2.0 enabled.
Figure 15: Starting the MIDlet

Vincent Claes
2003 / 2004
When you start my application you must first give the MIDlet permission to
access the network this is build in because getting on the network may cost you
money.
Figure 16: Making connection
The next screen that comes to you is a splashscreen that is there for some
seconds, it gives you information on what this application is about and who it
has developed.
Figure 17: Splashscreen

Vincent Claes
2003 / 2004
After this screen you will be automatically taken to the main menu of the
application. On top of the screen you see a ticker that welcomes you. In this
main menu you have three options and an EXIT button, the options are: news,
events and contents. The EXIT button is meant for quitting the application.
When you click on one of the options in the list, you go to another menu where
there will be shown a new main screen of the option you selected.
Figure 18: MainMenu
Figure 19: NewsMenu
When you are in the news menu you can select there a news item when you do
so you will get more information on the item you selected. There will be a new
screen on your device.
Figure 20: A NewsItem

Vincent Claes
2003 / 2004
When you select events from the main menu you go to the events menu. There
you can choose for an event where you want more information on. If you select
an event you go to a next screen where there is more information available on
that event. From this menu you can go to various other screens. Like there is
the main events menu screen, you can go to the screen of the next event, you
can go to the previous event, you can go to the page of the event where there
will be more information available from the selected event. Or you can EXIT the
program.
Figure 21: EventMenu
Figure 22: An EventItem
Figure 23: An event

Vincent Claes
2003 / 2004
When you select the contents option from the list in the main menu you go to
the main contents menu. There are 9 options available. When you select an
option you go to the page of that content option you selected.
Figure 24: ContentsMenu
Figure 25: A Content
Server side code
First I want to say that you can find the full source code of my application in the
appendix (Client side = Appendix A, Server side = Appendix B).
The best way to explain the code of my project is beginning with the generation
of the XML files that are formed out of the information in the database on the
server side and that are when received parsed on the client side. The
information that we get out of the SQL database is on the server side being put
between brackets the so called ‘tags’.
When looking at the first lines of the code we see there is a #Region and #End
Region this code is there for navigating through the code it expand or shrinks
the structure of the xml - file.

Vincent Claes
2003 / 2004
When you want to access a SQL database from ASP.NET you need to:
• Create a database connection using the SqlConnection class
• Select a set of records from the database using the SqlDataAdapter
class
• Fill a new DataSet using the SqlDataAdapter class
• If you are selecting data from a database from non-interactive display
only, it is recommended that you use a read-only, forward only
SqlDataReader for best performance. When using a SqlDataReader,
select the records using a SqlCommand query and create a
SqlDataReader that is returned from the SqlCommand object’s
ExecuteReader method.
• Bind a server control, such as DataGrid, to the DataSet, SqlDataReader
or DataView.
Response.Cache.SetExpires(Date.Now)
This code sets the expiration time to now. Once you have enabled output
caching, the initial HTTP GET request for the page places its dynamic content
in the output cache for the amount of time you specify. The output cache
satisfies subsequent GET, HEAD, or POST requests for that page until the
amount of time you specify expires.
Response.ContentType=”text/xml”
This informs the client (browser,…) that the response of the request is XML.
System.DateTime.Today.ToShortDateString()
The return value of this is a string that contains the numeric month, the numeric
day of the month and the year equivalent to the date of this instance.

Vincent Claes
2003 / 2004
Response.Write()
The Write method writes a specified string to the current HTTP output.
Response.Flush()
The flush method sends buffered output immediately, if the flush method is
called on an ASP page, the server does not honor Keep-Alive requests for that
page. It is used to be sure everything is transferred.
Return (entrada.Replace (“&”, “&”))
This line replaces the & with an ampersand because VB.NET don’t recognize &
as an ampersand.
Me.Request.QueryString(“id”)
The QueryString retrieves the values of the variables in the HTTP query string.
The HTTP query string is specified by the values following the question mark
(?).[16][24]

Vincent Claes
2003 / 2004
Client side code
CLDC packages that I have used:
• java.io: This provides classes for input and output through data streams
• java.lang: Provides classes that are fundamental to the Java programming
language
• java.util: Contains the collection classes, and date and time facilities
• javax.microedition.io: Classes for the Generic Connection framework
If you want more information about the CLDC packages you can download the
javadoc at Sun’s website.
MIDP 2.0 packages that were used in my project:
• javax.microedition.lcdui: This is an user interface package.
The UI API provides a set of features for implementation of user
interfaces for MIDP applications. This package includes both the high-
level UI classes (such as Form, Command, DateField, TextField and
more), as well as the low-level UI classes (allowing Low-level control
over the UI).
• javax.microedition.midlet: this is the application lifecycle package.
The MIDlet package defines Mobile Information Device Profile
applications and the interactions between the application and the
environment in which the application runs.
• javax.microedition.io: this is a networking package
MID profile includes networking support based on the Generic
Connection framework from the Connected, Limited Device
Configuration.
• java.util: this is a core package
MID Profile Utility classes included from Java 2 Standard Edition [20]

Vincent Claes
2003 / 2004
Here are some primary APIs that I have used in this project:
• Ticker: Tickers implement a ticker string, a piece of text that runs
continuously across the top portion of the display. The direction and
speed of scrolling are determined by the implementation. When
animated, the ticker tape string scrolls continuously. That is, when the
string finishes scrolling off the display, the ticker starts over at the
beginning of the string. There is no API provided for starting and stopping
the ticker. However, the implementation is allowed to pause the scrolling
for power consumption purposes – for example, if the user doesn't
interact with the device for a certain period of time. The implementation
will resume scrolling the ticker when the user interacts with the device
again.
• List: This is the API most frequently used by MIDP developers. The List
class is defined as a screen containing a list of choices. When a List is
presented on the display, the user can interact with it indefinitely (for
instance, traversing from element to element and possibly scrolling).
These traversing and scrolling operations do not cause application-
visible events. The system notifies the application when a Command is
invoked.
• Form: When the developer wanted to add more then one item to a
screen, he uses the Form API. A Form is defined as a screen that
contains an arbitrary mixture of items: images, read-only text fields,
editable text fields, editable date fields, gauges, and choice groups. In
general, any subclass of the Item class may be contained within a Form.
None of the components contained in the Form has any internal scrolling;
all contents scroll together.

Vincent Claes
2003 / 2004
• Alert: An alert is a screen that informs the user about an exceptional
condition or error. The alert screen can handle both text and images.
There are two variations of alert screens: timed and modal. The timed
variation allows the alert to pause for a certain period of time before
proceeding to the next screen on its own. The model variation requires
input from the user before it can proceed; the user must initiate a
command (for example, press a button) for the screen to go away. If
there is not enough space to display all of the timed alerts, and the user
is forced to scroll the screen, the timed alerts can be turned into modal
alerts.
• Command: The Command object encapsulates the name and
information related to the semantics of an action. It is primarily used for
presenting a choice of actions to the user. The behavior that the
Command activates is not encapsulated in the Command object. This
means that it contains only information about “Command,” not the actual
action that occurs when Command is activated. The resulting behavior is
defined in a CommandListener associated with the screen. Each
Command contains three pieces of information: a label, a type, and a
priority. The label is used for the visual representation of the command;
the type and priority are used by the system to determine how the
Command is mapped into a concrete user interface.[20]
If you want more information you can download the MIDP javadoc at Sun’s
website.
I have used one third party library:
• org.kxml2.io: this is kXML, the XML parser that I used to parse my XML
files.[14] [20]

Vincent Claes
2003 / 2004
ASPX - XML files
When you watch the aspx files in a normal desktop browser like internet
explorer you see XML files. Those XML files are generated with the code I have
developed in VB.NET. You see the tags and the information between the tags.
This information will be parsed on the mobile device when received.
Figure 26: news.aspx

Vincent Claes
2003 / 2004
Figure 27: events.aspx
Figure 28: Contents.xml

Vincent Claes
2003 / 2004
You see that this file (Fig. 28) is a static XML file, it was not needed to make the
contents menu dynamic, because the contents of this menu doesn’t change.
Figure 29: page.aspx?id=5
On this screen you see very good that we requested only for page 5, so we only
get the information about page 5. We are not interested in the other pages. Only
the one that we requested.

Vincent Claes
2003 / 2004
Figure 30: page.aspx?content=7
Here we only see the page of content number 7, because we only requested
this one by use of the ‘content=7’ parameter.

== [ Chapter 7 : Conclusions ] == 59
Vincent Claes
2003 / 2004
Chapter 7: Conclusions
The application that I have developed shows that it is possible to let a
web server and a wireless device talk to each other. The concept of this system
is very easy and that is a big advantage. With my work I show furthermore that
there is no need to use one platform for making a client / server application that
works fine. It is possible to use Microsoft technology on the server side and use
Sun’s Java technology on the client side. To do this I have used the power of
XML, this is a very powerful cross platform, software and hardware independent
tool for transmitting information. You can see the program I have written on the
client side as a kind of micro-browser that understands the XML files and tags
that I have created, just like your Internet Explorer or other browsers recognize
the HTML tags and know what to do with it.
Content and service providers don’t want to write applications for every possible
mobile device. Developers know that an application can be written once and
then run on any of the millions of J2ME devices. By the same logic, device
manufacturers will want to support J2ME and MIDP so that their devices have
immediate access to widest range of services. MIDP provides a quite minimal
but a functional framework for small devices like cellular phones and two-way
pagers.
The next years there will be much going on in the wireless and the mobile
industry the demand for mobility and mobile applications is constantly growing.
When designing an application like this you must keep in mind that you must try
to do so much as possible processing of the data on the server side. Because
there is the most memory and processing power available. You must also think
about that you have only a very limited screen-size on your client and not very
handy input tools. The mobile network needed for my wireless environment for
data access on a server is available today, you don’t need a high-bandwidth
network. But when in the future there will be UMTS available the market of
mobile applications will grow in a huge rate. Then you can design applications

== [ Chapter 7 : Conclusions ] == 60
Vincent Claes
2003 / 2004
for video calling, watching movies on your mobile device when you are
traveling,…. We are living in a world where we would like to have constant
access to real time information, when we put all the information we have on
servers we can access it everywhere we go if we take our mobile device with
us.[8]
There is one thing we must not forget: we must install the MIDlet on the mobile
device where we would like to use it on. The user must find my application. For
instance I can sell it by use of the sharewire system (more information on
http://www.sharewire.net). This is a system where you can sell your mobile
content like games, applications, ringtones,… and the users can pay by various
systems like visa, premium SMS or like that so it is possible to earn money with
your developed application or game.

== [ Chapter 8 : Future Work ] == 62
Vincent Claes
2003 / 2004
Chapter 8: Future Work
I can think about several applications where you can use my system, or where
there will be some future for my application; it can be very good integrated into
mobile games for getting the high scores into the games.
I can develop this application further so that it will be possible to change the
information in the database too. When we are then capable of integrating a
web-server into our home we can install a database on this server where we
keep all the stuff in that we have in our fridge,… so we can see from in the shop
what we have or what we need to buy, on our mobile device if we run a MIDlet
that is quite similar to mine. We can even build applications that control things
by use of our mobile device.
Some nice projects I can think about is controlling your television, your VCR or
even your domotica system with your mobile device this are some nice projects
for in the future!

Chapter 9: Alternative technologies

== [ Chapter 9 : Alternative technologies ] == 64
Vincent Claes
2003 / 2004
Chapter 9: Alternative technologies
In my project we have chosen to use a server that was running Microsoft
Windows but if you want you can use a different OS on the server like Linux. As
long as the server generates the same XML files it is no problem. For
generating XML files we have used ASPX but you can use other languages like
PHP, servlets, CGI (Common Gateway Interface),… too.
I-mode
i-Mode (the I stands for information) is a wireless technology developed by the
Japanese company NTT DoCoMo that enables users to access Internet
services via their mobile phones. i-mode is based on packet data transmission
technology. This means that i-Mode is always active, and therefore users are
charged only for how much information they retrieve, not how long they are
online. I-Mode can be used to exchange e-mail with computers, personal digital
assistants (PDAs) and other i-Mode cellular phones.
i-Mode is similar to WAP (WAP is another technology which has a scope of
offering Internet access worldwide). The reason DoCoMo decided to go with i-
Mode instead of waiting for WAP was simple. The Japanese were ready to
access the Internet through their mobile phones. They didn't want to have to
wait for WAP to provide them with wireless data services they needed. It was a
completely practical solution to use i-Mode and not WAP. And with 10 million
new subscriptions predicted for the service within the next three years, the
decision was obviously the right one.

Vincent Claes
2003 / 2004
With that said, there are essentially four main components that are required for
the i-Mode service:
• A cellular phone capable of voice and packet communication and with an
i-Mode browser installed
• A packet network
• An i-Mode server
• Information providers
i-Mode is a client / server system. The client is constantly connected to the
network and we can view information on it that is stored on a server, just like
with my project.
The way the Internet works is that servers hold our web pages. We then view
those web pages from our desktop web browsers (the clients). In the case of
the i-Mode Internet, an Internet server contains the i-Mode web pages. But now,
instead of viewing the pages from a desktop web browser, we are using a
cellular i-Mode phone. These phones are now the clients.
Web pages today are often written in HTML (Hypertext Markup Language),
which is too complex for mobile phones because of their slower connection
speeds. An i-Mode enabled web site utilizes pages that are written in cHTML
(Compact Hypertext Markup Language), which is a subset of HTML designed
for devices with slower connection speeds.
Today, the i-Mode service boasts 500+ i-Mode enabled websites linked to a
portal page, as well as +12000 "unofficial" web pages created by private
individuals.
i-mode-compatible HTML is based on a subset of HTML 2.0, HTML 3.2 and
HTML 4.0 specifications that was extended by NTT DoCoMo with tags for
special use on cell phones, such as the "tel:" tag, which is used to hyperlink a
telephone number and let users initiate a call by clicking on a link.

Vincent Claes
2003 / 2004
The criteria for creating an i-Mode application or an i-Mode web page are
essentially the same as creating web apps and web pages with HTML. You
must develop in the cHTML language, and then load the page to an Internet
web server utilizing FTP (File Transfer Protocol) or some other transfer method.
We didn’t use i-Mode because if you want to use it you have the problem that
you don’t have full control over the developed application. With my project you
can for instance change the name of the tags to what you like, but if you use i-
Mode you must use cHTML to show the contents on your i-mode phone and
you don’t need a special i-mode phone.[23][24]
WAP / WML
WAP stands for Wireless Application Protocol, a secure specification that allows
users to access information instantly via handheld wireless devices such as
mobile phones, pagers, two-way radios, smartphones and communicators.
WAP is supported by all operating systems. Ones specifically engineered for
handheld devices include PalmOS, Windows CE, and JavaOS, …
Devices that are WAP enabled access the internet by and run what are called
micro-browsers with small file size that can accommodate the low memory
constraints of handheld devices and the low-bandwidth limitations of a wireless-
handheld network.
Although WAP supports HTML and XML, the WML (Wireless Markup
Language) language is specifically devised for small screens and one-hand
navigation without a keyboard. WML is scalable from two-line text displays up
through graphic screens found on items such as smart phones and
communicators. WAP also supports WMLScript. It is similar to JavaScript, but
makes minimal demands on memory and CPU power because it does not
contain many of the unnecessary functions found in other scripting languages.
Almost every mobile phone browser around the world supports WML.
Maybe you are thinking now why didn’t you build a system that generates WML
pages because then almost everyone in the world could use it? Just the same
as with i-mode: when we use J2ME on our client this give us full control over the
developed project; we don’t need to use a micro-browser that is made by

Vincent Claes
2003 / 2004
someone else. We can design our own system. I was very happy that we did
use J2ME because this is I think the most powerful technology for developing
mobile applications.[22][23]
SOAP
This is the abbreviation of Simple Object Access Protocol, a lightweight XML-
based messaging protocol used to encode the information in Web service
request and response messages before sending them over a network. SOAP
messages are independent of any operating system or protocol. SOAP is a
protocol for accessing a Web Service. It is important for application
development to allow Internet communication between programs.
Today's applications communicate using Remote Procedure Calls (RPC) but
HTTP was not designed for this. RPC represents a compatibility and security
problem; firewalls and proxy servers will normally block this kind of traffic.
RPC is short for remote procedure call, a type of protocol that allows a program
on one computer to execute a program on a server computer. The client
program sends a message to the server with appropriate arguments and the
server returns a message containing the results of the program executed.
A better way to communicate between applications is over HTTP, because
HTTP is supported by all Internet browsers and servers. SOAP was created to
accomplish this. SOAP provides a way to communicate between applications
running on different operating systems, with different technologies and
programming languages. SOAP is a key element of Microsoft's .NET
architecture for future Internet application development. But I haven’t work with
SOAP because this is not easy to work with, this system is more complex; this
is an advantage of my project I have shown that it is very simple to set up a
wireless environment for data access on a server and I show with it we don’t
need SOAP for something like this.[22][23][24]

Vincent Claes
2003 / 2004
JXTA for J2ME
JXTA is a Java-based technology for implementing dynamic peer-to-peer
networks on mobile devices, PCs, and servers. An implementation of JXTA for
J2ME devices is in the early stages of development, although it has been
demonstrated on several devices. For more information you can check out the
JXTA website: http://www.jxta.org/.

69
Vincent Claes
2003 / 2004
Appendix A

70
Vincent Claes
2003 / 2004
StartScreen.java
import javax.microedition.lcdui.*;
// This class shows the MainMenu (a list of options)
class StartScreen extends List implements CommandListener
{
private Project midlet;
private Command exitCommand = new Command("EXIT",Command.EXIT,2);
private String options[]=new String [3];
//sets the basic properties of the screen
StartScreen(Project midlet)
{
super("Menu",List.IMPLICIT);
setTicker(new Ticker("Bienvenido al Portal "+
"Interactivo del Medio Natural para Galicia Sur"));
this.midlet =midlet;
}
//setting the contents of the MainMenu
void setContents()
{
options[0]="News";
options[1]="Events";
options[2]="Contents";
for (int i=0; i<options.length;i++)
{
append(options[i],null); //null stands for no image.
}
//setting the commandlistener
setCommandListener(this);
//add the exit button
addCommand(exitCommand);
}
//here we are going to set the title of the MainMenu
void setMenu()
{
setTitle("MainMenu");
}

71
Vincent Claes
2003 / 2004
public void commandAction(Command command, Displayable displayable)
{
//making a choice: exit the program or selecting an other menu.
if (command == exitCommand)
{
midlet.destroyApp(true);
}
else if (command ==List.SELECT_COMMAND)
{
if (getSelectedIndex()==0)
{
midlet.displayNewsMenu();
}
else if(getSelectedIndex()==1)
{
midlet.displayEventsMenu();
}
else if(getSelectedIndex()==2)
{
midlet.displayContents1Menu();
}
}
}
}

72
Vincent Claes
2003 / 2004
PropertiesScreen.java
import java.util.*;
class PropertiesScreen extends Form implements CommandListener
{
private Project midlet;
private Command exitCommand = new Command("Exit", Command.EXIT, 1);
private Command backCommand = new Command("Back", Command.BACK, 1);
public PropertiesScreen(Project midlet, Hashtable properties)
{
super("Info");
this.midlet=midlet;
//displays the list of th menu's properties
Enumeration keys = properties.keys();
while(keys.hasMoreElements())
{
String key =(String) keys.nextElement();
String value=(String) properties.get(key);
append(new StringItem(key,value));
}
setCommandListener(this);
addCommand(exitCommand);
addCommand(backCommand);
}
public void commandAction(Command command, Displayable displayable)
{
if (command== exitCommand)
{
midlet.destroyApp(true);
}
else if (command ==backCommand)
{
midlet.displayStartMenu();
}
}
}

73
Vincent Claes
2003 / 2004
Project.java
import java.io.*;
import java.util.*;
import javax.microedition.midlet.*;
import javax.microedition.io.*;
import org.kxml2.io.*;
//this is the main midlet class It sets the basic screen,
//and handles transistions to other screens.
public class Project extends MIDlet
{
static String url_news = "http://193.146.37.76/Vincent/news.aspx";
static String url_events= "http://193.146.37.76/Vincent/events.aspx";
static String url_contents="http://users.skynet.be/poyzon/Project/" +
"CONTENTS_level1.xml";
private Image logo;
private NewsMenuScreen newsmenuScreen = new NewsMenuScreen(this);
private ContentsMenuScreen contentsmenuScreen=new ContentsMenuScreen(this);
private EventsMenuScreen eventsmenuScreen = new EventsMenuScreen(this);
private PageMenuScreen pagemenuScreen2= new PageMenuScreen(this);
private PageContentsMenuScreen pageContentsmenuScreen2= new
PageContentsMenuScreen(this);
private StartScreen startscreen = new StartScreen(this);
private MenuNews menunews;
private MenuEvents menuevents;

Wireless environment for data access on a server

Wireless environment for data access on a server

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (15)

Ähnlich wie Wireless environment for data access on a server

Ähnlich wie Wireless environment for data access on a server (20)

Mehr von Vincent Claes

Mehr von Vincent Claes (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (6)

Wireless environment for data access on a server