Công nghệ J2ME xây dựng game cờ caro online trên mobile

LỜI CẢM ƠN
Qua thời gian học tập và rèn luyện tại Đại Học Công Nghệ Thông Tin &
Truyền Thông - Đại học Thái Nguyên, đến nay chúng em đã kết thúc khoá học
và hoàn thành đồ án tốt nghiệp. Để có được kết quả này em xin chân thành cảm
ơn:
 Các thầy cô giáo bộ môn công nghệ phần mềm cùng các thầy, cô giáo
trong trường đã giảng dạy, quan tâm và tạo điều kiện thuận lợi để em học
tập và rèn luyện trong suốt thời gian theo học tại trường.
 Thầy giáo T.S Nguyễn Văn Tảo và Cô giáo – Th.s Ngô Thị Lan đã tận
tình hướng dẫn, giúp đỡ em trong quá trình học tập và đặc biệt là trong
suốt thời gian làm đồ án tốt nghiệp.
 Em cũng xin gửi lời cảm ơn tới gia đình, bạn bè, những người đã động
viên, giúp đỡ em rất nhiều trong thời gian học tập và làm đồ án tốt nghiệp.

Sinh viên thực hiện:
Nguyễn Văn Phong

1


LỜI CAM ĐOAN
Đồ án tốt nghiệp là sản phẩm tổng hợp toàn bộ các kiến thức mà sinh viên
đã học được trong suốt thời gian học tập tại trường đại học. Ý thức được điều đó,
với tinh thần nghiêm túc, tự giác cùng sự lao động miệt mài của bản thân và sự
hướng dẫn tận tình của Thầy giáo T.S Nguyễn Văn Tảo và Cô giáo – Th.s Ngô
Thị Lan em đã hoàn thành xong đồ án tốt nghiệp của mình.
Em xin cam đoan: nội dung đồ án của em không sao chép nội dung cơ bản
từ các đồ án khác và sản phẩm của đồ án là của chính bản thân em nghiên cứu
xây dựng lên. Mọi thông tin sai lệch em xin hoàn toàn chịu trách nhiệm trước hội
đồng bảo vệ.
Sinh viên cam đoan:

Nguyễn Văn Phong

2


MỤC LỤC
1.1 Giới thiệu kiến trúc của J2ME...........................................................................7
1.2. CLDC................................................................................................................9
1.2.1.Yêu cầu phần cứng:..........................................................................................................................9
1.2.2.Yêu cầu phần mềm:........................................................................................................................10
1.2.3.Máy ảo Java:...................................................................................................................................10
1.2.4 Một số hạn chế:..............................................................................................................................10

1.3.MIDP:...............................................................................................................12
1.3.1. Yêu cầu phần cứng:.......................................................................................................................12
1.3.2. Yêu cầu phần mềm........................................................................................................................12
1.3.3. Cấu trúc MID Profile:.....................................................................................................................12
1.3.4. MIDlet Suite:..................................................................................................................................13

1.4. Cơ bản về Midlet.............................................................................................15
1.4.1. Cấu trúc cơ bản..............................................................................................................................15
1.4.2. Xây dựng một ứng dụng MIDlet:...................................................................................................16
1.4.3. Lớp MIDlet:....................................................................................................................................16
1.4.4. Lớp MIDletStateChangeException:...............................................................................................18
1.4.5.Display............................................................................................................................................18
1.4.6. Lớp Displayable:............................................................................................................................19
1.4.7. Quản lý các sự kiện (event)...........................................................................................................21

2.1.Giao diện người dùng cấp cao.........................................................................26
2.1.1. Đối tượng Display, Displayable và Screens...................................................................................26

2.1.2.Thành phần Form và Items.............................................................................................................26
2.1.3.Form:..............................................................................................................................................27
2.1.4. Item:..............................................................................................................................................28
2.1.5. TextField........................................................................................................................................28
2.1.6. ChoiceGroup..................................................................................................................................29
2.1.7. Thành phần List, Textbox, Alert, và Ticker....................................................................................31

2.2. Giao diện người dùng cấp thấp.......................................................................32
2.2.1.Các hàm API ở mức thấp................................................................................................................32
2.2.2. Lớp Canvas và kỹ thuật xử lý đồ họa:............................................................................................32
2.2.3. Hệ thống trục tọa độ....................................................................................................................33
2.2.4. Đối tượng Canvas..........................................................................................................................33
2.2.4.1. Vẽ trên đối tượng Canvas.....................................................................................................33
2.2.4.2. Sự kiện hành động.................................................................................................................34
2.2.4.3. Mã phím.................................................................................................................................34
2.2.4.4. Các hành động trong xử lý các trò chơi.................................................................................35
2.2.4.5. Xác định các hành động của trò chơi....................................................................................36
2.2.4.6. Sự kiện con trỏ......................................................................................................................37
2.2.5.Lớp Graphics...................................................................................................................................38
2.2.5.1. Hỗ trợ màu............................................................................................................................38
2.2.5.2. Vẽ cung...................................................................................................................................40
2.2.5.3. Vẽ hình chữ nhật...................................................................................................................41
2.2.5.4. Font chữ................................................................................................................................41
2.2.5.5. Điểm neo................................................................................................................................42

3


2.2.5.6. Vẽ các chuỗi ký tự..................................................................................................................43
2.2.5.7. Vẽ ảnh...................................................................................................................................43

2.2.5.8. Một số các phương thức khác của lớp Graphics:.................................................................43

3.1. Cây phân cấp Connection...............................................................................45
3.2. Kết nối HTTP..................................................................................................46
3.3. Client Request và Server Response................................................................49
3.4. Kết nối socket Datagram (UDP).....................................................................53
3.5. Kết nối TCP socket.........................................................................................54
3.6. Giới thiệu media player API...........................................................................56
4.1. Mô tả trò chơi..................................................................................................60
4.2. Phân tích thiết kế UML...................................................................................60
4.2.1. Use-case Diagram..........................................................................................................................60
4.2.2. Sequence Diagram.........................................................................................................................61
4.2.3. Activity Diagram............................................................................................................................62
4.2.4. Class Diagram................................................................................................................................64

4.3.Chức năng của game :......................................................................................64
4.3.1.Đăng nhập......................................................................................................................................64
4.3.2.Đăng ký tài khoản...........................................................................................................................65
4.3.3.Chọn các mục thông tin (Thông tin User, thông tin Bạn bè...).......................................................66
4.3.4.Tạo Phòng cho người chơi..............................................................................................................67
4.3.5.Cho phép người chơi Join vào phòng.............................................................................................68
4.3.6.Cho phép người chơi sẵn sàng.......................................................................................................69
4.3.7.Quản lý lượt đánh (Turn) của từng người chơi trong phòng........................................................69
4.3.8.Quản lý thắng thua.........................................................................................................................70
4.3.9.Cập nhật tiền người chơi sau mỗi ván...........................................................................................71
4.3.10. Tạo ván chơi mới.........................................................................................................................72
4.3.11.Xử lý Thoát khỏi phòng................................................................................................................72
4.3.12.Thoát Game..................................................................................................................................73

4.4.Giao diện của game .........................................................................................74

4


DANH MỤC HÌNH ẢNH
Hình 1.1: Kiến trúc của J2ME...........................................................................................7
Hình 1.2 : kết cấu CDC và CLDC.....................................................................................8
Hình 1. 3: Cấu trúc chương trình J2ME............................................................................9
Hình 1.4: Cấu trúc chương trình MIDP.............................................................................9
Hình 1.5 Cấu trúc thiết bị MID.......................................................................................13
Hình 1.6 Sơ đồ MiDlet....................................................................................................17
Hình 1.7 Command Exit..................................................................................................22
Hình 1.8 Command Label...............................................................................................22
Hình 2.1: Đối tượng Display...........................................................................................26
Hình 2.2 : Cấu hình của các thành phần Screen..............................................................32
Hình 2.3 vẽ cung tròn......................................................................................................41
Hình 3.1 Cấu hình HTTPConnection..............................................................................46
Hình 3.2 Kết nối UDP....................................................................................................53
Hình 3.3 Kết nối TCP Socket..........................................................................................55
Hình 4.1 Use-case Diagram.............................................................................................60
Hình 4.2: Sequence Diagram ..........................................................................................61
Hình 4.3: Activity Diagram.............................................................................................63
Hình 4.4 Class Diagram..................................................................................................64

5


LỜI MỞ ĐẦU
Cùng với sự phát triển nhanh chóng của các thế hệ máy tính hiện đại cùng
với mạng internet trên toàn cầu đã làm cho nhu cầu giải trí bằng game trên

Mobile ngày càng phát triển mạnh. Trong những năm gần đây sự phát triển của
game càng mạnh mẽ với nhiều thể loại, nhiều phiên bản khác nhau. Từ các phiên
bản game control, game 2D, game 3D… với nhiều hình thức chơi khác nhau,
chơi độc lập với Mobile , chơi đối kháng hay team qua mạng dưới sự trợ giúp
của internet. Giải trí bằng game là nhu cầu của rất nhiều người không phân biệt
tuổi tác giới tính. Ngày nay việc giải trí được mở rộng tới các thiết bị cầm tay
thông minh làm cho việc chơi game càng được mở rộng hơn và nhiều người
tham gia hơn điều đó đồng nghĩa với việc phát triển game ngày càng phải đa
dạng đáp ứng nhu cầu chơi game trên các thiết bị khác nhau. Trong thời điểm
hiện tại có rất nhiều bạn trẻ hướng sự quan tâm của mình vào việc thiết kế và lập
trình game. Đây là một trong nhưng lĩnh vực tiềm năng lớn hấp dẫn cả người lập
trình, người thiết kế và người chơi. Tuy nhiên việc phát game là công việc tương
đối phức tạp nó đòi hỏi rất nhiều kiến thức từ các tri thức xã hội để phát triển cốt
truyện cho game, các kỹ năng thiết kế đồ họa và lập trình với sự giúp đỡ của các
công cụ hiện đại. Chính vì vậy, các bạn yêu thích làm game nên thành lập thành
các nhóm để thảo luận chia sẻ học hỏi lẫn nhau và cùng phát triển các game yêu
thích. Tuy vấn đề làm game là khó nhưng chắc chắn sẽ làm được nếu được quan
tâm đúng mức và có sự đam mê yêu thích và đây cũng là một trong những lĩnh
vực đang có xu hướng phát triển mạnh đặc biệt trong giai đoạn internet bùng nổ
như hiện nay.
Nói đến game trên các hệ máy desktop người ta thường hay nhắc tới
những cái tên như C, C++, C# ……, game trên các ứng dụng RIA trên mạng thì
người ta thường nhắc tới Flash…., Còn nói tới java thì người ta thường hay nhắc
tới những trò game dành cho các thiết bị di động mobile….. đó cũng là do ngay
từ khi mới ra đời java đã là ngôn ngữ nổi tiếng với tiêu chí « Viết một lần chạy ở
bất cứ nơi đâu« . Do đó lập trình game java trên các thiết bị đi động rất phát
triển trên cộng động mạng, có rất nhiều tài liệu, diễn đàn được lập ra thảo luận về
vấn đề này. Cho nên em nhận đề tài về tìm hiểu Game trên Mobile.

6

CHƯƠNG 1 : TỔNG QUÁT J2ME
(Java 2 Platform Micro Edition)
1.1 Giới thiệu kiến trúc của J2ME

Hình 1.1: Kiến trúc của J2ME
Định nghĩa về Configuration (Cấu hình): là đặc tả định nghĩa mộ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à đặc tả 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 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:

7


• 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 (lowend), các thiết bị nàythô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 nhưng 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, đố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.

Hình 1.2 : kết cấu CDC và CLDC
Đến đây chúng ta có thể hình dung phần nào cấu trúc tổng thể của một
chương trình J2ME như sau:

8


Hình 1. 3: Cấu trúc chương trình J2ME
Nếu chương trình được biên dịch với CDC, nó chạy trên máy ảo “truyền
thống” và mang các đặc tính như chương trình J2SE. Nếu chương trình được
biên dịch với CLDC, nó chạy với máy ảo chuyên biệt KVM và đặc tính riêng do
CLDC đòi hỏi.
Với chương trình xây dựng bởi MIDP, chúng ta có cấu trúc chuyên biệt
sau:

Hình 1.4: Cấu trúc chương trình MIDP

1.2. CLDC
1.2.1.Yêu cầu phần cứng:
Yêu cầu tối thiểu để có thể sử dụng CLDC như sau:
• 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”).

9


1.2.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ị

1.2.3.Máy ảo Java:
Do các thiết bị di động dùng CLDC thường có tài nguyên hạn chế nên Sun
đã đề ra máy ảo Java KVM phục vụ riêng cho các thiết bị này. Máy ảo KVM
thực chất là một bộ phận con của các máy ảo trên môi trường J2SE và J2EE nên
cũng có nhiều hạn chế và khác biệt so với hai phiên bản trên.

1.2.4 Một số hạn chế:
• Không hỗ trợ kiểu dữ liệu float: Việc sử lý số float đòi hỏi nhiều tài
nguyên xử lý, ngoài ra các thiết bị di động không có những cấu hình phần cứng
dành riêng cho việc xứ lý số float nên trong J2ME chúng ta không thể khai báo

các biến, mảng float, các hàm cũng không nhận tham số và trả về các số float.
• Phương thức finalize: Trong J2SE, chúng ta có thể khai báo phương
thức finalize (tương tự như phương thức destructor). Garbage Collector sẽ gọi
phương thức này trước khi hủy bỏ một đối tượng, phương thức này
thường được dùng để thu hồi các tài nguyên hệ thống như sockets, file
handles… trước khi đối tượng bị “phá hủy”. Tuy nhiên trong J2ME chúng ta
không có phương thức finalize.
• Error Handling: Trong J2ME chúng ta vẫn được hỗ trợ các công cụ về
bẫy lỗi (chủ yếu thông qua try và catch). Tuy nhiên khả năng về xử lý lỗi của
J2ME cũng hạn chế hơn với hai phiên bản còn lại.
• Không hỗ trợ việc sử dụng code của các ngôn ngữ lập trình khác
• Không hỗ trợ Reflection: Trong J2SE và J2EE, chúng ta có thể dùng các
lớp Reflection để tìm hiểu thông số môi trường máy ảo Java đang thực thi.
• Không hỗ trợ ThreadGroup: mỗi thread được quản lý riêng biệt, không
còn lớp ThreadGroup. Nếu muốn điểu khiển một lúc nhiều threads chúng ta có
thể dùng mảng hoặc Vector. J2ME cũng còn một số điểm khác biệt so với J2SE
và J2EE, một trong những khác biệt chính là quá trình Class Verify (tạm dịch là

10


“kiểm tra lớp”). Các lớp trước khi được load sẽ thông qua một quá trình “kiểm
tra” về sự hợp lệ và tính nguyên vẹn. Đây là một cơ chế quan trọng để bảo đảm
an toàn (security) của Java. Quá trình này trong J2SE và J2EE có thể chiếm đến
50 kbytes bộ nhớ, trong J2ME chúng được chia thành 2 giai đoạn:
• Tiền kiểm tra (Pre-verification): Trước khi một lớp được nạp vào thiết
bị, một phần mềm sẽ được sử dụng để thêm vào một số thông số bổ sung vào file
class. Quá trình này giảm thời gian và bộ nhớ cần thiết để máy ảo thực hiện giai
đoạn 2 trong quá trình kiểm tra. File class sau khi được “tiền kiểm tra” sẽ tăng
dung lượng khoảng 5%

• Kiểm tra nội thiết bị (In-device verification): Khi thiết bị nạp các file
class đã được tiền kiểm tra, công cụ kiểm tra trong thiết bị sẽ thực hiện một vài
kiểm tra để xác nhận tính hợp lệ của đoạn code. Nếu phát hiện một lỗi nào đó bộ
kiểm tra sẽ phát sinh báo cáo và từ chối nạp lớp đối tượng vào bộ nhớ. Quá trình
này đòi hỏi ít bộ nhớ và tài nguyên hơn nhiều lần so với trong J2SE và J2EE.
CLDC không hỗ trợ tất cả các lớp và thư viện được hỗ trợ trong ngôn ngữ Java
truyền thống mà chỉ hỗ trợ những thư viện thật sự cần thiết đối với thiết bị di
động. Ngoài ra trong CLDC ta được hỗ trợ việc truy vấn một số thuộc tính của hệ
thống:
• Lấy thông tin về platform của thiết bị:
System.getProperty("microedition.platform")
• Lấy thông tin về bảng mã mặc định:
System.getProperty("microedition.encoding")
• Lấy thông tin về Profile:
System.getProperty("microedition.profiles")
• Lấy thông tin Vesion
Ngoài ra chúng ta có thể truy cập lớp Runtime để lấy các thông số về thiết
bị:
Runtime rtime= Runtime.getRuntime();
System.out.println("Total memory: " + rtime.totalMemory());
//thông tin về tổng bộ nhớ
System.out.println("Free memory: " + rtime.freeMemory());
//thông tin về bộ nhớ trống

11


1.3.MIDP:
1.3.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)

1.3.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).

1.3.3. Cấu trúc MID Profile:
Tầng dưới cùng là phần cứng của thiết bị di động. Bên trên phần cứng ta
có hệ điều hành điều khiển các hoạt động.
Bên trên hệ điều hành ta có thể chia thành 2 phần riêng biệt. Chúng ta sẽ
thấy phần bên phải là các chương trình native application (tạm dịch là “chương
trình nguyên gốc”). Trước khi J2ME ra đời, thông thường đây là loại chương
trình duy nhất có trên các thiết bị. Đây là loại chương trình được nhà sản xuất
đưa sẵn vào máy di động lúc sản xuất như chương trình chọn tiếng chuông, chỉnh
thông số điện thoại, chỉnh giờ… Chính nhờ J2ME ra đời chúng ta mới có chức

năng cài đặt thêm các chương trình được viết thêm vào điện thoại.

12


Hình 1.5 Cấu trúc thiết bị MID
CLDC là nền tảng cơ bản cho MID Profile, các chương trình MIDP
(MIDP Applications) có thể sử dụng các lớp được cung cấp bởi cả CLDC và
MIDP. Ngoài ra chúng ta còn có các lớp OEM (original equipment
manufacturer) là các lớp do các nhà sản xuất cung cấp thêm cho điện thoại (các
hãng như Nokia, Samsung, Motorola… thường có thêm nhiều lớp cấp cao hỗ trợ
cho lập trình viên) và bên trên là các ứng dụng được xây dựng từ các lớp này, các
ứng dụng này thường chỉ chạy trên các điện thoại của hãng đã cung cấp thư viện
lơp OEM.

1.3.4. 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ột 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).
Cấu trúc file Jar:
Ngoài các file lớp 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 của 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. Trong file manifest
chúng ta có thể định nghĩa các thuộc tính của file jar:
Thuộc tính
MIDlet-Name

Mục đích
Tên của bộ MIDlet

13

Bắt buộc
Có


MIDlet-Version

Số phiên bản

Có

MIDlet-Vendor

Cho biết người tạo MIDlet Suite

Có

MIDlet-<n>

Tham chiếu đến từng MIDlet trong Có
bộ MIDlet (trong file Jar), mỗi một
MIDlet cần một mẫu tin này, mẫu tin này
gồm 3 mẫu tin:
Tên MiDlet
File Icon MIDlet (có thể không cần)
Tên lớp sẽ được nạp khi thực thi
MIDlet

MicroEditionProfile

Tên profile cần thiết để chạy MIDlet Có
này, thường là MIDP1.0 hoặc MIDP2.0

MicroEdition

Configuration

Configuration

(thường là CLDC 1.0)

MIDlet-Icon

File icon (.pgn) của bộ MIDlet

cần

để

chạy

MIDlet Có

Không

MIDlet-Description Mô tả (text) của bộ MIDlet

Không

MIDlet-Info-URL

Không

Địa chỉ trang web nhà phát triển MIDlet
Bảng Cấu trúc file manifest

Đây là một ví dụ đơn giản của file manifest:
MIDlet-Name: Todo List
MIDlet-Version: 1.0
MIDlet-Vendor: Core J2ME
MIDlet-1: TodoList, /images/Todo.png, Todo.TodoMIDlet
MicroEdition-Profile: MIDP-1.0
MicroEdition-Configuration: CLDC-1.0 File JAD (Java Application
Descriptor File):
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:

14


• 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

Mục đích

Bắt

MIDlet-Name

Tên của bộ MIDlet

Có

MIDlet-Version

Số phiên bản

Có

MIDlet-Vendor

Cho biết người tạo MIDlet Suite

Có

MIDlet-<n>

Tham chiếu đến từng MIDlet trong bộ
MIDlet (trong file Jar), mỗi một MIDlet cần
một mẫu tin này, mẫu tin này gồm 3 mẫu tin:

Có

Tên MIDlet
File Icon MIDlet (có thể không cần)
MIDlet-Jar-URL

Tên lớp sẽ được nạp khi thực thi MIDlet này
Đị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 để ghicác Không
dữ liệu của chương trình (persistent data)

MIDlet-Description

Mô tả MIDlet (dạng text)

Không

MIDlet-Delete-

Thông báo nhắc nhở khi xóa MIDlet

Không

MIDlet-Install-

URL nhận thông báo về quá trình cài đặt

Không

Bảng Cấu trúc file JAD

1.4. Cơ bản về Midlet.
1.4.1. Cấu trúc cơ bản
Một chương trình MIDlet khi được nạp vào 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

15


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ị.

1.4.2. Xây dựng một ứng dụng MIDlet:
Chúng ta xây dựng một ứng dụng MIDlet bằng cách kế thừa (extends) lớp

MIDlet. Lớp này thực chất là một interface và chúng ta phải khai báo ba hàm sau
đây: startApp(), pauseApp() và destroyApp(). Đây là một ví dụ về một chương
trình MIDlet đơn giản:
public class Shell extends MIDlet {
// phương thức khởi tạo (constructor) không bắt buộc phải có
public Shell(){ … }
// Được application manager gọi trước khi thực thi MIDlet
public void startApp(){…}
// Được gọi trước khi tạm dừng MIDlet
public void pauseApp(){ …}
// Được gọi trước khi kết thúc chương trình
public void destroyApp(boolean unconditional){… }
}

1.4.3. Lớp MIDlet:
Lơp MIDlet đượ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;
}
Ba hàm được nêu ở trên là ba hàm bắt buộc chúng ta phải xây dựng khi
tạo ứng dụng MIDlet. Lớp MIDlet được chứa trong package
javax.microedition.midlet

16


Sơ đồ hoạt động của Midlet

Hình 1.6 Sơ đồ MiDlet
Ở đây tôi xin mô tả hai quá trình quan trọng nhất của một ứng dụng
MIDlet là quá trình khởi nạp và quá trình thoát ứng dụng:
– 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
(constructor).
• Ứ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.
– 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.

17


1.4.4. Lớp MIDletStateChangeException:
Khi tìm hiểu về package javax.microedition.midlet, còn một lớp quan
trọng chúng ta phải chú ý đến là lớp MIDletStateChangeException. Ứng dụng
MIDlet có hai hàm có khả năng tạo ra (throw) Exception này là hàm
destroyApp() và hàm startApp().
Như chúng ta đã biết, trước khi ứng dụng được đưa vào trạng thái active
thì hàm startApp() sẽ được gọi. Nếu trong quá trình gọi hàm này dẫn đến phát

sinh lỗi (thiết bị hết tài nguyên, tài nguyên cần dùng đang bị ứng dụng
khác chiếm…) thì MIDletStateChangeException sẽ được tạo ra. Trong
quá trình thoát, hàm destroyApp() cũng có thể phát sinh exception này, ví dụ
như khi chúng ta thoát mà chương trình đang nhận dữ liệu hết sức quan trọng từ
network ta có thể phát sinh exception để dừng việc thoát.
Ta xem xét hàm destroyApp(boolean condition):
Tham số condition ở đây có một ý nghĩa khá thú vị, nếu tham số này là
true dù chúng ta có phát sinh exception MIDletStateChangeException thì ứng
dụng vẫn thoát; chỉ khi nào tham số này là false thì exception
MIDletStateChangeException mới có khả năng hủy việc thoát chương trình.

1.4.5.Display
Ứng dụng của chúng ta chắc chắn có nhu cầu xuất dữ liệu ra màn hình.
Việc này trong một ứng dụng MIDlet do một đối tượng thuộc lớp display
đảm nhiệm. Lớp này nằm trong package javax.microedition.lcdui, package này
chứa hầu như tất cả các lớp phục vụ cho việc phát triển giao diện của ứng dụng.
Chúng ta sẽ xem xét một số hàm quan trọng nhất của lớp Display:
Phương thức:

Mô tả:

static Display getDisplay(MIDlet m)

Lấy đối tượng Display của MIDlet

Displayable getCurrent()

Lấy về đối tượng hiện thời

void

setCurrent
(Alert
Displayable nextDisplayable)

alert, Đối tượng Alert

void setCurrent (Displayable next)

Đối tượng Alert

boolean isColor()

Kiểm tra xem Display có hỗ trợ hệ

18


màu này không
int numColors()

Xem hệ thống hỗ trợ bao nhiêu màu
Bảng Lớp Display

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.
Ví dụ: Display display=Display.getDisplay(this);
Tham số đầu vào là một MIDlet, ở đây chúng ta gọi hàm từ lớp kế thừa từ
MIDlet nên có thể truyền vào con trỏ this. Thực ra công dụng chính của Display
là cho phép hiển thị đối tượng nào lên màn hình hiện thời. Các đối tượng có thể

hiển thị lên màn hình là các đối tượng thuộc lớp Displayable (sẽ được giới thiệu
sau), ví dụ như form, TextBox, Canvas,Screen…
Ta xét ví dụ sau:
public class Vidu extends MIDlet
{Form mainForm;
Vidu{
mainForm=new Form(…….); }
public void startApp()
{ Display display=Display.getDisplay(this);
Display.setCurrent(mainFrom); }
}
Ban đầu ta khởi tạo một form để thể hiện lên màn hình, sau khi ứng dụng
MIDlet được nạp vào bộ nhớ constructor được gọi để tạo form. Sau đó, phương
thức startApp() được gọi, trong phương thức này ta chọn Form mainForm để thể
hiện lên màn hình bằng lệnh setCurrent. Khi ứng dụng bị tạm ngưng (paused) và
phục hồi trở lại (resume) thì hàm startApp() cũng được gọi và form lại được thể
hiện trên màn hình. Đến đây chúng ta có thể hình dung được phần nào tác dụng
của đối tượng Display.

1.4.6. Lớp 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

19


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. Ở những phần sau chúng ta sẽ tìm hiểu kỹ hơn về các lớp giao diện ở
cấp thấp lẫn cấp cao.
* Tạo một đối tượng Displayable:
Thông thường ta không tạo trực tiếp một đối tượng thuộc lớp Displayable
mà sử dụng các lớp con của nó. Để viết các ứng dụng đồ họa ta thường kế thừa
từ lớp Canvas:
public class GameScreen extends Canvas
{ draw images, shapes, text …}
Khi xây dựng các ứng dụng tiện ích (ít dùng đến các chức năng đồ họa) ta
sẽ dùng các lớp đồ họa cấp cao như Form, TextBox … hoặc kế thừa từ các lớp
này.
Các hàm chính của lớp Displayable:

Phương thức:

Mô tả:

void addCommand
(Command cmd)

Thêm một đối tượng Command vào đối
tượng Displayable

void removeCommand
(Command

Xóa bỏ một đối tượng Command từ đối
tượng Displayable

20


void setCommandListener

Thêm CommandListener vào đối tượng
Displayble

boolean isShown()

Kiểm tra đối tượng Displayable có được thể
hiện trên thiết bị hay không?
Bảng Lớp Displayable

Tại thời điểm này chúng ta có thể hình dung một Command như một nút
ấn điều khiển trong ứng dụng của chúng ta, CommandListener có tác dụng
chuyển các sự kiện khi người dùng kích hoạt một Command đến lớp xử lý của
ứng dụng. Để “bắt” được các sự kiện được chuyển tới khi người dùng kích hoạt
một Command, ứng dụng của chúng ta phải cài đặt hàm commandAction. Ví dụ
như sau:
public void commandAction(Command c, Displayable s)
{if (c == cmExit)
{destroyApp(true);
notifyDestroyed();

}
}

1.4.7. Quản lý các sự kiện (event)
A> .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.
Trong ví dụ sau ta thấy Command “Exit” tương ứng với một nút ấn trên
điện thoại. 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. Trước tiên, ta sẽ tìm hiểu các công việc
phải làm để thêm một command vào ứng dụng:

21


Hình 1.7 Command Exit
• Tạo một command để lưu giữ thông tin về event
• Thêm command này vào Form, TextBox hay Alert… (các đối
tượng displayable)
• Thêm một listener vào các Form hay TextBox … trên.
Khi phát hiện một event được kích hoạt, bộ listener sẽ gọi hàm
commandListener() và truyền các thông tin về event làm thông số cho hàm.
Khi chúng ta tạo một Command có ba thông số cần cung cấp:
Command CmdHelp = new Command(“Help”,command.OK, 1);
Label: Đoạn văn bản được xem như nhãn của command. Như trong hình

3.1, “Exit” là nhãn của command. Như trong hình 3.2, ta thấy đây cũng là label
của command nhưng được thể hiện ở dạng khác: dạng menu.

Hình 1.8 Command Label
Type: Thật thuận tiện nếu ta có thể ánh xạ một command với một nút trên
thiết bị (ta gọi là “soft-button”). Giả sử ta có một command tên help và ánh xạ
được với HELP Button trên thiết bị thì thật trực quan và dễ dàng cho người
dùng.Thông số Type giúp chúng ta làm chuyện này: Ta chọn Command.HELP.
Nếu thiết bị không có nút help, thông số này không có ý nghĩa và command được
đối xử như các command thông thường. Tuy nhiên, ta cần lưu ý khi ta

22


tặt type là Command.HELP thì không có nghĩa khi ta chọn command này các
hướng dẫn sẽ được phát sinh mà ta cần phải làm việc này trong hàm
commandAction(). Thông số type chỉ giúp việc ánh xạ các nút soft-button được
dễ dàng.
Các type được hỗ trợ:
Giá trị

Mô tả

BACK

Dùng để đi ngược lại màn hình trước đó.

CANCEL

Dùng để hủy công việc đang thực hiện

EXIT

Dùng để thoát chương trình

HELP

Cung cấp thông tin trợ giúp

ITEM

Dùng để ánh xạ một Command với một item trên màn hình. Giả sử khi
ta dùng giao diện List, khi chọn một item ta có thể gắn item này với
một command để phát sinh một sự kiện nào đó.

OK

Xác nhận một yêu cầu nào đó hoặc thoát khỏi màn hình thông báo.

SCREEN

Thông thường thiết bị không có các soft button tương ứng với các
command dạng này. Việc thể hiện các command sẽ tùy vào từng thiết
bị (sẽ có các ví dụ)

STOP

Dừng một công việc đang thực hiện.

Bảng Các Command Type

Như đã đề cập, các type chỉ có ý nghĩa khi thiết bị có một nút tương ứng
dành riêng cho type này (như nút help của thiết bị hình 3.3).
Priority: Độ ưu tiên, dùng để sắp xếp các command từ trên xuống dưới
hay trái sang phải khi được thể hiện chung dạng menu. Hình 3.2 thể hiện
command Upload có độ ưu tiên cao hơn command Download. Giá trị này càng
cao thì độ ưu tiên càng thấp. Sau đây là các hàm chính của lớp Command và
CommandListener (hai lớp này nằm trong package javax.microedition.lcdui).
Lớp javax.microedition.lcdui.Command
Phương thức

Chức năng

23


Command (String
cmdType, int priority)

label,

int

Hàm khởi tạo, các thông số đã được
trình bày

int getCommandType()

Cho biết Type của Command

int getLabel()

Cho biết Label của Command

int getPriority()

Cho biết độ ưu tiên
Lớp javax.microedition.lcdui.CommandListener

void commandAction(Command

Được gọi khi command c nằm trên
đối tượng

Bảng các phương thức Command

B>. Item và 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
(chúng ta sẽ tìm hiểu về các items này trong phần Đồ Họa Cấp Cao). Items chỉ
được sử dụng như một thành phần của form, khác với Commands có thể được sử
dụng trong Form, TextBox, List và Canvas.
Khi chúng ta thêm một Item vào Form, để 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:

24


• 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.

25