xây dựng ứng dụng và tìm kiếm trên bản đồ cho điện thoại di động hỗ trợ java

Lời mở đầu
Sau một thời gian tìm hiểu và thực hiện, luận văn “Xây dựng bản đồ cho di động
kết hợp định vị” đã cơ bản hoàn thành. Để đạt được kết quả này chúng tôi đã rất cố
gắng đồng thời cũng nhận được rất nhiều sự giúp đỡ của các thầy cô, và bạn bè.
Xin cảm ơn các thầy cô trong khoa Công nghệ thông tin, đặc biệt là thầy Trần
Minh Văn đã tận tình hướng dẫn em thực hiện luận văn này.
Luận văn hoàn thành với một số kết quả nhất định, tuy nhiên vẫn không tránh
khỏi sai sót. Rất mong nhận được ý kiến đóng góp từ các thầy cô và các bạn để chương
trình có thể hoàn thiện hơn.
Nha Trang, tháng 6 năm 2010.


Chương 1: GIỚI THIỆU
1.1. Sơ lược về tình hình viễn thông di động ở Việt Nam:
Mặc dù chịu ảnh hưởng của cuộc suy thoái kinh tế thế giới nhưng trong 6 tháng
đầu năm 2010, thị trường viễn thông di động của Việt Nam vẫn hết sức náo nhiệt.
Đầu tiên là sự xuất hiện của công nghệ 3G với nhiều tính năng nổi trội đã mở ra 1
trào lưu di động mới: nhanh hơn, mạnh hơn và đa dạng hơn. Các dòng sản phẩm hỗ trợ
công nghệ này được các nhà sản xuất đưa ra đều đặn với mức giá ngày càng cạnh
tranh. Trên thực tế, 3G tuy chưa làm khách hàng hài lòng nhưng theo các chuyên gia,
thị phần của nhóm thiết bị này sẽ tiếp tục tăng trong thời gian tới.
Cũng trong năm nay, chiếc điện thoại đình đám iPhone chính thức được cung cấp
tại Việt Nam sau đó là sự xuất hiện của một loạt các hệ điều hành mới như iPhone 4.0,
Android, Window mobile 7 cùng với một số lượng sản phẩm hỗ trợ không nhỏ làm cho
thị trường theo đó cũng nóng lên từng ngày một.
Trước làn sóng sôi động đó, người tiêu dùng Việt Nam thật khó có thể đứng yên.
Tỷ lệ người sử dụng điện thoại ở Việt Nam còn cao hơn cả Trung Quốc và Ấn Độ (theo
báo cáo của công ty nghiên cứu thị trường Nielsen năm 2009), đa phần trong độ tuổi
thanh thiếu niên. Tuy nhiên, trong năm 2010, thị trường đang dần bão hòa. Theo ước
tính, số người còn có thể sử dụng điện thoại ở Việt Nam vào khoảng 15 – 20 triệu
khách hàng và “miếng bánh” này không đủ cho cả 6 nhà cung cấp. Họ không còn chạy

đua để tăng số lượng thuê bao mà chuyển sang chiến lược giữ chân khách hàng bằng
chất lượng dịch vụ.
1.2. Nhu cầu phát triễn phần mềm trên thiết bị di động:
Trong vài năm gần đây, hoạt động sản xuất phần mềm cho điện thoại diễn ra khá
mạnh mẽ. Theo dự báo, doanh thu phần mềm cho điện thoại sẽ đạt 16,6 tỷ USD vào
năm 2013. Các hãng điện thoại, các nhà cung cấp ngày càng tập trung nhiều vào phát
triễn kho ứng dụng của họ: OviStore(Nokia), Apple App Store, Microsoft MarketPlace,
Fstore(FPT), Mstore(Vietel)…Việc đầu tư này góp phần làm tăng tính cạnh tranh của
họ trên thị trường điện thoại thông minh được đánh giá là rất khả quan trong thời gian
tới. Thực tế cho thấy, sự thành công của iPhone ngoài vấn đề công nghệ và thời trang
còn có sự hỗ trợ mạnh của một kho ứng dụng cực lớn với hơn 100000 ứng dụng.
Người sử dụng sẽ chọn nền tảng có nhiều ứng dụng nhất mặc dù họ chỉ sử dụng một
phần nhỏ trong số đó. Ngày nay, mọi chuyện đã dễ dàng hơn với một chiếc điện thoại.
1.3. Mục tiêu của đề tài:
Bản đồ cho di động là đề tài không mới, tuy nhiên các ứng dụng tương đương
trên thị trường chủ yếu phải kết nối Internet và chỉ hỗ trợ ở một số thành phố lớn. Nhận
thấy việc xây dựng một bản đồ số cho một thành phố du lịch như Nha Trang cũng hết
sức cần thiết nên em chọn thực hiện đề tài này.
Đề tài nhằm xây dựng ứng dụng bản đồ dùng cho điện thoại có hỗ trợ J2ME với
một số chức năng chính như:
- Xem, di chuyển , phóng to, thu nhỏ bản đồ.
- Tìm đường theo tên.
- Tìm một địa điểm trên bản đồ.
- Xác định lộ trình ngắn nhất giữa hai điểm.
- Định vị người dùng.
Chương 2: TỔNG QUAN VỀ LẬP TRÌNH
DI ĐỘNG
Được giới thiệu lần đầu vào năm 1995, ngày nay mục iêu Java nhắm đến cũng đã
thay đổi khá nhiều. Java hiện nay không chỉ nhắm đến họ máy tính để bàn đơn thuần.
Hai năm sau ngày đầu được ra mắt, một phiên bản Java mới là J2EE (Java 2 Enterprise

Edition) đã được giới thiệu nhắm tới việc phát triển các ứng dụng có qui mô lớn hơn.
Phiên bản mới nhất được thêm vào dòng ngôn ngữ Java là J2ME (Java 2 Micro
Edition). J2ME nhắm đến việc phát triễn ứng dụng cho các thiết bị “nhỏ” có bộ nhớ,
khả năng hiển thị và xử lý hạn chế như:đầu giải mã kỹ thuật số TV set-top boxes, điện
thoại di động…
6.1. Các thành phần của J2me:
Hình 1.
1

T
ổ
ng quan

6.1.1. Configuration:
Để đáp ứng cho nhiề
u ch
Configuration. Khái niệ
m Configuration có m
chính xác hơn, mộ
t Configuration qui đ
của ngôn ngữ
Java mà máy
Việ
c phân chia thành nh
bộ nhớ, năng lục hiển thị,
năng l
Như chúng ta biết, các thiế
t b
phần cúng. Với những thiế
t b

trợ vào máy ảo trên thiết b
ị
những thiết bị có khả
năng cao hơn, chúng ta s
máy ảo giúp cho công việ
c l
thành nhiề
u Configuration là
Configuration khác nhau:
-
CDC (Connected Device Configuration)
Hình 1. 2 Các thành phần của J2me
u ch
ủng loại thiết bị khác nhau, Sun đã
đưa ra khái ni
m Configuration có m
ối liên hệ chặt chẽ vớ
i máy
t Configuration qui đ
ịnh những thành phần và nh
ữ
Java mà máy
ảo phải hỗ trợ cho configuration đó.
c phân chia thành nh
ững Configuration khác nhau chủ yế
u d
,
năng lực xử lý và khả năng kết nối mạ
ng c
t b

ị di động rất khác nhau về nguồ
n tài nguyên, v
t b
ị có năng lực hạn chế, nế
u ta đưa quá nhi
ị
đó sẽ gây chậm hệ thống và dư thừ
a không c
năng cao hơn, chúng ta s
ẽ đưa thêm nhiề
u thư vi
c l
ập trình của các nhà phát triể
n. Do đó , nhu c
u Configuration là
việc cần thiết. Hiện nay Sun đ
ã
CDC (Connected Device Configuration)


đưa ra khái ni
ệm
i máy
ảo Java. Nói
ữ
ng thư viện gốc
u d
ựa vào khả năng
ng c
ủa các thiết bị.

n tài nguyên, v
ề khả năng
u ta đưa quá nhi
ều thư viện hỗ
a không c
ần thiết. Với
u thư vi
ện hỗ trợ vào
n. Do đó , nhu c
ầu phân chia
ã
đưa ra 2 loại
§ 512 kb (minimum) bộ nhớ để chạy Java
§ 256 kb (minimum) bộ nhớ cấp phát động.
§ Kết nối mạng liên tục, băng thông rộng.
- CLDC (Connected Limited Device Configuration) :
§ 128 kb (minimum) bộ nhớ để chạy Java
§ 32 kb (minimum) bộ nhớ cấp phát động.
§ Giao diện người dùng hạn chế.
§ Năng lượng tiêu tốn it (chủ yếu dùng pin).
§ Kết nối mạng Wireless, chậm.
Việc phân chia này thực chất cũng chỉ mang tính tương đối. Công nghệ hiện nay
đang phát triễn khá nhanh và điều này càng làm cho ranh giới giữa các loại
Configuration trở nên không rõ ràng.
6.1.2. Profile:
Configuration thực ra chỉ cung cấp 1 số rất ít các lớp và người phát triển ứng
dụng hầu như không thể chỉ làm việc đơn thuần với các Configuration này. Vì lý do
này Sun đã linh hoạt và đưa thêm một khái niệm mới nằm ở tầng trên của
Configuration, đó là Profile.
Ta có thể xem Profile là mộ mở rộng của khái niệm Configuration. Profile định

nghĩa các thư viện giúp lập trình viên phát triển ứng dụng cho một dạng thiết bị nào đó.
Ví dụ Mobile Information Device Profile (MIDP) định nghĩa các hàm API cho các
thành phần giao diện nhập liệu và xử lý sự kiện, lưu trữ, kết nối mạng và xử lý thời
gian,… phù hợp với màn hình hiển thị và khả năng xử lý của các thiết bị di động.
Profile MIDP được định nghĩa trên nền tảng của CLDC. Ngoài ra chúng ta còn một số
Profile tiêu biểu khác như:
- PDA Profile: tương tự như MIDP, nhưng với thị trường là các máy PDA
với màn hình và bộ nhớ lớn hơn.
- Foundation Profile: cho phép mở rộng các tính năng của CDC với phần
lớn các thư viện của bộ Core Java2 1.3.
- Ngoài ra còn có Personal Basis Profile, Personal Profile, RMI Profile,
Game Profile.
Báo cáo chỉ đề cập đến Profile MIDP và các thư viện liên quan để phục vụ cho
việc viết ứng dụng trên điện thoại di động.
6.1.3. Máy ảo java:
Như chúng ta đã biết, một chương trình Java sẽ được biên dịch thành mã trung
gian sau đó chính máy ảo Java sẽ biên dịch phần mã này sang mã máy để thực thi. Máy
ảo Java sẽ chịu trách nhiệm việc cung cấp tính năng bảo mật, cấp phát và thu hồi bộ
nhớ và quản lý việc điều phối các tiến trình.
Với CDC, máy ảo Java có cùng các đặc tính như J2SE. Tuy nhiên, với CLDC,
Sun đã phát triển riêng một dạng máy ảo chuyên biệt được gọi là K Virtual Machine,
gọi tắt là KVM. Chính những hạn chế về tài nguyên của các thiết bị di động đã đề ra
nhu cầu về sự ra đời của KVM:
- Chỉ cần 40-80 kb bộ nhớ
- Chỉ đòi hỏi 20-40 kb bộ nhớ động (heap)
- Có thể chạy với bộ vi xử lý 16-bit và xung nhịp 25MHz
6.2. CLDC và MIDP:
6.2.1. CLDC:
6.2.1.1. Yêu cầu phần cứng:
- 128 kilobytes để chạy JVM và các thư viện của CLDC. Không phân

biệt loại bộ nhớ sử dụng (Rom, Flash,…), bộ nhớ của thiết bị phải bảo
lưu được nội dung lâu dài, ngay cả khi ngắt điện. Bộ nhớ này thường
được gọi là nonvolatile memory.
- 32 kilobytes bộ nhớ trống để cấp phát các đối tượng (objects). Bộ
nhớ này thường được gọi là volatile memory (hay là “heap”).
6.2.1.2. Yêu cầu phần mềm:
CLDC có yêu cầu tối thiểu về mặt phần mềm. Hệ điều hành phải tương thích với
JVM và có chức năng quản lý các ứng dụng Java, bao gồm:
- Cho phép chọn và kích hoạt ứng dụng.
- Cho phép gỡ bỏ ứng dụng khỏi thiết bị.
6.2.2. MIDP:
6.2.2.1. Yêu cầu phần cứng:
- Màn hình ít nhất phải có 96 x 54 pixels.
- Có ít nhất một thiết bị nhập liệu: bàn phím hoặc màn hình cảm ứng.
- Có ít nhất 128 kilobytes bộ nhớ non-volatile để chạy các thành phần
của MID.
- Có ít nhất 8 kilobytes bộ nhớ non-volatile để lưu các cấu hình chương
trình và dữ liệu.
- Có ít nhất 32 kilobytes để chạy Java.
- Có kết nối không dây (wireless network).
6.2.2.2. Yêu cầu phần mêm:
- Mặc dù hệ điều hành của từng thiết bị có thể khác nhau nhưng phải
đáp ứng được các yêu cầu tối thiểu sau:
- Hệ điều hành phải hỗ trợ việc xử lý ngắt, xử lý exception và hỗ trợ xử
lý đồ họa bitmap để xuất dữ liệu ra màn hình
- Hệ điều hành phải nhận được tín hiệu nhập liệu (input) và chuyển dữ
liệu đó cho máy ảo Java
- Hệ điều hành phải hỗ trợ việc đọc/ghi vào bộ nhớ non-volatile. Không
đòi hỏi hệ điều hành phải định nghĩa file system nhưng phải cho phép
ghi dữ liệu dạng persistent (không bị mất đi khi tắt máy, ngắt điện).

- Phải hỗ trợ truy xuất mạng, đặc biệt phải có tính năng đọc/ghi dữ liệu
thông qua mạng không dây (wireless network).
6.2.3. MIDlet Suite:
Ta gọi chương trình Java chạy trên thiết bị di động là một MIDlet. MIDlet sẽ sử
dụng các lớp cung cấp bởi CLDC và MIDP. Mộ MIDlet Suite (một bộ MIDlet) chứa
một hay nhiều ứng dụng MIDlet được nên chung trong một file JAR (Java Archive).

Hình 2. 3 Jar file & Jad file
6.2.3.1. File JAR:
Ngoài các file class và resource, trong file JAR còn có một tập tin được gọi là
manifest. Đây là tập tin mô tả nội dung toàn file JAR. Tập tin này có tên manifest.mf
và bản thân nó cũng được nén trong file JAR. Manifest.mf có các thuộc tính quan trọng
sau:
Thuộc tính Ý nghĩa Bắt buộc
MIDlet-Name
Tên của bộ MIDlet Có
MIDlet-Version
Số phiên bản Có
MIDlet-Vendor
Tác giả Có
MIDlet-<n>
Tham chiếu đến từng
MIDlet trong file JAR, mỗi
MIDlet cần một mẫu tin
này
Có
MicroEdition-Profile
Tên profile cần để chạy
MIDlet này, thường là
MIDP 1.0 hoặc MIDP 2.0

Có
MicroEdition Cnfiguration
Configuration cần để chạy
MIDlet (thường là CLDC
1.0)
Có
MIDlet-Icon
File icon (.pgn) của bộ
MIDlet
Không
MIDlet-Description
Mô tả bộ MIDlet Không
MIDlet-Info-URL
Địa chỉ trang web nhà phát
triễn MIDlet
Không
Một ví dụ đơn giản của file Manifest:
- MIDlet-1: HelloMIDlet, , hello.HelloMIDlet
- MIDlet-Vendor: Vendor
- MIDlet-Name: MobileApplication1
- MIDlet-Version: 1.0
- MicroEdition-Configuration: CLDC-1.1
- MicroEdition-Profile: MIDP-2.1
6.2.3.2. File JAD:
Bên cạnh file JAR, một bộ ứng dụng MIDlet còn có thêm file JAD (.jad) để cung
cấp thông tin về các MIDlet trong file JAR. Việc đặt ra file JAD có một só mục đích
sau:
- Cung cấp thông tin về nội dung file Jar. Từ thông tin này, bộ quản lý ứng
dụng trên thiết bị mới quyết định ứng dụng này có thích hợp để chạy trên
thiết bị hay không.

- Cung cấp các tham số dùng cho MIDlet để tránh thay đổi file JAR. File
JAR chứa mã ứng dụng nên cần tránh bị thay đổi.
Danh sách các thuộc tính trong file JAD:
Thuộc tính Ý nghĩa Bắt buộc
MIDlet-Name
Tên của bộ MIDlet Có
MIDlet-Version
Số phiên bản Có
MIDlet-Vendor
Tác giả Có
MIDlet-<n>
Tham chiếu đên từng MIDlet trong
file JAR, mỗi một MIDlet cần một
mẫu tin này.
Có
MIDlet-Jar-URL
Địa chỉ URL của file JAR Có
MIDlet-Jar-Size
Kích thước file JAR tính bằng byte Có
MIDlet-Data-Size
Kích thước tối thiểu tính bằng byte
để ghi các dữ liệu của chương trình
(persitent data)
Không
MIDlet-Description

Mô tả MIDlet Không
MIDlet-Delete-
Confirm
Thông báo nhắc nhở khi xóa

MIDlet
Không
MIDlet-Install-
Notify
URL nhận thông báo về quá trình
cài đặt
Không
Một ví dụ đơn giản về file JAD:
- MIDlet-1: HelloMIDlet, , hello.HelloMIDlet
- MIDlet-Jar-Size: 1358095
- MIDlet-Jar-URL: MobileApplication1.jar
- MIDlet-Name: MobileApplication1
- MIDlet-Vendor: Vendor
- MIDlet-Version: 1.0
- MicroEdition-Configuration: CLDC-1.1
- MicroEdition-Profile: MIDP-2.1


Chương 3: CÁC VẤN ĐỀ CƠ BẢN CỦA
CHƯƠNG TRÌNH MIDlet
3.1. Vòng đời của các ứng dụng MIDlet:
Một chương trình MIDlet khi được nạp và thiết bị có những trạng thái sau:
- Paused: Một chương trình MIDlet sẽ được đưa vào trạng thái paused sau khi
thực hiện phương thức khởi tạo (constructor) và trước khi được chương trình
quản lý ứng dụng (application manager) trên thiết bị gọi thực thi. Trong quá
trình hoạt động, chương trình MIDlet cũng có thể bị đưa trở lại trạng thái
paused bởi thiết bị (khi cần trả lời cuộc gọi đến …) hoặc bởi chính chương
trình MIDlet.
- Active: Chương trình MIDlet đang thực thi.
- Destroyed: Chương trình MIDlet đã giải phóng tất cả tài nguyên và đã được

tắt bởi trình quản lý ứng dụng trên thiết bị.

Hình 3. 1 Vòng đời chương trình MIDlet
3.2. Xây dựng ứng dụng MIDlet:
Một ứng dụng MIDlet phải kế thừa lớp MIDlet. Chúng ta phải khai báo ba hàm:
startApp(), pauseApp(), va2 destroyApp(). Ta có ví dụ:
public class HelloWorld extends Midlet {
public HelloWorld() {}
public startApp() {}
public void pauseApp() {}
public void destroyApp(boolean unconditional) {}
}
Các hàm thường dùng trong lớp MIDlet:
Phương thức Chức năng
abstract void destroyApp
Hàm được gọi khi tắt MIDlet. Được dùng
(boolean unconditional)
để giải phóng tài nguyên.
abstract void pauseApp ()
Hàm được gọi để giải phóng tài nguyên
trước khi tạm dừng chương trình.
abstract void startApp ()
Được gọi khi MIDlet sắp được đưa vào
trạng thái thực thi (active state).
final void notifyDestroyed ()
Báo cho Application manager biết
chương trình đã giải phóng tài nguyên và
cần được tắt.
final void notifyPause()
Báo cho Application manager biết

chương trình đã giải phóng tài nguyên và
muốn vào trạng thái tạm dừng.
final void resumeRequest()
Báo cho application manager MIDlet cần
đưa vào trạng thái hoạt động trở lại. (Sau
đó application manager sẽ gọi startApp).
final string getAppProperty
(String key)
Lấy các thông số của chương trình (từ file
JAD và file manifest).

3.3. Lớp MIDlet:
Như đã đề cập, mọi ứng dụng của ta đều kế thừa từ lớp MIDlet. Lơp này được
khai báo như sau:
public abstract class MIDlet {
protected abstract void startApp()throws MIDletStateChangeException;
protected abstract void pauseApp();
protected abstract void destroyApp(boolean unconditional) throws
MIDletStateChangeException;
}
Các hàm thường dùng trong lớp MIDlet:
Phương thức Chức năng
abstract void destroyApp
(boolean unconditional)
Hàm được gọi khi tắt MIDlet. Được dùng
để giải phóng tài nguyên.
abstract void pauseApp ()
Hàm được gọi để giải phóng tài nguyên
trước khi tạm dừng chương trình.
abstract void startApp ()

Được gọi khi MIDlet sắp được đưa vào
trạng thái thực thi (active state).
final void notifyDestroyed ()
Báo cho Application manager biết
chương trình đã giải phóng tài nguyên và
cần được tắt.
final void notifyPause()
Báo cho Application manager biết
chương trình đã giải phóng tài nguyên và
muốn vào trạng thái tạm dừng.
final void resumeRequest()
Báo cho application manager MIDlet cần
đưa vào trạng thái hoạt động trở lại. (Sau
đó application manager sẽ gọi startApp).
final string getAppProperty
(String key)
Lấy các thông số của chương trình (từ file
JAD và file manifest).

3.4. Quá trình nạp và thoát của MIDlet:
3.4.1. Quá trình nạp:
- User chọn kích hoạt ứng dụng MIDlet
- Application manager khởi tạo các biến, gọi phương thức khởi tạo.
- Ứng dụng MIDlet sau khi được nạp vào bộ nhớ sẽ được đưa vào trạng thái
paused (nhưng hàm pauseApp() sẽ không được gọi).
- Application manager gọi hàm startApp(). Thực chất hàm startApp() sẽ được
gọi mỗi khi ứng dụng được đưa vào trạng thái thực thi (active); khi ta tạm
ngưng ứng dụng và có nhu cầu kích hoạt trở lại hàm này cũng được gọi.
3.4.2. Quá trình thoát:
- User chọn thoát chương trình

- Hàm destroyApp() được gọi, hàm này phải bảo đảm việc giải phóng tài
nguyên.
- Hàm notifyDestroyed() được gọi để báo cho application manager ứng dụng
đã giải phóng hết tài nguyên và sẵn sàng bị tắt.
3.5. Display và Displayable:
3.5.1. Display:
Lớp Display đảm nhiệm việc xuất dữ liệu ra màn hình.
Môt số phương thức quan trọng:
Phương thức
Chức năng
static Display getDisplay (MIDlet m)
Lấy đối tượng Display của MIDlet
Displayable getCurrent ()
Lấy đối tượng Displayable hiện
thời
void setCurrent (Alert alert,
Displayable nextDisplayable)
void setCurrent (Displayable
nextDisplayable)
Thiết lập đối tượng Displayable
hiển thị lên màn hình
boolean isColor ()
Cho biết thiết bị có hỗ trợ màu hay
không
int numColor ()
Có bao nhiêu màu được hỗ trợ
Một MIDlet sẽ có một và chỉ một đối tượng Display để điều khiển việc thể hiện
dữ liệu. Đối tượng Display không có phương thức khởi tạo mà được khởi tạo trực tiếp
từ phương thức static của lớp.
public class HelloMIDlet extends MIDlet {

private Display display; // đối tượng display cho MIDlet

public HelloMIDlet() {
display = Display.getDisplay(this);
}
public void startApp() {
TextBox t = new TextBox("Hello", "Hello, World!", 256, 0); // hàm khởi tạo
display.setCurrent(t);
}
public void pauseApp() {}
public void destroyApp(boolean unconditional) {}
}

Hình 3. 2 Hiển thị textBox lên màn hình
3.5.2. Displayable:
Như đã đề cập, một ứng dụng MIDlet chỉ có một đối tượng Display duy nhất và
đối tượng Display này dùng để thể hiện các đối tượng Displayable lên màn hình.
Như tên của lớp Displayable cho chúng ta thấy, đây là các đối tượng có khả năng
hiển thị thông tin lên màn hình thiết bị. Lớp Displayable bao gồm 2 lớp con là lớp
Screen và lớp Canvas. Cụ thể chúng được định nghĩa như sau:
- abstract public class Displayable;
- public abstract class Canvas extends Displayable;
- public abstract class Screen extends Displayable;
Lớp Screen còn được chia thành những lớp con nhỏ hơn như: TextBox, List,
Form và Alert. Đây là những lớp giao diện cấp cao (vì phần lớn các công việc thể hiện
của các lớp này đã được cài đặt sẵn). Các đối tượng của lớp Canvas được gọi là những
đối tượng đồ họa cấp thấp, các lớp này cho phép chúng ta xử lý các giao tác đồ họa ở
tầng dưới, xử lý màu sắc và chủ yếu dùng trong quá trình viết games.
Các hàm chính của lớp Displayable:
Phương thức

Chức năng
void addCommand (Command
cmd)
Thêm 1 đối tượng Command vào
đối tượng Displayable
void removeCommand (Command
cmd)
Xóa đối tượng Command
void setCommandListener
(CommandListener l)
Đặt bộ lắng nghe cho đối tượng
Displayable
boolean isShown ()
Kiểm tra đối tượng Displayable có
được thể hiện trên thiết bị hay
không
3.6. Quản lý sự kiện (event):
Quá trình xử lý các sự kiện phát sinh bao gồm 3 quá trình cơ bản:
- Phần cứng (thiết bị di động) phải cảm nhận được khi có một sự kiện phát
sinh: người dùng ấn một phím, một cable được cắm vào hay rút ra.
- Phần mềm trên thiết bị (hệ điều hành) phải nhận biết được có sự kiện
phát sinh
- Hệ điều hành chuyển thông tin về sự kiện cho ứng dụng, bắt đầu từ đây là
công việc của những lập trình viên J2ME. Tùy theo các thông tin về sự
kiện mà chúng ta phải đưa ra các giải pháp thích hợp
3.6.1. Command & CommandListener:
Ta định nghĩa Command là một đối tượng giữ thông tin về một sự kiện (Event).
Nói một cách đơn giản nhất thì command như một nút ấn (button) trên ứng dụng di
động, khi ta chọn nút này thì sẽ phát sinh một sự kiện tương ứng.
Việc xem một Command tương ứng với một nút ấn trên thiết bị là một quan niệm

nhằm đơn giản hóa vấn đề nhưng không hoàn toàn chính xác. Nếu chúng ta xem xét
các hạn chế về kích thước về màn hình và số lượng nút ấn có trên thiết bị thì vấn đề sẽ
trở nên phức tạp hơn, có những form số lượng command có thể nhiều hơn số nút ấn
chức năng trên thiết bị, lúc này các command được tổ chức theo dạng menu.

Hình 3. 3 Command

Hình 3. 4 Menu command
3.6.2. Item & ItemStateListener:
Sự kiện (event) không chỉ được phát sinh thông qua kích hoạt commands mà còn
có thể được phát sinh thông qua các items. Một item là một bộ phận có thể gắn kèm lên
trên các form. ChoiceGroup, DateField, Gauge và TextField là các dạng khác nhau của
Item và mỗi dạng đều có thể phát sinh các sự kiện. Để xử lý được các sự kiện phát sinh
ta phải cài đặt một Listener (ở đây là ItemStateListener).
Khi có một thay đổi trên Item (ví dụ như ta chọn một mục trong ChoiceGroup
hay thay đổi dữ liệu của một DateField) thì đối tượng listener sẽ được thông báo có
một sự kiện phát sinh cùng các thông tin về sự kiện này. Sự kiện này sẽ kích hoạt hàm
itemStateChanged() được chúng ta cài đặt.
Hiện tại MIDP hỗ trợ các loại Items sau: ChoiceGroup, DateField, Gauge,
ImageItem, StringItem và TextField. Ở đây có một ngoại lệ là hai loại StringItem và
ImageItem không hỗ trợ phát sinh sự kiện mặc dù chúng là lớp con của lớp Item.
Chúng ta cài đặt một listener trong lớp Form, khi một Item phát sinh sẽ kích hoạt hàm
itemStateChanged(), tuy nhiên không phải khi chúng ta thay đổi giá trị nhiều items
cùng lúc thì itemStateChanged() sẽ được gọi đủ bấy nhiêu lần. Ở đây có một luật được
đề ra:
Nếu một Item bị thay đổi, hàm itemStateChanged() phải được gọi đối với Item
này trước khi những thay đổi trên những Item sau đó được nhận biết.
Nếu chính bản thân MIDlet thay đổi giá trị một Item (giả sử chúng ta dùng mã
lệnh để thay đổi chứ không phải do người dùng), hàm itemStateChanged() không được
gọi.

Nếu thiết bị nhận biết được người dùng chuyển từ Item này sang Item khác
(chuyển focus) thì hàm itemStateChanged() phải được gọi trước khi chuyển sang Item
kế tiếp.
Các hàm quan trọng khi sử dụng Item:
Phương thức
Chức năng
String getLabel ()
Lấy nhãn của Item
void setLabel (String label)
Đặt nhãn cho Item
void itemStateChanged (Item item)

Được gọi khi giá trị item thay đổi



Chương 4: ĐỊNH VỊ TRÊN DI ĐỘNG
4.1. Giới thiệu:
Điện thoại di động và PDA là các thiết bị có tính cá nhân rất cao. Không như máy
tính cá nhân, điện thoại di động có thể được đem theo ở khắp mọi nơi, cho phép chúng
ta sử dụng các dịch vụ ngay cả khi đang di chuyển. Từ đó, các loại hình dịch vụ ngày
ngay không còn gói gọn trên bàn làm việc nữa.
Có nhiều phương pháp khác nhau dùng định vị các thiết bị di động. Tuy nhiên,
mục đích của việc định vị này nhằm phục vụ cho việc phát triển loại dịch vụ quan
trọng nhất của Internet di động: Các dịch vụ dựa trên định vị địa điểm (Location-based
services). Phạm vi báo cáo chỉ đề cập đến 2 công nghệ định vị phổ biến nhất là GPS và
Cell-ID.
4.2. Các dịch vụ dựa trên địa điểm(Location-based services):
Location-based services (LBS) trả lời 3 câu hỏi: Tôi đang ở đâu? Xung quanh tôi
có gì? Làm sao tôi đến đó? Họ xác định vị trí của người dùng bằng cách sử dụng một

số các công nghệ xác định vị trí, sau đó sử dụng vị trí này và một số các thông tin khác
để cung cấp các ứng dụng và các dịch vụ đến cá nhân từng người dùng. Ví dụ:
- Dịch vụ gọi khẩn cấp 911 xác định vị trí người gọi một cách tự động nếu
cuộc gọi được thực hiện bằng điện thoại di động. Một dịch vụ rất hữu ích
cho những người không thạo về địa phương họ đang ở.
- Dịch vụ tư vấn giao thông và chỉ đường.
- Dịch vụ kết hợp địa điểm và các thông tin cá nhân giúp người dùng tìm
kiếm vị trí các quán ăn, khách sạn, máy ATM, trường học…
- Cung cấp các thông tin tiếp thị khi người dùng đang ở trong một khu vực
địa lý cụ thể nào đó.
LBS gồm 5 thành phần cơ bản:
- Phần mềm ứng dụng của nhà cung cấp dịch vụ.
- Mạng điện thoại di động để truyền dữ liệu và yêu cầu dịch vụ
- Nhà cung cấp nội dung để cung cấp người dùng cuối các thông tin địa lý
cụ thể và có giá trị.
- Một thành phần định vị.
- Người sử dụng thiết bị di động.
Theo luật, LBS phải cung cấp dựa trên sự cho phép. Điều này có nghĩa là người
dùng phải lựa chọn vào dịch vụ và sử dụng nó. Trong phần lớn các trường hợp người
dùng phải cài đặt ứng dụng LBS và đồng ý cho dịch vụ biết được vị trí của thiết bị.
4.3. Các công nghệ:
4.3.1. Cell-ID(Cell site Identification):
Cell-ID được sử dụng trong mạng GSM, GPRS và WCDMA, đây là cách xác
định vị trí thuê bao đơn giản nhất. Phương pháp này yêu cầu mạng xác định vị trí của
BTS (Base Transceiver Station - trạm phát sóng) mà MS (Mobile Station - máy thu
sóng, vd: moblie, ) đang trực thuộc. Vị trí của MS cũng chính là vị trí của BTS đó.
Tuy nhiên, do MS có thể ở mọi vị trí bất kỳ trong cell (được hiểu như phạm vi trạm
phát sóng đó bao quát) nên độ chính xác của phương pháp này phụ thuộc vào kích cỡ
cell. Nếu MS thuộc vùng đô thị, mật độ đông thì kích cỡ cỡ cell bé nên độ chính xác
cao hơn, vùng ngoại ô kích cỡ cell lớn hơn nhiều nên sai lệch về vị trí có thể lên tới

chục km.