MỤC LỤC
Trên IDE: 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. Sau khi đã gỡ rối và kiểm tra mã lệnh trên trình mô phỏng (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. 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.
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. 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. 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ền tảng J2ME SV: Lê Ngọc Quốc Khánh MIDlet-Jar-URL: http://www.semc.com/j2me/games. 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. Giá trị trong tập tin mô tả sẽ đè giá trị của tập tin manifest.
Như trong hình, các MIDlet có thể có nhiều hơn một tập lưu trữ bản ghi, chúng chỉ có thể truy xuất dữ liệu lưu trữ bản ghi chứa trong bộ MIDlet của chúng. Do đó, MIDlet 1 và MIDlet 2 có thể truy xuất dữ liệu trong Record Store 1 và Record Store 2 nhưng chúng không thể truy xuất dữ liệu trong Record Store3. Ngược lại, MIDlet 3 chỉ có thể truy xuất dữ liệu trong Record Store 3 và không thể truy xuất dữ liệu dữ liệu trong Record Store 1 và Record Store 2.
Tên của các lưu trữ bản ghi phải là duy nhất trong một bộ MIDlet nhưng các bộ khác nhau có thể dùng trùng tên. Các bản ghi trong một lưu trữ bản ghi được sắp xếp thành các mảng byte. Các mảng byte không có cùng chiều dài và mỗi mảng byte được gán một số ID bản ghi.
Các bản ghi được định danh bằng một số ID bản ghi (record ID) duy nhất. Các số sẽ không được dùng lại khi một bản ghi bị xóa do đó sẽ tồn tại các khoảng trống trong các ID bản ghi. Đặc tả MIDP không định nghĩa chuyện gì xảy ra khi đạt đến số ID bản ghi tối đa, điều này phụ thuộc vào ứng dụng.
Nền tảng J2ME SV: Lê Ngọc Quốc Khánh outputStream.writeUTF(name); // byte [5] đến 2 + name.length byte[] theRecord = boas.toByteArray();. Trong ví dụ trên, hai dòng đầu tạo một luồng xuất để giữ dữ liệu bản ghi. Sử dụng đối tượng DataOutputStream (bọc mảng byte) cho phép các bản ghi dễ dàng được định dạng theo các kiểu chuẩn của Java (long, int, string,…) mà không phải quan tâm đến tách nó thành dữ liệu byte.
Phương thức writeByte(), writeInt(), và writeUTF() định dạng dữ liệu như trong hình (tag, score, name). Sử dụng thẻ (tag) làm byte đầu tiên có ích để xác định loại bản ghi sau này. Phương thức toByteArray() chép dữ liệu trong luồng xuất thành một mảng byte chứa bản ghi để lưu trữ.
Phát biểu openRecordStore() tạo và mở một lưu trữ bản ghi với tên là RecordStoreName. Phát biểu addRecord() thêm bản khi (bắt đầu bằng byte 0 của theRecord) và trả về ID bản ghi gắn với record này. Bản ghi được xóa bằng cách chuyển số ID bản ghi cho phương thức deleteRecord() của đối tượng RecordStore.
Ví dụ, bản ghi 7 bị xóa bằng phương thức deleteRecord(), nếu một bản ghi khác được thêm vào thì số ID bản ghi sẽ là 8 và ID bản ghi 7 sẽ không được dùng lại.
Sau đây là mô tả các giao diện kết nối được định nghĩa trong CLDC StreamConnectionNotifier. Giao diện StreamConnectionNotifier được dùng khi đợi một kết nối phía server được thiết lập. Nếu tham số host được xác định, thì datagram mở kết nối ở chế độ client.
Nếu tham số host không được xác định, thì datagram được mở ở chế độ server. Giao diện InputConnection dùng để thực hiện một luồng nhập tuần tự dữ liệu chỉ đọc. Nền tảng J2ME SV: Lê Ngọc Quốc Khánh Giao diện ContentConnection mở rộng giao diện StreamConnection và thêm vào các phương thức getType(), getEncoding(), và getLength().
Giao diện HttpConnection được định nghĩa trong MIDP và mở rộng giao diện ContentConnection của CLDC.
Một số WAP gateway có thể dùng để chuyển đổi các trang HTML thành một định dạng để có thể hiển thị trên các thiết bị vô tuyến. Nhưng bởi vì HTML không thật sự được thiết kế cho các màn hình nhỏ, giao thức WAP định nghĩa ngôn ngữ đánh dấu (markup) của riêng nó, Wireless Markup Language (WML), theo chuẩn XML và được thiết kế để hỗ trợ các ứng dụng trong điều kiện ràng buộc của các thiết bị di động. Trong hầu hết trường hợp, ứng dụng thật sự hay nội dung đặt trên máy chủ Web sẽ được tạo hoàn toàn bằng WAP với WML hoặc được sinh ra động sử dụng Java servlet hay JSP.
Trong HTML, không có các hàm để kiểm tra tính hợp lệ của dữ liệu nhập hay để sinh ra các thông điệp hay hộp thoại. Tương tự, để khắc phục giới hạn giống như vậy trong WAP, một ngôn ngữ script được gọi là WMLScript cũng đã được phát triển. Để giảm thiểu yêu cầu băng thông, và bảo đảm các mạng vô tuyến đa dạng có thể chạy các ứng dụng WAP, một chồng giao thức mới và nhẹ được phát triển.
Chồng giao thức WAP có bốn lớp: lớp phiên (session layer), lớp giao tác (transaction layer), lớp bảo mật (security layer), và lớp datagram (datagram layer). Wireless Markup Language (WML) là một ngôn ngữ đánh dậu dựa theo ngôn ngữ XML được thiết kế để mô tả cách mà nội dung WAP được biểu diễn trên đầu cuối vô tuyến. • WML được thiết kế đặc biệt cho các đầu cuối vô tuyến với màn hình chỉ có chiều dài vài dòng và chiều rộng khoảng một inch.
Dựa trên những điểm khác nhau này, WML cung cấp tập các thẻ nhỏ hơn, làm cho nó thích hợp hơn so với HTML khi áp dụng cho các đầu cuối vô tuyến.
Nó là kết hợp của pull parser và XML Writer, được dùng để viết XML. Nó chứa một WAP Binary XML (WBXML) được dùng để chuyển tài liệu XML trên các kênh truyền thông vô tuyến. Nó đơn giản hơn và quản lý không gian hiệu quả hơn Document Object Model.
Nó biên dịch và làm việc với môi trường Thiết bị thông tin di động (Mobile Information Device-MID) mà không cần phải hiệu chỉnh.
Client và server sử dụng gói DBXMLParser để xử lý tài liệu XML, DBXMLParser sử dụng bộ phân tích kXML để phân tích tài liệu XML phục vụ cho các chức năng của nó. Trong tập tin mô tả Enroll.jad có một tham số mô tả tự định nghĩa là server-URL chứa địa chỉ đến server chạy các trang JSP. Sau đó tạo ra hai đối tượng EnrollScreen là màn hình hiển thị chính của ứng dụng, HttpPoster để gởi request và nhận response trên HTTP.
Lớp này có nhiệm vụ hiển thị giao diện nhập liệu, cho phép người dùng nhập mã trường và số báo danh của mình, đưa ra menu cho phép người dùng chọn kết quả cần xem. Khi có yêu cầu, EnrollScreen sẽ sử dụng gói DBXMLParser để phát sinh yêu cầu theo định dạng XML, sau đó dùng đối tượng HttpPoster gởi yêu cầu đến Server. Khi gởi yêu cầu EnrollScreen truyền cho HttpPoster tham chiếu đến đối tượng HttpPosterListener (sẽ đề cập sau).
Khi có hồi đáp, HttpPoster sẽ dùng tham chiếu đến HttpPosterListener gọi phương thức receiveHttpResponse() để xử lý hồi đáp nhận về. Gói này có đầy đủ các phương thức để phân tích tài liệu XML, ở đây ta chỉ sử dụng một số phương thức của nó trong lớp DBXMLParser. Đây là trang JSP gốc, có nhiệm vụ tiếp nhận yêu cầu từ MIDlet client, khi nhận được request, enrolljsp.jsp sẽ dùng gói support.DBXMLParser để phân tích dữ liệu nhận được dưới dạng XML.
Sau khi lấy được dữ liệu, hoặc không tìm thấy, trang JSP sẽ trả về dữ liệu theo khuôn dạng XML (dữ liệu text không được bọc trong thẻ. <%%> của trang JSP sẽ mặc định trả về trong response).