nghiên cứu công nghệ j2me và thử nghiệm lập trình ứng dụng trên thiết bị di động

Đặc điểm của lập trình ứng dụng trên thiết bị di động Đặc trưng thiết bị di động hỗ trợ tài nguyên phần cứng không cao, với đặc điểm là bộ nhớ hạn chế, khả năng xử lý chậm, các thiết bị

ứu công nghệ J2ME và thử nghiệm lập trình ứng dụng trên thiết bị di độngTRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Đặng Đình Hùng

NGHIÊN CỨU CÔNG NGHỆ J2ME VÀ THỬ NGHIỆM LẬP TRÌNH ỨNG DỤNG TRÊN THIẾT BỊ DI ĐỘNG

KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành: Công nghệ thông tin

ứu công nghệ J2ME và thử nghiệm lập trình ứng dụng trên thiết bị di động

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Đặng Đình Hùng

NGHIÊN CỨU CÔNG NGHỆ J2ME VÀ THỬ NGHIỆM LẬP TRÌNH ỨNG DỤNG TRÊN THIẾT BỊ DI ĐỘNG

KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành: Công nghệ thông tin

Cán bộ hướng dẫn: ThS Đào Ngọc Phong

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Đặng Đình Hùng

NGHIÊN CỨU CÔNG NGHỆ J2ME VÀ THỬ NGHIỆM LẬP TRÌNH ỨNG DỤNG TRÊN THIẾT BỊ DI ĐỘNG

KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành: Công nghệ thông tin

Cán bộ hướng dẫn: ThS Đào Ngọc Phong

Lời cảm ơn

Sau một thời gian tập trung nghiên cứu và thực hiện, em đã hoàn thành xong luận

văn của mình Đây là kết tinh của một quá trình lao động và học tập nghiêm túc dựa trên

kiến thức mà em đã thu thập được dưới sự truyền dạy của quý thầy cô

Lời đầu tiên, em xin được gửi lời cảm ơn sâu sắc tới ThS Đào Ngọc Phong và thầy–

PGS TS Trịnh Nhật Tiến, những người thầy đã nhiệt tình giúp đỡ em cũng như các bạn

được thầy hướng dẫn trong suốt quá trình làm khóa luận

Em xin được cảm ơn các thầy, các cô đã giảng dạy em trong suốt bốn năm qua

Những kiến thức mà các thầy, các cô đã dạy sẽ mãi là hành trang giúp em vững bước

trong tương lai

Em cũng xin được cảm ơn tập thể lớp K51CC, một tập thể lớp đoàn kết với những

người bạn luôn nhiệt tình giúp đỡ mọi người, những người bạn đã giúp đỡ em trong suốt

bốn năm học tập trên giảng đường Đại học

Cuối cùng, em xin được gửi lời cảm ơn sâu sắc tới bố mẹ và gia đình em, những

người luôn kịp thời động viên, khích lệ em, giúp đỡ em vượt qua những khó khăn trong

cuộc sống

Hà Nội, tháng 5 năm 2010

Đặng Đình Hùng

Mục lục

Chương 1 Tổng quan về lập trình trên thiết bị di động 1

1.1 Thực tế các ứng dụng trên thiết bị di động 1 1.2 Đặc điểm của lập trình ứng dụng trên thiết bị di động _ 1 1.3 Các công nghệ trong lập trình trên thiết bị di động _ 1

Chương 2 Giới thiệu J2ME 3

2.1 Lịch sử hình thành J2ME 3 2.2 Các phiên bản, đặc điểm _ 3 2.2.1 MIDP 1.0 _ 3 2.2.2 MIDP 2.0 _ 4 2.3 Sự khác nhau giữa J2ME và J2SE _ 5 2.4 Các đặc điểm khác _ 7

Chương 3 Công nghệ lập trình J2ME trên thiết bị di động 8

3.1 Kiến trúc _ 8 3.2 Các lớp của J2ME _ 10 3.3 Các tầng của CLDC J2ME 11 3.4 Tầng máy ảo Java _ 12 3.5 Tầng cấu hình 15 3.6 Tầng hiện trạng _ 16 3.7 MIDlet _ 16 3.7.1 Bộ khung MIDlet 17 3.7.2 Chu kỳ sống của MIDlet 18 3.7.3 Tập tin JAR 20 3.7.4 Tập tin kê khai và JAD _ 20 3.7.5 Bộ MIDlet _ 21

Chương 4 Một số công nghệ trong J2ME 22

4.1 Đồ họa 23 4.1.1 Đồ họa mức cao _ 23

4.1.1.1 Text Box _ 23 4.1.1.2 Form 23 4.1.1.3 List _ 23 4.1.1.4 Alert 23 4.1.1.5 Form và các Form Item 24 4.1.1.5.1 String Item 24 4.1.1.5.2 Image Item 24 4.1.1.5.3 Text Field _ 24 4.1.1.5.4 Date Field _ 24 4.1.1.5.5 Choice Group 24 4.1.1.5.6 Gause 25 4.1.1.5.7 Ticker 25 4.1.2 Đồ họa mức thấp 25

4 2 Lập trình mạng _ 26 4.2.1 Khung mạng CLDC tổng quát 26 4.2.2 Các lớp giao diện kết nối 28 4.2.3 Kết nối HTTP _ 30 4.2.3.1 Ví dụ kết nối HTTP GET 31 4.2.3.2 Ví dụ kết nối HTTP POST _ 32 4.2.4 Triệu gọi CGI script 33 4.2.5 HTTP Request Header 34 4.3 Wireless Messaging API 34

Chương 5 Xây dựng ứng dụng thử nghiệm 38

5.1 Giới thiệu ứng dụng _ 38 5.1.1 Mục tiêu _ 38 5.1.2 Ứng dụng thử nghiệm 38 5.2 Các công nghệ sử dụng trong chương trình _ 38 5.2.1 Lightweight UI Toolkit (LWUIT) _ 38 5.2.2 XML 40 5.2.2.1 Phân tách XML 41

5.2.2.2 Các bộ phân tích XML cho KVM _ 42 5.2.2.2.1 kXML 43 5.2.2.2.2 Tiny XML 43 5.2.2.2.3 Nano XML 43 5.2.2.3 Làm việc với kXML 44 5.2.2.4 Gói org.kxml 44 5.2.2.5 Gói org.kxml.io 45

Chương 6 Tổng quan về chương trình ứng dụng thử nghiệm 46

6.1 Web Services 46 6.1.1 Giới thiệu khung xử lý hệ thống 46 6.1.2 Xây dựng cơ sở dữ liệu cho hệ thống 48 6.1.3 Quá trình hoạt động của hệ thống _ 49 6.1.3.1 Phần quản trị nội dung 49 6.1.3.1.1 Khu vực người quản trị đăng nhập vào hệ thống 49 6.1.3.1.2 Khu vực chung _ 50 6.1.3.1.3 Khu vực thao tác với các danh mục tin 50 6.1.3.1.4 Khu vực quản lý nội dung 51 6.1.3.2 Phần dành cho người quản trị _ 51 6.1.3.2.1 Phần menu bên trái _ 51 6.1.3.2.2 Phần quản lý nhóm người dùng 52 6.1.3.2.3 Phần quản lý nhóm thực đơn 52 6.1.3.2.4 Phần quản lý các nhóm Component 53 6.1.3.2.5 Phần quản lý ngôn ngữ hiển thị _ 53 6.1.3.3 Phần xuất bản nội dung định dạng XML 54 6.1.3.3.1 Xuất bản nội dung các danh mục tin 54 6.1.3.3.2 Xuất bản các bản tin trong cùng danh mục _ 54 6.2 Trên thiết bị di động _ 55 6.2.1 Quy trình hoạt động 55 6.3 Các module chính trong ứng dụng 57 6.3.1 Web Services _ 57

6.3.2 Trên thiết bị di động 61 6.4 Mã nguồn tham khảo 65 6.4.1 kxml2 _ 65 6.4.2 Convert UTF-8 65 6.4.3 LWUIT 65

Chương 7 Cài đặt ứng dụng thử nghiệm 66

7.1 Web Services 66 7.1.1 Cài đặt phần giả lập máy chủ Web trên máy tính cá nhân 66 7.1.2 Cấu hình gói ứng dụng Web Services 66 7.2 Trên thiết bị di động _ 67 7.2.1 Cài đặt phần mềm mô phỏng _ 67 7.2.2 Cấu hình ứng dụng thử nghiệm _ 67

Kết luận:……… Tài liệu tham khảo:………

Danh mục hình vẽ và bảng biểu

Hình 1: Lịch sử J2ME 3

Hình 2: Sơ đồ kiểm tra của bộ tiền kiểm tra và bộ kiểm tra 5

Hình 3: Mô hình Sandbox……….…….6

Hình 4: J2ME và J2SE……… 7

Hình 5: Kiến trúc J2ME……….8

Hình 6: Phân khúc dòng thiết bị với các ngôn ngữ Java……… 9

Hình 7: Các lớp của J2ME……… 11

Hình 8: Tiến trình xây dựng MIDlet……… .13

Hình 9: MIDlet……… 16

Hình 10: Bộ khung yêu cầu tối thiểu cho một ứng dụng MIDlet……… 17

Hình 11: Chu kỳ sống của MIDlet……….18

Hình 12: Hai bộ MIDlet……….21

Hình 13 Phân cấp lớp đồ họa……… 25

Hình 14 Khung mạng CLDC tổng quát……… 26

Hình 15 Các lớp kết nối……… 27

Hình 16 Các trạng thái kết nối HTTP………29

Hình 17: Các phân tầng lớp trong LWUIT……….38

Hình 18 : Ứng dụng thử nghiệm với LWUIT……….39

Hình 19 : Quá trình xử lý trên web services………45

Hình 20 : Biểu đồ thực thể liên kết của hệ thống………48

Hình 21: Người quản trị đăng nhập vào hệ thống……… 49

Hình 22: Khu vực mặc định của hệ thống……… 49

Hình 23: Khu vực hiển thị danh mục của hệ thống……….50

Hình 24: Khu vực hiển thị nội dung bản tin………50

Hình 25: Phần tùy chọn bên trái của hệ thống……….51

Hình 26: Phần quản lý nhóm người dùng………51

Hình 27: Phần quản lý nhóm thực đơn………52

Hình 28: Phần quản lý Component ……… 52

Hình 29: Khu vực quản lý ngôn ngữ hiển thị trong hệ thống……….53

Hình 30: Kết quả thu được với trình duyệt Mozilla Firefox 3.5……….…53

Hình 31: Kết quả thu được với trình duyệt Mozilla Firefox 3.5………54

Hình 32: Màn hình khởi động của ứng dụng……… 55

Hình 33: Màn hình tùy chọn ứng dụng……… …57

Hình 34:Yêu cầu cho phép kết nối tới dịch vụ……… …57

Hình 35: Các quá trình khi xem tin tức với ứng dụng………58

Hình 36: Tạo cơ sở dữ liệu trong phpmyadmin……… …66

Hình 37: Quá trình nhập cơ sở dữ liệu……… 66

Hình 38: Bước đầu tạo Project mới………67

Hình 39: Cấu hình ban đầu……….…………68

Hình 40: Cấu hình chi tiết……… ………68

Thuật ngữ viết tắt

API Application Program Interface

ASCII American Standard Code for Information Interchange

AWT Abstract Window ToolKit

CBS Cell Broadcast Short Message Service

CDC Connected Device Configuration

CDMA Code Division Multiple Access

CGI Common Gateway Interface

CLDC Connected Limited Device Configuration

CPU Central Processing Unit

DOM Document Object Model

DTD Document Type Definition

GPRS General Packet Radio Service

GPS Global Positioning System

GSM Global System for Mobile Communications

GUI Graphical User Interface

HTTP Hyper-Text Transfer Protocol

IDE Integrated Development Environment

IP Internet Protocol

IR Infra Red

J2EE Java 2 Platform, Enterprise Edition

J2ME Java 2 Platform, Micro Edition

J2SE Java 2 Platform, Standard Edition

JAD Java Application Descriptor

JAR Java Application Archive

JCP Java Community Process

JNI JavaNative Interface Support

JSR Java Specification Request

KVM K Virtual Machine

MIDP Mobile Information Device Profile

RMI Remote Method Invocation

RMS Record Management System

SAX Simple API for XML

SMS Short Message Service

UDP User Datagram Protocol

URL Uniform Resource Locator

WAP Wireless Application Protocol

WMA Wireless Messaging API

XML eXensible Markup Language

Chương 1 Tổng quan về lập trình trên thiết bị di động

1.1 Thực tế các ứng dụng trên thiết bị di động

Mạng điện thoại di động đã xuất hiện tại Việt Nam từ đầu những năm 1990 và theo thời gian, số lượng các thuê bao cũng như các nhà cung cấp dịch vụ di động tại Việt Nam ngày càng tăng Cùng với sự phát triển của số lượng thuê bao di động là sự đa dạng hóa các dịch vụ hướng đến thiết bị di động Trong những năm gần đây, điện thoại di động không chỉ mang chức năng nghe gọi hay nhắn tin thông thường mà còn là một thiết bị giải trí, tra cứu thông tin hay trợ giúp cá nhân đắc lực Do vậy, xây dựng các ứng dụng cho điện thoại di động đang là một yêu cầu tất yếu trong xu thế hiện nay Năm 2009, các nhà mạng lớn đã bắt tay vào việc triển khai mạng 3G tại Việt Nam, năm 2010 trở đi được đánh giá là những năm nở rộ các dịch vụ tiện ích trên thiết bị di động đặc biệt là các ứng dụng trực tuyến trên nền thiết bị di động

Trong tương lai, với sự phát triển mạnh mẽ của các thiết bị di động về phần cứng cũng như chất lượng mạng di động, ngành công nghiệp phần mềm trên thiết bị di động sẽ gặt hái được nhiều thành quả và nó sẽ thu hút lượng lớn các nhân công cũng như hứa hẹn nhiều điều thú vị

1.2 Đặc điểm của lập trình ứng dụng trên thiết bị di động

Đặc trưng thiết bị di động hỗ trợ tài nguyên phần cứng không cao, với đặc điểm là

bộ nhớ hạn chế, khả năng xử lý chậm, các thiết bị mở rộng còn hạn chế, vì vậy lập trình ứng dụng trên thiết bị di động đòi hỏi các lập trình viên quản lý tốt bộ nhớ, độ lớn của mã nguồn, cũng như các thư viện hay cơ chế làm việc với các file media

Do thiết bị di động được phát triển bởi nhiều hãng nên cấu trúc phần cứng đa dạng

và khó có chuẩn chung nên yêu cầu các ngôn ngữ lập trình độc lập với phần cứng và linh hoạt là rất cao

1.3 Các công nghệ trong lập trình trên thiết bị di động

Hai hướng phát triển ứng dụng trên điện thoại di động phổ biến hiện nay là sử dụng ngôn ngữ C++ trên nền hệ điều hành Symbian và J2ME Khoảng mấy năm trở lại đây, nền tảng di động mở Android của Google và iPhone OS của Apple cũng đang có tín hiệu phát triển rất khả quan

Các ứng dụng viết trên nền Symbian có các ưu thế truy cập trực tiếp các tài nguyên của điện thoại cũng như hỗ trợ hệ thống tập tin, thư mục… như máy tính cá nhân vì được

hỗ trợ trực tiếp bởi hệ điều hành Tuy nhiên hệ điều hành Symbyan lại có kích thước khá lớn nên chỉ có ở các thế hệ điện thoại tương đối cao cấp, và xây dựng ứng dụng dùng Symbian API cũng phức tạp hơn

Đối trọng với Symbian API là công nghệ J2ME với kích thước nhỏ gọn, tiện dụng, được hỗ trợ bởi hầu hết các thế hệ điện thoại mới ra đời, kể cả các điện thoại có hệ điều hành Symbian J2ME không những là một ngôn ngữ hướng đến các thiết bị di động mà còn là ngôn ngữ chính để lập trình trên các thiết bị gia dụng, thẻ tín dụng điện tử và các thiết bị thông minh khác Chúng ta có thể nói đối tượng của ngôn ngữ J2ME là rộng hơn rất nhiều so với C++ trên nền Symbyan Tại thời điểm hiện tại, ngôn ngữ J2ME không hỗ trợ được nhiều tính năng như trên C++ trên nền Symbian nhưng lại có những ưu điểm trội hơn J2ME là một ngôn ngữ nhỏ, gọn nhưng rất chặt chẽ và dễ nắm bắt, với những lập trình viên đã có kinh nghiệm với Java việc lập trình với J2ME trở nên rất dễ dàng J2ME còn là ngôn ngữ được các tổ chức mã nguồn mở ủng hộ mạnh mẽ và phát triển rất nhanh chóng

Năm 2007, liên minh Google, OHA ra mắt nền tảng Android, nó được giới thiệu là một nền tảng mở với sự kết hợp của ngôn ngữ Java và hệ điều hành Linux 2.6 Trong Android, nét đặc trưng nổi bật là tính tương thích lẫn nhau, khả năng hỗ trợ thiết bị, cũng như ngôn ngữ Java SE cộng với việc tích hợp sử dụng cơ sở dữ liệu ngay trong thiết bị Một đối thủ rất đáng gờm trong thị phần của điện thoại thông minh đó là iPhone của Apple, các ứng dụng của iPhone được viết bằng ngôn ngữ Objective C hoạt động trên nền iPhone OS Đặc điểm chính của Objective C là ngôn ngữ hướng đối tượng nhưng được hỗ trợ nhiều bởi các API nên việc xử lý đa phương tiện nổi trội, điều này cũng tạo nên thương hiệu đình đám của Apple

Chương 2 Giới thiệu J2ME

2.1 Lịch sử hình thành J2ME

J2ME được phát triển từ kiến trúc Java Card, Embeded Java và Personal Java của phiên bản Java 1.1 Đến sự ra đời của Java 2 thì Sun quyết định thay thế Personal Java và được gọi với tên là Java 2 Micro Edition, hay viết tắt là J2ME J2ME là nền tảng cho các thiết bị có tính chất nhỏ gọn:

Hình 1: Lịch sử J2ME

2.2 Các phiên bản, đặc điểm

Có hai phiên bản MIDP chính trong ngôn ngữ J2ME:

2.2.1 MIDP 1.0

Phiên bản này xuất hiện đầu tiên vào năm 2001, và phổ biến rộng rãi ở Mỹ (dẫn đầu

là Motorola ) Với thế hệ ban đầu này, các chương trình chỉ được hỗ trợ cơ bản như giao diện chương trình, giao thức HTTP và các tính năng hỗ trợ âm thanh hay khả năng viết game chưa được hỗ trợ

 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

Nâng cấp các tính năng bảo mật như:

 Download qua mạng an toàn hơn qua việc hỗ trợ giao thức HTTPS

 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

 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)

 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, nhưng các thay đổi lớn nhất (ngoài API cho game) là trong Form và Item

 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 Ý 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ớ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ỗ 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

2.3 Sự khác nhau giữa J2ME và J2SE

 Các điểm khác nhau là do một trong hai lý do Do lớp Java đã bị bỏ đi để giảm kích thước của J2ME hoặc do lớp bị bỏ bởi vì nó ảnh hưởng đến sự an toàn, bảo mật của thiết bị di động hay của các ứng dụng khác trên thiết bị di động (có thể dẫn đến phát

triển virus)

 Điểm khác biệt chính là không có phép toán số thực Không có JNI (JavaNative Interface Support) do đó không thể truy xuất các chương trình khác được viết bằng ngôn ngữ của thiết bị (như C hay C++) Luồng (thread) được cho phép nhưng không

có các nhóm luồng (thread group)

 CLDC định nghĩa một mô hình an toàn, bảo mật được thiết kế để bảo vệ thiết bị di động, KVM, và các ứng dụng khác khỏi các mã phá hoại Hai bộ phận được định nghĩa bởi CLDC này là bộ tiền kiểm tra và mô hình sandbox

Hình 2 biểu diễn cách mà bộ tiền kiểm tra và bộ kiểm tra làm việc với nhau để kiểm tra mã chương trình Java trước khi chuyển nó cho KVM

Hình 2: Sơ đồ kiểm tra của bộ tiền kiểm tra và bộ kiểm tra

Hello.class Bộ tiền kiểm tra Hello.class

Bộ kiểm tra Bộ biên dịch mã bytecode Java

Trạm phát triển

Thiết bị đích

Download về thiết bị

Bộ tiền kiểm tra

Các tập tin lớp được gán nhãn bằng một thuộc tính trên máy trạm Thuộc tính này sau đó được bộ tiền kiểm tra kiểm tra trước khi mã chương trình được giao cho KVM hay

bộ biên dịch mã bytecode

Một bộ phận khác của bảo mật trong CLDC là mô hình sandbox

Hình 3 biểu diễn khái niệm mô hình sandbox:

Hình 3: Mô hình Sandbox

Mô hình Sandbox

Ứng dụng J2ME đặt trong một sandbox bị giới hạn truy xuất đến tài nguyên của thiết bị và không được truy xuất đến Máy ảo Java hay bộ nạp chương trình Ứng dụng được truy xuất đến các API của CLDC và MIDP Ứng dụng được truy xuất tài nguyên của thiết bị di động chỉ khi nhà sản xuất điện thoại di động cung cấp các API tương ứng Nhưng các API này không phải là một phần của J2ME

Thế hệ kế tiếp của CLDC là đặc tả JSR - 139 và được gọi là CLDC thế hệ kế tiếp

Nó sẽ nhắm đến các vấn đề như nâng cao việc quản lý lỗi và có thể phép toán số thực

Tài nguyên thiết bị

Các CLDC API

Các MIDP API

Chương trình ứng dụng Java

API

API API

Class Loader

Hệ thống JVM

Hình 4: J2ME và J2SE

2.4 Các đặc điểm khác

Khi viết J2ME, do đặc tính cần nhỏ gọn và bảo mật tốt cho thiết bị di động nên Sun

đã lược bớt các lớp đồ sộ chỉ để lại các lớp c ơ bản, do vậy, về bản chất J2ME l à ngôn ngữ

kế thừa và tinh lược của phiên bản J2SE

Bên cạnh đó nhưng MIDP vì được viết cho thiết bị có cấu hình lẫn bộ nhớ thấp nên

nó không hỗ trợ:

 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 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,

do đó MIDP cũng không có

 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

 Hỗ trợ hạn chế 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

Chương 3 Công nghệ lập trình J2ME trên thiết bị di động

3.1 Kiến trúc

Hình 5: Kiến trúc J2ME

Configuration: 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ư:

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 một cách tối thiểu nhất để có thể chạy trên điện thoại Nokia…

Hiện nay Sun đưa ra hai dạng cấu hình:

 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, các thiết bị này

thông thường là máy điện thoại di động và PDA với khoảng 512 KB bộ nhớ Vì tài nguyên bộ nhớ hạn chế nen CLDC được gắn với Java không dây, dạng cho phép người dùng mua hoặc tải về các ứng dụng Java, ví dụ như 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 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 trên 2 Mb) 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…

Cả hai dạng cấu hình kể trên đều chứa máy ảo Java – JVM (Java Virtual Machine)

và tập hợp các lớp Java cơ bản để cung cấp một môi trường cho các ứng dụng J2ME Tuy nhiên, 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ư máy ảo của J2SE, đơn cử, 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 6: Phân khúc dòng thiết bị với các ngôn ngữ Java

CLDC CDC RAM >=32Kb, <=512Kb >=256Kb

số profile tiêu biểu:

o Mobile Information Device Profile (MIDP): 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)

o PDA Profile: tương tự 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

o 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

3.2 Các lớp của J2ME

Mục tiêu của J2ME là giúp các lập trình viên viết các ứng dụng độc lập với thiết bị

di động, viết một lần đúng mọi chỗ, không cần quan tâm đến phần cứng thực sự Để làm

điề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

Hình 7: Các lớp của J2ME

3.3 Các tầng của CLDC J2ME

Mỗi tầng trên tầng hardware 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

Từ dưới lên trên:

 Tầng phần cứng thiết bị (Device hardware layer):

Đây chính là cấu hình thực sự của thiết bị di động với cấu hình phần cứng như bộ nhớ hay cấu hình của nó Đây độc lập với J2ME nhưng nó là nơi xuất phát Mỗi thiết bị di động và các nhà sản xuất khác nhau thì thường có các bộ vi xử lý khác nhau cùng 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 chung cho tất cả các thiết bị di động khác nhau này

 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ã 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 Tầng

Phần cứng thiết bị Máy ảo Java

Cấu hình CLDC Hiện trạ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

 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 Đây là một tập các API định nghĩa lõi của ngôn ngữ J2ME

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

Tầng hiện trạng hay MIDP ( 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

3.4 Tầng máy ảo Java

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 8: Tiến trình xây dựng MIDlet

Quá trình phát triển ứng dụng MIDlet với IDE ( Intergrated Development Environment ):

Lập trình viên: 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)

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 lưu trong các tập tin *.class và sẽ có 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 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

Trên IDE: Tạo tập tin JAR 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

Người dùng: Download ứng dụng về thiết bị di động Người dùng sau đó download

tập tin JAR chứa ứng dụng về thiết bị di động Trong hầu hết các điện thoại di động, có ba cách để download ứng dụ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

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

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

Bộ quản lý ứng dụng: Lưu trữ chương trình

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: Thực thi mã bytecode khi chương trình chạy

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

3.5 Tầng cấu hình

Tầng J2ME kế trên tầng KVM là CLDC hay 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 Nó cung cấp cơ sở cho tầng Hiện trạng, tầng này sẽ chứa nhiều API chuyên biệt hơn

CLDC – Connected Limited Device Configuration:

Phạm vi: Định nghĩa các thư viện tối thiểu và các API

o Chu kỳ sống ứng dụng

o Giao diện người dùng

o Quản lý sự kiện

o Giao diện ứng dụng và người dùng

Các lớp lõi Java cơ bản, input/output, mạng, và bảo mật được định nghĩa trong CLDC Các API hữu dụng hơn như giao diện người dùng và quản lý sự kiện được dành cho hiện trạng MIDP

3.6 Tầng hiện trạng

Tầng J2ME cao nhất là tầng hiện trạng và mục đích của nó là định nghĩa các API cho các thiết bị di động 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

Lớp chính của ứng dụng được định nghĩa là lớp kế thừa lớp MIDlet của MIDP Có thể chỉ có một lớp trong ứng dụng kế thừa lớp này Lớp MIDlet được trình quản lý ứng dụng trên điện thoại di động dùng để khởi động, dừng, và tạm dừng MIDlet (ví dụ, trong trường hợp có cuộc gọi đến)

3.7.1 Bộ khung MIDlet

Một MIDlet là một lớp Java kế thừa (extend) của lớp trừu tượng java.microedition.midlet.MIDlet và thực thi (implement) các phương thức startApp(), pauseApp(), và destroyApp()

Hình 10: Bộ khung yêu cầu tối thiểu cho một ứng dụng MIDlet

Hàm tạo chỉ được thực thi một lần khi MIDlet được khởi tạo lần đầu tiên Hàm tạo

sẽ không được gọi lại trừ phi MIDlet thoát và sau đó khởi động lại

public void startApp() {}

public void pauseApp() {}

public void destroyApp(boolean unconditional) {}

Phương thức startApp() được gọi bởi bộ quản lý ứng dụng khi MIDlet được khởi tạo, và mỗi khi MIDlet trở về từ trạng thái tạm dừng

6) destroyApp()

Phương thức destroyApp() được gọi khi thoát MIDlet (ví dụ khi nhấn nút exit trong ứng dụng) Nó chỉ đơn thuần là thoát MIDlet Nó không thật sự xóa ứng dụng khỏi điện thoại di động 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

Tóm tắt các trạng thái khác nhau của MIDlet:

Tạo (Created)  Hàm tạo MIDletExample() được gọi một một lần

Hoạt động (Active)  Phương thức startApp() được gọi khi chương trình bắt đầu

hay sau khi tạm dừng

Tạm dừng (Paused)  Phương thức pauseApp() được gọi Có thể nhận các sự kiện

timer

Hủy (Destroyed)  Phươ ức destroy() được gọi

3.7.2 Chu kỳ sống của MIDlet

Hình 11: Chu kỳ sống của MIDlet

Chu kỳ sống của MIDlet

Khi người dùng yêu cầu khởi động ứng dụng MIDlet, bộ quản lý ứng dụng sẽ thực thi MIDlet (thông qua lớp MIDlet) Khi ứng dụng thực thi, nó sẽ được xem là đang ở trạng thái tạm dừng Bộ quản lý ứng dụng gọi h àm tạo và hàm startApp() Hàm startApp()

có thể được gọi nhiều lần trong suốt chu kỳ sống của ứng dụng Hàm destroyApp() chỉ có thể gọi từ trạng thái hoạt động hay tạm dừng

Lập trình viên cũng có thể điều khiển trạng thái của MIDlet

Các phương thức dùng để điều khiển các trạng thái của MIDlet:

resumeRequest(): Yêu cầu vào chế độ hoạt động

Ví dụ: Khi MIDlet tạm dừng, và một sự kiện timer xuất hiện

notifyPaused(): Cho biết MIDlet tự nguyện chuyển sang trạng thái tạm dừng

Ví dụ: Khi đợi một sự kiện timer

từ bất kỳ lớp nào trong tập tin JAR, trong MIDP, hay CLDC Nó không thể truy xuất các lớp không phải là bộ phận của tập tin JAR hay vùng dùng chung của thiết bị di động

3.7.4 Tập tin kê khai và JAD

Tập tin kê khai (manifest.mf) và tập tin JAD (Java Application Descriptor) mô tả các đặc điểm của MIDlet Sự khác biệt của hai tập tin này là tập tin kê khai là một phần của tập tin JAR còn tập tin JAD không thuộc tập tin JAR Ưu điểm của tập tin JAD là các đặc điểm của MIDlet có thể được xác định trước khi download tập tin JAR Nói chung, cần ít thời gian để download một tập tin văn bản nhỏ hơn là download một tập tin JAR Như vậy, nếu người dùng muốn download một ứng dụng không được thiết bị di động hỗ trợ (ví dụ, MIDP 2.0), thì quá trình download sẽ bị hủy bỏ thay vì phải đợi download hết toàn bộ tập tin JAR

Mô tả nội dung của tập tin JAR:

Các trường yêu cầu

o Manifest-Version // Phiên bản tập tin Manifest

o MIDlet-Name // Tên bộ MIDlet (MIDlet suite)

o MIDlet-Version // Phiên bản bộ MIDlet

o MIDlet-Vendor // Nhà sản xuất MIDlet

o MIDlet-<n> for each MIDlet // Tên của MIDlet

o MicroEdtion-Profile // Phiên bản hiện trạng

o MicroEdtion-Configuration // Phiên bản cấu hình

Ví dụ một tập tin manifest.mf:

MIDlet-Name: CardGames

MIDlet-Version: 1.0.0

MIDlet-Vendor: Sony Ericsson

MIDlet-Description: Set of Card Games

MIDlet-1: Solitaire, /Sol.png, com.semc.Solitaire

MIDlet-2: BlackJack, /Blkjk.png, com.semc.BlackJack

Tập tin JAD chứa cùng thông tin như tập tin manifest Nhưng nó nằm ngoài tập tin JAR

Các thuộc tính MIDlet-Name, MIDlet-Version, và MIDlet-Vendor phải được lặp lại trong tập tin JAD và JAR Các thuộc tính khác không cần phải lặp lại Giá trị trong tập tin

mô tả sẽ đè giá trị của tập tin manifest

3.7.5 Bộ MIDlet

Một tập các MIDlet trong cùng một tập tin JAR được gọi là một bộ MIDlet (MIDlet suite) Các MIDlet trong một bộ MIDlet chia sẻ các lớp, các hình ảnh, và dữ liệu lưu trữ bền vững Để cập nhật một MIDlet, toàn bộ tập tin JAR phải được cập nhật

Hình 12: Hai bộ MIDlet

Các bộ MIDlet

Trong hình trên, một bộ MIDlet chứa MIDlet1, MIDlet2, và MIDlet3 Bộ kia chỉ chứa MIDlet4 Ba MIDlet trong bộ đầu tiên truy xuất các lớp và dữ liệu của nhau nhưng không truy xuất đến các lớp hay dữ liệu của MIDlet4 Ngược lại, MIDlet4 cũng không truy xuất được các lớp, hình ảnh, và dữ liệu của chúng

Lưu trữ bền vững 2

Lưu trữ bền vững 3

midlet4.class

Lưu trữ bền vững 4

MIDlet1, MIDlet2, MIDlet3

MIDlet4

Chương 4 Một số công nghệ trong J2ME

4.1 Đồ họa

Các lớp MIDP cung cấp hai mức đồ họa: đồ họa mức thấp và đồ họa mức cao Đồ họa mức cao dùng cho văn bản hay form Đồ họa mức thấp dùng cho các ứng dụng trò chơi yêu phải vẽ lên màn hình

4.1.1 Đồ họa mức cao

Đồ họa mức cao là lớp con của lớp Screen Nó cung cấp các thành phần như text box, form, list, và alert Ta ít điều khiển sắp xếp các thành phần trên màn hình Việc sắp xếp thật sự phụ thuộc vào nhà sản xuất

4.1.1.1 Text Box

Lớp TextBox cho phép người dùng nhập và soạn thảo văn bản Lập tr ình viên có thể định nghĩa số ký tự tối đa, giới hạn loại dữ liệu nhập (số học, mật khẩu, email,…) và hiệu chỉnh nội dung của textbox Kích thước thật sự của textbox có thể nhỏ hơn yêu cầu khi thực hiện thực tế (do giới hạn của thiết bị) Kích thước thật sự của textbox có thể lấy bằng phương thức getMaxSize()

4.1.1.2 Form

Form là lớp hữu dụng nhất của các lớp Screen bởi vì nó cho phép chứa nhiều item trên cùng một màn hình Các item có thề là DateField, TextField, ImageItem, TextItem, ChoiceGroup

4.1.1.3 List

Lớp List là một Screen chứa danh sách các lựa chọn chẳng hạn như các radio

button Người dùng có thể tương tác với list và chọn một hay nhiều item

4.1.1.4 Alert

Alert hiển thị một màn hình pop-up trong một khoảng thời gian Nói chung nó dùng

để cảnh báo hay báo lỗi Thời gian hiển thị có thể được thiết lập bởi ứng dụng Alert có

thể được gán các kiểu khác nhau (alarm, confirmation, error, info, warning), các âm th anh tương ứng sẽ được phát ra

4.1.1.5 Form và các Form Item

Sử dụng form cho phép nhiều item khác nhau trong cùng một màn hình Lập trình viên không điều khiển sự sắp xếp các item trên màn hình Sau khi đã định nghĩa đối tượng Form, sau đó sẽ thêm vào các item

Mỗi item là một lớp con của lớp Item:

4.1.1.5.1 String Item

Public class StringItem extends Item

StringItem chỉ là một chuỗi hiển thị mà người dùng không thể hiệu chỉnh Tuy nhiên, cả nhãn và nội dung của StringItem có thể được hiệu chỉnh bởi ứng dụng

4.1.1.5.2 Image Item

public class ImageItem extends Item

ImageItem cho phép thêm vào hình form ImageItem chứa tham chiếu đến một đối tượng Image phải được tạo trước đó

4.1.1.5.3 Text Field

public class TextField extends Item

TextField cho phép người dùng nhập văn bản Nó có thể có giá trị khởi tạo, kích thước tối đa, và ràng buộc nhập liệu Kích thước thật sự có thể nhỏ hơn yêu cầu do giới hạn của thiết bị di động

4.1.1.5.4 Date Field

public class DateField extends Item

DateField cho phép người dùng nhập thông tin ngày tháng và thời gian Có thể xác định giá trị khởi tạo và chế độ nhập ngày tháng (DATE), thời gian (TIME), hoặc cả hai

4.1.1.5.5 Choice Group

public class ChoiceGroup extends Item Implements Choice

ChoiceGroup cung cấp một nhóm các radio-button hay checkbox cho phép lựa chọn đơn hay lựa chọn nhiều

4.1.1.5.6 Gause

public class Gauge extends Item

Lớp Gauge cung cấp một hiển thị thanh (bar display) của một giá trị số học Gauge

có thể có tính tương tác hoặc không Nếu một gauge là tương tác thì người dùng có thể thay đổi giá trị của tham số qua gauge Gauge không tương tác chỉ đơn thuần là để hiển thị

4.1.1.5.7 Ticker

Một màn hình có thể có một ticker là một chuỗi văn bản chạy liên tục trên màn hình Hướng và tốc độ là do thực tế qui định Nhiều màn hình có thể chia sẻ cùng một ticker

Ví dụ:

Ticker myTicker = new Ticker(“Useful Information”);

MainScreen = new Form(“Main Screen”);

Hình 13 Phân cấp lớp đồ họa

4 2 Lập trình mạng

4.2.1 Khung mạng CLDC tổng quát

Mạng cho phép client di động gởi và nhận dữ liệu đến server Nó cho phép thiết bị

di động sử dụng các ứng dụng như tìm kiếm cơ sở dữ liệu, trò chơi trực tuyến… Trong J2ME, mạng được chia làm hai phần Phần đầu tiên là khung được cung cấp bởi CLDC và phần hai là các giao thức thật sự được định nghĩa trong các hiện trạng

CLDC cung cấp một khung tổng quát để thiết lập kết nối mạng Ý tưởng là nó là đưa

ra một khung mà các hiện trạng khác nhau sẽ sử dụng Khung CLDC không định nghĩa giao thức thật sự Các giao thức sẽ được định nghĩa trong các hiện trạng

Command Displayable

Screen Canvas

List Alert Form TextBox

Item

DateField TextField Gauge ImageItem TextItem ChoiceGroup

Choice

import javax.microedition.lcdui.*;

Nằm trong gói sau:

Hình 14 Khung mạng CLDC tổng quát

Kết nối mạng được xây dựng bằng phương thức open() của lớp Connector trong CLDC Phương thức open() nhận một tham số đầu vào là chuỗi Chuỗi này dùng để xác định giao thức Định dạng của chuỗi là:

protocol:address;parameters

CLDC chỉ xác định tham số là một chuỗi nhưng nó không định nghĩa bất kỳ giao thức thật sự nào Các hiện trạng có thể định nghĩa các giao thức kết nối như HTTP, socket, cổng truyền thông, datagram,… Phương thức open() trả về một đối tượng Connector Đối tượng này sau đó có thể đóng vai trò là một giao thức xác định được định nghĩa trong hiện trạng

Trả về một đối tượng Connection

Ví dụ trên minh họa kết nối socket, cổng truyền thông, datagram, file và HTTP Tất

cả các kết nối mạng đều có cùng định dạng, không quan tâm đến giao thức thật sự Nó chỉ

khác nhau ở chuỗi chuyển cho phương thức open() Phương thức open() sẽ trả về một đối

tượng Connection đóng vai trò là lớp giao thức (ví dụ HttpConnection) để có thể sử dụng

các phương thức cho giao thức đó J2ME chỉ định nghĩa một kết nối là kết nối HTTP

trong MIDP

4.2.2 Các lớp giao diện kết nối

Dẫn xuất từ lớp Connection là nhiều lớp giao diện con cung cấp khung kết nối

mạng Các giao diện khác nhau để hỗ trợ các loại thiết bị di động khác nhau