apt hrd programme for exchange of ict … · mahathir said (telekom malaysia berhad) syahrifendi...

APT HRD PROGRAMME FOR EXCHANGE OF

ICT RESEARCHERS AND ENGINEERS

TITLE OF PROJECT:

DEVELOPMENT OF JAVA MOBILE APPLICATION USING

BLUETOOTH TECHNOLOGY FOR RURAL COMMUNITY

COMMUNICATION

PROJECT REPORT

NOR AZHAR MOHD ARIF (MULTIMEDIA UNIVERSITY MALAYSIA)

HAFIZAL MOHAMAD (MULTIMEDIA UNIVERSITY MALAYSIA)

MAHATHIR SAID (TELEKOM MALAYSIA BERHAD)

SYAHRIFENDI LUKMANILHAKIM (TIME DOTCOM BERHAD MALAYSIA)

SALINA SAMSUDIN (FELDA SUNGAI BEHRANG MALAYSIA)

RYOICHI KOMIYA (NICT JAPAN)

YOSHINORI SAKAI (TOKYO INSTITUTE OF TECHNOLOGY JAPAN)

TAKAMICHI MIYATA (TOKYO INSTITUTE OF TECHNOLOGY JAPAN)

KOJI KOYAMADA (KYOTO UNIVERSITY JAPAN)

31 JULY 2008

Abstract

This project is led and conducted by university researchers and telecommunication

companies’ engineers in Malaysia through collaborations with universities’ researchers in

Japan. It aims to increase the awareness and knowledge of digital and information and

communication technologies among the people in the rural community by developing a

simple but useful application and where they have it run on mobile phones and be used in

their daily activities. As a result, a basic application is successfully developed using Java

programming language for mobile devices (J2ME) that enables users to exchange text

messages similar to a combination of short message service (SMS) and chat through

Bluetooth frequency but free of charge i.e. no charges for network connection and for every

transmission of message. Based on the tests conducted, so far the success rate of installation

and running of the application on 21 different models of mobile phones equipped with

Bluetooth is around 71%. A very positive response are also received from the key people of

the rural community and from the preliminary survey on the role of such application in

reducing the digital and ICT knowledge gap between the urban and rural community.

However, the tests has also uncover some significant limitations of the application namely the

maximum range of coverage, maximum number of users at a time and compatibility issue for

installation in some models of mobile phones. Also, it has been suggested that an application

for a more specific usage to be developed within the known limitation of Bluetooth to

achieve the primary goal of bridging the gap through usage of technologies in daily activities.

These have provided a much guided direction for the enhancement and future work to be

conducted for the continuation of this project.

1 INTRODUCTION

In this day and age, ubiquitous system applications are widely used in information and

communication technology world. But not all walks of life have the privilege to access the

digital technologies. A digital divide is building up mostly in rural areas where people do not

have access to digital technologies. The term “Digital divide” refers to a gap between people

with regular, effective access to digital technologies and those who do not. Ubiquitous system

applications are mostly applied in urban and city areas but rarely used among the rural

development areas community. Modes of communication are vastly categorized and

sometimes can be expensive. All levels of society are adhering to the cheapest information

services for everyday information.

Generally, this project aims to increase the awareness and knowledge of digital and

information and communication technologies among the people in the rural community. This

is done by providing them with a simple but useful application installed in their mobile

phones and suitable to be used in their daily activities. The application should be similar to

the type of application that they are comfortable with, in this case short message service or

better known in Malaysia as SMS. Thus, an application that enables users to exchange text

messages similar to SMS and Chat has been identified to be developed for this purpose.

There are two main motivations for choosing this approach i.e. mobile device with Bluetooth:

(a) The hardware factor – the penetration of mobile phones in rural area is much higher

as compared to personal computers. This due to adequate coverage of mobile wireless

communication services normally associated with mobile phones and the

unavailability of fixed line internet broadband services in rural area normally

associated with personal computers.

(b) The monetary cost factor – through Bluetooth frequency, the network connection and

transmission of each message is free of charge, unlike the standard SMS service or

Chat through the internet.

Currently, there are several applications and software’s in the market using Bluetooth to

communicate among mobile phone and personal computer users. However, almost all of

these applications require the license purchase. So far we have found only one application

that is similar to ours known as Bluechat which is totally free for use. However, its system

architecture and working procedure are completely different from our developed application

since unlike ours, Bluechat does not work on Server and Client concept i.e. there is no

requirement for one of the users to be a server as every user runs on the same mode. In

addition, although our developed application is also applicable to the general public use, our

next research focus is to get the rural community responses on the developed application for

any enhancement on the current version and development on a similar application using the

same architecture but for a more specific purpose such as voting or item ordering

applications.

2 PROJECT OBJECTIVES AND MILESTONES

2.1 To educate the rural community to make use the Bluetooth feature that is available in

mobile transceivers (mobile phones) through appropriate application.

2.2 To develop an application using Java programming language for mobile devices

(J2ME) that enables users to exchange text messages at real time basis similar to a

combination of short message service (SMS) and chat through Bluetooth frequency.

2.3 Milestone (significant phases of the project)

a) Additional background study and purchases of necessary devices and tools are to be

completed by middle of December 2007.

b) Detail study on project implementation and preliminary work are to be completed by

middle of January 2007.

c) Documentation and submission of the interim report by end of February 2006.

d) The basic Java mobile application is to be confirmed in working order by end of

March 2008.

e) Main project is to be completed by end of June 2008.

f) Documentation and submission of final report to APT by end of July 2008.

3 PROJECT PARTNERS

The followings are the institutions and companies involve in this collaborative research:

3.1 Multimedia University (MMU) Malaysia.

3.2 Telekom Malaysia Berhad (TM)

3.3 Time Dotcom Berhad, Malaysia

3.4 Felda Sungai Behrang Malaysia

3.5 National Institute of ICT (NICT), Japan.

3.6 Tokyo Institute of Technology (TIT), Japan.

3.7 Kyoto University Japan

Purpose of collaboration and role of partners.

3.8 The development of the basic Java mobile application is the responsibility of

project members in Malaysia. The development of the application was carried

out in two stages; the first version of the application which is a very simple

and basic system was completed at the end of February 2008. This version of

the application was the main item of discussion during the second round of

project meetings in Malaysia. Based on the feedbacks from these meetings the

second version of the application which is a much more improved system was

developed based on the earlier version and was completed in middle of June

2008.

3.9 Researchers from NICT, TIT and Kyoto University are expected to help out by

sharing their expertise and experiences in developing the application. During

the second round of project meetings in Malaysia, through the hardware

demonstration of the application, the Japanese partners have given several

valuable feedbacks and comments for the enhancement to be implemented on

the application based on the limitations of the first version. Among them were

better outlook of graphical interface, necessary indication to the user when

sending and receive messages (sound and vibration alerts), more lines of

previous sent messages and setting page for preferences changes by user.

4 SUMMARY OF PROJECT ACTIVITIES

The related work commenced on 18th

October 2007. The following describes the project

activities conducted and completed by the end of January 2008:

4.1 Site Visits:

The local project team members have visited the local rural community location

(Felda Kampung Sungai Behrang) in Perak several times as follows:

4.1.1 26-10-2007 : Project leader made the first visit to the local community in

Perak to meet the community contact person for initial discussion and to get

the actual view of the community.

4.1.2 19-01-2008 : All local project team members visited the rural community

location for the first time as a team. Meeting between all local project

members was held during this visit at this location.

4.1.3 21-06-2008 : Second visit by all local project members. Training session on

how to install and use the develop application for the rural community key and

contact persons and was conducted during this visit.

4.1.4 10-07-2008 : Project leader attended a program organized by the rural

community contact person held at another rural community nearby. The plan

is to get responses from the people on the developed application as it was

expected around 500 turn outs. However, due to bad weather condition the

plan was abandoned.

4.2 Local Meetings:

Meetings between the local project members were conducted twice a month since

November 2007 at various venues to discuss the progress of project.

4.3 International Meetings:

Coordination meetings between local and Japanese project members were conducted

as follows:

4.3.1 30-11-2007 : Local project members meeting with Prof. Koyamada at Kyoto

University, Japan - initial discussion on project overview, planning, planned

milestone and responsibilities of each member.

.

4.3.2 01-12-2007 : Local project members meeting with Prof. Komiya in Tokyo,

Japan - initial discussion on project overview, planning, planned milestone

and responsibilities of each member.

4.3.3 04-12-2007 : Local project members meeting with Prof. Sakai and Takamichi

Miyata at Tokyo Institute of Technology - initial discussion on project

overview, planning, planned milestone and responsibilities of each member.


Miyata in Kuala Lumpur:

• update on the progress of project by each project members.

• hardware demonstration on the basic version of the developed

software.

• comments and feedback on the basic version by each member for

improvement.

• site visit to the rural community.

4.3.5 19-06-2008 : Local project members meeting with Prof. Ryoichi Komiya in

Kuala Lumpur:


• hardware demonstration on the improved version of the developed

software.

• comments and feedback.

4.3.6 05-07-2008 : Local project members meeting with Prof. Koji Koyamada in

Kuala Lumpur:



software.


• site visit to the rural community.

4.3.7 21-07-2008 : Local project members meeting with Prof. Ryoichi Komiya in

Tokyo:



software.

• discussion on the final report.



Miyata in Tokyo:



software.



4.3.9 24-07-08 : Local project members meeting with Prof. Koji Koyamada in

Kyoto:



software.



5 DEVELOPMENT OF BTOOTH COMM APPLICATION

5.1 System Architecture

5.1.1 Developing a Client/Server communication using RFCOMM

The application developed is divided into two sections, a server MIDlet and a client MIDlet.

A MIDlet (Mobile Information Device Toolkit) is a Java program that is develop using J2ME

(Java 2 Micro Edition) language for embedded devices. This application uses RFCOMM

(Radio Frequency Communication) protocol. RFCOMM is one of Bluetooth protocols. It is a

simple set of transport protocols, made on top of the L2CAP (Logical Link Control and

Adaptation Protocol) that is the lowest level of Bluetooth protocol that can be accessed by an

application. A mobile phone is used for both the client and server side and communication is

via Bluetooth technology.

5.1.2 Required Connections

A client MIDlet will wait to accept a connection from an appropriate remote “server” MIDlet.

The server MIDlet will first performs a device inquiry and when the device inquiry has

completed, the server has a list of possible nearby Bluetooth devices. It then performs service

discovery on found devices having a suitable COD (Class of Device). A COD is a value to

indicate the capability of the device. The COD value will show whether the device is a

printer, headset or a keyboard. These numerical values are reserved by the Bluetooth

specification. In this case the COD shows a mobile phone value. COD also allows the server

to find any reachable nearby clients. After the service discovery phase has completed, the

user of the server MIDlet is presented with a list of devices. The server MIDlet will next

initiate a connection to each client selected by the end user. The user of the server MIDlet

selects which client to initiate a connection to and the order in which connections are created.

This means connections are created from the server to clients, one by one. Fig. 5.1 shows the

server is the Bluetooth master for each connection.

Figure 5.1: Device inquiry, Service discovery and connection creation

5.1.3 Device Inquiry

The first step in a networked Bluetooth application is to discover other devices that are in

range. Bluetooth devices are mobile and form networks dynamically, so they must be a way

to find other devices to connect to. This process is called the inquiry procedure in the

Bluetooth Baseband Specification. A discovered device is identified by its Bluetooth device

address, as well as its class of device (COD) value. In a MIDlet application, it can either use

the GIAC (General Unlimited Inquiry Access Code) or the LIAC (Limited Inquiry Access

Code) for device inquiry. A Bluetooth device can have various settings for its “discoverable

mode”. If the device is configured to GIAC, it is set to be generally discoverable by other

Bluetooth devices and if configured to LIAC, it is set to be discoverable in a “limited”

manner by other Bluetooth devices. This means, the device can only be discovered for a

limited amount of time.

5.1.4 Service discovery

In wired networks, usually there is a central infrastructure for managing connections but in

Bluetooth technology, it is different. Connections are made dynamically, and devices must

determine what services are provided on discovered devices. This procedure is called service

discovery which is the process by which applications locate and gather information about

other services in the surrounding area. Once a desired service has been discovered on a

nearby device, an application may attempt to connect to the service and use it.

5.1.5 Client/server connections

A connected client MIDlet may send a message to its server MIDlet. The server will simply

echoes the message back to all connected clients. The message is also echoed back to the

original sending client. The purpose is to allow a client to send message to all connected

clients via the server. Another alternative way is the server can also sends a “non-echo”

message to all connected clients. The application architecture is shown in Figure 5.2

Figure 5.2: A client sends a message and the server echo messages to all clients

In this application, the server MIDlet is also known as “btSppEcho MIDlet” while the client

MIDlet is “btsppEcho MIDlet”. This is the name of the compile file used in the application.

5.1.6 Dropped Connections

If a client MIDlet exits or otherwise disconnects, the server will remain connected to and in

communication with the remaining clients. However, if the server MIDlet exits or otherwise

disconnects, then all communication is lost between the clients. This means all connections to

the server are closed.

5.2 Implementation of “btsppEcho MIDlet”

The MIDlet can be started in either the client or server mode in the initial The MIDlet can be

started in either the client or server mode in the initial SettingsList screen (Figure 4.2). The

SettingsList screen lets the user choose between discoverable mode (server) or discovery

mode (client) used for device inquiry, and if the general (GIAC) or limited inquiry access

codes (LIAC) are used. It also lets the user choose appropriate security settings

(authentication, encryption, and authorization).

When the MIDlet is started and the user chooses to set it as client mode, the screen map

transitions from the initial SettingsList screen to a ClientForm. The ClientForm will use a

class called ConnectionServer to accept and open incoming connections from the remote

server. Once a connection has been set up, the ClientForm allows the user to send messages

to the server. It also displays messages received from the server.

When the MIDlet is started in server mode, the screen map changes from the initial

SettingsList screen to a ServiceDiscoveryList. It is used to initiate device inquiry, and

subsequent service discovery on any found devices that have a suitable COD. Once the

device is discovered,it is displayed to the user as elements of the list. The user can next

choose to open a connection from the server to a client. When the connection has been

created, the screen map changes to a ServerForm screen. The ServerForm is used to display a

text messages received from any client and to allow the user to send a simple text messages

to all connected clients. It also displays how many clients are currently connected, and allows

a new connection to be added by a screen transition back to the ServiceDiscoveryList. This is

used to select an open the next connection to other not connected Bluetooth device. The

screen map is shown in Figure 5.3.

Figure 5.3: Screen map

5.2.1 Client

Figure 5.4: Class diagram of classes used by the client

Figure 5.4 shows a diagram to illustrate the class diagram for the MIDlet design. In this sub-

chapter, the client and server MIDlet will be explained in more detail from the application

starts to sending messages. When the MIDlet first starts, it will display a SettingList Screen

that is used to set important settings for the MIDlet and to give option to the server whether to

start in client or server mode. If the MIDlet is started in client mode, it will create an instance

of a ConnectionService object and displays the ClientForm screen.

The ConnectionService runs continuously, waiting to accept new connections on the

appropriate server connection string. When it accepts a new connection from a remote server,

it notifies the ClientForm that it has accepted a new connection and creates a new

ClientConnectionHandler to handle that connection. A ClientConnectionHandler is a class

that is runnable, so it may be read and write from the appropriate input and output streams.

The ClientForm starts the thread of each accepted ClientConnectionHandler and causes it to

instantiate the actual InputStream and OutputStream objects needed. This will both start a

reader and writer thread for them. The ClientForm is a ClientConnectionHandlerListener, and

so accepts callbacks from its ClientConnectionHandler objects related to opening the input

and output streams, received messages, sent messages and when connection closes normal or

abnormally. The ClientForm directly uses a ClientConnestionHandler to send messages.

5.2.2 Server

Figure 5.5 shows a diagram to illustrate the class diagram for the MIDlet design. When the

MIDlet started in server mode, it will change the screen map to ServiceDiscoveryList. From

this screen, the user may begin a “search” (device inquiry and service inquiry) and this phase

will return matching devices and services. The end user may then select to open the first

connection to a remote client, and the screen map is change to the ServerForm screen.

The ServerForm screen creates the actual connection to a remote client, and maintains the list

of all ServerConnectionHandler objects. One object is created per created connection. The

ServerConnectionHandler objects are runnable and separate threads are used in such object

for reading and writing to input and output streams. The ServerForm is responsible for

starting these threads when it creates a new ServerConnectionHandler object.

Figure 5.5: Class diagram of classes used by the server

The ServerForm implements the interface ServerConnectionHandlerListener, and so accepts

callbacks from its ServerConnectionHandler objects. The purpose of callback is related to

opening the input and output streams, received messages, sent messages and connection

closes normal or abnormally. The ServerForm directly uses a ServerConnectionHandler to

send messages. The ServerForm also has an “Add connection” command, which temporarily

causes a screen transition back to the ServiceDiscoveryList screen to select the next client to

open a connection to.

5.3 Developing the BtoothComm Application

The application was developed using J2ME on Netbeans platform. This section summarized

the Java classes used, how they work and their purpose in the application. The classes are

based on two packages namely the btsppecho and lib.btsppEcho

5.3.1 BtsppEcho Package

BttspEcho package contains the following e java classes:

Java Class Description

5.3.1.1

BtoothComm

BtoothComm class is a MIDlet class which means

“BtoothComm” class is to “appear” on the device screen

and it is the main class for the whole application.

5.3.1.2

MIDletApplication

The MIDletApplication class handles the MIDlet state

model callbacks. This is to manage the user interface for

delegating it to appropriate screens. The MIDlet provides a

central”state model” for the screens, so that each screen

calls back to the MIDlet and the MIDlet displays the

appropriate next screen.

5.3.1.3

MIDletApplicationBackground

To provide canvas background for “Room”. Also to

determine the characteristic for font, width and to interface

with command action

5.3.1.4

MIDletApplicationPreferences

To provide record storage for “setting” option for main

menu which contain font size, language, vibration, tones

and User ID setting.

5.3.1.5

ServiceDiscoveryList

When the MIDlet is run in the server mode, it must first

search for suitable clients to create connections to. This

screen is used to perform device inquiry, service discovery,

and open connections to selected clients. After the

connections are open, the screen map is changed to the

ServerForm and this is done via the callback to the MIDlet

.

5.3.1.6

Locale

To provide language translation for the application.

5.3.2 lib.btsppEcho Package

Java Class Description

5.3.2.1

SettingsList

This is the first screen displayed by the MIDlet. It is used

to make a few settings and then start the MIDlet. The

settings are as follows:

• An option to select either client or server mode

• The inquiry type used to be discoverable by a client,

or when performing discovery by a server

• Use of authentication: true/false

• If authentication is used:

o Use of encryption: true/false

o Use of authorization: true/false

The Start command is used to start the MIDlet in the

appropriate role and using the appropriate settings. This

is done via an appropriate callback to the

MIDletApplication, since it manages the screen

transitions. There is also a Bluetooth Properties

command to examine the system properties related to use

of Bluetooth. For example, a Bluetooth device might

only allow a limited number of other devices to be

connected.

5.3.2.2

TextScreen

This is a simple read-only text screen. It has just one

command (Back), which is used for transition to the next

appropriate user interface screen via an appropriate

MIDletApplication callback. This class deals mainly

with user interface related classes.

5.3.2.3

LogScreen

LogScreen is used to give end users a way to follow the

progress of the device inquiry and service discovery

phases. It is also a helpful debugging aid for

sophisticated end users.

5.3.2.4

Client

To handle connection for client

5.3.2.5

ClientForm

This class is the main screen of the MIDlet when it is run

in client mode. It displays the number of open

connections, status strings as connections are

created/deleted or as messages are sent, and simple text

messages as they are received from a remote server.

5.3.2.6

BT

To provide UUID address for Server

5.3.2.7

ServerForm

This is the main user interface screen of a connected

MIDlet when run in server mode. It is used to receive

messages from a remote client and echo those back to all

connected clients. This screen also shows the number of

connected clients and if one client disconnects, it does

not affect the connectivity between the server and the

other clients.

5.3.2.8

ServerRoom

To retrieve information on any connected client and

manage connection between client and server only

5.3.2.9

ConnectionService

A ConnectionService class is a runnable object that runs

continuously. The class listens for new inbound

connection requests from a remoter server and it uses its

listener to handle the request.

5.3.2.10

ConnectionPacket

To manage data rate during connection between server

and client

5.3.2.11

Reader

To manage connection and data stream when either

server or client receive data.

5.3.2.12

Sender

To manage connection and data stream when either

server or client sending data

5.3.2.13

ClientConnectionHandler

When the MIDlet is run in the client mode, each

connection is represented by a ClientConnectionHandler.

5.3.2.14

ClientConnectionHandlerListener

This interface describes the callbacks of a

ClientConnectionHandler.

5.3.2.15

ServerConnectionHandler

When the MIDlet is run in the server mode, each

connection is represented by a ServerConnectionHandler

5.3.2.16

ServerConnectionHandlerListener

This interface describes the callbacks of a

ServerConnectionHandler

5.3.2.17

ServerConnection

To manage Server Room during active service broadcast.

5.3.2.18

ServerRoomDiscovery

To provide and manage server inquiry service and

retrieve information on status discovered server.

5.3.2.19

ServerRoomDiscoveryListener

To initiate server discovery.

5.3 Building and running in an emulator

All classes are developed and created using a Java editor (Crimson Editor), and build using

Java Wireless Toolkit 2.2 (JTW 2.2). JTW 2.2 is an emulator that will run and simulate the

application in a Bluetooth environment. This process is important for debugging and errors

correction before deploying onto a real mobile device.

5.5 Deploying to a device

After the application has been tested using a simulator, it is now ready to be deploy onto a

mobile device. The transfer is done by sending the required files from the computer to a

mobile device via Bluetooth connection.

5.6 Usage Procedure of BtoothComm Application

Once the application is successfully installed in the mobile device, the steps to use the

BtoothComm are as follows:

5.6.1 Open the BtoothComm application.

5.6.2 Click the Setting option – fill in the User ID and choose alert options.

5.6.3 To become a Server – click Set As Server and fill in the Server name. Server name

should be the same as the name set in User ID.

5.6.4 To become a Client – click search for Server. Once Server appears on screen, select

the server and click Join.

5.6.5 Click the Send Message option to type and transmit messages.

5.6.7 Click the Back to Room option to return to conversation screen.

5.6.8 Click the Disconnect option to terminate the connection with Server and to go out

from the BtoothComm application.

Figure A through Figure I illustrate the usage steps for a client for using the setting, connect

to a server and sending a text message.

Figure A: “Setting” option is selected Figure B: User ID is entered

Figure C: Search for Server is selected Figure D: Active server named “Hubert” found

Figure E: User join server “Hubert” Figure F: User send “Hello There” to Server

Figure G: User send “Hello There” to Server Figure H: Text appear in Client Screen and

appear in Server Screen

Figure I: Text appear in Client Screen and appear in Server Screen

5.7 Testing of BtoothComm Application

Several tests have been conducted on the developed application and these tests include both

simulation and actual hardware. The tests conducted are as follows:

5.7.1 Installation and run tests on different makes and models of mobile devices

The application has been tested through installation and running on 21 different models of

mobile phones equipped with Bluetooth from among the popular brands i.e. Nokia, Sony

Ericsson, Motorolla, HTC and Samsung. Out of these 21, the application was verified to fully

run on 15 devices i.e. 71% success rate. However, we will continue testing the application on

other models of mobile phones from time-to-time and we expect that the success rate to

slightly decrease. This is through testing, we found that the application work perfectly on

most on mobile devices running on Symbian operating system (OS) whereas it does not work

at all on devices running on Windows Mobile OS. At this point of time we are still clueless

on this issue but investigations are ongoing in order to address the problem.

The same testing has also been conducted to the 2 key persons of the selected rural

community. During this session, they have gone through in details on the installation

procedure as well as the steps for using the BtoothComm application. This is necessary when

it comes for them to distribute the application to the other members of the rural community.

We have also receive a very positive instant response from them during the session where

they were also in favour of an application with more specific usage specifically the E-Voting.

5.7.2 Maximum distance between Server and Client

The testing to find the maximum allowable distance and height are conducted for different

two conditions and three different environments as follows:

Environment

Condition 1:

Maximum allowable

range to connect to

server (meter)

Condition 2:

Maximum allowable range

to communicate once

connected ( meter )

Within a building 10.11 23.67

Open field 10.25 18.60

Different level (height) 9.69 16.60

As summarized in the table above, it is shown that the maximum allowable range for a client

to be connected to a server is around half the maximum allowable distance for

communication once the client is connected to the server. Basically, this limitation is due to

the coverage limitation of Bluetooth.

In addressing this issue, we are currently looking into the possibility of scatternet i.e. having

multiple servers and multiple clients running the same application. However, through

readings and initial findings we found that this option is very difficult to be realized. Another

option that we are looking at is having one of the clients as a dummy server to act as a

transponder in order to extend the range of coverage.

5.7.3 Maximum number of user per one server

From the start of the development process, through the literature review particularly on

Bluetooth topic, it is understood that the maximum number of allowable users for any

application to communicate through Bluetooth is 8. In our case, this means 1 server and 7

clients at a time. Through simulation using the JTW 2.2, we have confirmed that the

application is capable to allow maximum 8 users at a time. However, the same was not

achieved through the actual hardware testing. In our latest test, from 10 mobile phones which

previously tested to fully run the application, with 1 set as server we have managed only 5

clients connected to the server at maximum i.e. 6 users at maximum. Up to this point of time,

we have yet to figure out the reason for this to happen. We shall continue with appropriate

testing in order to find out the reason behind this problem and to achieve the maximum 8

users at a time.

5.7.4 Server capabilities

Based on the feedback from project members during our latest meetings, we have identified

the following issue for improvement on the Server:

• In the current version, the Server did not have the capability to reject any clients from

joining the conversation. Instead, at the moment it is the Client who is to decide

whether to approve or not connection with Server. Thus the Server should have this

capability.

• The Server did not have the capability to disconnect/terminate any Client during

conversation. This is necessary if one or more Client(s) are behaving out of order.

Thus the Server should have this capability.

5.7.5 Public testing and survey

In addition to the testing on different makes and models of mobile phone as described in

5.7.1, at the same time we have also conducted a preliminary survey to get the public

response on the developed BtoothComm application by distributing a survey form as attached

in Appendix I. The actual survey form is typed in the Malay language i.e. Malaysia national

language. Since the survey is still at preliminary stage and so far only 15 responses received,

no concrete conclusion can be made yet. However, these early responses have indicated

positive feedbacks on Question 15 to 19 i.e. the main issue of the survey.

5.8 Limitations BtoothComm

Based on the testing conducted as described in 5.7, the following are the limitations identified

for developed BtoothComm application:

5.8.1 BtoothComm application does not necessary be installed and run on every

mobile devices equipped with Bluetooth. It can be installed and run on most

mobile phones running on Symbian OS but not on phones running on

Windows Mobile OS.

5.8.2 The maximum allowable distance for client connection to server is around 10

meters and the maximum allowable range for communication between server

and client once connected is around 23 meters.

5.8.3 Although based on the limitation of communication through Bluetooth for the

maximum number of allowable clients to be connected to a server at a time is

7, but so far through testing BtoothComm only allows maximum of 5 clients

to be connected to a server at a time.

5.8.4 In the current version of BtoothComm, the server does not have the

capabilities to reject any clients from joining the conversation and to

disconnect/terminate any Client during conversation.

5.9 Proposed Environment for Usage of BtoothComm

Due to the main limitation in terms on maximum allowable range for communication and

maximum allowable number of users, the following usage environments are proposed:

5.9.1 Religious class session normally held in the mosque. The teacher can be the

server whereas the students (mostly mature and older people) can be the

clients. Questions can be sent to the teacher throughout the session and not

only during Q&A session.

5.9.2 Communication between few people during a specific function held in the

community hall for not disturbing a speech that is being delivered. This is

applicable especially to the organizing committee members of that particular

event. This would enable them to communicate without interfering with the

ongoing programme.

5.9.3 Communication between the committee members during a meeting held in a

meeting room. This is to avoid distraction to the person giving a speech.

5.9.4 Discussion and study group held in a library. The users can opt for the

vibration mode or even silent mode that available at the setting page.

5.9.5 Other daily activities that the rural community members feel suitable for usage

of this application.

6. CONCLUSIONS

In general, the collaboration work between the Malaysians and Japanese team members went

according to plan where the Malaysian team focuses more on developing the application

whereas the Japanese team has given valuable feedback and guidance in achieving the

objective of the project. All the set milestones are achieved satisfactorily although few of

these milestones have taken more time than expected for completion based on the initial plan.

In particular, specific objective of developing an application using Java programming

language for mobile devices (J2ME) that enables users to exchange text messages at real time

basis similar to a combination of short message service (SMS) and chat through Bluetooth

frequency has been achieved. The application called as BtoothComm has been tested on 21

different models of mobile phones where the success rate on installation and running of

software is so far 71%. Positive responses and feedbacks are received from the

representatives of the rural community during the training session as well as from the general

public based on the preliminary survey conducted. This gives the impression that the usage of

such application is capable of reducing the knowledge gap in digital technologies and ICT

between urban and rural community.

However, the several tests conducted have revealed some significant limitations of the

current version of the developed application specifically in terms of the maximum allowable

range of communication, maximum allowable number of users at a time, compatibility issue

for software installation on certain models of mobile phones and some capability limitation of

the server midlet. More times are required in order to implement the enhancement and

improvement on the current version of the application. It also suggested that a more specific

usage application be developed within the Bluetooth limitation that suits certain activities of

the community as to achieve the main goal of the project that is to reduce the knowledge

divide.

Although, the basic application is successfully developed, more works and time are needed in

order to come out with applications that capable to serve the community better. Thus, we

hope to get continuous support from the Ministry, APT and other bodies to enable us to

continue working on this project and to finally achieve the main goal.

APPENDIX I Response Survey Form:

1. You are a male/female age ……, come from urban/sun-urban/rural area and currently live in

urban/sun-urban/rural area.

2. Is there a personal computer(PC) at your parents/hometown residence?

a. Yes b. No

3. If Yes, is the PC connected to the internet?

a. Yes b. No

4. If Yes, choose one from the following for the type of the internet service.

a. dial-up b. broadband

5. Do you own a mobile phone?

a. Yes b. No

6. Does your parent own a mobile phone?

a. Yes b. No

7. Does your mobile phone equipped with Bluetooth?

a. Yes b. No

8. If Yes, please state the brand and model of your mobile phone: …………………………………

9. Have you ever used an “Instant Messaging” and/or a ”Chatting” applications prior to this moment?

a. Yes b. No

10. If Yes, based on your opinion do you find the BtoothComm application similar to the commonly

available Instant Messaging and Chatting application mentioned earlier?

a. Yes b. No

11. Are you familiar with the usage of short message service (SMS) on mobile phones?

a. Yes b. No

12. If Yes, based on your opinion do you find the method of sending messages through the BtoothComm

application is similar to the method used in sending messages through the SMS service?

a. Yes b. No

13. Is the BtoothComm application installable on your mobile phone?

a. Yes b. No

14. Can the BtoothComm application fully run on your mobile phone?

a. Yes b. No

15. Based on your opinion, an application that enables you to exchange messages through mobile phones at

no cost (free of charge) such as this BtoothComm application is:

a. Very interesting b. Interesting c. Fair d. Not interesting

16. Based on your opinion, a free application such as this BtoothComm is capable to encourage and

motivate you to learn more on the latest wireless mobile technologies.

a. Yes b. No

17. Based on your opinion, this BtoothComm Application can be used in one of the activities

suggested/proposed in (B).

a. Yes b. No

18. Based on your opinion, this BtoothComm application is capable to reducing the digital and ICT

knowledge divide between those who live in the city and those who live in the rural area.

a. Yes b. No

19. If a much more specific usage application such as E-Voting and /or Meal Ordering System for

restaurant, this is to you:

a. Very interesting b. Interesting c. Fair d. Not interesting

apt hrd programme for exchange of ict … · mahathir said (telekom malaysia berhad) syahrifendi...

Documents