developing wireless mobile application for series … science/ms.c/2006/developing...“developing...

“Developing Wireless Mobile Application for Series 60 and Symbian OS Using J2ME”

A thesis Submitted to the College of Science / the University of Baghdad in partial fulfillment of the requirement for the degree

of Master of Science in Computers

By Azhar Najah Amir Rashim

Supervised by Dr. Suha M. Hadi

2006 January

Ministry of Higher Education And Scientific Research University of Baghdad

College of Science

بسم احلي العظيم

ون أل�فسكم، و اكرهوا هلم ما تكرهونوا األصحابكم ما تحبأحبفا�ظروا، و امسعوا، و آمنوا، و تقبلوا .. و تزودوا آلخرتكم بالعمل الصاحلهلا

.كلمات ربكم١٧٧

٨١٧

ينكما�ظروا بأع و ا�طقوا بأفواهكم عوا بآذا�كمو امس و إعملوا مبشيئة ربكم، و اعملوا بأيديكم زدقا و طبوثا آمنوا بقلوبكم

.و ال تعملوا مبشيئة الشيطان

١٨٤

١٧٩١٨٠١٨١

١٨٣

١٨٢

مال األجسام فجمالها زائلكم ج�اليأسر و ال تسجدوا للشيطان، و ال .ألصنام هذا العامل الزائف

١٨٥١٨٦

با عصنميوت، و كل ما ي ر كل من يولدفنى، فأين س و العامل كله ،دفسأليدي يإن عكازتكم يوم احلساب األلوهية اليت فيه إن كنتم تنظرون

.أعمالكم اليت عليها تتوكأون، فا�ظروا اىل ماذا تستندون

١٨٧

١٨٨

املزكي و احلي

Dedication

I dedicate this effort with my deep pleasure to my dear Father and Mother who

tried their best to make life as safe and happy as possible, Also I would like to

dedicate it to my dear Brother and sisters who give all support and assistance.

Azhar Najah A. Rashim

Acknowledgments First of all, I would like to thank GOD for blessing me with hope and power

to continue my study in my beloved field.

My great thanks to my supervisor Dr. Suha Mohammed Hadi, who

guided me in making my endeavor, in producing this thesis, successfully

accomplished. She gave me a lot of her time and effort and I really got benefit

from her experience especially in this important particular subject.

Finally, I would like to thank my cousin Dr. Hussam Abed who supports

me from his location in the USA by sending me the most important resources

used in this thesis.

Azhar Najah A. Rashim

Table of contents

List of Abbreviations..................................... iii Abstract .................................................. vi Chapter 1 - Mobile and Wireless Overview .............1

1.1 Introduction ...................................................................................... 1 1.1.1 Thin Client overview.....................................................................................1 1.1.2. Smart Client Application.............................................................................3 1.1.3. Messaging Application.................................................................................5

1.2 The Mobile and Wireless Definitions.............................................. 6 1.3 Survey of Related Work .................................................................. 8 1.4 Thesis Objective: .............................................................................. 9 1.5 Thesis Layout: ................................................................................ 10

Chapter 2 - Symbian OS and Other Technology...... 11

2.1 The Smartphones Operating System............................................ 11 2.2 Generic Technology........................................................................ 13 2.3 Symbian operating system............................................................. 14

2.3.1 Symbian OS Structure: ..............................................................................15 2.4 The Series 60 Platform Structure ................................................. 19

2.4.1 Series 60 Principal Characteristics............................................................21 2.4.2 The Hardware Requirements for Series 60 ..............................................21 2.4.3 Series 60 Platform Versions .......................................................................23

2.5 Bluetooth Overview........................................................................ 24 2.5.1 The Bluetooth Stack....................................................................................26 2.5.2 Bluetooth Protocols .....................................................................................27 2.5.3 Bluetooth Profiles........................................................................................28 2.5.4 The Service Advertisement and Discovery ...............................................29 2.5.5 Future of Bluetooth Technology ................................................................30

Chapter 3 - J2ME Technology on Mobile Phone ...... 32

3.1 Introduction to Java 2 Micro Edition........................................... 32 3.2 Basic Information about J2ME..................................................... 34

3.2.1. Java Virtual Machine Layer .....................................................................34 3.2.2. Configuration Layer ..................................................................................35 3.2.3. Profile Layer...............................................................................................36

i

3.3 Mobile Information Device Profile ............................................... 37 3.3.1 MIDlets and MIDlets Suite.........................................................................38 3.3.2 MIDlet Lifecycle ..........................................................................................38 3.3.3 User Interfaces.............................................................................................40 3.3.4 Network Communication ...........................................................................42 3.3.5 Persistent Storage........................................................................................43

3.4 The Bluetooth API.......................................................................... 44 3.4.1 The Requirement of JSR 82 .......................................................................44 3.4.2 The Java Bluetooth Packages.....................................................................45 3.4.3 MIDP and the Bluetooth API.....................................................................46

3.5 The mean Benefits of using J2ME ................................................ 47

Chapter 4 - Design and Implementation of Mobile Bluetooth Chat........................................... 49

4.1 Introduction .................................................................................... 49 4.2 The Supported Tools Design ......................................................... 50

4.2.1 The Service Registration ............................................................................50 4.2.2 Device Discovery .........................................................................................51 4.2.3 Service Discovery ........................................................................................52

4.3 The Proposed Software Design ..................................................... 53 4.3.1 The Server Mode Design ............................................................................55 4.3.2 The Client Mode Design .............................................................................57 4.3.3 Send and Receive Procedure......................................................................59 4.3.4 User Interface Design..................................................................................60

4.4 The Implementation....................................................................... 61 4.5 Performance Operation ................................................................. 65

Chapter 5 - Conclusions and Future Work............. 67

5.1 Conclusions ..................................................................................... 67 5.2 Future Work................................................................................... 68

References............................................... 69

ii

List of Abbreviations 2.5G : 2.5 Generation

2G : 2 Generation

3G : 3 Generation

AMS : Application Management Software

API : Application Programming Interface

Avkon : The Series 60 standard user interface library and

Application framework built on Symbian Uikon

BCC : Bluetooth Control Center

CDC : Connected Device Configuration

CLDC : Connected Limited Device Configuration

COM : A Serial Communication Port Which Support the RS-232

Standard of communication

DMA : Direct Memory Access

DRM : Digital Rights Management

DUN : Dial-Up Networking

EMS : Enhanced Message Service

ETel :

The Telephony server on Symbian OS; provide access to the

telephony functions of a mobile phone, such as GSM, GPRS

and fax.

GCF : Generic Connection Framework

GHz : Gaga Hertz

GIAC : General/Unlimited Inquiry Access Code

GT : Generic Technology

GUI : Graphical User Interface

HCI Host Controller Interface

HDML: Handheld Devices Markup Languages

iii

HTTP : HyperText Transfer Protocol

I/O : Input / Output

ID : Identification

IDE : Integrated Development Environment

IM : Instant Messaging

IMAP4 : Internet Mail Access Protocol, v.4

IMPS : Instant Messaging and Presence Services

IP : Internet Protocol

IrDA : Infrared Data Association

ISM : Industrial, Scientific and Medical

J2EE : Java 2 Enterprise Edition

J2ME : Java 2 Micro Edition

J2SE : Java 2 Standard Edition

JCP : Java Community Process

JSR : Java Specification Request

JVM : Java virtual machine

KVM : Kilo virtual machine

L2CAP : Logical Link Control and Adaptation Protocol

LIAC : Limited Dedicated Inquiry Access Code

LMP : Link Management Protocol

MID : Mobile Information Device

MIDlet : Midlet is an application written for MIDP Platform

MIDP : Mobile Information Device Profile; built on CLDC and

defines characteristics for a mobile device

MMS : Multimedia Message Service

OBEX : Object Exchange

OMA : Open Mobile Alliance

iv

OO : Object Oriented

OS : Operating System

PC : Personal Computer

PDA : Personal Digital Assistant

PIM : Personal Information Manager

RFCOMM : Radio Frequency Communications

RMS : Record Management System

ROM : Read Only Memory

RS-232 : The Standard for serial transmission using cables

RTC : real-time clock

SDAP : Service Discovery Application Protocol

SDDB : Service Discovery Database

SDK : Software Development Kit

SDP : Service Discovery Protocol

SIG : The Bluetooth Special Interest Group

SMIL : Synchornized Multimedia Integration Language

SMS : Short Message Service

TCP : Transmission Control Protocol

TCS : Telephone Control Protocol

UI : User Interface

UIKON : Generic Symbian User Interface toolkit on which all device

- specific toolkit build on

UUID : Universally Unique Identifiers

VM : Virtual Machine

WAP : Wireless Application Protocol

XHTML : Extensible HyperText Markup Language

XML : Extensible Markup Language

v

Abstract Wireless communications have become an important aspect of our lives. One

of the mobile phone is the smartphone which is a device that provide the

ability for voice communication as well as thin and smart client application.

Most of the smartphone devices now support Bluetooth wireless

technology between mobile computers, mobile phones, and portable handheld

devices. The main objective of this thesis is to design and implement Chatting

Application as a new software application for a mobile devices support series

60 version 2.0. This new software application will give the smartphone the

ability of sending and receiving transparently instant messages free of charge

independent on the availability of the mobile service provider and without

affecting other mobile activities. The complete software package was written

using J2ME for the smartphones support MIDP 2.0. The design of this

Bluetooth Chat application based on a Server-Client mode.

vi

Chapter 1 Mobile and Wireless Overview

1


1.1 Introduction

Mobile and wireless computing has the power to change the way business

is conducted. It allows employees, partners, and customers to access corporate

data from almost anywhere. Universal data access, combined with increased

worker productivity and effectiveness, reduced processing costs, heightened

accuracy, and competitive advantages, is driving the demand for enterprise

mobile applications. As the demand continues to increase, the mobile

infrastructure that makes creating sophisticated mobile applications possible is

maturing [1].

In contrast, the concern that developing mobile and wireless applications

will involve many new technologies and concepts that many corporate

developers are still learning to use. One of the challenges in the mobile

application space is the variety of application architectures available, which

can be abbreviated as the following [1]:

1. Thin Client application.

2. Smart Client application.

3. Messaging application.

1.1.1 Thin Client overview

It should be realized that thin client refers to wireless Internet applications.

This application called "thin client" because no software is required on the

wireless device except microbrowser for an Internet browser. For true thin

client applications, all of the application logic resides and is executed on the

server platform. Hence, the client does not require much processing power or

1


memory to be able to run these types of applications, making them suitable for

very small, resource-constrained devices [2].

The thin client architecture is very similar to the architecture of Internet

applications. It is based on three-tier architecture, as depicted in Figure (1.1).

Figure (1.1) Thin Client Architecture [2]

The following points are the key components of the thin architecture:

a) The First tier - Thin client. The client is a microbrowser focused on the

presentation of the markup language. It is the part of the application that

the end user sees, although it does not execute any of the application logic.

The design of the client user interface is crucial to the overall success of

the application [3].

b) The Second tier - Middle tier. The middle tier is where most of the work

is performed. A couple of main components run in this tier: the Web server

and the wireless application server. The Web server receives the inbound

2


HTTP requests and routes them to the wireless application server. The

application server then takes these requests and executes the appropriate

logic. This execution may include session management, content

management, as well as integration to the back-end system.

c) The Third tier - Back-end system. The back-end system is where the data

and related services reside. This system may be a relational database, an

email server, business applications, an XML content source, or any number

of other enterprise systems. In any case, it is important that this data can be

reached, so that it is available to the mobile worker [4].

1.1.2. Smart Client Application

These applications allow corporations to deploy an application to the mobile

device so the user can continue to interact with the application even when a

wireless data connection is unavailable. These applications commonly include

a form of persistent data storage that communicates with enterprise systems

using data synchronization. This combination enables applications to have

sophisticated user interfaces and high-performance data access, making them

suitable for offline computing [5].

The smart client architecture can be illustrated in Figure (1.2). In the client

side, there will be the user interface, the business logic, and the persistent data

store resides here. This application communicates with a back-end data

source, often through an intermediate synchronization server. The

communication stream itself can run either wirelessly or over a wireline

connection. Depending on the technology being used, the connection may

require an IP-based network or an additional communication layer for the

synchronization process [3].

3


Figure (1.2) Smart client architecture [2].

When this type of solution is implemented, it quickly becomes clear why it

is called a smart client solution. By deploying an application to the device

itself, you have the ability to give the client application some "smarts," or

logic. This logic dictates many aspects of the application. It determines where

the application gets it's data from (either locally or from a round-trip to the

server), how the data is presented and stored, as well as the set of data that

needs to be communicated back to the enterprise systems via a

synchronization process. In the wireless space, the impact of having business

logic on the device is often overlooked as many vendors and developers focus

on low-level technical features of the solution rather than satisfying the

requirements of the mobile user [2].

4


The following points are the key components of the Smart Client architecture:

a) The Smart Client. Smart client applications provide many attractive

features for end users. Many of these features reside in the client

application itself. By providing a rich user interface with persistent data

storage, smart client applications are suitable for a large variety of

corporate applications.

b) The synchronization Server. Though the server component of smart

client applications is invisible to the end user, it is still very important. The

server component is responsible for data synchronization, data storage, and

messaging.

c) Enterprise Data Source. The final part of the smart client solution is the

enterprise data itself. This data will vary in formats ranging from enterprise

databases from vendors, such as Oracle, Sybase, Microsoft, or IBM, to flat-

file systems and everything in between. For the more common storage

systems, this should be able to find a driver or adapter that will provide an

integration layer for your synchronization server. Keeping in mind that one

of the most common reasons for implementing a mobile solution is to

provide enterprise data access to the mobile worker, so the enterprise

integration is an essential part of the overall solution [3].

1.1.3. Messaging Application

Mobile and wireless messaging is available in many forms, including email,

paging, SMS, EMS, MMS, IM, HDML notifications, WAP Push, and

application-to-application messaging. All of these messaging options, SMS

has so far been the most widely adopted in the mobile space, though in the

future it can expect large competition from both instant messaging and MMS.

5


For smart client applications, application-to-application messaging is the most

suitable. Implementing a complete messaging solution will involve many

components of the messaging value chain. The only required component of

the value chain is the mobile device; a wireless carrier, system aggregator, and

mobile messaging middleware provider are not required in every solution

which is illustrated in figure (1.3) [6].

Figure (1.3) Messaging value chain [1].

1.2 The Mobile and Wireless Definitions

The mobile and wireless definition varies from person to person and from

organization to organization. In many cases, the terms mobile and the wireless

are used interchangeably, even though they are two different things. Mobile is

the ability to be on the move. A mobile device is anything that can be used on

the move, ranging from laptops to mobile phones. As long as location is not

fixed, it is considered mobile. Wireless refers to the transmission of voice and

6


data over radio waves. It allows workers to communicate with enterprise data

without requiring a physical connection to the network. Wireless devices

include anything that uses a wireless network to either send or receive data.

The wireless network itself can be accessed from mobile workers, as well as in

fixed locations. Figure (1.4) depicts the relationship between mobile and

wireless area. As can be seen in the most cases, wireless is a subset of mobile;

but in many cases, an application can be mobile without being wireless [1].

Figure (1.4) The Relationship between the mobile and the wireless [1].

For an application to be considered a mobile or a wireless, it must be

adapted to the characteristics of the device that it runs on. Limited resources,

low network bandwidth, and intermittent connectivity all these are the factors

into the proper design of these applications [3].

On the other side, there are many examples where the Mobile applications

are not wireless. There are many examples where this is the case. Any

application that can be used on the move and that does not have wireless

connectivity fits into this category. This includes many laptop and personal

digital assistant (PDA) applications. Until only a few years ago, it was actually

rare to have wireless data access for mobile devices. For these mobile

7


applications, data is often synchronized using a fixed connection and stored on

the device for use at a later time. It is worthwhile to note that even though

these applications do not require wireless connectivity, they can often benefit

from it when it is available [1].

1.3 Survey of Related Work:

Wireless mobile applications have been studied since the advent of the mobile

with its all generations. About our work there are many relevant studies in the

same field. That can be classified into the following categories.

1. Series 60 Application Development Integration with CS457 Course

Material. In 2004 Dennis Craven, The goal of this thesis is to asses the

feasibility of integrating development on the Series 60 Developer Platform

SDK into the curriculum of Dr. Michael Katchabaw’s CS457/546 Computer

Networks II course at the University of Western Ontario and to develop some

documentation and tools to shorten the learning curve of the students should

the decision to use the devices go forward [7].

2. J2ME Bluetooth Programming. In 2004 André N. Kilingsheim, This

Master's thesis gives insights into the technologies needed to develop Java

Bluetooth applications for mobile devices. Bluetooth, Java 2 Micro Edition

(J2ME), and Java APIs for Bluetooth Wireless Technology (JABWT) are

discussed. The necessary infrastructure for developing Java Bluetooth

applications is also described. Descriptions of how different Bluetooth actions

like inquiry and service discovery are done with the Java API are provided.

Code samples are included as well, highlighting the functionality available in

JABWT [8].

8


3. Secure Access Control Using Mobile Bluetooth Devices. In 2003 Allan

Beaufour Larsen, The goal of this thesis it to design a solution for secure

access control that can replace physical keys for accessing private buildings.

They propose a solution using digital keys on Bluetooth-enabled mobile

phones providing wireless and automatic unlocking. The design allows easy

distribution of keys to users [9].

4. Mui: Controlling Equipment via Migrating User Interfaces. In 2002

David Svensson and Torbjörn Eklund, This master thesis is about controlling

equipment via migrating user interfaces. Ahandheld device, such as a

Bluetooth-equipped cellular phone or handheld computer, is used as a generic

“remote control”. When the user gets in the vicinity of controllable equipment,

the equipment is automatically discovered and a user interface is downloaded,

if the user so wishes. This enables the user to interact with the equipment [10].

1.4 Thesis Objective: This thesis concerned with developing wireless mobile application software

using J2ME as a programming language, over Symbian OS series 60 platform.

The goals of this thesis can be summarized as the following:

Design and implement Free of charge Smartphone’s Chat program by

designing simple network (point to point) between two smartphone devices

(Like Nokia 6600) that uses Series 60 version 2.0 and Symbian OS version

7.0s as operating system, by using there Bluetooth devices to establish the

network and enable them to send and receive Free Instant Messages (IM)

between them.

9


1.5 Thesis Layout:

This thesis studies the Mobile applications and the important

technologies adapted with it as organized bellow:

Chapter 2: Symbian OS and Series 60 and other Technology.

This chapter will represent the information on the operating system and other

technology used in smartphone. Focusing on Symbian OS, Series 60 Platform

and Bluetooth Technology This background is provided to give the reader an

understanding to the structure feature of the Symbian OS and Series 60.

Which the work depend on.

Chapter 3: Java 2 Micro Edition.

This chapter is intended to explain in general terms what Java 2 Micro Edition

Technology offers and how to develop an application with it and focus on

Mobile Information Device Profile (MIDP). This is the most important part

that the proposed application depends on MIDP 2.0

Chapter 4: The design and Implementation of the proposed application

software.

This chapter will represent the design for the proposed Application Software

and the main point for implementing it with the best quality to obtain the main

objective for this thesis.

Chapter 5: Conclusions and Future Work.

This chapter will present the conclusions and the future work for this thesis.

10

Chapter 2 Symbian OS and Other Technology

11


2.1 The Smartphones Operating System

The smartphone is categorized as a device having the size and form factor of a

normal phone, while providing, a graphics-capable color screen, value-adding

applications such as messaging tools (e.g. e-mail, advanced calendar, and

contacts book) and the ability to install new applications. Smartphone

examples can be seen in Figure (2.1).

Figure (2.1) Example for Smartphones

The Smartphones are devices that are always on and typically run for

weeks or months without restarting. Actually, many users turn their devices

off only when traveling by plane - in all other situations the silent mode is

sufficient. Another issue is the nature of data and storage media used with

11


these devices. As the users store important personal data - such as their

itineraries and precious memories - loss of data simply cannot be tolerated.

These set stringent requirements for the memory management in the

smartphone, and a smartphone operating system must be robust and support

design principles that allow other software to be reliable. Robustness of the

operating system is one of the key criteria to be considered when selecting the

platform for smartphones. Especially important is the performance in error

conditions, and it is vital that the user data and system integrity are not

compromised in any situation.

The operating system of a smartphone is the most critical software

component as it depicts the nature of the software development and operating

principles. The most important requirements are [11]:

• Multi-tasking (with multi-threading).

• Real-time operation of the cellular software.

• Effective power management.

• Small size of the operating system itself, as well as the applications built on

it.

• Ease of developing new functionality.

• Reusability.

• Modularity.

• Connectivity (i.e. interoperation with other devices and external data

storage)

• Robustness.

Based on the choices of the world's top mobile phone manufacturers with

the largest market share (Nokia, Motorola, Samsung, Sony Ericsson and

Siemens holding almost 80% of the market), the most significant alternatives

12


for extending smartphone functionality in a phone are either Symbian OS or

the manufacturer's proprietary operating system [11].

2.2 Generic Technology

Most parts of the generic technology remain unchanged between different

devices utilizing Symbian OS. The architecture of the system is modular, and

it is designed with a good object-oriented approach. Most of the operation is

based on a client-server model to allow all applications to use the services

provided by the system, as well as other applications. This provides a very

flexible system, allowing secure and robust resource allocation. It also saves

significantly in the binary size and development effort of the applications, as

the most used functionality is provided by the platform. Generic technology

also contains a security framework that provides certificate management and

cryptography modules [12].

The base is the bottom layer of the operating system. It consists of the

microkernel, device drivers, and user library. The microkernel is run directly

in the processor in privileged mode. It is responsible for power management,

memory management, and owns device drivers. The device drivers are the

hardware-software interface layer needed for accessing, for example, the

display and audio devices of the terminal as well as the communication

channels. The user library in turn provides many of the functionalities such as

error handling, cleanup framework, hardware abstraction layer, client-server

architecture, as well as context (i.e. process and thread), and memory

management, used by virtually all programs [11].

The Application framework in turn is a set of reusable libraries providing

means for handling text, graphics, and sound.

13


Communication architecture contains the infrastructure needed for

communications and protocol stacks of the most needed communication

protocols. One of the key strengths of Symbian OS is the provided set of

communication methods and their tested interoperability. In addition to the

protocols provided with the system, the licensee and the application

developers are able to create support for additional protocols in the form of

new protocol modules or by building the needed protocol into an application

[11].

2.3 Symbian operating system

The Symbian have been developed by the Symbian software company for

mobile phones. First Symbian OS mobile phone, Nokia Communicator 9210,

became available in the first half of 2001 and since then there have been

several others from several different manufacturers, for example Sony

Ericsson P800, Fujitsu F2102V, Nokia 6600, Siemens SX1, and Sendo X [12].

Symbian operating system is an open operating system that is specifically

designed for data-enabled Second Generation (2G), Second and half

Generation (2.5G) and third Generation (3G) mobile phones. It includes multi-

tasking kernel, communications protocols, integrated telephony support,

advanced graphics support, low-level graphical user interface framework, etc

[13].

Symbian OS has been designed to support many different kinds of mobile

phones varying from voice-centric phones to information-centric phones.

Symbian vision is to build an operating system for mobile phones that are not

only phones but more like personal digital assistants (PDAs) that come closer

to a computer than to a traditional mobile phone.

14


The Symbian operating system is designed specifically for mobile phones

rather than scaling down a PC operating system or building communication

capabilities over a small basic operating system found on many PDAs. Fitting

an existing operating system to mobile phone needs would induce so many

fundamental compromises that it would be impossible to build a robust and

scalable operating system on that foundation. Therefore Symbian OS is built

from scratch and designed to be an efficient and robust operating system on

various different mobile phones [12].

Openness of Symbian OS does not mean that it is open source but that it is

open for third party application development and that licensees of the

operating system get also the source code. Symbian provides free SDKs, tools

and documentation for developing applications on their OS [14].

2.3.1 Symbian OS Structure:

Symbian OS was designed for use in small battery-powered devices with

extensive communications capabilities. The main key design features include

the following points [11] [15]:

• Performance - Designed to maximize battery life through careful device-

specific power management.

• Memory management optimized for embedded software environment-very

small executable sizes and ROM-based code that executes in place.

• Runtime memory requirements are minimized.

• Security mechanisms for enabling secure communications and safe data

storage.

• Application support for an international environment, with built-in

Unicode character sets and eases of localization.

15


• Integrated multimode mobile telephony – Symbian OS integrates the

power of computing with mobile telephony, bringing advanced data

services to the mass market.

• Open application environment – Symbian OS enables mobile phones to

be a platform for deployment of applications and services (programs and

content) developed in a wide range of languages and content formats.

• Open standards and interoperability – with a flexible and modular

implementation, Symbian OS provides a core set of application

programming interfaces (APIs) and technologies that is shared by all

Symbian OS phones. Symbian supports key industry standards and

contributes to the development of industry standards through Board

membership of the Open Mobile Alliance.

• Multitasking and Hard Real-time – Symbian OS is based on a micro

kernel architecture and implements full multitasking and threading. System

services such as telephony, networking middleware and application

engines all run in their own processes.

• Fully Object-oriented and component based – the operating system has

been designed from the ground up with mobile devices in mind, using

advanced OO techniques, leading to a flexible component based

architecture.

• Flexible user interface design – by enabling flexible graphical user

interface design on Symbian OS, Symbian is fostering innovation and is

able to offer choice to manufacturers, carriers, enterprises and end-users.

Using the same core operating system in different designs also eases

application porting for third party developers

16


• Robustness – Symbian OS maintains instant access to user data. It ensures

the integrity of data, even in the presence of unreliable communication and

shortage of resources such as memory, storage and power.[15]

The Symbian OS generic technology (GT) components can be explained as the following [16]:

Symbian OS UIKON GUI Library

Application Engines

Servers

Symbian OS Base (EUSER.DLL, File Server, Kernel, etc.)

Low-Level Hardware – Manufacturer Device Drivers, etc.

Java KVM

Figure (2.2) Symbian OS Generic Technology Structure [16]

A. Symbian OS Base: This includes the kernel, file server, memory

management and device drivers [16]. The kernel library includes support for

all peripheral hardware that is resident on the chip and that is essential to the

operating system. The peripheral hardware includes such things as timers,

DMA engines and interrupts controllers. The kernel library is customized for a

17


particular chip. Applications are not permitted to access peripheral hardware

directly. Instead applications must link to the User library whose functions

may invoke peripheral control through the kernel [17]. Device drivers provide

the control and interface to specific items of hardware such as the keyboard,

display, infrared port and so on. The developer interface to most of the base

Operating System functionality is through the EUser Library, via a huge range

of static function calls.

B. The Servers: It is the layer provides communication and extensive

computing services, such as TCP/IP, IMAP4, SMS and the database

management. Symbian OS components provide data management,

communications, graphics, multimedia, security, personal information

management (PIM) application engines, messaging engine, Bluetooth,

browser engines and support for data synchronization and internationalization

[16].

The Access to these services and resources is coordinated through a client-

server standard framework. Servers run as unprivileged threads. Any

application thread can be a client connecting to a server by name and passing

messages through a standard interface imposed by the kernel [17].

Client/Server architecture is a key design feature of Symbian OS. User

applications and system processes are clients that use the resources of a wide

variety of system servers. In Symbian OS, servers can be accessed only by

their clients via well-defined interfaces. Virtually all servers run with a high

priority, but without system privileges, to ensure a timely response to all of

their clients while controlling access to the resources of the system [16].

18


C. The Application Engines: Some core application engines, written as

servers, enable software developers to create their own user interfaces to the

application data and databases. The Application engines include Contacts,

Calendar, to-do, alarm, agenda (schedule), world servers, help engine,

Multimedia Services (decoding and rendering of image formats) and

Messaging [15].

D. Symbian OS UIKON Library: It is a layer that provides generic controls

to the application developers it provides the application launching service, a

set of standard UI components and user input handlers for the applications.

2.4 The Series 60 Platform Structure:

Series 60 Platform builds on the Operating System from Symbian,

complementing it with a configurable graphical user interface library and a

comprehensive suite of applications plus other general-purpose engines. Series

60 is a complete smartphone reference design.

The APIs provided are widely used by the suite of "standard" applications

that are an integral part of Series 60 Platform. However, the extensive APIs

were designed for use by third-party application developers as well.

The core of Series 60 Platform is Symbian OS GT (Generic Technology)

layers as shown in Figure (2.3). Series 60 adds the extensive Avkon UI layer,

a full suite of applications based on the Avkon and Uikon libraries plus a

number of key application engines. Avkon provide the concrete look-and-feel

for UI components and new UI components for smartphone based on the

Series 60 Platform. Series 60 Platform contains the majority of the user

interface and framework APIs used by third-party GUI applications.

19


Symbian OS UIKON GUI Library

Application Engines

Servers

Symbian OS Base (EUSER.DLL, File Server, Kernel, etc.)

Low-Level Hardware – Manufacturer Device Drivers, etc.

Series 60 AVKON GUI Library

Java MIDlet

ManagerApplications

Java KVM

Figure (2.3) Series 60 Structure [16] There are also a number of platform-specific dynamic link libraries and device

drivers - for example, to control the specific keyboard, display, real-time clock

(RTC), Bluetooth, IrDA and persistent storage devices. Symbian OS

communicates with the device's core cellular software through a well-defined

interface (ETel), based on a Client/Server architecture. Porting Series 60 to a

20


new target hardware platform will involve production of some low-level

hardware-specific code such as device drivers

2.4.1 Series 60 Principal Characteristics

The key features of Series 60 Platform are the large color screen (current

minimum specification is 176 by 208 pixels, and at least 4096 colors, 64K

colors in Series 60 2.x) with various interaction modes (two soft keys, five-

way navigator and a number of other dedicated keys).

A primary UI design objective was operation using only one hand. This has

important implications, as it provides convenience for users on the move. A

few exceptions exist for functions that are targeted to power users and require

pressing two keys simultaneously, for example selecting text to copy and paste

[16].

Since single applications fill the available screen, an application switcher is

available via a long press of the menu button - this greatly enhances

productive use of the device. Any user with experience of mobile phones will

grasp the workings of this intuitive UI very quickly.

The software developed for one Series 60 based device will function with

little or no change on the devices from any other handset manufacturer,

providing the version of the platform is the same or is defined to be backward

compatible with an earlier version [11].

2.4.2 The Hardware Requirements for Series 60

The Series 60 UI has specific requirements concerning the hardware. The

following lists the assumed hardware specification for the first product

implementations; it is possible to extend and modify the hardware to some

21


extent for subsequent generations of Series 60 Platform. Specifications for the

current Series 60 UI display can be explained in the following points and it is

represented in figure (2.4) [16]:

• Resolution: 176 pixels (width) by 208 pixels (height)

• Square pixels

• Physical size: about 35 mm (width) by 41 mm (height), corresponding to

approximately 0.2 mm pixel pitch. Using a significantly smaller pitch risks

making some fonts too small to be readable. Using a larger pitch is possible

after considering usability issues.

• Color capability (minimum of 4096)

• Right and left Soft keys.

• Power key

• Clear key

• Edit key

• Navigation keys

• Call handling keys

• Application key

• Alphanumeric keypad with numeric keypad (0-9,*,#).

These specifications are likely to change in future releases of the platform.

22


Figure (2.4) Series 60 User Interface

2.4.3 Series 60 Platform Versions

There are two versions of the series 60 platform:

1. Series 60 1.x is based on Symbian OS 6.1 which includes [18]:

• Java APIs, including:

- Mobile Information Device Protocol (MIDP) 1.0

- Connected Limited Device Configuration (CLDC) 1.0

- Wireless Messaging API (JSR-120)

- Mobile Media API (JSR-135)

• XHTML browsing over TCP/IP

• MMS messaging

• Symbian OS v6.1 native APIs

23


2. Series 60 2.x is based on Symbian OS 70s. Some features in Series 60 2.x

come from enhancements to Symbian OS and others come from Series 60

Platform enhancements. Series 60 2.x includes [18]:

• Java APIs, including:

- Mobile Information Device Protocol (MIDP) 2.0

- Connected Limited Device Configuration (CLDC) 1.0

- Wireless Messaging API (JSR-120)

- Mobile Media API (JSR-135)

- APIs for Bluetooth (JSR-82)

- Security (JSR 118)

• XHTML Browsing over TCP/IP

• MMS messaging with Synchronized Multimedia Integration Language

(SMIL)

• Symbian native APIs

• Open Mobile Alliance (OMA) Digital Rights Management (DRM)

(forward-lock)

• OMA Client Provisioning

2.5 Bluetooth Overview:

Bluetooth is a short-range radio technology that enables wireless connectivity

between mobile devices. Design-wise, the three main goals for Bluetooth

were: small size, minimal power consumption, and low price. The technology

was designed to be simple, and the target was to have it become a de facto

standard in wireless connectivity [19].

24


Bluetooth radio operates in the unlicensed ISM band at 2.4 GHz. In some

countries, this band is reserved for military use, but these countries have now

begun freeing that band for general use. The maximum gross data rate is 1

Mbps [20].

The range of Bluetooth depends on the power class of the radio. Most

devices are expected to use the class 2 radio that provides 0 dBm nominal

output power, resulting in a range of up to 10 meters in an obstacle-free

environment. This range is sufficient for cable-replacement applications.

When a longer range is needed (e.g., in access points), a more powerful radio

(class 1) can be used. Larger power consumption is not a problem if the device

is a piece of fixed equipment. With mobile devices such as mobile phones,

power-consumption issues are crucial and therefore class 2 is the only feasible

option [19].

Some of the features of Bluetooth wireless technology are [21]:

• Signals can be transmitted through walls and briefcases, thus

eliminating the need for line-of-sight.

• Devices do not need to be pointed at each other, as signals are omni-

directional.

• Both synchronous and asynchronous applications are supported, making

it easy to implement on a variety of devices and for a variety of

services, such as voice and Internet.

• Devices have a range of about 10-100 meters and up to eight devices

can link to form a piconet. Piconets communicate with each other easily

and the chips can change frequency at about 1600 hops per second. This

phenomenon is known as frequency hopping, and provides protection

against interference. 25


• Governments world wide regulate it, so it is possible to utilize the same

standard wherever one travels.

Series 60 provides support for a range of Bluetooth technologies. Most

usefully, it provides a Bluetooth plug-in to the Symbian OS Socket Server,

which allows developers to form Bluetooth connections using the standard

Sockets API.

2.5.1 The Bluetooth Stack

The combination of the hardware and the software required on a device to

support the Bluetooth is known as the Bluetooth stack which is explained in

Figure (2.5). It comprises the following parts [16] [22]:

• Physical Layer - The Bluetooth radio transceiver.

• Baseband - A low-level layer concerned with establishing connections and

controlling the transmission of data bits over the physical layer. Typically this

is also implemented in hardware.

• Host Control Interface (HCI) – It is the combination of software and

hardware that produces a bridge between the software and hardware.

Everything below the HCI is implemented in hardware; everything above is

implemented in software.

• Bluetooth Protocols - A set of software components, similar in concept to

network protocols such as IP and TCP, which provide support for Bluetooth

communication at varying levels of capability and reliability.

• Bluetooth Profiles - Higher-level software components that implement well-

defined services on Bluetooth-capable devices and ensure correct

interoperability with other devices.

26


Bluetooth Radio

Baseband

Link Manager Protocol

Host Control Interface

L2CAP

RFCOMM SDP TCS

OBEX

Audio

….

Figure (2.5) Bluetooth Stocks [30]

2.5.2 Bluetooth Protocols

The following are some of the most commonly used Bluetooth protocols

[16]:

• Link Manager Protocol (LMP) - Manages the behavior of the wireless

link, controlling the baseband device and allowing service discovery. It

also addresses security.

• Logical Link Control and Adaptation Protocol (L2CAP) - Offers

connectionless and connection-oriented data services between the

baseband layer and the upper protocols. It also supports data stream

27


segmentation and reassembly, allowing the upper layers to use data

packets larger than the baseband can handle.

• Radio Frequency Communications (RFCOMM) - A reliable transport

protocol that provides emulation of RS-232 serial ports over the L2CAP

protocol.

• Service Discovery Protocol (SDP) - Allows Bluetooth devices to discover

services offered by other devices. It is responsible for broadcasting

queries and fielding the responses to determine which devices offer

particular services.

2.5.3 Bluetooth Profiles

The Bluetooth Special Interest Group (SIG) has defined a number of usage

models for Bluetooth technology. They describe the main Bluetooth

applications and the intended devices, e.g., the synchronization between a

handheld device and a PC, and connecting to the Internet wirelessly using a

mobile phone or a cordless modem. Profiles specify how the interoperable

solution for the functions described in the usage models is provided; in other

words, a profile defines the protocols and protocol features supporting a

particular usage model [19].

A number of different profiles are defined by the Bluetooth specification,

and each Series 60 device supports a subset of these. The exact set of profiles

supported is determined by the handset manufacturer - there is no single set of

Series 60-supported profiles. However, commonly implemented profiles

include [22]:

• Object Push Profile - Allows a Bluetooth device to send and receive

OBEX objects, such as vCard and vCal items.

28


• File Transfer Profile - Depending on the profile implementation on the

device, this profile may allow you to browse, delete, send files to and

receive files from a Series 60 device. File Transfer Profile can also be

implemented as a server only.

• Fax Profile - The Fax profile will allow you to send faxes to, and receive

faxes from, a Bluetooth device (typically a PC) using the phone as a fax

modem.

• DUN (Dial-Up Networking) Profile - Allows a device such as a laptop to

use a phone as a data modem.

• Serial Port Profile - Provides legacy support for older applications and

protocols using the RFCOMM protocol. It provides a virtual COM port,

similar to an RS-232 port on a PC. This profile is often used as the data

carrier for other profiles and applications.

• Headset Profile, Hands Free Profile - Enable phones to connect to

wireless headsets and Bluetooth car kits.

2.5.4 The Service Advertisement and Discovery

A Bluetooth device may offer services for other devices to connect to other

devices itself and make use of their services. A Bluetooth device that offers

services to others is known as a server, and the user is known as a client.

A Bluetooth server makes services available by means of a process known

as Service Advertisement - information about the new service is provided to

any other Bluetooth devices that wish to query it. It does not necessarily

guarantee that an attempted connection will be successful. When an

application advertises its ability to accept connections, an entry is placed in

the device's Bluetooth Service Discovery Database (SDDB).

29


Regardless of the type of service provided, a Bluetooth service advertisement

will consist of the following information:

1. Port - The port number of an incoming connection will be accepted on.

Many applications can advertise their services on a device, with each

accepting a connection on a specified port.

2. Class ID - A class ID that will provide information on the type of service

provided.

3. Availability - The availability of this service. When an application accepts

an incoming connection, it will mark its entry in the Service Discovery

Database as not available. This will inform any other devices that may wish

to connect that it is currently occupied.

Most entries will also contain user-readable text to explain the type of

service they offer, and it is even possible to provide a graphical icon for a

service.

On the client side, an attempt to make a Bluetooth connection is typically

preceded by a process of searching for local Bluetooth-enabled devices and

querying the services they provide. This process is known as Service

Discovery [16].

2.5.5 Future of Bluetooth Technology

While Bluetooth wireless technology will surely endure more growing pains,

it will almost certainly become a technology in many people’s lives.

Developers will create numerous useful applications and the Bluetooth SIG

will continue to grow and to evolve the specifications. When the next

specification is released, which will probably be the Bluetooth 2.0

Specification; it will support more usage models, better performance and

30


backwards compatibility. Additional usage model will include wireless

workplace, briefcase, PC speakerphone, enhanced service delivery and PAN

network [22].

31

Chapter 3 J2ME Technology on Mobile Phone Device

32

Chapter 3

J2ME Technology on Mobile Phone Device

3.1 Introduction to Java 2 Micro Edition

In order to understand how Java 2 Micro Edition (J2ME) lies within the wider

Java landscape it is best to explore the overall Java architecture. J2ME has

been developed primarily as a technology for the execution of applications on

constrained devices. In this case, the constrained devices are mobile phones,

PDAs, TV set-top boxes, in-vehicle telemetry, residential gateways and other

embedded devices [23].

J2ME as a whole can be described as the technology that caters for all

these devices. Because many of them have limited resources, it would be

imprudent to expect all of these devices to be able to deliver all of the

functionality of the few. The Java community therefore decided that these

devices should be grouped to best reflect their purpose and capabilities. This

would provide a lowest common denominator for each device group and

arrange them into configurations [24].

J2ME is the newest and the smallest addition in the Java family. It is the

smaller brother of Java 2 Standard Edition (J2SE) and the server-based Java 2

Enterprise Edition (J2EE). As mentioned, J2ME provides a development

environment for a range of small, constrained devices. Even though J2ME is

targeted at devices with limited capabilities, it has been derived from J2SE

and shows all the characteristics of the Java language. Each combination of

configuration and profile matches a group of products specifically optimized

to match the memory, processing power and I/O capabilities of each device

[23].

The full Java architecture can be seen in Figure (3.1) that shows how the

technology has been developed to offer a platform for a range of 32

Chapter 3


Servers, enterprise computers

High-end PDAs TV set-top

boxes Embedded

devices Optional Packages

Optional Packages

Java 2 Platform

Enterprise Edition (J2EE)

JVM

Personal Profile

Personal Basis Profile

Foundation Profile

CDC

JVM

Servers, personal

computers

Optional Packages

Java 2 Platform Standard Edition (J2EE)

JVM

Mobile phones &

entry – level PDAs

Optional Packages

MIDP

CLDC

KVM

Smart Cards

Java Card

Card VM

Java 2 Platform, Micro Edition (J2ME)

circumstances. Enterprise applications can be developed using the J2EE

packages, taking full advantage of the power for large servers capable of

transmitting large chunks of data across networks. The J2SE complements

J2EE and provides the basis for desktop-type applications. Already we can see

that these two versions of Java are defined with consideration of processor

power, memory and communication ability: it would be inefficient for the

virtual machine running on a desktop machine.

Figure (3.1) Java 2 Platform, Micro Edition [23]

Further inspection of the Java architecture reveals that there are two groups

of special interest to us, under the banner of J2ME. It provides an environment

for developers wishing to develop applications for smaller devices. This

environment has been specialized to cater for machines with even less

capacity [23].

33

Chapter 3


3.2 Basic Information about J2ME

As motioned before J2ME enables Java applications to run on small, resource-

constrained devices such as PDA, mobile phone, set-top TV box, interactive

pager etc. Being very much different from J2EE/J2SE, the J2ME architecture

is designed to be flexible, modular and scalable in order to meet the market

demand: It must cover up the large range of existing device types, hardware

configurations, applications and features; it should stand the rapid

improvement of the device technology. This modularity and scalability are

defined by J2ME technology in a model with three layers of software built

upon the Host Operating System of the device. These layers are illustrated in

Figure (3.2) and explained below

Figure (3.2) J2ME software layer stack and layers on a mobile phone 3.2.1. Java Virtual Machine Layer

This layer is an implementation of a Java virtual machine (JVM) that is

customized for a particular device's host operating system and supports a

particular J2ME configuration. Java binary code is always executed in the

virtual processor environment; call a virtual machine. The Series 60 Platform

provides implementation of the KVM (which stood for Kilo Virtual Machine),

34

Chapter 3


designed for resource-limited host devices. It is written in C language, and the

features are carefully selected to support a low memory footprint [11] [23].

3.2.2. Configuration Layer

The configuration layer is less visible to the users, but it is very important for

profile implementers. It defines the minimum platform for a particular

"horizontal" category or grouping of devices, each with similar requirements

on total memory budget and processing power. In a way, a configuration

defines the "lowest common denominator" of the JVM features and libraries

that the developers can assume to be available on all devices of the same

category. A configuration consists of a combination of a virtual machine and

set of class libraries designed to provide the base functionality for distinct set

of devices with similar characteristics, such as network connectivity,

processor power and memory. There are two such current configurations,

defined as following [23]:

1. Connected Device Configuration (CDC):

This configuration is designed for devices with more memory, faster

processors and greater network bandwidth. It is appropriate, at least in the near

term, for home automation and automotive entertainment, navigation, and

telemetry systems. A programming model closer to J2SE simplifies porting

existing desktop clients for enterprise systems to mobile devices that support

CDC [23].

2. Connected Limited Device Configuration (CLDC):

This configuration is intended for devices with intermittent network

connections, small processors and limited memory. Expected far-gets included

two-way pagers, mobile phones and entry-level PDAs. However, in practice,

35

Chapter 3


the functionality delivered by CLDC and the associated profiles and optional

packages is very close to that of CDC. As a consequence it is used today on

most high-end mobile phones, or smartphones. This relationship, and the

relationship to Java 2 Standard Edition, can be shown in Figure (3.3) [23]

J2ME

Figure (3.3) The Relationship between J2ME configurations and Java 2 Standard Edition

3.2.3. Profile Layer

CLDC alone is not enough to be able to write useful Java programs for a

handheld device. Most importantly, it contains no user interface libraries.

These are instead covered by a profile. A profile is layered on the top of (and

thus extends) a configuration. This is the most visible layer to the users and

the application provider. It defines the minimum set of Application

Programming Interfaces (API) available on a particular "family" of devices

representing a particular "vertical" market segment. The Applications are

written "for" a particular profile and they are portable to any device that

"supports" that profile. A device can support multiple profiles. The mobile

phone specific profile is defined under the name of Mobile Information

Device Profile (MIDP) [23] [24].

36

Chapter 3


3.3 Mobile Information Device Profile

As mentioned before, a profile extends a configuration, adding domain-

specific classes to the core set of classes. In other words, profiles provide

classes that are geared toward specific uses of devices, such as user interface

classes, persistence mechanism, and so on. While profiles provide important

and necessary functionality, we must keep in mind that not every device will

support every profile [24].

The Mobile Information Device Profile (MIDP) specification was defined

through the Java Community Process (JCP) by an expert group of more than

50 companies, including leading device manufacturers, wireless carriers, and

vendors of mobile software. It defines a platform for dynamically and securely

deploying optimized, graphical, networked applications.

Developers using the MIDP can write applications once, then deploy them

quickly to a wide variety of mobile information devices. It has been widely

adopted as the platform of choice for mobile applications. It is deployed

globally on millions of phones and PDAs, supported by leading integrated

development environments (IDE). The MIDP specification covers the

following areas [11]:

1. User Interface support

2. HTTP network support

3. Persistent storage support

4. Miscellaneous classes

37

Chapter 3


3.3.1 MIDlets and MIDlets Suite

Java applications that run on the MIDP are known as MIDlets, and in some

ways resemble the J2SE concept of Applets. Like Applets, MIDlets must

extend the MIDP-defined abstract class javax.microedition.MIDlet

and provide a public default constructor (i.e. a constructor that requires no

arguments), which enables the system software to create an instance of

MIDlet. MIDlets run in an execution environment within the Java VM that

provides a well-defined lifecycle controlled via MIDlet class methods,

which each MIDlet must implement.

A collection of one or more MIDlets is packaged together into one JAR

(Java archive) file to form a MIDlet suite. All the MIDlets in a suite can be

installed, uninstalled and removed only as a group. The MIDlets in a suite

share both static and runtime resources of their host environment, e.g. classes

loaded into their mutual Java VM and persistent storage; in the MIDP 2.0

though, inter-suite access is allowed as for the persistent storage, if explicit

permission is given [23].

3.3.2 MIDlet Lifecycle

MIDlet has one more analogy to Applet: like the Applet's start, stop and

destroy methods, the MIDlet class defines three abstract methods that the

system software calls to start, pause, and destroy an application – namely

startApp, pauseApp, and destroyApp.

38

Chapter 3


Paused Active

Destroyed

Suspend by device or

MIDlet calls notifypused()

Started or resumed by device or MIDlet calls ResumeRequest()

User Ends MIDlet

User Ends MIDlet

MIDlet calls notifyDestroyed()

Constracted

Figure (3.4) The lifecycle of a MIDlet [24]

On a mobile information device (MID), an Application Management Software

(AMS) controls the activation and deactivation of MIDlets. The AMS also

maintains state information about each MIDlet. As Figure (3.4) shows, there

are only three states possible:

• active – the application is running

• paused – the application has yet to run or is in an idle state

• destroyed – the application is terminated

Especially in the case of mobile phone, we must assume that the

application would be often interrupted, among other things, by incoming or

outgoing phone calls. Therefore it is essential to implement the MIDlet's

pauseApp() method, to save important data and free up as much memory

and other resources as possible before going into the paused state.

The destroyed state indicates that a MIDlet has terminated and resource

associated with it can be freed by the system. Once in the destroyed state, the

39

Chapter 3


MIDlet cannot transitn back to the other state. Again, developers are to

implement the destroyApp method in a proper way so that the important

data are saved, all the allocated resources are released, any background

threads are terminated and any active timers are stopped as well as all the

connections are closed. In fact, finalizes do not exist in the CLDC-based

profiles, so the only way to free the resource used by an object is to do it

explicitly [23] [25].

3.3.3 User Interfaces

The MIDP defines a UI library that is optimized for mobile devices. The user

interface on mobile devices is typically key-driven, providing a small screen,

and it must be manageable by users who are not necessarily experts in using

computers.

The use of UI classes is straight forward, which makes MIDP

programming the easiest way to get into mobile programming. The main idea

of the MIDP is to provide a way to implement applications that can be done

with minimum effort and implementation time.

The price of the easy implementation is a quite restricted collection of

usable components. These components cannot be modified by developers as

might be possible with the language C++, pure Symbian programming. These

constraints exist also because of the MIDPs sandbox framework.

The concept that the MIDP expert group introduces is based on displays. A

Display class is the manager of the screen and the input devices of the system.

Display is capable of showing and switching between Displayables, as shown

in Figure (3.5). The MIDP defined javax.microedition.lcdui package

to be used [11].

40

Chapter 3


Display Displayable

Screen Canvas

TextBox Form Alert List

Item

StringItem Gauge Datefield TextField ChoceGroup

CustomItemSpacer

ImageItem

Figure (3.5) User Interface Classes in the MIDP [11]

The MIDP UI model considers the display to consist of a single, fixed-size

window that contents are controlled by a MIDlet or the system at any time.

The window displays one of a set of the virtual displayables, which are UI

components that have the same height and width as the window. As the

application runs, it changes the displayable that the window shows.

Thus, the class Display can be seen as the manager of the displayable

screens and input devices of the system. There is exactly one instance of

Display per MIDlet and the application can get a reference to that instance by

calling the following static method (no constructor available in the class

Display):

41

Chapter 3


public static Display Display.getDisplay(MIDlet myMidlet);

The MIDP UI has a high-level and a low-level API. The high-level UI API

classes Alert, Form, List and TextBox are subclasses of the abstract class

Screen. These classes are designed mainly for business applications and are

highly portable across devices. The particular device's implementation of these

classes performs the adaptation to its hardware and native UI look and feel.

The low-level API is based on the use of the abstract class Canvas and used

mainly for game applications [23].

3.3.4 Network Communication

Networking on CLDC devices has been streamlined so that the programmer

does not have fully understand the underlying device capabilities. The Generic

Connection Framework (GCF) has been created, streamlining the

implementation of the networking with applications. The framework seeks to

provide a consistent interface for every network connection between the

MIDP classes and the underlying network protocols. Every time network

connection is made, no matter what protocol in being used, the interface

remains the same. To open a connection, the static open() method in

Connector class is used.

In MIDP 1.0, the only protocol for which support was required was HTTP.

MIDP 2.0 has made many more protocols available, although HTTP and

HTTPS are the only two mandatory protocols. The optional protocols include

sockets, server sockets and datagram.

An example code to open up an outbound HTTP connection might look like:

Connector.open("www.nokia.com");

42

Chapter 3


Networking operations often slow and are therefore typically initiated in a

separate thread [23].

3.3.5 Persistent Storage

The MIDP does not allow applications to read and write to a filesystem.

However, MIDlets often need to store and retrieve data, such as:

• User configuration or preference information

• A history of the user's past inputs or game score

• Data that the user recently entered or uses frequently

For this reason, a data persistence mechanism named the Record

Management System (RMS) is defined in the MIDP. In RMS, a persistent

datastore is called a record store being represented by the RecordStore

class, which is a collection of records that persists across multiple invocations

of a MIDlet and shared with other MIDlets within the same suite. Also, if

explicit permission is given, MIDlets within other suites can access the record

store. A MIDlet suite can have multiple record stores, each identified by a

string.

The RecordStore class provides a series of methods for opening,

closing and deleting the record store, and modifying the contents of it.

The data in a record store is stored in chunks called records. A record is

written as byte arrays of arbitrary size. To read a record, the byte arrays must

be converted back to the original "readable" form. [23].

43

Chapter 3


3.4 The Bluetooth API As part of the Java Community Process (JCP) a Java Specification Request

(JSR) was approved in October 2000 to design the architecture and associated

API’s to allow developers to utilize the Bluetooth technology in the Java

applications. The aim of JSR 82 was to provide a standard set of Java APIs to

allow Java-enabled devices to integrate into a Bluetooth environment [26][23].

One of the main barriers to the prevalence of Bluetooth applications is the

differences in the interfaces between propriety Bluetooth stacks. The

Bluetooth Java API is intended to help foster the development of Bluetooth

applications by eliminating the need to modify the applications for each stack.

The API is targeted at the devices with limited memory and processing power

because it was the opinion of the expert group that these would be the first

type of Bluetooth products to reach consumers in high volumes.

Hence, the API is based on the CLDC, which also allows for scalability to

other Java configurations. This means nearly all types of Bluetooth and Java

devices can take advantage of the Bluetooth API [26].

3.4.1 The Requirement of JSR 82

JSR 82 is an optional API targeted at J2ME devices. More specifically, it is

aimed at any device that supports the Connected Limited Device

Configuration (CLDC) and Generic Connection Framework (or a superset of

them, such as the CDC).

To implement the Java APIs for the Bluetooth Wireless Technology, the

underlying Bluetooth system must support the following layers and generic

profiles in the Bluetooth stack:

44

Chapter 3


1- L2CAP.

2- RFCOMM.

3- SDP

4- Service Discovery Application Profile.

5- Serial Port Profile.

The specification for JSR 82 also requires that the system supply a

nebulous entity known as the Bluetooth Control Center (BCC). The BCC is a

Control Panel like application options including allowing the user to specify

security settings for Bluetooth connections as well as maintaining a list of

known devices. On Symbian OS the BCC functionally is already provided by

underling native Bluetooth system [23].

3.4.2 The Java Bluetooth Packages

The JSR 82 specifies two packages:

1- javax.obex.

2- javax.bluetooth.

The Object Exchange Protocol (OBEX) is a communication protocol

originally defined by the Infrared Data Association (IrDA) that has been

adopted by Bluetooth SIG. Since OBEX is an independent protocol, it is

supplied in a separate package. Applications may use OBEX API

independently of the Bluetooth API. We will use the second one for the

proposed software application.

The Java Bluetooth API is intended to provide support for the following

capabilities:

1- Registering services.

2- Discovering devices and services.

45

Chapter 3


3- Establishing connection using L2CAP, RFCOMM and OBEX.

4- Providing support for secure connection.

Symbian’s company current implementation of JSR 82 does not provide an

implementation of the OBEX API and hence it does not have a javax.obex

package [23]. Figure (3.6) shows all of the interfaces and classes available to a

JSR-82-enabled MIDlet. [27]

<< Interface>> StreamConnection

<< Interface>> StreamConnectionNotifer

<< Interface>> L2CAPConnection

<< Interface>> L2CAPConnectionNotifer

JSR – 82 enabled MIDlet

<< Interface>> StreamConnection

<<Class>> LocalDevice

<<Class>> DiscoveryAgent

<<Class>>

RemoteDevice

<<Interface>> ServceRecord

Uses

Uses Uses

Implements Uses

Uses

Figure (3.6) Anatomy of JSR 82 enabled MIDlet [27]

3.4.3 MIDP and the Bluetooth API

MIDP devices are expected to be the first class of devices to incorporate this

specification, and the specification allows for the coexistence of MIDP and

Bluetooth APIs [28].

Using the Java APIs for Bluetooth consists of initializing the Bluetooth

stack, discovering devices or services that are in a proximity, open and close

46

Chapter 3


and waiting or initiate connections, performs I/O data. Figure (3.7) illustrates

the different Bluetooth operations that the application can perform [27].

Start

Initialize Clean up

Wait For Connections

Open Connection

Close Connection Discovery

Send Receive Discover Devices

Discover Services

Figure 3.7 Using Bluetooth API [27]

3.5 The mean Benefits of using J2ME There are many points indicate the benefits of using J2ME [23]:

1- Security: Services and application cannot be subverted. Wireless services

depend on the secure delivery of trusted applications and the secure exchange

of information. Security was, and still one of Java’s critical design goals and it

builds into Java form ground up. Feature such as the bytecode verifier,

preventing random accesses and disallowing inappropriate casting, ensure that

Java can be used to develop secure systems. Achieving the same watertight

security with other languages in much harder.

47

Chapter 3


2- Standardization: more developers and tools mean that more services can

be developed. As a consequence a wide range of development tools,

documentations, books, technical support and training is available. Java is the

preferred object-oriented language.

3- Robustness: Java code can be developed more quickly and it is easier to

maintain than C++ code, at the same time it is likely to be more robust and

contain fewer faults than equivalent C++ code. Java applications also require

fewer lines of source code than C++ code.

4- Ease of porting: service providers can deploy on as many mobile phone as

possible. Java is not a guarantee of success when it comes to device-

independence and coping with the huge range of mobile phones; however, it is

the least painful solution. APIs are compact and standard user interface classes

reduce the worst of variability.

48

Chapter 4

Design and Implementation of Mobile Bluetooth Chat

49

Chapter 4 Design and Implementation of Mobile Bluetooth Chat

4.1 Introduction:

The Short Message Service (SMS) was first introduced in Europe in 1991 as

part of the GSM Phase 1 standard. Since that time it has had tremendous

success, with more than 1 billion messages sent around the world daily. SMS

is one of the most important applications for the mobile phone users its

existence depend on the existence of Service Provider. SMS makes it possible

to send and receive short text messages to and from mobile telephones. The

message can contain alphanumeric characters to a maximum length of 160

characters for Latin alphabets, including English, and 70 characters for non-

Latin alphabets, such as Arabic and Chinese. It provides an easy way for

individuals to communicate with one another and with external systems. This

service is provided with low cost for the mobile [1].

Instant messaging (IM) is well positioned to be the next greater application

for the wireless industry. With the monumental growth rate of SMS, and more

than 100 million desktop instant messaging users, the potential for wireless

instant messaging is incredible. It provides similar capabilities to other two-

way messaging technologies, such SMS and email, with the addition of one

significant feature presence. Presence is so elemental to IM that this form of

messaging is often referred to as Instant Messaging and Presence Services

(IMPS).

Instant messaging has been available for fixed Internet users for some time

and it is very popular. Adding the mobile aspect to these services will enable

users everywhere to communicate with one another, regardless of their type of

connectivity. Unfortunately, before this can happen, and/or mobile instant

messaging can meet its potential, the proprietary nature of the leading IM

services will have to be resolved. Interoperability between IM services will be

49


a key ingredient to its success. The leading desktop instant messaging

services, such as AOL Instant Messenger, MSN Messenger, Yahoo!

Messenger, and ICQ, do not allow for cross-service communication. Users can

only communicate with others using the same vendor's product, resulting in

many users having multiple IM clients on their PCs. In the mobile market,

having multiple clients will not be an option, and in some cases, users will be

required to use the IM service that comes preinstalled on their device [29].

The proposed application software (Bluetooth chat application) suggests

using the smartphone's Bluetooth device to provide wireless IM between two

smartphones which is free of charge service instead of use Services Provider

network, the proposed new software application can be worked even if there is

no service provider for cell phone in the area.

4.2 The Supported Tools Design: Before getting to the design of the software application and while J2ME is the

programming language the Java Bluetooth Package (JSR-82) provide some

capabilities as listed in chapter 3 need to be explained:

4.2.1 The Service Registration

When users, make a Bluetooth connection to a remote device to perform some

task such as sending file, They are in fact doing access a service offered by the

remote device. So, Before a Bluetooth host device can communicate with

remote Bluetooth peer, a service must be registered and offered by the remote

device. To register a service it needs to perform the following steps [23]:

⋅ Create a service record

⋅ Add a service record to the server’s Service Discovery Database

⋅ Set security measures associated with connections to clients 50


⋅ Accept connection from client that request service.

A. Service Record

The Service Discovery Database (SDDB) maintains a repository of the service

records corresponding to the services offered by the host device. A service

record provides sufficient information to allow a client to connect to the

Bluetooth service being offered by the server. Service discovery is the

province of the Service Discovery Application Protocol (SDAP) which itself

uses the Service Discovery Protocol layer in the Bluetooth stack. The APIs for

creating a service record and adding it to the SDDB are Java wrappers around

functionality in the SDAP and SDP [23].

B. Universally Unique Identifiers (UUID)

UUIDs are 128-bit value that is guaranteed to be unique across all space and

time. UUIDs are used in the Bluetooth SDP to identify service. Some UUIDs

are defined by Bluetooth specification for specific protocol or uses [30].

4.2.2 Device Discovery

The first step in a networked Bluetooth application often discovers other

devices that are in range, in other words devices must be able to discover other

nearby devices, a process referred to as Device Discovery. A discovered

device is identified by its Bluetooth device address.

For reasons of privacy, a Bluetooth device can have various settings for its

"discoverable mode." For example, a device may be configured not

discoverable. In this case, other Bluetooth devices that are within range won’t

detect it.

51


Alternatively, a Bluetooth device may be configured to be generally

discoverable by other Bluetooth devices. In this case, the discoverable mode

will be set using the General/Unlimited Inquiry Access Code (GIAC) meaning

there are no restrictions placed on which remote devices may discover the

host. A Bluetooth device may also be configured to be discoverable in a

"limited" manner by other Bluetooth devices by using a limited inquiry. In this

case, the discoverable mode is set by using the Limited Dedicated Inquiry

Access Code (LIAC). Using LIAC as the discoverable mode is a bit like

briefly sticking your head above the crowd in a crowded (with GIAC devices)

area, in order to be temporarily more visible to someone who is trying to find

you. It is only used a specific type of devices [20] [30].

4.2.3 Service Discovery

Device Discovery is not enough to use a nearby service. Applications must

also be able to find services hosted on nearby Bluetooth devices. This process

is referred to as service discovery, and the Bluetooth Service Discovery

Protocol (SDP) is used for this purpose. Once a desired service has been

discovered on a nearby device, an application may attempt to connect to the

service and use it [30].

52


4.3 The Proposed Software Design: The Bluetooth chat application allows two users to exchange short messages

chat using Bluetooth as the communication medium. The basic design of this

application based on a client-server model, one device should be act as a

server and the other one act as a client. Figure (4.1) explains the main design

for the proposed software application. First the application will ask the user to

enter nick name to use it later in the chat application after that the user can

choose either to be in server mode or the client mode, the first one will start

running and waits indefinitely to accept new client connection requests from

remote client which is running from the other side. L2CAP protocol (which is

one of the Bluetooth protocols) will be used to establish the connection

between the two devices. This protocol is a packet-based protocol that is more

suitable for certain type of non-stream communication.

So it is performed generally in four stage of design process. First stage is to

design and program the server mode which is offer the service of

BluetoothChat for the client using L2CAP protocol to establish the connection

and wait for a client to connect to it. The second stage is to design and

program the client mode, which is search for an active Bluetooth server

offering BluetoothChat server to connect to it. The third stage is to design and

program Send and Receive procedure and make them run simultaneously by

using two threads for each Send and Receive Procedures. Finally the last stage

is to design and program a user interface that collects all the previous stages in

one software package.

53


Figure (4.1) The Proposed Software Application Block Diagram.

54


4.3.1 The Server Mode Design

A server is the program that services those requests in some way. Bellow the

steps and snippet of codes to create the server mode in this application

offering “Bluetoothchat” as a service for client. Figure (4.2) will explain in

detail the steps of the server mode flowchart.

1. Using string to create a UUID which is 128-bit value that uniquely

identifies a Bluetooth service.

private final String UUID_STEING =

“11112233445566778899AABBCCDDEEFF”;

2. Represent the Host device and make the Bluetooth device discoverable, as

Bluetooth device can have various setting for its "discoverable mode" in

the proposed application set the discoverable mode to GIAC.

LocalDevice device = LocalDevice.getLocalDevice(); Device.setDiscoverable(DiscoveryAgent.GIAC);

3. Initiate the L2CAP protocol connection and set the name of the service to

“Blouetoothchat” with other parameter.

L2CAPConnectionNotifier notifier = (L2CAPConnectionNotifier)Connector.open(btl2cap://localhost:” + UUID_STRING + “;name=Bluetoothchat”);

4. Create Service Record

ServiceRecord record = LocalDevice.getRecord(notifier);

5. Add Service Record to SDDB and make the server ready to accept Client

connection (wait for client connection) L2CAPconnection conn = notifier.acceptAndOpen();

55


Figure (4.2) The Server mode steps flowchart

56


4.3.2 The Client Mode Design

In the pervious section Server mode was designed and offered a Bluetooth

service. Bellow the steps to design the client mode and make this client access

the service offered by the server. This is generally a three-stage process as

bellow. Figure (4.3) will explain in detail the steps of the client mode

flowchart.

1. The first stage in creating client is the device discovery in this stage the

client try to discover all active Bluetooth devices in the range and add them

to a list. Snippets of the codes as bellow:

Public void deviceDiscovered(RemoteDevice btDevice, DeviceClass cod);

Public void inquiryCompleted(int discType);

2. The second stage, select the suitable device in the range and start search for

the required service that its named here (Bluetoothchat) in the SDDB.

Snippets of the codes as bellow:

Public void servicesDiscoverd (int transID, ServiceRecord[]servRecord)

Public void sericeSearechCompleted(int transID, int

respCode)

3. Last stage connecting to the Service, once the service record related to the

required service have been obtained, that is all needed to connect to service.

Using getConnectionURL() method of the ServiceRecord to

obtain a String encapsulating the necessary information (protocol, Bluetooth

address of the device provide the service, L2CAP server channel identifier,

57


etc.) then this information will be used in the open() method to obtain an

L2CAPConnection, as shown bellow.

Stringurl = serviceRecord.getConnectionURL.NOATHENTICAE_NOENCRYPT, false);

L2CAPConnection conn =

(L2CAPConnection)Connector.open(url);

Figure (4.3) The Client Mode steps flowchart

58


4.3.3 Send and Receive Procedure

Send and Receive part are the same in the Server mode and in the Client mode

both of the send and receive procedure will run concurrently (in parallel) in

other words the send procedure will be always ready to send message when

the user press send bottom and the receive procedure will be always ready for

incoming messages. Send and Receive procedure will be run automatically

when the connection between the Server and client established. To send a

message using J2ME over L2CAP connection need to used send() method,

where byte[] data contain the packet to be sent which is here the

message and as written bellow:

public void send (byte[] data)

To receive the message that has been sent, it need to call first ready()

method which is return true if there is message wait to be received then call

receive() method to receive it. That can be written as bellow:

If (conn.ready(){ . . public int receive(byte[] inBuf) . . }

To run both Send and Receive procedure in parallel its need to create two

threads, one for Send procedure and the other for receive. The secret behind

the success of this proposed software application is the available of thread

(Multitasks) facilities in the Symbian OS that have been discussed in chapter

two.

59


4.3.4 User Interface Design:

The UI of the chat application start by priesnt the StartScreen screen then

the screen map transitions from the StartScreen screen to Option screen.

The Option screen lets user to choose Start Server (Server Mode) or Connect

to Server (Client Mode), When the user select Start Server the screen map will

transitions to ServerForm screen and waiting to accept and open incoming

connection from the remote client. Once a connection has been set up, the

ServerForm will allow the user to send and receive messages.

When the user selects Connect to server the screen map will transit to

DeviceDiscoveryList screen. It is used to search for the active devices

and add them to a list to display to the user which the user can select the

suitable device to open a connection with the server. When connection has

been created, the screen map changes to a ClientForm screen.

OptionList

ServerForm

Devices DiscoveryList

ClientForm

Exit

Exit

Exit

Send & Receive Message

Client

Server

StartScreen

Send & Receive Message

Open Selected Connection

Search for Active Devices

Figure (4.5) Software Application Screen Map

60


4.4 The Implementation: In the implementation side of this software application we will use all the

technologies mentioned in the previous chapters. This phase will contain the

implementation of the new software application which was programmed using

JBluilder 9 Enterprise Edition and Nokia Developer Suite 2.2 to create the

application package JAR which is instilled in two Nokia 6600 devices. The

icons of the new software application can be seen in the application menu of

each device and the user can choose it to start the Bluetooth chat application.

Bellow some of GUI screenshots and brief explanation.

Figure (4.6) contain the start screen (show the name of the application,

name of vendor and time of creation) for the application it just appear for 6

seconds and then disappeared automatically to show the next screenshot.

Figure (4.6) The Start Screen for the Application

The software will ask the user to enter the Nick Name to be used later as a

chat name as shown in figure (4.7 a), after entering the Nick name as shown in

figure (4.7 b), the user can select either “Close” bottom which leads to exit or

61


select from “Options” the “OK” bottom which leads to the next screenshot in

the program, as shown in figure (4.8) or the “Exit” bottom will lead the user

to exit from the application or the user can choose “Cancel” bottom which

appears in the right of the screen to return the present screenshot shown in

figure (4.7 b).

Figure (4.7) Screenshot for entering the Nick name. (a) (b) (c)

(a) (b) Figure (4.8) Screenshot shows the options provide to the user

62


After entering the Nick name and select “OK” bottom from the “Options” list

the new screenshot will show a clue helps the user to select from the new

“Options” list either “Start Server” or “Connect to Server” to start chat with

other device (user) as shown in figure (4.8 a and b) or can choose “Exit” to

exit from the application.

1- Start Server:

If the user select “Start Server” the system made an alert to the user asking the

user for permission to let the application (MIDlet) open Bluetooth as shown in

figure (4.9 a), when the user gives the permission to the program to open

Bluetooth connection by press on “OK” bottom, the program will present a

message to the user tell him/her that the server is running now and wait a

request from other device (Client) to start chat as shown in figure (4.9 b).

(a) (b) Figure (4.9) Start Server Screenshots

2. Connect to the Server:

If the user select “Connect to Server” this means that this device will act as

Client and start search for active Bluetooth devices in the rang as shown in

63


figure (4.10 a) after searching has been completed new screenshot will present

tell the user that the search was complete and he/she must select one of the

devices appear in the list as shown in figure (4.10 b) by using the joystick the

user can scroll up and down to select the suitable device from the list, as

shown in figure (4.10 c).

(a) (b) (c) Figure (4.10) Connect to server screenshots

When one device is selected the program will start searching for a specific

service offered by other devices as shown in figure (4.11 a), if the service

search is completed and the specific service was found then the system will

alert the user that the application try to open Bluetooth connection as the one

appear in the server which is shown in figure (4.9 a). So, by pressing “Ok” the

chat screen will start automatically in both devices (server and client). As

shown in figure (4.11 b & c) and the two users can enjoy in chat with each

other free of charge and the application will not affect or effect of the other

activates of the smartphone (like receiving call or SMS).

64


(a) (b) (c)

Figure (4.11) Start Chat between two users

4.5 Performance Operation During the implement of the Mobile Chatting Software using both smartphone

devices we get the following results:

First from the power side that needed to run this software in both devices

smoothly and with no troubles we fined that it will be run successfully if they

have been used according to the Bluetooth range and it can be run as long as

the users want, it will cause battery power down if it is run for a long time

(over than one hour).

Second during the chatting operation between device “A” and device “B”

if there is any interrupt just like a phone call they can obviously continue

using the chatting software by sending and receiving messages while

answering the phone call by making a voice conversation without any effects

on the running of the mobile chat software.

65


Third the operation of the chatting will slow down the sending and receiving

messages during using the same Bluetooth to send or receive any other object

in the same time.

Fourth some time when the user search for an active Bluetooth device he

get alert message that here is no active device in the range and add new option

capable the user to do new search for an active Bluetooth device, this happen

when one of the user forget to turn on the Bluetooth or they are far way from

each other (out of Bluetooth coverage area).

Fifth this software application can not receive Arabic messages because

Arabic characters used 16-bit (Unicode UCS2) instead 7-bit for English

characters and while the receive message procedure deal with English

characters (7-bit) the Arabic characters will show as question mark “???”. And

it needs a sophisticated processing to solve this issue.

Sixth when the users gone out of the Bluetooth range the software

application will stop the program and gave the user alert message that he lost

the connection with the other device.

66

67

Chapter 5

Conclusions and Future Work

Chapter 5 Conclusions and Future Work

67

5.1 Conclusions: This thesis has described and evaluated Bluetooth and J2ME technologies -

helping the reader understand the foundation for these technology. The Bluetooth

architecture was therefore described in general, before important Bluetooth

concepts such as device discovery, service discovery, creation of services, and

service record usage were discussed.

In this work we have designed and implement a system that allows a

Bluetooth-enabled mobile device to provide the ability of doing free of charge

chatting between two smartphones.

This solution for smartphone devices is dependent upon the capabilities in the

programming environment on the devices. MIDP, which is a Java programming

environment for mobile phones, provides simple syntaxes support that limits.

The most important points that are concluded throughout the design and the

implementations of this software are:-

1. The evaluation shows that the design consumes minimal power from the

hardware.

2. This software application has been Bluetooth hardware independent, in other

words the software can be run under any type of Bluetooth. And to be

hardware mobile manufactured independent that means it can be run on any

type of smartphone support Series 60 and MIDP 2.0.

4. It is free of charge and it can be run successfully even if there is no service

provider network for cell phone in the area.

5. The programmer who uses J2ME to create new application does not need to

know the tiny detail of the Symbian OS or Series 60 compared with the

programmers who uses C++.

Chapter 5 Conclusions and Future Work

5.2 Future Work There are many avenues for seeking improvement in the proposed software

application. The following are some of these avenues:

1. Developing the proposed software application to support Arabic messages

send and receive.

2. Developing the proposed software application to work with more than two

smartphone at the same time.

3. Developing the proposed software application by making PC work as a

server connected to Bluetooth Access point which covered wide area (all

office) and make all the smartphones (Clients) connected to that PC

(Server), which lets every one can reach every one in the office.

4. Create hyper Bluetooth network form PCs and Smartphones connected each

other covered full building. That means every PC or smartphone can send

and receive messages to any PC or smartphone in the building.

68

References

69

References

1. Martyn Mallick, “Mobile and Wireless Design Essentials”, John Wiley & Sons Ltd, 2003.

2. “Mobile and Wireless Application Options”, iAnywhere Solutions, Inc.,

2004. (accessed 10-11-2004) http://www.ianywhere.com/downloads/whitepapers/mobile_and_wireless_application_optionsV2.pdf

3. Valentino Lee, Heather Schneider and Robbie Schell, “Mobile

Applications: Architecture, Design, and Development”, by Prentice Hall., Apr 16, 2004. (accessed 15-11-2004) http://www.informit.com/articles/article.asp?p=336262&seqNum=1

4. “Mobile Application Architectures”, Marco Avvenuti, University di Pisa,

2005 (accessed 10-6-2005) http://info.iet.unipi.it/~marco/smp/MobileApplication.pdf#search='Mobile%20Application%20Architectures

5. “A smart client architecture Making the Case for Local Database and

Synchronization”. (accessed 20-6-2005) http://www.devx.com/wireless/Article/11398/1954?pf=true

6. “White Paper: Extending Enterprise Applications with Mobile Devices

Jargon Software Inc.” Minneapolis, Minnesota, May 2004. (accessed 20-6-2005) http://www.jargonsoft.com/m2/tech/JargonWhitePaper.html

7. Dennis Craven, “Series 60 Application Development Integration with CS457 Course Material”, Master Thesis, Department of Computer Science, University of Western Ontario, London, 2004.

8. André N. Kilingsheim, “J2ME Bluetooth Programming”. Master Thesis,

Department of Informatics University of Bergen, 2004. 9. Allan Beaufour Larsen, “Secure Access Control Using Mobile Bluetooth

Devices”, Master Thesis, Department of Computer Science University of Copenhagen, Denmark, 2003.

10. David Svensson and Torbjörn Eklund, “Mui: Controlling Equipment

via Migrating User Interfaces”, Master of Science Thesis,Department of Computer Science Engineering, Lund Institute of Technology, 2002.

69

http://www.ianywhere.com/downloads/whitepapers/mobile_and_wireless_application_optionsV2.pdf

http://www.ianywhere.com/downloads/whitepapers/mobile_and_wireless_application_optionsV2.pdf

http://info.iet.unipi.it/~marco/smp/MobileApplication.pdf#search='Mobile%20Application%20Architectures

http://info.iet.unipi.it/~marco/smp/MobileApplication.pdf#search='Mobile%20Application%20Architectures

http://www.jargonsoft.com/m2/tech/JargonWhitePaper.html

References

11. Digia Inc., “Programming for Series 60 Platform and Symbian OS”, John Wiley & Sons Ltd, May 2004.

12. SYMBIAN LTD. Symbian WWW site, 2004.

http://www.symbian.com. (Accessed 15-12-2004) 13. “Symbian OS version v7.0s functional description”, Symbian Ltd,

DIXON, K. 2004 http://www.symbian.com/technology/symbos-v7s-det.html.

14. “Why is a different operating system needed?” MERY, D Symbian Ltd.

2004 (Accessed 5-1-2005) http://www.symbian.com/technology/why-diff-os.html.

15. Sander Siezen, “Symbian OS Version 8.0, Product Description”,

Symbian Ltd. Revision 2.1, February 2004. http://www.symbian.com/technology/SymbianOS_funcdesc

16. Leigh Edwards, Richard Barker & the Staff of EMCC Software Ltd.,

Nokia Mobile Developer Series, “Developing Series 60 Applications”, Addison–Wesley, 2004.

17. Peter Sanders, Developer Consultant, Professional Services, “Creating

Symbian OS Phones”, Symbian Revision 1.1, April 2002. http://www.symbian.com/create-OS-phones.html

18. “Series 60 Developer Platform: Introductory White Paper”, Version

1.1 June 28, 2004 http://ncsp.forum.nokia.com/asset_id=1184f

19. “Bluetooth Technology Overview”, Forum N O K I A, Version 1.0;

April 4, 2003 http://ncsp.forum.nokia.com/asset_id=21;ref=dxvx

20. Special Interest Group (SIG), “Bluetooth Core Specification v1.2”, SIG,

USA, November 2003 21. “Symbian on Bluetooth wireless technology”, Revision 1.1, October

2001 http://www.symbian.com/technology/standardblue.html

70

http://www.symbian.com/

http://www.symbian.com/technology/symbos-v7s-det.html

References

22. H. M Deitel, P. J. Deitel, T. R. Nieto, K. Steinbuhler, “Wireless Internet & Mobile Business How to Program”, Prentice Hall, 2001.

23. Martin de Jode, “Programming Java 2 Micro Edition on Symbian OS

(A Developer’s Guide to MIDP 2.0)”, John Wiley & Sons Ltd., 2004. 24. C. Enrique Ortiz and Eric Giguère., “Mobile Information Device Profile

for Java 2 Micro Edition”, John Wiley & Sons, Inc., 2001. 25. “Programming the MIDP Lifecycle on Symbian OS”, Martin de Jode

Version: 1.00, November 2004 http://symbian.com/techlib/papers/midspsdlifecy/

26. “BluetoothTM Developers and Implementers Can Succeed with JavaTM

Specification Request (JSR) 82”, Sun Microsystems, Inc. ‘’. 2002. www.jcpd.org/press/success/bluetoothshowPrint

27. “Developing Applications with the Java APIs for Bluetooth™ (JSR-

82)”, Sony Ericsson, January 2004. http://www.microjava.com/Bluetooth-jsr-82

28. “Java API for Bluetooth Wireless Technology (JSR-82)”, Specification

version 1.0a, Motorola, Wireless software, Application & Service, April 5, 2002. http://megaisttl.pt/icapse/docs/JSR82_1a.pdf

29. “Mobile Instant Messaging”, Roland Parviainen, Peter Parnes, Centre for

Distance-spanning Technology, Department of Computer Science, Luleå University of Technology, 971 87 Luleå, Sweden. http://www.cdtluth/peppar/docs/mim2/mim2.pd

30. “Introduction To Developing Networked MIDlets Using Bluetooth”,

Nokia, May 11, 2004. http://sw.com/id/c0d95e6e-ccb7-4793-b3fc-2e88c9871bf5 /Introduction_To_Developing_Using_Bluetooth_v1_0

71

http://sw.com/id/c0d95e6e-ccb7-4793-b3fc-2e88c9871bf5%20/Introduction_To_Developing_Using_Bluetooth_v1_0

http://sw.com/id/c0d95e6e-ccb7-4793-b3fc-2e88c9871bf5%20/Introduction_To_Developing_Using_Bluetooth_v1_0

developing wireless mobile application for series … science/ms.c/2006/developing...“developing...

Documents