Lập trình trò chơi lines cho điện thoại trên J2ME

Mục lục
LấI N I ĐầU...................................................................2
CHơNG I...........................................................................4
TặNG QUAN Về J2ME..................................................4
1.1 GII THIệU Về JAVA V CôNG NGHệ J2ME

4

1.2 KIếN TRểC CẹA J2ME

9

1.3 ĐNG GI V TRIểN KHAI ỉNG DễNG

11

1.4 TẩI U Mã CHơNG TRìNH V GIảM KíCH THC ỉNG DễNG

13

2.1 MIDLET V đẩI TẻNG DISPLAY

14

2.2. SCREEN (GIAO DIêN NGấI DẽNG CấP CAO)

18

2.3. Hệ THẩNG QUảN Lí BảN GHI (RECORD MANAGEMENT SYSTEM - RMS)

21

3.1 CáC HM API ậ MỉC THấP

29

3.2 LP CANVAS

29

3.3 LP GRAPHICS

32

3.4 CáC GI Hầ TRẻ CHO LậP TRìNH GAME

35

4.1 TặNG QUAN Về LM GAME

44

4.2 GIảI QUYếT BI TOáN TRONG TRSS CHơI LINES.

45

4.3 XâY DNG TRSS CHơI LINES TRêN J2ME.

48

4.4 KếT QUả THU đẻC.

51

CHơNG II........................................................................14
LậP TRìNH V I J2ME................................................14

CHơNG III......................................................................29
LậP TRìNH GAME BằNG J2ME...............................29

CHơNG IV......................................................................44
XâY D NG CHơNG TRìNH TRSS CHơI LINES..44

1


LờI NóI ĐầU
Ngày nay công nghệ viễn thông đang có những bớc phát triển vô cùng to
lớn. Cùng với các ngành khoa học khác, công nghệ viễn thông đã đem đến cho
con ngời những ứng dụng quan trọng trong tất cả các nghành, lĩnh vực đời sống
nh: kinh tế, giáo dục, y học, khoa học kỹ thuậtđể thoả mãn nhu cầu ngày càng
cao của con ngời.
Song song cùng với sự phát triển của công nghệ viễn thông là sự phát
triển không ngừng về các công nghệ trên điện thoại di động và điện thoại di
động đang nhanh chóng trở thành một phần của cuộc sống. Các thiết bị di động
ngày càng hiện đại hơn, "thông minh" hơn và ngày càng có nhiều tính năng nổi
bật. Chúng không chỉ đơn thuần đảm nhận chức năng hội thoại mà còn có thêm
nhiều chức năng nh chụp ảnh, nghe nhạc, xem phim, chơi game... nh một "trung
tâm giải trí". Nhu cầu phát triển phần mềm cho các thiết bị di động ngày càng
tăng cao và đợc đánh giá là một ngành công nghệ có thể đem lại nhiều lợi
nhuận. Một thực tế đặt ra cho các nhà phát triển phần mềm trên các thiết bị này

là hiện nay không có một chuẩn hóa nào dành cho các nhà sản xuất phần cứng.
Các thiết bị trên thị trờng hiện nay rất đa dạng và mang nhiều đặc điểm cũng
nh cấu hình khác nhau. Trớc thực tế đó, việc có thể chạy trên nhiều môi trờng là
một lợi thế rất lớn của ngôn ngữ Java. Các nhà phát triển Java đã cho ra đời
ngôn ngữ J2ME (Java 2 Micro Edition) hớng đến việc phát triển phần mềm cho
các thiết bị di động. Ngôn ngữ J2ME thực sự là một ngôn ngữ nhỏ gọn, dễ nắm
bắt, chặt chẽ và thích hợp cho các thiết bị có khả năng hạn chế. Các thiết bị di
động trên thị trờng hiện nay, đặc biệt là điện thoại di động hầu hết đều hỗ trợ
ngôn ngữ J2ME và J2ME thực sự đã trở thành một trong những ngôn ngữ phổ
biến nhất trong lãnh vực lập trình di động.
Từ những yêu cầu thiết yếu đó tôi đã chọn đề tài đồ án tốt nghiệm của
mình là:" Lập trình trò chơi Lines cho điện thoại di động trên J2ME (Java 2
Platform, Micro Edition)".
Nội dung của đồ án bao gồm
Chơng I: "Tổng quan về J2ME". Chơng này tìm hiểu đợc sự ra đời, ý nghĩa hay
các khái niệm, định nghĩa, kiến trúc cơ bản, quan trọng trong J2ME và cách
đóng gói, triển khai ứng dụng của J2ME.
2


Chơng II: "Lập trình với J2ME". Chơng này trình bày các kỹ năng chính khi lập
trình với J2ME (MIDlet, Dislay). Và làm quen với giao diện ngời dùng cấp cao
nh form, list, textbox... Hay biết cách lu trữ kiểu bản ghi trong J2ME.
Chơng III: "Lập trình Game bằng J2ME". Chơng này trình bày các th viện của
API trong J2ME để phát triển Game. Nh các gói Canvas, Graphics, Layer,
TiledLayer, Sprites,....
Chơng IV: "Xây dựng chơng trình trò chơi Lines". Trình bày về tổng quan về
game, và ứng dụng trên bài toán cụ thể. Cách giải quyết các vấn trong việc xây
dựng trò chơi Lines trên J2ME và kết quả thu đợc.

3


Chơng I
tổng quan về J2ME
1.1 Giới thiệu về Java v công nghệ J2ME
1.1.1 Giới thiệu về Java
Java là một công nghệ đợc hãng Sun Microsystems xây dựng từ cuối năm
1990 với cái tên Oak và hiện nay đang phát triển vợt bậc với sự đóng góp của
hàng vạn lập trình viên trên thế giới. Ban đầu, Oak đợc kỹ s James Gosling và
các cộng sự xây dựng với mục đích lập trình cho các mặt hàng điện dân dụng
với mục tiêu nhỏ gọn và tơng thích đợc với nhiều loại thiết bị phần cứng khác
nhau. Sau đó Oak đợc sử dụng trong nhiều dự án nh dự án Xanh (Blue Project),
dự án Phim theo yêu cầu (Video on demand Project). Sau một chuyến du lịch
tới đảo Java của Indonesia, nhóm phát triển Oak đã đổi tên Oak thành Java.
Java mà tiền thân là Oak đợc xây dựng chủ yếu dựa trên bộ công cụ phát
triển (Java Development Kit - JDK) nh là bộ th viện chuẩn trong đó cha trình
biên dịch, trình thông dịch, trình đóng gói, tài liệu, Đây chính là nền tảng cho
việc phát triển các ứng dụng Java. Hiện nay, cộng đồng Java trên thế giới mà đi
đầu là hãng Sun Microsystems đã xây dựng nhiều nhánh mới cho Java nh:
JavaMail (th điện tử), Java TAPI (viễn thông), Java3D (đồ họa 3 chiều), J2ME
(ứng dụng cho thiết bị di động),
Hiện nay Java có các phiên bản sau:
+ J2SETM (Java 2 Platform, Standart Edition): Phiên bản chuẩn gồm bộ
công cụ thông dụng dùng để chạy trên các máy PC hoặc các mạng máy
tính nhỏ.
+ J2EETM (Java 2 Platform, Enterprise Edition): Phiên bản dành cho các
máy chủ với bộ nhớ lớn. Bao gồm các kiến trúc nâng cao nh Web, EJB,
Transaction, dùng để xây dựng các ứng dụng có quy mô lớn
+ J2METM (Java 2 Platform, Micro Edition): Bao gồm môi trờng và th viện

Java dùng để phát triển các ứng dụng trên các thiết bị có bộ nhớ nhỏ nh
điện thoại di động, PDA, các đồ gia dụng,
1.1.2 Khái quát các lớp J2ME
J2ME đợc phát triển từ kiến trúc JavaCard, EmbededJava và PersonalJava
của phiên bản Java 1.1. Đến khi ra đời phiên bản Java 2 thì Sun quyết định thay
4


thế PersonalJava bằng một phiên bản mới có tên Java 2 Micro Edition, viết tắt là
J2ME. J2ME đợc sử dụng cho các thiết bị nhỏ gọn với dung lợng bộ nhớ bé và
khả năng xử lý thấp.
Mục tiêu của J2ME là cho phép ngời lập trình viết các ứng dụng độc lập
với thiết bị di động, không cần quan tâm đến phần cứng thật sự. Với mục tiêu
đó, J2ME đợc xây dựng bằng các tầng (layer) khác nhau để giấu đi việc thực
hiện phần cứng khỏi nhà phát triển. Các tầng của J2ME đợc xây dựng trên
CLDC (Connected Limited Device Configuration - cấu hình thiết bị kết nối giới
hạn) nh sau:
Hiện trạng
MIDP Mobile
Information
Device Profile

Các API khác

Cấu hình

CLDC Connected Limited Device
Configuration

Máy ảo Java

Phần cứng thiết bị

Hình 1.1 Các tầng của J2ME đợc xây dựng trên CLDC
+ Tầng Phần cứng thiết bị (Device Hardware Layer): Tầng này chỉ ra
thiết bị di động thật sự cùng với bộ nhớ và tốc độ xử lý cụ thể của nó. Dĩ
nhiên đây không phải là một phần của J2ME nhng nó là điểm xuất phát
để phát triển các phần mềm ứng dụng trên thiết bị đó. Các thiết bị di động
khác nhau có thể có bộ vi xử lý và các tập lệnh rất khác nhau. Mục tiêu
của J2ME là cung cấp cho lập trình viên khả năng giao tiếp giống nhau
với tất cả các loại thiết bị di động khác nhau.

5


Hình 1.2 Quá trình xây dựng ứng dụng cho thiết bị di động sử dung KVM
+ Tầng máy ảo Java (Java Virtual Machine Layer): Đây là tầng đóng vai
trò thông ngôn giữa chơng trình và thiết bị. Nó sẽ thông dịch các mã
bytecode (mã có đợc sau khi biên dịch mã nguồn chơng trình) thành mã
máy của các thiết bị di động. Tầng này sử dụng KVM (Kernel Virtual
Machine - Máy ảo đợc thiết kế nhỏ gọn với mục tiêu tiết kiệm bộ nhớ) để
biên dịch mã bytecode thành mã máy. Chính KVM sẽ chuẩn hóa đầu ra
của các chơng trình Java cho các thiết bị di động khác nhau có thể có bộ
vi xử lý và tập lệnh khác nhau. Nó cung cấp một sự chuẩn hóa cho các
thiết bị di động để ứng dụng J2ME sau khi biên dịch có thể chạy đợc trên
bất kỳ thiết bị di động nào hỗ trợ KVM. Nh vậy, không có KVM các chơng trình Java phải đợc biên dịch thành tập lệnh cho mỗi thiết bị di động
v lập trình viên phải xây dựng nhiều đích cho mỗi loại thiết bị di động.
+ Tầng cấu hình (Configuration Layer): Kế trên tầng KVM là CLDC
(Connected Limited Device Configuration: Cấu hình thiết bị kết nối giới
hạn). Mục đích của tầng này là cung cấp một tập tối thiểu các th viện cho
phép một ứng dụng Java chạy trên thiết bị di động. Tầng này cung cấp

các hàm API cơ bản là nhân của J2ME. Lập trình viên có thể sử dụng các
lớp và các phơng thức của các API này tuy nhiên nó không thực sự phong
phú bằng tập API của tầng hiện trạng.
+ Tầng hiện trạng (Profile Layer): Đây là tầng cao nhất của J2ME, tầng
này cung cấp các hàm API hữu dụng hơn cho việc lập trình. Mục đích của

6


tầng này xây dựng nên lớp cấu hình và cung cấp nhiều th viện ứng dụng
hơn. Một thiết bị di động có thể hỗ trợ nhiều hiện trạng. Một hiện trạng
có thể áp đặt thêm các giới hạn trên các loại thiết bị di động (nh nhiều bộ
nhớ hơn hay độ phân giải màn hình cao hơn). Hiện trạng là tập các API
hữu dụng hơn cho các ứng dụng cụ thể. Lập trình viên có thể viết một
ứng dụng cho một hiện trạng cụ thể và không cần quan tâm đến nó chạy
trên thiết bị nào. Hiện tại hiện trạng đợc công bố là MIDP (Mobile
Information DeviceProfile: Cấu hình thông tin thiết bị di động) với đặc tả
JSR - 37. Có 22 công ty là thành viên của nhóm chuyên gia tạo ra chuẩn
MIDP. MIDP cung cấp các API cho phép thay đổi trạng thái chu kỳ sống
ứng dụng, đồ họa (mức cao và mức thấp), tuyến đoạn, timer, lu trữ bền
vững (persistent storage), và mạng. Những chức năng MIDP cung cấp:
o Có thể sử dụng phần lớn các lớp và kiểu dữ liệu quen thuộc vẫn
còn đợc giữ lại ví dụ nh các lớp trong gói java.util nh Stack, Vector
và Hastable cũng nh Enumeration trong Java.
o Hỗ trợ đối tợng Display: Đúng nh tên gọi một chơng trình MIDP sẽ
hỗ trợ duy nhất một đối tợng Display là đối tợng quản lý việc hiển
thị dữ liệu trên màn hình điện thoại.
o Hỗ trợ Form và các giao diện ngời dùng.
o Hỗ trợ Timer và Alert
o Cung cấp tính năng Record Management System (RMS) cho việc lu trữ dữ liệu

Ngoài ra vào tháng 11 năm 2003 Sun đã tung ra MIDP 2.0 với hàng loạt
tính năng khác đợc cung cấp thêm so với bản 1.0 (Hiện nay tại Việt Nam
đã có những đời điện thoại hỗ trợ MIDP 2.0 ví dụ nh Nokia 6600 hay
Sony Ericsson P900). Một số các cải tiến nổi bật của MIDP 2.0 so với
MIDP 1.0:
o Nâng cấp các tính năng bảo mật: Download qua mạng an toàn hơn
qua việc hỗ trợ giao thức HTTPS.
o Kiểm soát việc kết nối giữa máy di động và server: ví dụ nh các chơng trình không thể kết nối tới server nếu thiếu sự chấp thuận của
ngời sử dụng.
7


o Thêm các API hỗ trợ Multimedia. Một trong nhng cải tiến hấp dẫn
nhất của MIDP 2.0 là tập các API media của nó. Các API này là
một tập con chỉ hỗ trợ âm thanh của Mobile Media API (MMAPI).
o Mở rộng các tính năng của Form. Nhiều cải tiến đã đợc đa vào API
javax.microedition.lcdui trong MIDP 2.0, nhng các thay đổi lớn
nhất (ngoài API cho game) là trong Form và Item.
o Hỗ trợ các lập trình viên Game bằng cách tung ra Game API: Có lẽ
Sun đã kịp nhận ra thị trờng đầy tiềm năng của các thiết bị di động
trong lĩnh vực Game. Với MIDP 1.0 thì các lập trình viên phải tự
mình viết code để quản lý các hành động của nhân vật cũng nh
quản lý đồ họa. Việc này sẽ làm tăng kích thớc file của sản phẩm
cũng nh việc xuất hiện các đoạn mã bị lỗi. Đợc hởng lợi nhất từ
Game API trong MIDP 2.0 không chỉ là các lập trình viên Game
mà còn là các lập trình viên cần sử dụng các tính năng đồ họa cao
cấp. Với Game API nhà phát triển còn đợc cung cấp các tính năng
nh quản lý các thao tác bàn phím
o Hỗ trợ kiểu ảnh RGB: một trong những cải tiến hấp dẫn cho các
nhà phát triển MIDP là việc biểu diễn hình ảnh dới dạng các mảng

số nguyên, cho phép MIDlet thao tác với dữ liệu hình ảnh một cách
trực tiếp.
Tuy nhiên MIDP không thể thực hiện:
o Phép tính dấu phẩy động (floating point): Phép tính này đòi hỏi rất
nhiều tài nguyên CPU. Phần lớn CPU dùng cho các thiết bị di động
không hỗ trợ phép tính này, do đó MIDP cũng không có.
o Bộ nạp class (Class Loader).
o Hỗ trợ từ khóa finalize() nh trong J2SE: Việc 'dọn dẹp' tài nguyên
trớc khi xóa đợc đẩy về phía lập trình viên.
o Hỗ trợ JNI (Java Native Interface - gọi các hàm đợc viết trong
những ngôn ngữ khác từ Java.)
o Hỗ trợ thao tác bắt lỗi: Chỉ hỗ trợ hạn chế.

8


o Th viện API cho Swing và AWT(Abstract Windowing Toolkit - bộ
công cụ chứa các lớp để tạo cửa sổ): Phần lớn không thể sử dụng
trong MIDP.
o Hỗ trợ các tính năng quản lý file và th mục: Điều này có thể làm
bạn ngạc nhiên nhng thực tế là các thiết bị J2ME không có hỗ trợ
các thiết bị lu trữ thông thờng nh ổ cứng v.v. Tuy nhiên, điều đó
không có nghĩa là bạn phải mất đi mọi dữ liệu quan trọng khi tắt
máy, Sun đã cung cấp một chức năng khác tơng đơng gọi là Record
Management system (RMS) để lu trữ cho các thiết bị này.
1.2 Kiến trúc của J2ME
Kiến trúc tổng quát của J2ME dựa trên nền tảng Java

Hình 1.3 Kiến trúc tổng quát của J2ME dựa trên nền tảng Java
Trong đó các thành phần chính của J2ME bao gồm Configuration và Profile.

a. Configuration (Cấu hình)
Là đặc tả môi trờng phần mềm cho một dòng các thiết bị đợc phân loại
bởi tập hợp các đặc tính.
Ví dụ nh:
- Kiểu và số lợng bộ nhớ
- Kiểu và tốc độ bộ vi xử lý
- Kiểu mạng kết nối
Do đây là yêu cầu về đặc tả môi trờng phát triển phần mềm, nên các nhà
sản xuất thiết bị nh Samsung, Nokia,bắt buộc phải thực thi đầy đủ các đặc tả
do Sun qui định để các lập trình viên có thể dựa vào môi trờng lập trình nhất
9


quán và thông qua sự nhất quán này, các ứng dụng đợc tạo ra có thể mang tính
độc lập thiết bị cao nhất có thể. Ví dụ nh một lập trình viên viết chơng trình
game cho điện thoại Samsung thì có thể sửa đổi chơng trình của mình một cách
tối thiểu nhất để có thể chạy trên điện thọai Nokia.. Hiện nay Sun đã đa ra 2
dạng Configuration:
- CLDC (Connected Limited Device Configuration - Cấu hình thiết bị kết
nối giới hạn): đợc thiết kế để nhắm vào thị trờng các thiết bị cấp thấp
(low-end), các thiết bị này thông thờng là máy điện thọai di động và
PDA với khoảng 512 KB bộ nhớ. Vì tài nguyên bộ nhớ hạn chế nên
CLDC đợc gắn với Java không dây (Java Wireless ), dạng nh cho phép
ngời sử dụng mua và tải về các ứng dụng Java, ví dụ nh là Midlet.
- CDC (Connected Device Configuration - Cấu hình thiết bị kết nối): CDC
đợc đa ra nhắm đến các thiết bị có tính năng mạnh hơn dòng thiết bị
thuộc CLDC nhng vẫn yếu hơn các hệ thống máy để bàn sử dụng J2SE.
Những thiết bị này có nhiều bộ nhớ hơn (thông thờng là trên 2Mb) và có
bộ xử lý mạnh hơn. Các sản phẩm này có thể kể đến nh các máy PDA
cấp cao, điện thoại web, các thiết bị gia dụng trong gia đình

Cả 2 dạng Cấu hình kể trên đều chứa máy ảo Java (Java Virtual Machine)
và tập hợp các lớp (class) Java cơ bản để cung cấp một môi trờng cho các ứng
dụng J2ME. Tuy nhiên, chú ý rằng đối với các thiết bị cấp thấp, do hạn chế về
tài nguyên nh bộ nhớ và bộ xử lý nên không thể yêu cầu máy ảo hổ trợ tất cả
các tính năng nh với máy ảo của J2SE, ví dụ, các thiết bị thuộc CLDC không có
phần cứng yêu cầu các phép tính toán dấu phẩy động, nên máy ảo thuộc CLDC
không đợc yêu cầu hỗ trợ kiểu float và double.
Bảng so sánh các thông số kỹ thuật của CDC và CLDC:
CLCD

CDC

Ram

32K, 512K

256K

Rom

128K, 512K

512K

Nguồn năng l- Có giới hạn
ợng
(nguồn Pin)

Không giớ hạn

Network

Nhanh

Chận

10


b. Profile:
Profile mở rộng Configuration bằng cách thêm vào các class để bổ trợ các
tính năng cho từng thiết bị chuyên biệt. Do mỗi profile định nghĩa một tập hợp
các class khác nhau, nên thờng không thể chuyển một ứng dụng Java viết cho
một profile này sang chạy trên một máy hỗ trợ một profile khác. Với lý do đó,
bạn không thể lấy một ứng dụng viết trên J2SE hay J2EE và chạy trên các máy
hỗtrợ J2ME. Sau đây là các profile tiêu biểu:
- Mobile Information Device Profile (MIDP: cấu hình thông tin thiêt bị
di động): profile này sẽ bổ sung các tính năng nh hỗ trợ kết nối, các
thành phần hỗ trợ giao diện ngời dùng, vào CLDC. Profile này đợc thiết
kế chủ yếu để nhắm vào điện thọai di động với đặc tính là màn hình hiển
thị hạn chế, dung lợng chứa có hạn. Do đó MIDP sẽ cung cấp một giao
diện ngời dùng đơn giản và các tính năng mạng đơn giản dựa trên HTTP.
Có thể nói MIDP là profile nổi tiếng nhất bởi vì nó là kiến thức cơ bản
cho lập trình Java trên các máy di động (Wireless Java)
- Personal Digital Assitant Profile (PDA Profile: thiết bị kỹ thuật số hỗ
trợ cá nhân): tơng tự MIDP, nhng 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.

1.3 Đóng gói và triển khai ứng dụng
Mã nguồn chơng trình có thể đợc biên dịch bằng các trình biên dịch
chuẩn của Java, chúng tạo ra các file.class. Ta có thể biên dịch từ các trình soạn
thảo hoặc biên dịch trực tiếp từ dòng lệnh.
Quá trình biên dịch đợc thực hiện nh sau:
- Tập tin nguồn: Từ các các tập tin nguồn Java do lập trình viên tạo ra, có
thể có nhiều tập tin (*.java).
- Biên dịch Java trên IDE: bộ biên dịch Java (Java Compiler) biên dịch
mã nguồn thành mã bytecode. Mã bytecode này sẽ đợc KVM dịch thành
mã máy. Mã bytecode đã biên dịch sẽ đợc lu trong các tập tin *.class và
sẽ có một tập tin *.class sinh ra cho mỗi lớp Java.

11


- Kiểm tra tính hợp lệ của mã bytecode trên IDE, bộ tiền kiểm tra sẽ kiểm
tra tính hợp lệ của mã bytecode. Một trong những yêu cầu an toàn của
J2ME là bảo đảm mã bytecode chuyển cho KVM là hợp lệ và không truy
xuất các lớp hay bộ nhớ ngoài giới hạn của chúng. Do đó tất cả các lớp
đều phải đợc tiền kiểm tra trớc khi chúng có thể đợc download về thiết bị
di động. Việc tiền kiểm tra đợc xem là một phần của môi trờng phát triển
làm cho KVM có thể đợc thu nhỏ hơn. Bộ tiền kiểm tra sẽ gán nhãn lớp
bằng một thuộc tính (attribute) đặc biệt chỉ rằng lớp đó đã đợc tiền kiểm
tra. Thuộc tính này tăng thêm khoảng 5% kích thớc của lớp và sẽ đợc
kiểm tra bởi bộ kiểm tra trên thiết bị di động.
- Tạo tập tin JAR trên IDE: IDE sẽ tạo một tập tin JAR chứa:
o Tất cả các tập tin *.class
o Các hình ảnh của ứng dụng. Hiện tại chỉ hỗ trợ tập tin *.png
o Các tập tin dữ liệu có thể đợc yêu cầu bởi ứng dụng
o Một tập tin kê khai (manifest.mf) cung cấp mô tả về ứng dụng cho bộ

quản lý ứng dụng (application manager) trên thiết bị di động.
o Tập tin JAR đợc bán hoặc đợc phân phối đến ngời dùng đầu cuối
Sau khi đã gỡ rối và kiểm tra mã lệnh trên trình giả lập (simulator), mã
lệnh đã sẵn sàng đợc kiểm tra trên điện thoại di động và sau đó đợc phân phối
cho ngời dùng.
- Download ứng dụng về thiết bị di động: Ngời dùng cách để download
tập tin JAR chứa ứng dụng về thiết bị di động:
o Kết nối cáp dữ liệu từ PC sang cổng dữ liệu của điện thoại di động:
Việc này yêu cầu ngời dùng phải có tập tin JAR thật sự và phần mềm
truyền thông để download ứng dụng sang thiết bị thông qua cáp dữ
liệu.
o Cổng hồng ngoại IR (Infra Red) Port: Việc này yêu cầu ngời dùng
phải có tập tin JAR thật sự và phần mềm truyền thông để download
ứng dụng sang thiết bị thông qua cổng hồng ngoại.
o OTA (Over the Air): Sử dụng phơng thức này, ngời dùng phải biết địa
chỉ URL chỉ đến tập tin JAR
12


- Kiểm tra mã bytecode: bộ tiền kiểm tra kiểm tra tất cả các lớp đều có
một thuộc tính hợp lệ đã đợc thêm vào bởi bộ tiền kiểm tra trên trạm phát
triển ứng dụng. Nếu tiến trình tiền kiểm tra thất bại thì ứng dụng sẽ
không đợc download về thiết bị di động.
- Lu trữ chơng trình: bộ quản lý ứng dụng trên thiết bị di động sẽ lu trữ
chơng trình trên thiết bị di động. Bộ quản lý ứng dụng cũng điều khiển
trạng thái của ứng dụng trong thời gian thực thi và có thể tạm dừng ứng
dụng khi có cuộc gọi hoặc tin nhắn đến.
- Thực thi ứng dụng: bộ quản lý ứng dụng sẽ chuyển ứng dụng cho KVM
để chạy trên thiết bị di động.
o KVM: Thực thi mã bytecode khi chơng trình chạy.

o KVM dịch mã bytecode sang ngôn ngữ máy của thiết bị di động để
chạy.

1.4 Tối u mã chơng trình và giảm kích thớc ứng dụng
Sau khi đóng gói chơng trình thành tập tin JAR chúng ta thấy rằng các
file dữ liệu đã đợc nén lại một cách đáng kể. Tuy nhiên ta có thể giảm kích thớc
file JAR này thêm một lần nữa bằng cách dùng một công cụ. Công cụ này thờng bao gồm các đặc tính sau:
- Loại bỏ các class không dùng đến
- Loại bỏ các hàm và biến không dùng đến
- Đổi tên class, package, hàm và biến thành các tên đơn giản và
ngắn gọn hơn
- Thêm vào file class một số mã để chơng trình khó bị dịch ngợc
hơn
Ba đặc tính đầu dùng để giảm kích thớc các file.class trong khi đó đặc
tính thứ 3 và thứ 4 dùng để bảo vệ chơng trình khó bị dịch ngợc lại thành mã
nguồn. Ngay cả khi bị dịch ngợc lại thành mã nguồn thì chơng trình cũng khó
bị đọc hơn vì các tên lớp, biến, hàm, package đã bị thay đổi. Các công cụ thờng
đợc dùng để tối u mã chơng trình là Jbuilder 9X, Retroguard, Jshrink.

13


Chơng II
LậP TRìNH VớI J2ME
2.1 MIDlet và đối tợng Display
2.1.1 MIDlet
Nếu ngời nào đã viết Applet thì chắc hẳn thấy hai cái tên này na ná nhau.
Thật vậy: MIDlet là viết tắt của Mobile Information Device applet. Hầu hết
các ứng dụng mà ta thấy trên điện thoại di động đều là MIDlet.
Một MIDlet kế thừa từ lớp javax.microedition.midlet.MIDlet và thực thi

ít nhất các phơng thức cơ bản sau: startApp(), pauseApp(), và destroyApp().
Trong một ứng dụng của bạn gồm có nhiều lớp thì có thể chỉ cần một lớp kế
thừa MIDlet. Dới đây là một bộ khung của MIDlet :
import javax.microedition.midlet.*;
public class MidletExample extends MIDlet {
public MidletExample(){}
public void startApp(){}
public void pauseApp(){}
public void destroyApp(boolean unconditional) {}
}
- import: dùng để nạp các lớp cần thiết từ th viện của CLDC và MIDP
- Dòng khai báo lớp: một lớp(class) test có thể đợc gọi từ bất kỳ lớp khác
(public), kế thừa (extends) từ lớp MIDlet (hay dễ hiểu hơn là: lớp test là
một MIDlet) và gọi thực thi (implements) các phơng thức của một
interface có tên là CommandListener.

- Hàm khởi tạo (Constructor): Tạo ra một form, list, hay thêm các
Command vào hàm hoặc gắn sự kiện cho nó. Hàm tạo chỉ đợc gọi một
lần khi MIDlet khởi tạo lần đầu tiên, và chỉ đợc gọi lại khi đã thoát ra
khỏi MIDlet, rồi khởi động lại
- startApp(): Phơng thức startApp() đợc gọi khi MIDlet đợc khởi tạo, và
mỗi khi MIDlet trở về từ trạng thái tạm dừng (pause). Các biến toàn cục
14


sẽ đợc khởi tạo lại trừ hàm tạo bởi vì các biến đã đợc giải phóng trong
hàm pauseApp(). Nếu không thì chúng sẽ không đợc khởi tạo lại bởi ứng
dụng.
- pauseApp(): Phơng thức pauseApp() đợc gọi mỗi khi ứng dụng cần đợc
tạm dừng (ví dụ, trong trờng hợp có cuộc gọi hoặc tin nhắn đến). Cách

thích hợp để sử dụng pauseApp() là giải phóng tài nguyên và các biến để
dành cho các chức năng khác trong điện thoại trong khi MIDlet đợc tạm
dừng. Cần chú ý rằng khi nhận cuộc gọi đến, hệ điều hành trên điện thoại
di động có thể dừng KVM thay vì dừng MIDlet. Việc này do nhà sản xuất
thiết bị quyết định sẽ chọn cách nào.
- destroyApp(boolean un): Phơng thức destroyApp() đợc gọi khi thoát
MIDlet trớc đó phải dải phóng hoàn toàn bộ nhớ đợc lấy bởi MIDlet (ví
dụ khi nhấn nút exit trong ứng dụng). Nó chỉ đơn thuần là thoát MIDlet.
Phơng thức destroyApp() chỉ nhận một tham số Boolean. Nếu tham số
này là true, MIDlet đợc tắt vô điều kiện. Nếu tham số là false, MIDlet có
thêm tùy chọn từ chối thoát bằng cách ném ra một ngoại lệ
MIDletStateChangeException.
Ngoài các hàm đợc thực thi tự động bởi bộ quản lý ứng dụng mà ngời
dùng không can thiệp đợc, MIDlet còn có những hàm cho phép ngời dùng gọi
trực tiếp trong mã lệnh để điều khiển quá trình thực thi của MIDlet:

- notifyDestroyed(): nếu ngời dùng gọi hàm này trong mã lệnh của mình
thì có nghĩa là ngời dùng muốn ra lệnh cho bộ quản lý ứng dụng hãy
đóng MIDlet. Hàm này có chức năng gần giống nh hàm exit trong C++
hay C#: gọi ra để shutdown ứng dụng.
- notifyPaused(): Nếu ứng dụng đang trong trạng thái hoạt động bình thờng mà ngời dùng gọi hàm này thì ứng dụng sẽ bị chuyển sang trạng thái
tạm ngừng (Paused) bởi bộ quản lý ứng dụng
- resumeRequest(): Ngợc lại của hàm notifyPaused(). Nếu ứng dụng đang
trong trạng thái tạm ngng mà ngời dùng gọi hàm này thì ứng dụng sẽ
quay trở về trạng thái hoạt động.
Vòng đời của một MIDlet từ lúc đợc nạp tới lúc thoát:

15

Hình 2.1. Vòng đời của một MIDlet
Khi ở trạng thái tạm dừng, ứng dụng MIDlet sẽ đợi chuyển sang trạng
thái kích hoạt. Khi ở trạng thái này thì ứng dụng của bạn nên giải phóng bớt các
tài nguyên hệ thống. Khi khởi động chơng trình thì ứng dụng của bạn sẽ ở trạng
thái tạm dừng này trớc khi chuyển sang trạng thái kích hoạt.
Đôi khi ứng dụng của ngời dùng phải chuyển sang trạng thái tạm dừng để
thiết bị xử lý một số chức năng nào đó, ví dụ nh việc nhận một cuộc điện thoại
gọi tới. Để chuyển ứng dụng sang trạng thái tạm dừng thì phần mềm quản lý
các ứng dụng MIDlet sẽ gọi phơng thức pauseApp(). Ngoài ra nếu ngời dùng
muốn tạm dừng ứng dụng của mình, ngời dùng có thể gọi phơng thức
notifyPaused(). Một cách cuối để chuyển sang trạng thái tạm dừng này là khi
phơng thức startApp() đợc gọi nhng lại ném ra một lỗi ngoại lệ là
MIDletStateChangeException.
Khi ứng dụng chuyển sang trạng thái kích hoạt, nó có thể thực hiện các
chức năng của nó, sử dụng các tài nguyên bộ nhớ và khả năng xử lý của thiết bị.
Một ứng dụng chuyển sang trạng thái kích hoạt khi phần mềm quản lý các ứng
dụng MIDlet gọi phơng thức startApp() khi ứng dụng đang ở trạng thái tạm
dừng. Nếu ứng dụng của bạn đang ở trạng thái tạm dừng và bạn muốn chuyển
sang trạng thái kích hoạt, bạn có thể gọi phơng thức resumeRequest(). Phần
mềm quản lý các ứng dụng MIDlet có thể bỏ qua yêu cầu này hoặc đa vào hàng
đợi nếu có nhiều ứng dụng cùng yêu cầu đợc chuyển sang trạng thái kích hoạt.

16


Một ứng dụng sẽ chuyển sang trạng thái kết thúc khi phơng thức
destroyApp(boolean unconditional) đợc gọi thành công khi ứng dụng đang ở
trạng thái kích hoạt hay tạm dừng. Khi phần mềm quản lý các ứng dụng MIDlet
muốn kết thức ứng dụng MIDlet, nó sẽ gọi phơng thức này để ứng dụng có thể
lu các thông số trạng thái và giải phóng tài nguyên hệ thống. Bạn có thể chuyển

ứng dụng của bạn sang trạng thái kết thúc bằng cách gọi phơng thức
notifyDestroyed(), bạn chú ý là trớc khi gọi phơng thức này thì ứng dụng của
bạn cần giải phóng tất cả tài nguyên vì phơng thức destroyApp(boolean
unconditional) sẽ không đợc gọi.
Vậy chuyện gì sẽ xảy ra khi ứng dụng của bạn đang xử lý một thao tác
quan trọng nào đó và phơng thức destroyApp(boolean unconditional) đợc gọi?
Điều này tuỳ thuộc vào giá trị của biến unconditional truyền vào. Nếu biến này
có giá trị là true (đúng) thì ứng dụng của bạn sẽ chắc chắn bị kết thúc mà phần
mềm quản lý các ứng dụng MIDlet không cần biết ứng dụng của bạn đang làm
gì. Tuy nhiên nếu biến unconditional này có giá trị false (sai) thì có nghĩa là
phần mềm quản lý các ứng dụng MIDlet muốn kết thúc ứng dụng của bạn, nhng
nếu ứng dụng của bạn đang xử lý một công việc quan trọng, bạn có thể ném ra
ngoại lệ MIDletStateChangeException để thông báo phần mềm quản lý các ứng
dụng MIDlet rằng ứng dụng cha muốn kết thúc.
Tuy nhiên việc này cũng có thể tuỳ thuộc vào đời điện thoại cụ thể, ví dụ
nh có thể phần mềm quản lý các ứng dụng MIDlet vẫn kết thúc ứng dụng hoặc
nó sẽ gọi destroyApp(boolean unconditional) sau đó. Các bạn cũng chú ý là khi
ứng dụng chuyển sang trạng thái kết thúc có nghĩa là ứng dụng sẽ đợc giải
phóng khỏi bộ nhớ nhng ứng dụng vẫn nằm trong điện thoại di động và bạn vẫn
có thể tiếp tục chạy nó những lần sau (trừ khi bạn gỡ bỏ ứng dụng của bạn ra
khỏi điện thoại di động).
2.1.2 Đối tợng Display, Displayable và Screens
a. Display:
Một ứng dụng MIDlet chỉ có duy nhất một đối tợng Display. Đối tợng
Display này dùng để lấy thông tin về màn hình cũng nh một số phơng thức cần
cho việc hiển thị các đối tợng khác trên màn hình. Có thể xem Display là đối tợng có nhiệm vụ quản lý việc hiển thị của màn hình. Chức năng của nó là quyết
định danh sách các thành phần cần xuất hiện trên màn hình cũng nh thời điểm

17

phù hợp để hiển thị chúng. Đối tợng Display cần thiết cho bộ quản lý việc trình
bày trên thiết bị điều khiển thành phần nào sẽ đợc hiển thị lên trên thiết bị.
b. Displayable:
Mặc dù chỉ có một đối tợng Display ứng với mỗi MIDlet, nhng nhiều đối
tợng trong một MIDlet có thể đợc hiển thị ra trên thiết bị nh Forms, TextBoxes,
ChoiceGroups,... Đó chính là đối tợng Displayable (là một thành phần đợc hiển
thị trên một thiết bị). Vậy đối tợng Displayable là đối tợng có thể nhìn thấy đợc
một cách trực quan trên màn hình. MIDP chứa 2 lớp con của lớp Displayable là
Screen và Canvas.
2.2. Screen (giao diên ngời dùng cấp cao)
Một đối tợng Screen không phải là một cái gì đó hiện ra trên thiết bị, mà
lớp Screen này sẽ đợc thừa kế bởi các thành phần hiển thị ở mức cao, chính các
thành phần này sẽ đợc hiển thị ra trên màn hình. Hình dới đây sẽ mô tả mối
quan hệ của lớp Screen và các thành phần thể hiện ở mức cao.

Hình 2.2. Mô tả mối quan hệ của lớp Screen và các thành phần thể hiện ở mức
cao
2.2.1 Thành phần Form và Items
Trong phần này sẽ giới thiệu các thành phần đợc hiển thị ra trên một
Form. Một Form chỉ đơn giản là một khung chứa các thành phần, mà mỗi thành

18


phần đợc thừa kế từ lớp Item. Chúng ta sẽ xem qua các thành phần hiển thị trên
thiết bị:

a. TextField:
Một thành phần TextField thì tơng tự nh bất kỳ các đối tợng nhập văn bản tiêu

biểu nào. Ta có thể chỉ định một nhãn, số ký tự tối đa đợc phép nhập, và loại dữ
liệu đợc phép nhập. Ngoài ra TextField còn cho phép ta nhập vào mật khẩu với
các ký tự nhập vào sẽ đợc che bởi các ký tự mặt nạ.
b. DateField:
Thành phần DateField cung cấp một phơng tiện trực quan để thao tác đối tợng
Date đợc định nghĩa trong java.util.Date. Khi tạo một đối tợng DateField, ta cần
chỉ rõ là ngời dùng chỉ có thể chỉnh sửa ngày, chỉnh sửa giờ hay đồng thời cả
hai
c. Gauge:
Một thành phần Gauge là một kiểu giao diện thờng đợc dùng để mô tả mức độ
hoàn thành một công việc.
d. StringItem:
Một thành phần StringItem đợc dùng để hiển thị một nhãn hay chuỗi văn bản.
Ngời dùng không thể thay đổi nhãn hay chuỗi văn bản khi chơng trình đang
chạy.
e. ChoiceGroup:
Thành phần ChoiceGroup cho phép ngời dùng chọn từ một danh sách đầu vào
đã đợc định nghĩa trớc.
f. Spacer:
Spacer là thành phần không nhìn thấy, đợc dùng để định vị trí cho các đối tợng
khác trên màn hình hiển thị. Chúng ta có thể dùng Spacer để chỉ rõ khoảng
trắng theo chiều dọc và chiều ngang giữa các thành phần, đơn giản bằng cách
chỉ ra chiều dài và chiều rộng cho từng cái. Vì Spacer là thành phần không nhìn
thấy nên nó không có sự kiện
g. CustomItem:

19


Thành phần CustomItem cho phép ta có thể tạo ra những thành phần Item của

chính mình. Những thành phần này cũng giống nh những Item khác là cũng có
thể đợc đặt vào trong Form và có thể nhận biết và xử lý sự kiện CustomItem đợc
vẽ lên màn hình hiển thị bằng phơng thức paint(). Vì thế nó sẽ tùy thuộc vào
đoạn mã đợc ta hiện thực bên trong phơng thức paint(). Quá trình tạo ra một đối
tợng CustomItem cũng không khác các đối tợng có sẵn trên nền Java.
h. Image and ImageItem:
Hai lớp đợc dùng để hiển thị hình ảnh là: Image và ImageItem. Image đợc dùng
để tạo ra một đối tợng hình ảnh và giữ thông tin nh là chiều cao và chiều rộng,
và dù ảnh có biến đổi hay không.
2.2.2 Thành phần List, Textbox, Alert, và Ticker
Trong phần này chúng ta sẽ xem xét các đối tợng ListBox, TextBox, Alert, và
Ticker trong các thành phần giao diện cấp cao của ứng dụng MIDP. Chúng ta
hãy cũng xem lại cây phân cấp các thành phần trình bày trên thiết bị một cách
hoàn chỉnh hơn
a. List:
List dùng để hiển thị các danh sách các khả năng cho ngời dùng lựa chọn. List
gồm 3 dạng:
- Multiple: cho phép ngời dùng lựa chọn nhiều khả năng.
- Exclusive: cho phép ngời dùng lựa chọn duy nhất một khả năng.
- Implicit: chỉ hiển thị danh sách các khả năng lựa chọn dạng menu.
Dạng thứ 3 là là dạng không tờng minh. Các List không tờng minh đợc dùng để
thể hiện một thực đơn các chọn lựa
b. TextBox:
TextBox đợc dùng để cho phép nhập nhiều dòng. Thành phần TextBox và
TextField có những ràng buộc giống nhau trong việc chỉ định loại nội dung đợc
phép nhập vào.
c. Alert và AlertType:
Một Alert đơn giản là một hộp thoại rất nhỏ thông báo cho ngời dùng biết
có một sự kiện xảy ra. Có 2 loại Alert:
- Modal: là loại hộp thoại thông báo đợc trình bày cho đến khi ngời dùng

ấn nút đồng ý.

20


- Non-modal: là loại hộp thoại thông báo chỉ đợc trình bày trong một số
giây nhất định.
d. Ticker:
Thành phần Ticker đợc dùng để thể hiện một đoạn chuỗi chạy theo chiều
ngang. Tham số duy nhất của thành phần Ticker là đoạn văn bản đợc trình bày.
Tốc độ và chiều cuốn đợc xác định bởi việc cài đặt trên thiết bị nào.
2.3. Hệ thống quản lý bản ghi (Record Management System - RMS)
MIDP không sử dụng hệ thống file để lu trữ dữ liệu. Thay vào đó MIDP lu toàn bộ thông tin vào non-volatile memory bằng hệ thống lu trữ gọi là Record
Management System (RMS)
2.3.1 Lu trữ cố định thông qua Record Store
RMS là hệ thống đợc tổ chức và quản lý dới dạng các record (bản ghi).
Mỗi bản ghi (sau này gọi là Record) có thể chứa bất kỳ loại dữ liệu nào, chúng
có thể là kiểu số nguyên, chuỗi ký tự hay có thể là một ảnh và kết quả là một
Record là một chuỗi (mảng) các byte. Nếu ta mã hoá dữ liệu của mình dới dạng
nhị phân (binary), ta có thể lu trữ dữ liệu bằng Record sau đó đọc dữ liệu từ
Record và khôi phục lại dữ liệu ban đầu. Tất nhiên kích thớc dữ liệu của nó
không đợc vợt quá giới hạn qui định của thiết bị di động. RMS lu dữ liệu gần
nh một cơ sở dữ liệu, bao gồm nhiều dòng, mỗi dòng lại có một số định danh
duy nhất.

Một cơ sở dữ liệu kiểu bản ghi.
Record ID

Data

1

Array of bytes

2

Array of bytes

3

Array of bytes

....

....

Một tập các bản ghi (sau này gọi là RecordStore) là tập hợp các Record
đợc sắp xếp có thứ tự. Mỗi Record không thể đứng độc lập mà nó phải thuộc
21


vào một RecordStore nào đó, các thao tác trên Record phải thông qua
RecordStore chứa nó. Khi tạo ra một Record trong RecordStore, Record đợc
gán một số định danh kiểu số nguyên gọi là Record ID. Record đầu tiên đợc tạo
ra sẽ đợc gán Record ID là 1 và sẽ tăng thêm 1 cho các Record tiếp theo. Cần
chú rằng Record ID không phải là chỉ mục (index), các thao tác xóa Record
trong RecordStore sẽ không tự động việc tính toán lại các Record ID của các
Record hiện có và cũng nh không làm thay đổi Record ID của các Record đợc
tạo mới, ví dụ: khi ta xóa record id 3 khi thêm một record mới sẽ có id là 4. Nh
vậy, các bản ghi đợc định danh bằng một số ID bản ghi (record ID) duy nhất.

Các số sẽ không đợc dùng lại khi một bản ghi bị xóa do đó sẽ tồn tại các
khoảng trống trong các ID bản ghi. Data là một dãy các byte đại diện cho dữ
liệu cần lu.
Nh trong hình 2.3, các MIDlet có thể có nhiều hơn một tập lu trữ bản ghi,
chúng chỉ có thể truy xuất dữ liệu lu trữ bản ghi chứa trong bộ MIDlet của
chúng. Do đó, MIDlet 1 và MIDlet 2 có thể truy xuất dữ liệu trong Record Store
1 và Record Store 2 nhng chúng không thể truy xuất dữ liệu trong Record
Store3. Ngợc lại, MIDlet 3 chỉ có thể truy xuất dữ liệu trong Record Store 3 và
không thể truy xuất dữ liệu dữ liệu trong Record Store 1 và Record Store 2. Tên
của các lu trữ bản ghi phải là duy nhất trong một bộ MIDlet nhng các bộ khác
nhau có thể dùng trùng tên. Các bản ghi trong một lu trữ bản ghi đợc sắp xếp
thành các mảng byte. Các mảng byte không có cùng chiều dài và mỗi mảng
byte đợc gán một số ID bản ghi.

22


Bộ MIDlet

MIDlet1

Lu trữ
bản ghi 1

MIDlet2

Lu trữ
bản ghi 2

Bộ MIDlet khác

MIDlet3
MIDlet3

Lu trữ
bản ghi 3

Hình 2.3 Minh họa dữ liệu lu trữ bản ghi với MIDlet
Record Store còn có 2 thuộc tính là Version Number và Date/time Stamp,
các giá trị này thay đổi khi thực hiện thêm, thay thế hay xóa một record, ngoài
ra còn có thể dùng cơ chế event handler (Listener) để phát hiện mỗi khi Record
store bị thay đổi. Version number là một số integer, để biết giá trị khởi đầu cần
gọi hàm getVersion() sau khi tạo một Record store. Date/time Stamp là số long
integer, là số miliseconds kể từ ngày 1 tháng 1 năm 1970, chúng ta có thể biết
đợc giá trị này thông qua hàm getLastModified().

2.3.2 Các hàm API trong RMS
RecordStore không có hàm khởi tạo.
RecordStore Class: javax.microedition.rms.RecordStore
Method
Description
static
RecordStore
openRecordStore Mở một Recordstore, có tham số tạo
(String
recordStoreName,
boolean Record store nếu nó cha tồn tại.
createIfNecessary)
recordStoreName: tên của Record
23

Store
createIfNecessary: tham số tạo, nếu
true thì tạo mới recordStore, nếu
false không tạo mới
Đóng Record Store

void closeRecordStore()
static
void
deleteRecordStore(String
Xóa Record Store
recordStoreName)
Danh sách các RecordStore trong
static String[] listRecordStores()
MIDlet suite.
Thêm một record có dữ liệu là mảng
int addRecord(byte[] data, int offset, int data[] đợc thêm vào từ phần tử thứ
numBytes)
(int offset) đến phần tử thứ (int
numBytes) vào RecordStore.
Đặt hoặc thay thế một record có chỉ
void setRecord(int recordId, byte[]
số là recordId trong RecordStore
newData, int offset, int numBytes)
bằng mảng newData[]
Xóa một record có chỉ số là recordId
void deleteRecord(int recordId)
trong RecordStore.

byte[] getRecord(int recordId)
Lấy mảng byte chứa record.
Lấy nội dung của RecordStore tại
int getRecord(int recordId, byte[] buffer,
recordId vào dãy byte buffer bắt đầu
int offset)
tại vị trí offset của dãy đó.
int getRecordSize(int recordId)
Kích thớc của một record.
int getNextRecordID()
Lấy record id của record mới.
int getNumRecords()
Số lợng các record.
long getLastModified()
Thời gian thay đổi gần nhất.
String getName()
Tên của RecordStore.
int getSize()
Kích thớc của RecordStore.
int getSizeAvailable()
Số byte trống cho RecordStore
RecordEnumeration
enumerateRecords( RecordFilter filter, Xây dựng enumeration dùng để
RecordComparator comparator, boolean duyệt recordstore
keepUpdated)
void addRecordListener (RecordListener
Thêm một listener vào recordstore
listener)
void
removeRecordListener

Remove listener.
(RecordListener listener)
2.3.3 Mở (open), Định dạng (Format), Thêm (Add), Đọc(Read) và Xóa
(Delete) các bản ghi
a. Hàm để mở một recordstore:
public void openRecStore() {
try {
24


// Create record store if it does not exist
rs = RecordStore.openRecordStore(REC_STORE, true );
}
catch (Exception e) {
db(e.toString()); } }
Với tham số true, hàm sẽ tạo một RecordStore nếu nó cha tồn tại.
b. Định dạng, thêm bản ghi:
Thêm bản ghi gồm hai bớc: Bớc đầu tiên là định dạng bản ghi theo định
dạng yêu cầu và bớc tiếp theo là thêm bản ghi đã định dạng vào lu trữ bản ghi.
Do việc tuần tự hóa (serialization) dữ liệu của lu trữ bản ghi không đợc hỗ trợ,
nên lập trình viên phải định định dạng các mảng byte để xây dựng dữ liệu lu trữ
bản ghi.
Sau đây là ví dụ của việc định dạng dữ liệu bản ghi, mở một lu trữ bản
ghi và sau đó thêm dữ liệu bản ghi vào lu trữ bản ghi
ByteArrayOutputStream baos = new ByteArrayOutputStream();
DataOutputStream outputStream = new DataOutputStream(baos);
outputStream.writeByte(T); // byte [0] Thẻ chỉ loại bản ghi
outputStream.writeInt(score); // byte [1] đến [4]
outputStream.writeUTF(name); // byte [5] đến (5 + name.length)
byte[] theRecord = boas.toByteArray();

recordStore rs = null;
rs
=
RecordStore.openRecordStore(RecordStoreName,
CreateIfNoExist);
int RecordID = rs.addRecord(theRecord, 0, theRecord.length);
Record
Record ID
ID

''T'
T'

Byte
Byte Byte
Byte Byte
Byte Byte
Byte Byte
Byte Byte
Byte Byte
Byte

Record
Record ID
ID

''S'
S'

Byte

Byte Byte
Byte Byte
Byte Byte
Byte Byte
Byte Byte
Byte Byte
Byte

Record
Record ID
ID

''S'
S'

Byte
Byte Byte
Byte Byte
Byte Byte
Byte Byte
Byte Byte
Byte Byte
Byte

Record
Record ID
ID

''T'
T'

Byte
Byte Byte
Byte Byte
Byte Byte
Byte Byte
Byte Byte
Byte Byte
Byte

Hình 2.4 Bản ghi thu đợc qua việc định dạng và thêm dữ liệu
+) Định dạng dữ liệu bản ghi:

25