LẬP TRÌNH ỨNG DỤNG MOBILE BẰNG JAVA

Thực thi chương trình...145 Để một chiếc điện thoại có thể chạy được ứng dụng MIDlet thì trước hết ta hãy xem những yêu cầu ràng buộc để một ứng dụng java chạy được trên mobile vấn đề n

TRƯỜNG ĐẠI HỌC MỞ TP.HCM KHOA CÔNG NGHỆ THÔNG TIN

KHÓA LUẬN TỐT NGHIỆP

TP.HỒ CHÍ MINH – NĂM 2009

Luận án đã được thực hiện trong một thời gian dài, và đây là thành phẩm lớn nhất mà tôi thực hiện được trong quá trình học tập tại trường Ngoài sự cố gắng, nỗ lực của bản thân, còn nhận sự giúp đỡ của nhiều người để tôi có thể hoàn thiện được luận án như ngày nay

Đầu tiên, con xin vô cùng biết ơn Ba Mẹ, đã có công sinh thành, dưỡng dục, thương yêu và chăm sóc để cho con có được ngày hôm nay

Tôi xin cảm ơn các thầy cô Khoa Công nghệ thông tin và các thầy cô trường Đại Học

Mở TP.HCM đã truyền đạt những kiến thức, kinh nghiệm quý báu trong quá trình học tập

và nghiên cứu

Em xin chân thành cảm ơn tiến sĩ.Nguyễn Văn Hiệp, giảng viên Khoa Công nghệ thông tin – trường Đại Học Bách Khoa Tp.HCM đã tận tình hướng dẫn, định hướng, góp

ý trong quá trình thực hiện luận văn

Tôi xin cảm ơn tập thể nhóm lập trình phần mềm công ty Tin học Thảo Chương đã tạo điều kiện cho tôi trong quá trình thực hiện luân văn này

Tôi xin cảm ơn các bạn đã động viên cho tôi trong quá trình thực hiện luận văn

Mặc dù, tôi đã nỗ lực để hoàn thành bài báo cáo này và đã đạt một số kết quả nhất định, tuy nhiên những sai sót trong báo cáo không tránh khỏi, kính mong sự thông cảm và đóng gớp ý kiến của quý thầy cô và các bạn

Xin chân thành cảm ơn!

CHƯƠNG 1: MỤC TIÊU VÀ NỘI DUNG ĐỀ TÀI 4

1.1 Đặt vấn đề 4

1.2 Mục tiêu đặt ra cho đề tài 5

1.3 Nội dung 6

CHƯƠNG 2: TỔNG QUAN VỀ J2ME 7

2.1 CÁC THÀNH PHẦN CỦA J2ME 7

2.1.1 Tầng phần cứng thiết bị (Device Hardware Layer) 8

2.1.2 Tầng máy ảo Java (Java Virtual Machine Layer) 8

2.1.3 Tầng cấu hình (Configuration Layer) 10

2.1.4 Tầng hiện trạng (Profile Layer) 12

2.1.5 Một số hạn chế của J2ME so với các phiên bản khác(chủ yếu nằm ở tầng Configuration này): 12

2.2 CHỨC NĂNG CÁC THÀNH PHẦN 13

2.2.1 Máy ảo Java (Kilobyte Virtual Machine - KVM) 13

2.2.2 CLDC 15

2.2.2.1 Yêu cầu phần cứng dành cho CLDC: 16

2.2.2.2 Yêu cầu phần mềm dành cho CLDC: 17

2.2.2.3 Sự khác biệt giữa CLDC 1.0 và CLDC 1.1 17

2.2.2.4 Danh sách các lớp mà CLDC cung cấp 17

2.2.3 MIDP 20

2.2.3.1 Định nghĩa: 20

2.2.3.2 Những chức năng mà MIDP không hỗ trợ: 20

2.2.3.3 Những chức năng mà MIDP cung cấp 21

2.2.3.4 Những yêu cầu dành cho MIDP 21

2.2.3.5 Các dạng profile 22

2.2.3.6 Sự khác nhau giữa MIDP 1.0 và MIDP 2.0 22

2.2.3.7 Danh sách lớp mà MIDP cung cấp 23

CHƯƠNG 3: BỘ MIDLET 26

3.1 ĐỊNH NGHĨA: 26

3.2 CÁC DẠNG MIDLET 26

3.2.1 Ứng dụng đơn (standalone application) 26

3.2.2 Ứng dụng nối mạng (networked application) 26

3.3 CẤU TRÚC MỘT BỘ MIDLET (MIDlet suite) 26

3.3.1 Cấu trúc file Jar 26

3.3.2 File JAD (Java Application Descriptor File) : 27

3.3.2.1 Đặt tả 27

3.3.2.2 Các phương thức trong MIDlet 29

3.3.2.3 Xây dựng một ứng dụng MIDlet: 29

3.3.2.4 Lớp MIDlet: 31

CHƯƠNG 4: GIAO DIỆN ĐỒ HỌA 33

4.1 QUẢN LÝ VIỆC HIỂN THỊ VÀ BẮT SỰ KIỆN .35

4.1.1 Quản lý việc hiển thị 35

4.1.1.1 Lớp Display 35

4.1.1.2 Lớp Displayable 36

4.1.2 Quản lý các sự kiện: 37

4.1.2.1 Command và CommandListener 38

4.1.2.2 Item và ItemStateListener 41

4.2 GIAO DIỆN ĐỒ HỌA CẤP CAO 42

4.2.1 Screen: 42

4.2.2 Form: 42

4.2.3 Item: 43

4.2.3.1 DateField: 44

4.2.3.2 Gauge: 45

4.2.3.3 StringItem: 47

4.2.3.4 TextField: 47

4.2.3.5 ChoiceGroup: 50

4.2.3.6 Image: 53

4.2.3.7 ImageItem: 54

4.2.4 TextBox 56

4.2.5 Alert 58

4.2.6 AlertType: 60

4.2.7 List: 61

4.2.7.1 Các dạng của list 61

4.2.7.2 Bắt sự kiện cho các đối tượng List 62

4.2.7.3 So sánh giữa lớp List và lớp ChoiceGroup: 62

4.2.8 Ticker: 64

4.3 ĐỒ HỌA CẤP THẤP 64

4.3.1 Canvas: 65

4.3.1.1 Hệ tọa độ 65

4.3.1.2 Vẽ trên đối tượng Canvas: 66

4.3.1.3 Bắt sự kiện trong các đối tượng Canvas 68

4.3.1.4 Game action: 70

4.3.2 Graphics: 72

4.3.2.1 Color: 73

4.3.2.2 Nét vẽ: 74

4.3.2.3 Font chữ: 76

4.3.2.4 Vẽ các đối tượng hình ảnh (Image): 78

4.3.2.5 Các phương thức tịnh tiến của đối tượng: 79

4.3.2.6 Vùng xén (Clipping regions): 81

CHƯƠNG 5: LƯU TRỮ THÔNG TIN VÀ LẬP TRÌNH MẠNG 82

 NộI DUNG TRÌNH BÀY: 82

 LƯU TRữ THÔNG TIN TRONG J2ME 82

82

5.1 Lưu trữ thông tin với RMS 82

5.1.1 RecordStore 83

5.1.2 RecordEnumeration 91

5.1.3 Sắp xếp các bằng RecordComparator 93

5.1.4 Lọc record với RecordFilter 95

5.1.5 RecordListener 96

5.2 Kết nối mạng với Generic Connection Framework (GCF) .97

5.2.1 Giới thiệu GCF 97

CHƯƠNG 6: NHỮNG QUI TRÌNH VÀ RÀNG BUỘC ĐỂ MỘT ỨNG DỤNG TRÊN JBUILDER CHẠY ĐƯỢC TRÊN MOBILE 117

6.1 Tìm hiểu và trình bày qui trình kỹ thuật để xây dựng một ứng dụng mobile trên Jbuilder 117 6.1.1 Cài đặt Jbuilder 117

6.1.2 Cài đặt SDK cho Nokia 121

6.1.3 Quá trình xây dựng 1 MIDlet 127

6.1.3.1 Quá trình đầu tiên: Tạo mới một project 127

6.1.3.2 Quá trình thứ hai: Tạo một lớp MIDlet 131

6.1.4 Các bước để xây dựng các file.Jar và file.Jad: 137

6.2 Tìm hiểu và trình bày các yêu cầu ràng buộc để một ứng dụng mobile trên Jbuilder có thể chạy trên mobile 141

6.2.1 Những ràng buộc trên thiết bị di động 141

6.2.1.1 Ràng buộc về phần cứng 141

6.2.1.2 Ràng buộc về phần mềm 142

6.2.2 Những ràng buộc đối với ứng dụng 142

CHƯƠNG 7: GIỚI THIỆU ỨNG DỤNG DEMO 143

7.1 Giới thiệu 143

7.2 Xây dựng một MIDlet .143

7.3 Mô tả chương trình .143

7.4 Các chức năng của chương trình: 144

7.5 Thực thi chương trình 145

Để một chiếc điện thoại có thể chạy được ứng dụng MIDlet thì trước hết ta hãy xem những yêu cầu ràng buộc để một ứng dụng java chạy được trên mobile (vấn đề này được trình bài trong chương 6) 145

CHƯƠNG 8: KẾT QUẢ VÀ HƯỚNG PHÁT TRIỂN 150

8.1 Kết quả 150

8.2 Nhưng hạn chế: 150

Về quyển luận văn trình bày Error! Bookmark not defined Về chương trình Error! Bookmark not defined 8.3 Hướng phát triển 150

CHƯƠNG 1: MỤC TIÊU VÀ NỘI DUNG ĐỀ TÀI

 Nội dung trình bày:

 Mục tiêu và nội dung của đề tại

1.1 Đặt vấn đề

Với chiếc máy tính để bàn (máy PC) thì ngày này chúng ta đã làm được hầu hết mọi việc từ đơn giản đến phức tạp Nhưng mà máy PC chỉ làm việc cố định, do đó, máy tính Laptop xuất hiện với tính năng nhỏ gọn có thể mang theo và làm việc hầu như ở mọi nơi Ngày nay các thiết bị di động đã trở nên rất phổ biến và được sử dụng rất rộng rãi tại Việt Nam, đặc biệt là các loại điện thoại di động Nhiều người đã coi điện thoại di động như một vật không thể thiếu trong cuộc sống hằng ngày Nắm bắt được nhu cầu đó, các nhà sản xuất điện thoại đã đẩy mạnh về mặt công nghệ, tăng cường mẫu mã, tích hợp các chức năng ngày càng nhiều vào các dòng sản phẩm mới, hầu đem lại cho người dùng những tiện ích cao cấp nhất với các công nghệ tiên tiến nhất Giờ đây, người dùng điện thoại có thể nghe nhạc, xem phim, chụp hình chơi game và thậm chí là xem TV, lướt web chỉ với chiếc điện thoại bé xíu ngay bên mình Chiếc điện thoại đã thực sự không chỉ là một phương tiên liên lạc, mà nó còn mang cả thế giới giải trí, thế giới Mobile đến với từng người mọi lúc mọi nơi Với công nghệ phát triển không ngừng như hiện nay, việc đòi hỏi các ứng dụng tốt hơn cũng ngày càng trở thành một yêu cầu đi đôi với sự phát triển của công nghệ Một chiếc điện thoại tốt luôn đòi hỏi những phần mềm cao cấp đi kèm với nó Nhưng vấn đề lại đặt ra

là có quá nhiều nhà sản xuất điện thoại sử dụng nhiều công nghệ khác nhau Vậy làm sao chúng ta có thể tạo ra được những ứng dụng chạy trên tất cả các dòng sản phẩm đó? Đây quả thật là một vấn đề không đơn giản chút nào Một thực tế đặt ra cho các nhà phát triển phần mềm 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à cũng 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 Như chúng ta đã biết, ban đầu Java được xây dựng chỉ gồm một phiên bản duy nhất, ngày nay được biết đến với tên J2SE (Java 2 Standard Edition) với

phương châm là “Write once, run anywhere” tạm dịch là “viết một lần, chạy trên mọi môi trường” Java được hình thành trên ý tưởng xây dựng một ngôn ngữ mà lập trình viên chỉ cần viết một lần duy nhất nhưng ứng dụng có thể chạy trên bất cứ môi trường nào có hổ trợ Java Virtual Machine tạm dịch là “máy ảo Java” Các nhà phát triển Java

đã cho ra một ngôn J2ME 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à 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ợ rất tốt 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 J2ME được xem như là một nhánh của ngôn ngữ lập trình Java được phát triển nhằm hướng tới việc lập trình cho các thiết bị nhỏ có bộ nhớ, khả năng hiển thị và xử lý hạn chế

1.2 Mục tiêu đặt ra cho đề tài

 Tìm hiểu các ràng buộc về phần cứng của các chủng loại thiết bị di động hiện nay

 Hiểu chi tiết về J2ME, các kiến trúc nên tảng của nó và những ứng dụng của nó

để lập trình trên các thiết bị di động

 Nắm được các kỹ thuật xử lý form, âm thanh, hình ảnh, và lưu trữ trên điện thoại

di động

 Tìm hiểu qui trình kỹ thuật để xây dựng ứng dụng mobile trên Jbuilder

 Những ràng buộc để một ứng dụng viết trên Jbuilder có thể chạy trên mobile

 Ứng dụng các kết quả đạt được để xây dựng chương trình đơn giản, có các tiện ích phục vụ nhu cầu của người sử dụng điện thoại di động

 Áp dụng thành công trên một số dòng máy điện thoại di động hỗ trợ Java của các hãng như Nokia, SonyEricsson, Samsung,…

 Những mục tiêu trên được đặt ra trên nhằm xây dựng một quyển luận văn tốt hơn, đây đủ hơn Và xa hơn nữa là, luận văn này đã trình bài đầy đủ những gì cần thiết để cho mọi người có thể tự viết những ứng dụng riêng cho chiếc điện thoại của mình

1.3 Nội dung

Với những mục tiêu trên thì quyển luận văn xin trình bày những nội dung sau:

 Giới thiệu chung về ngôn ngữ J2ME: tầng configuration và profile

 Các vấn đề liên quan đến một bộ MIDlet

 Lập trình trên thiết bị di động sử dụng giao diện đồ họa cấp thấp và cấp cao

 Việc lưu trữ thông tin trên MIDlet xuống bảng ghi và truy xuất chúng khi cần thiết

 Lập trình mạng

 Các bước cần thiết để xây dựng và thực thi một MIDlet

 Những ràng buộc để một ứng dụng viết trên Jbuilder chạy được trên Mobile

 Xây dựng ứng dụng game caro để demo

CHƯƠNG 2: TỔNG QUAN VỀ J2ME

 Nội dung trình bày:

 Trình bài những thành phần chính để cấu thành nên J2ME

 Máy ảo java

 Configuration và Profile

 Chức năng của các thành phần này

2.1 CÁC THÀNH PHẦN CỦA J2ME

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ự Để đạt được mục tiêu này, 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 Sau đây là các tầng của J2ME được xây dựng (2)

Hình 1: Các thành phần của J2ME

Khái niệm điện thoại di động là tương đối rộng lớn Chúng bao gồm những thiết bị

có kích thước vật lý khác nhau nhiều lần và cho dù cùng kích thước những thiết bị này vẫn có khả năng xử lý cũng như thể hiện cũng khác nhau (những chiếc điện thoại hiển thị 12,000 pixels cho đến những chiếc PDA 20000 pixels) Để đáp ứng được nhu cầu khác nhau của những thiết bị này, bản thân ngôn ngữ J2ME cũng chia thành những thành phần nhỏ hơn

Hình 2: Cấu trúc của thiết bị MID

MIDP Applications

OEM-Specific Applications

Native Applications

OEM-Specific Classes Mobile Information

Device Profile (MIDP) Connected Limited Device Configuration (CLDC)

Native Operating System

Mobile Information Device(MID)

Mỗi tầng ở trên tầng Mobile Information Device là tầng trừu tượng hơn cung cấp cho lập trình viên nhiều giao diện lập trình ứng dụng (API-Application Program Interface) thân thiện hơn

2.1.1 Tầng phần cứng thiết bị (Device Hardware Layer)

Đây chính là thiết bị di động thật sự với cấu hình phần cứng của nó về bộ nhớ và tốc độ xử lý Dĩ nhiên thật ra nó không phải là một phần của J2ME nhưng nó là nơi xuất phát Các thiết bị di động khác nhau có thể có các bộ vi xử lý khác nhau với các tập mã lệnh khác nhau Mục tiêu của J2ME là cung cấp một chuẩn cho tất cả các loại thiết bị di động khác nhau

2.1.2 Tầng máy ảo Java (Java Virtual Machine Layer)

Khi mã nguồn Java được biên dịch nó được chuyển đổi thành mã bytecode Mã bytecode này sau đó được chuyển thành mã ngôn ngữ máy của thiết bị di động Tầng máy ảo Java bao gồm KVM (K Virtual Machine) là bộ biên dịch mã bytecode có nhiệm vụ chuyển mã bytecode của chương trình Java thành ngôn ngữ máy để chạy trên thiết bị di động, và đồng thời máy ảo Java sẽ chịu trách nhiệm việc cung cấp các tính năng bảo mật, cấp phát, thu hồi bộ nhớ và quản lý việc điều phối các tiến trình Tầng này 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ể hoạt động trên bất kỳ thiết bị di động nào có J2ME 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

Đây là những yêu cầu dành cho máy ảo KVM:

 Máy ảo Java chỉ cần 40 – 80 KB bộ nhớ

 Chỉ cần 20 – 40 KB bộ nhớ động

 Có thể chạy với bộ vi xử lý 16 bit và xung nhịp 25 MHz

Mã nguồn java phải trãi qua 2 giai đoạn như hình bên dưới

Hình 3: Hai quá trình biên dịch và thông dịch của mã nguồn java

 Các phiên bản của Java:

Java được giới thiệu lần đầu tiên vào những năm 1995, trong thời gian đầu thì mục tiêu nhắm đến của Java là phát triển của GUIs, applets, và những ứng dụng đặc trưng khác Hai năm sau ngày ra mắt lần đầu tiên, một phiên bản mới là Java 2 Enterprise Edition (J2EE) cũng được giới thiệu nhắm đến việc phát triển các ứng dụng có qui mô lớn hơn (có thể xem là các máy server) Đồng thời phiên bản này cũng đưa ra nhưng công cụ cho việc truy xuất dữ liệu, truyền thông tin, điều khiển việc thực thi

Và phiên bản mới nhất được thêm vào dòng ngôn ngữ Java là Java 2 Micro Edition (J2ME) J2ME nhắm đến việc phát triển ứng dụng cho các ứng dụng có năng lực hạn chế như đầu giải mã kỹ thuật số TV set-top boxes, điện thoại di động…

KVM (Kilobyte Virtual Machine)

Hình 4: Các phiên bản khác nhau của java

Chúng ta có thể thấy các phiên bản khác nhau của Java, phụ thuộc vào phần cứng

mà thiết bị hỗ trợ Hình sẽ thể hiện 3 máy ảo được sử dụng trong những môi trường khác nhau Các Hotspot VM là mặc định máy ảo được cung cấp bởi Sun do thực hiện đầy đủ quy mô phiên bản mới hơn JavaHotspot là một loại máy ảo có khả năng tự động tối ưu hóa nặng nề thực hiện các đoạn mã (hotspots) trong thời gian thực Compact Virtual Machine (CVM) and Kilobyte Virtual Machine (KVM) là những máy ảo nhỏ hơn dùng để hiện thực việc thiết kế để chạy trong những ràng buộc của giới hạn về tài nguyên trên những thiết bị nhỏ

2.1.3 Tầng cấu hình (Configuration Layer)

Tầng cấu hình của CLDC định nghĩa giao diện ngôn ngữ Java (Java language interface) cơ bản để cho phép chương trình Java chạy trên thiết bị di động

Để đáp ứng nhu cầu cho nhiều chủng loại thiết bị khác nhau, Sun đã đưa ra khái niệm Configuration Khái niệm Configuration có mối liên hệ chặt chẽ với máy ảo

Java Nói chính xác hơn, một Configuration qui định những thành phần và những thư viện gốc của ngôn ngữ Java mà máy ảo phải hổ trợ cho configuration đó Việc phân chia thành những configuration khác nhau chủ yếu dựa vào khả năng bộ nhớ, năng lực hiển thị, năng lực xử lý và khả năng kết nối mạng của các thiết bị Như chúng ta đã biết, các thiết bị di động rất khác nhau về nguồn tài nguyên, về khả năng phần cứng Với những thiết bị có năng lực hạn chế, nếu ta đưa nhiều thư viện hỗ trợ vào máy ảo trên thiết bị đó sẽ gây chậm hệ thống và dư thừa không cần thiết Với những thiết bị có khả năng cao hơn, chúng ta sẽ đưa thêm nhiều thư viện hỗ trợ vào máy ảo giúp ích cho công việc lập trình của các nhà phát triển Do đó, nhu cầu phân chia thành nhiều Configuration là việc cần thiết

Hiện nay Sun đã đưa ra hai loại Configuration khác nhau:

 CDC (Connected Divice Configuration):

 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 ít (chủ yếu dùng pin)

 Kết nối mạng Wireless và chậm

Việc phân chia này cũng mang tính chất tương đối, công nghệ hiện nay đang phát triển khá nhanh, và việc phát triển này càng làm cho ranh giới giữa các loại configuration này trở nên không rõ ràng

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, bạ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

2.1.4 Tầng hiện trạng (Profile Layer)

Tầng hiện trạng hay MIDP (Hiện trạng thiết bị thông tin di động-Mobile Information Device Profile) cung cấp tập các API hữu dụng hơn cho lập trình viên Mục đích của hiện trạng là xây dựng trên lớp cấu hình và cung cấp nhiều thư viện ứng dụng hơn MIDP định nghĩa các API riêng biệt cho thiết bị di động Cũng có thể có các hiện trạng và các API khác ngoài MIDP được dùng cho ứng dụng Ví dụ, có thể có hiện trạng PDA định nghĩa các lớp và phương thức hữu dụng cho việc tạo các ứng dụng PDA (lịch, sổ hẹn, sổ địa chỉ,…) Cũng có thể có một hiện trạng định nghĩa các API cho việc tạo các ứng dụng Bluetooth Thực tế, các hiện trạng kể trên và tập các API đang được xây dựng Chuẩn hiện trạng PDA là đặc tả JSR - 75 và chuẩn bluetooth API là đặc tả JSR - 82 với JSR là viết tắt của Java Specification Request

2.1.5 Một số hạn chế của J2ME so với các phiên bản khác(chủ yếu nằm ở tầng Configuration này):

 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ả 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 handle,….trước khi đối tượng bị

“phá hủy” Tuy nhiên trong J2ME ,để cải tiến việc thực thi và giảm toàn bộ các yêu cầu, CLDL loại bỏ hẳn đối tượng finalize, điều này có nghĩa là không có phương thức Object.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) Cũng do nguyên nhân hạn chế tài nguyê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, CLDC không hỗ trợ bất kỳ java.lang.Error nào

 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 J2ME và J2ME, 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 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 J2ME và J2EE, một trong những khác biệt chính là quá trình Class Verify (tạm dịch là “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 kb 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 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

2.2 CHỨC NĂNG CÁC THÀNH PHẦN

2.2.1 Máy ảo Java (Kilobyte Virtual Machine - KVM)

Vai trò của máy ảo Java hay KVM là dịch mã bytecode được sinh ra từ chương trình Java đã biên dịch sang ngôn ngữ máy Chính KVM sẽ chuẩn hóa output 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 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 Như vậy 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 Hình dưới đây biểu diễn tiến trình xây dựng ứng dụng MIDlet hoàn chỉnh và vai trò của KVM

Hình 5: Tiến trình xây dựng một MIDlet

 Xây dựng ứng dụng trên IDE (Intergrated Development Environment - Môi trường phát triển tích hợp)

Đây là những công việc của lập trình viên trên:

 Tạo các tập tin nguồn Java:

 Bước đầu tiên là lập trình viên phải tạo mã nguồn Java, có thể có nhiều tập tin (*.java) (vấn đề này được trình bày trong chương 6)

 Biên dịch trên IDE:

 Bộ biên dịch Java (Java Compiler): Biên dịch mã nguồn thành mã bytecode

Bộ biên dịch Java sẽ 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 lưu trong các tập tin *.class và một tập tin *.class sinh ra cho mỗi lớp Java

 Bộ tiền kiểm tra (Preverifier): 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

Tập tin nguồn java

Bộ biên dịch mã bytecode

Tập tin JAR

Thiết bị đích

Trạm phát triể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 Lưu ý: Nếu không có quá trình tiền kiểm tra này thì thiết bị di động sẽ từ chối ứng dụng

 Tạo tập tin JAR

IDE sẽ tạo một tập tin JAR chứa:

 Tất cả các tập tin *.class

 Các hình ảnh của ứng dụng Hiện tại chỉ hỗ trợ tập tin *.png

 Các tập tin dữ liệu có thể được yêu cầu bởi ứng dụng

 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

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 (tập tin *.jar) về thiết bị di động – xem phần phụ lục)

 Trên thiết bị di động

 Bộ tiền kiểm tra: 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

 Bộ quản lý ứng dụng: Bộ quản lý ứng dụng trên thiết bị di động sẽ lưu 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

 Người dùng 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

 KVM sẽ dịch mã bytecode sang ngôn ngữ máy của thiết bị di động để chạy 2.2.2 CLDC

CLDC - cấu hình thiết bị kết nối giới hạn đây là tầng nằm kế trên tầng KVM, đây là một tập các API định nghĩa lõi của ngôn ngữ J2ME 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 (các lớp và các phương thức ) cho phép một ứng dụng Java chạy trên thiết bị di động Tập các API hữu dụng và chuyên biệt hơn được chứa trong tầng hiện trạng - profile layer, nhưng chính tầng CLDC này cung cấp cơ sở cho tầng hiện trạng Các CLDC API được định nghĩa với sự hợp tác với 18 công ty là bộ phận của JCP (Java Community Process) Nhóm này giúp bảo đảm rằng các API được định nghĩa sẽ hữu dụng và thiết thực cho cả nhà phát triển lẫn nhà sản xuất thiết

bị di động

Hình 6: Tổng quan về CLDC

2.2.2.1 Yêu cầu phần cứng dành cho CLDC:

Khi đề ra yêu về phần cứng việc xem xét các chi tiết như bộ xử lý, bộ nhớ… và các thành phần mềm hiện có trên các thiết bị di động là việc vô cùng quan trọng Nhằm mục đích phục vụ tối đa các thiết bị hiện có trên thị trường, CLDC chỉ đề ra các yêu cầu về bộ nhớ và không đề ra yêu cầu nào cho các thành phần khác 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 CDLC 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 còn được gọi là heap)

J2SE CDC # O J2SE CLDC # O

CLDC CDC J2SE

CDC

CLDC

2.2.2.2 Yêu cầu phần mềm dành cho CLDC:

 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 như:

số JSR – 139 Dưới đây là sự khác biệt chính của 2 phiên bản:

 Kiểu số thực được hỗ trợ, 2 class Float và Double được đưa thêm vào trong CDLC 1.1 và đồng thời cũng kèm theo những phương thức hỗ trợ cho 2 class này

 Thiết kế lại những class Calendar/Date/TimeZone so với J2SE

 Những thread hiện tại đã có phương thức Thread.getName() và chúng ta

có thể ngắt chúng bởi phương thức Thread.interrup()(2)

 Việc bắt lỗi đã trở nên dễ hiểu hơn, có đưa thêm vào một lớp mới đó là NoClassDefFoundError

 Nhiều thay đổi trên các thư viện không quan trọng, như là thêm các trường và các phương thức như:

o Boolean.TRUE and Boolean.FALSE

Đây là tầng nằm kế trên tầng CLDC, định nghĩa dành riêng cho các thiết

bị di động và là thành phần chính trong J2ME CLDC chỉ cung cấp các API đơn giản, giả vụ nếu mà Sun không cung cấp MIDP thì người lập trình sẽ phải xây dựng lại tất cả các giao diện MIDP cung cấp các chức năng cơ bản cho hầu hết các dòng thiết bị di động phổ biến nhất như các máy điện thoại di động và các máy PDA Tuy nhiên, vì phải xây dựng thư viện cho một thiết bị rất hạn chế về tài nguyên nên MIDP cũng có những giới hạn của nó

2.2.3.2 Những chức năng mà MIDP không hỗ trợ:

 Không hỗ trợ phép tính dấu phẩy động (floating point) là do tính này đòi hỏi rất nhiều tài nguyên CPU và phần lớn các CPU cho các thiết bị di động không hỗ trợ phép tính này

 Không hỗ trợ bộ nạp class - Class Loader

 Hỗ trợ từ khóa finalize() như trong J2SE: Việc “dọn dẹp“ tài nguyên trước khi nó bị xóa được đẩy về phía các lập trình viên

 Không hỗ trợ JNI

 Không hỗ trợ nhiều cho thao tác bắt lỗi

 Phần lớn các thư viện API cho Swing và AWT không thể sử dụng được trong MIDP

 Không hỗ trợ các tính năng quản lý file và thư mục: Đây có thể làm bạn ngạc nhiên nhưng thực tế là các thiết bị J2ME không có hỗ trợ các thiết bị lưu 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 mỗi 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) để cung cấp khả năng lưu trữ cho các thiết bị này

2.2.3.3 Những chức năng mà MIDP cung cấp

 Các lớp và kiểu dữ liệu: Phần lớn các lớp mà các lập trình viên Java 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

 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

 Hỗ trợ Form và các giao diện người dùng

 Có ít nhất 32 kilobytes để chạy Java

 Có kết nối không dây (wireless network)

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 và chuyển dữ liệu đó cho máy ảo Java

 Hệ điều hành phải hỗ trợ việc đọc và 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 khi ngắt máy, tắt điện)

 Phải hỗ trợ truy xuất mạng, đặc biệt phải có tính năng đọc và ghi dữ liệu thông qua mạng không dây

 PDA Profile: tương ứng 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 Java 2 1.3

 Ngoài ra còn có Personal Basis Profile, Personal Profile, RIM Profile, Game Profile

Lưu ý: Luận văn chủ yếu 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

2.2.3.6 Sự khác nhau giữa MIDP 1.0 và MIDP 2.0

Bảng 1: Sự cải tiến của MIDP 2.0 so với MIDP 1.0

Mạng  Hỗ trợ giao thức HTTPS, download qua mạng an toàn hơn

 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 không có sự chấp thuận của người sử dụng

Âm thanh  Thêm các API hỗ trợ Multimedia Một trong nhưng 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)

UI (Giao diện)  Mở rộng các tính năng của Form và Item

 Cải tiến việc bố trí các công cụ

 Các điều khiển được cải tiến tốt hơn

 Có thể xây dựng các điều khiển riêng

Games  Hỗ trợ lớp Graphics

 Hỗ trợ 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 Ý tưởng cơ bản của Game API là việc giả định rằng một màn hình game là tập hợp các layer (lớp) Ví dụ như: trong một game đua xe thì màn hình nền là một layer, con đường là một layer và chiếc xe được xem như đang nằm trên layer khác 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

Hình ảnh  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

2.2.3.7 Danh sách lớp mà MIDP cung cấp

Hầu hết các MIDlet đều ở một trong hai dạng sau:

3.2.1 Ứng dụng đơn (standalone application)

Đây là ứng dụng được nạp hoàn toàn vào thiết bị và có thể chạy bất kỳ lúc nào thiết bị được mở, không yêu cầu tài nguyên bên ngoài Loại này bao gồm:

 Các ứng dụng PDA và ứng dụng organizer như sổ địa chỉ, danh sách công việc và lịch hẹn

 Các công cụ đơn giản như máy làm tính (calculator)

 Trò chơi

3.2.2 Ứng dụng nối mạng (networked application)

Được chia thành ít nhất hai thành phần, một thành phần là client được triển khai trên thiết bị di động Thành phần này sẽ ít được dùng nếu không có kết nối đến ít nhất một server trên hệ thống Server thường là được đặt trong môi trường J2EE, và phục vụ bằng Web hoặc các giao thức Internet khác

3.3 CẤU TRÚC MỘT BỘ MIDLET (MIDlet suite)

Chúng 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 được cung cấp bởi CLDC và MIDP Một MIDlet Suite là 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)

3.3.1 Cấu trúc 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à mainfest Đây là tập tin mô tả nội dung của toàn file jar Trong file mainfest chúng

ta có thể định nghĩa các thuộc tính của file jar (có 6 thuộc tính bắt buộc):

Bảng 2: Các thuộc tính trong tập tin JAR

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 con: Tên MIDlet, File Icon MIDlet (có thể không cần), và tên lớp sẽ được nạp khi thực thi MIDlet này

Địa chỉ trang web nhà phát triển MIDlet Không

Lưu ý: Nếu 1 trong 6 thông tin này thiếu thì thiết bị sẽ từ chối chạy các ứng dụng

trong file jar này

3.3.2 File JAD (Java Application Descriptor File) :

3.3.2.1 Đặt tả

Những thông tin trong file jad sẽ cung cấp thông tin về các MIDlet trong 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 ứng dụng hay không Bên cạnh đó, nó còn 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)

Ta cũng có thể định nghĩa thêm các thuộc tính riêng, bắt đầu bằng “MIDlet –“ tùy theo mục đích của lập trình viên

Bảng 3: Các thuộc tính trong tập tin JAD

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 con: Tên MIDlet, File Icon MIDlet (có thể không cần), và tên lớp sẽ được nạp khi thực thi MIDlet này

Có

MIDlet-Jar-URL

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 (persistent data)

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

Đây là 4 thuộc tính bắt buộc giống nhau ở file Jad và file mainfest (nằm trong file jar) :

 MIDlet – Name

 MIDlet – Version

 MIDlet – Vendor

 MIDlet - <n>

Lưu ý: * Nếu các thuộc tính này không giống nhau thì ứng dụng sẽ bị từ chối

* Với các thuộc tính còn lại, nếu file Jad và file mainfest khác nhau thì thuộc tính trong file Jad sẽ được ưu tiên hơn

3.3.2.2 Các phương thức trong MIDlet

Các chương trình MIDlet này đều được kế thừa từ lớp MIDlet Không giống như chương trình trên máy PC, các chương trình MIDlet không cần hàm main()

để thực thi Sau đây là danh sách các hàm thường được dùng trong lớp MIDlet:

Bảng 4: Các phương thức trong MIDlet

abstract void pauseApp() Quản lý ứng dụng sẽ gọi phương thức này trên

MIDlet khi người chơi game tạm dừng game lại abstract void startApp() Quản lý ứng dụng sẽ gọi lại phương thức này

khi người chơi muốn chơi lại từ đầu

abstract void notifyDestroyed() Khi người chơi quyết định thoát game, thi

phương thức này được gọi để báo cho quản lý ứng dụng biết

abstract void notifyPaused() Phương thức này được gọi để nói cho quản lý

ứng dụng rằng người chơi muốn dừng MIDlet abstract void resumeRequest() Gọi phương thức này để nói cho quản lý ứng

dụng biết rằng MIDlet muốn khởi động lại

3.3.2.3 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(), destroyApp() Đây là một ví dụ về một chương trình MIDlet đơn giản:

//Được apllication manager gọi trước khi thực thi MIDlet

public void startApp() throws MIDletStateChangeException

{

System.out.println("Vendor: " + getAppProperty("MIDlet-Vendor")); System.out.println("Description: " + getAppProperty("MIDlet-

Description"));

System.out.println("JadFile Version: " +

getAppProperty("JadFile-Version"));

System.out.println("MIDlet-Data-Size: " + Data-Size"));

getAppProperty("MIDlet-}

//Được gọi khi tạm ngừng MIDlet

public void pauseApp(){ //…………}

//Được gọi trước khi kết thúc chương trình

public void destroyApp(boolean unconditional){ //………….}

}

Ví dụ ta có một bộ MIDlet với 2 tập tin sau:

Nội dung của tập tin MANIFEST.MF nằm trong tập tin showProperties.jar:

MIDlet-Name: Show Properties MIDlet

MIDlet-Version: 1.0.1

MIDlet-Vendor: My Corporation Inc

MIDlet-1: ShowProps, , showProperties

MicroEdition-Profile: MIDP-1.0

MicroEdition-Configuration: CLDC-1.0

MIDlet-Description: A simple property list example

MIDlet-Data-Size: 1500

Nội dung của tập tin showProperties.jad:

MIDlet-Name: Show Properties MIDlet

Khi chạy chương trình ở ví dụ trên thì ta sẽ được

Hình 7: Hiển thị kết quả việc truy xuất các thông tin trong tập tin Jar

Hình 8: Vòng đời của một MIDlet

Chúng ta sẽ xem qua vòng đời của một ứng dụng MIDlet

 Khi MIDlet đươc kích hoạt một đối tượnng được tạo ra, hàm khởi tạo được chạy và MIDlet rơi vào trạng thái Paused

 Kế tiếp MIDlet di vào trạng thái Active và trình quản lý ứng dụng sẽ gọi hàm startApp()

 Trong khi MIDlet đang Active thì trình quản lý ứng dụng có thể trì hoãn bất

kì chương trình nào đang thực thi bằng cách gọi hàm pauseApp() Chính điều này đã đặt MIDlet vào trạng thái Paused Một MIDlet có thể đặt chính

nó vào trạng thái Paused bằng lời gọi notifyPaused()

 Trong khi MIDlet đang ở trạng thái dừng, thì trình quản lý ứng dụng có thể gọi startApp() để đặt nó vào trạng thái Active

 Trình quản lý ứng dụng có thể kết thúc việc thực thi của MIDlet bằng lời gọi destroyApp(), tại thời điểm đó MIDlet bị phá hủy và chờ cho đến khi dọn dẹp rác xong Một MIDlet có thể bị phá hủy bằng lời gọi hàm notifyDestroyed()

Startup

Shutdown Paused

CHƯƠNG 4: GIAO DIỆN ĐỒ HỌA

 Nội dung trình bày:

 Quản lý việc hiển thị và bắt sự kiện trong J2ME

 Giao diện đồ họa cấp cao

 Giao diện đồ họa cấp thấp

MIDP hỗ trợ thiết kế giao diện dưới hai cấp độ:

 Giao diện cấp cao (high-level interfaces): chủ yếu dùng cho các chương trình ứng dụng Ở cấp độ này, MIDP cung cấp sẵn các thành phàp cho các thành phần giao diện thường dùng như textbox, choicegroup, alert… và hỗ trợ việc hiển thị các thành phần giao diện này lên màn hình thiết bị Người viết chương trình chỉ cần gọi các phương thức đồ họa đã được sử dụng bên dưới

 Giao diện cấp thấp (low-level interfaces): chủ yếu sử dụng trong các chương trình games Các lớp đồ họa ở cấp thấp này cung cấp các phương thức vẽ trực tiếp các đối tượng đồ họa (như điểm, đường thẳng, đường tròn…) lên màn hình và bắt sự kiện bấm phím

Tất cả các lớp hỗ trợ đồ họa được đóng gói trong package javax.microedition.cldui Trong đó, lớp Screen và các lớp kế thừa từ nó là các thành phần giao diện cấp cao; lớp Canvas thuộc phần giao diện cấp thấp

Hình 9: Sơ đồ các lớp trong giao diện đồ họa

Bảng 5: Các đối tượng trong giao diện đồ họa

Image Cung cấp lớp cho việc quản lý hình ảnh (hình ảnh ở dạng

PNG)

AlertType Cung cấp một lớp trợ giúp để định nghĩa các kiểu cảnh báo

mà chúng ta có thể tạo ra như là: alarm, confirmation, error, info, warning

Displayable Cung cấp một lớp trù tượng cho đối tượng được hiển thị Command Là một lớp trừu tượng chỉ một hành động trên giao diện Screen Cung cấp một lớp cơ sở cho những thành phần đồ họa ở

mức cao

Alert Cung cấp một màn hình cảnh báo cho người dùng

List Hiển thị một đối tượng chứa đựng danh sách để lựa chọn TextBox Cung cấp một đối tượng dùng để hiệu chỉnh text

Form Cung cấp một màn hình được xem như là một bộ chứa một

hoặc nhiều Item

Item Cung cấp một lớp cơ bản cho những thành phần mà chúng

ta có thể đánh dấu trên Form

ChoiceGroup Cung cấp một thành phần cho việc thể hiện danh sách được

chọn

DateField Cung cấp một thành phần để lấy ngày mà người dùng nhập

vào

Gauge Là một thanh đồ họa để hiển thị quá trình thực thi

ImageItem Cung cấp một Item mà cũng có thể là Image

StringItem Cung cấp một đối tượng Item để hiển thị một String

TextField Cung cấp một Item được sử dụng để hiệu chỉnh một text Ticker Cung cấp một Item để cuộn một chuỗi text

Graphics Cung cấp một công cụ đồ họa 2D

Canvas Cung cấp một lớp cơ bản để tạo ra một đối tượng đồ họa

cấp thấp

4.1 QUẢN LÝ VIỆC HIỂN THỊ VÀ BẮT SỰ KIỆN

4.1.1 Quản lý việc hiển thị

4.1.1.1 Lớp Display

Lớp này đảm nhiệm việc cung cấp giao diện cho người dùng nhập dữ liệu vào

và nhu cầu xuất dữ liệu ra màn hình Các đặt trưng của lớp Display:

 Lớp này nằm trong package javax.microedition.lcdui, lớp này chứa hầu hết 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

 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ừ lớp MIDlet nên có thể truyền vào con trỏ this

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…

mainForm = new Form (//………);

}

public void startApp() {

Display display = Display.getDisplay(this);

Display.setCurrent(mainForm);

} }

4.1.1.2 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 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á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

Bảng 6: Các phương thức chính của lớp Displayable

(CommandListener l) Displayble

boolean isShown() Kiểm tra đối tượng Displayable có được thể

hiện trên thiết bị hay không?

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 họat 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 họat 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==cmdExit) {

destroyApp(true);

notifyDestroyed();

} }

4.1.2 Quản lý các sự kiện:

Ngày nay, việc xử lý sự kiện là một trong những vấn đề cơ bản nhất của một chương trình Có thể nói, trong thế giới thực phần mềm ngày nay không một chương trình nào lại không có khả năng tương tác với người dùng, do đó việc quản lý các sự kiện phát sinh là một vấn đề mà bất cứ phần mềm nào cũng phải thực hiện 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 phải đả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ị phải nhận biết 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

Trong phần này chúng ta chỉ nghiên cứu về các sự kiện phát sinh ở những ứng dụng sử dụng các chức năng đồ họa ở mức cao (Form, TextBox….), còn các sự kiện phát sinh ở những ứng dụng sử dụng các thư viện đồ họa ở mức thấp như games sẽ được đề cập sau

Thực chất để nhận được thông báo từ hệ điều hành về các sự kiện phát sinh lớp ứng dụng chính của chúng ta phải cài đặt (implement) các “listener” Trong J2ME

hỗ trợ sẵn cho chúng ta 2 listener là CommandListener và ItemStateListener Lớp CommandListener có hàm commandListener() và tương ứng lớp ItemStateListener

có hàm itemStateChange(), đây là 2 hàm chúng ta cần cài đặt để nhận biết các sự kiện xảy ra Trước khi đi sâu vào các sự kiện chúng ta sẽ tìm hiểu 2 tác nhân chính phát sinh một sự kiện là Command và Item

4.1.2.1 Command và CommandListener

Ta định nghĩa Command là một đối tượng giữ thông tin về một sự kiện 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ụ trên 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 những hạn chế về kích thước của màn hình và 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:

 Tạo một command để lưu trữ thông tin về event

 Thêm command này vào Form, TextBox hay Alert…(nói chung là 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 sự kiện được kích hoạt, bộ listener sẽ gọi hàm

commandListener() và truyền các thông tin về sự kiện làm thông số cho hàm

Ví dụ

public class TestCommand extends MIDlet implements CommandListener {