Những phiên bản Java hiện thời
- Phiên bản chuẩn (Standard Edition - J2SE): thiết kế chạy trên Desktop và máy tính kiểu trạm làm việc
- Phiên bản xí nghiệp (Enterprise Edition – J2EE): Đưa thêm vào những hỗ trợ dành cho Servlets, JSP và XML. Phiên bản nhắm đến những ứng dụng trên nèn Web server.
- Phiên bản nhỏ gọn (Micro Edition – J2ME): thiết kế cho những thiết bị với bộ nhớ có hạn, cả về sức mạnh màn hình và tốc độ xử lý kém.
Configuration (Cấu hình):Do đây là đặc tả nên các nhà sản xuất thiết bị như Samsung, Nokia …bắt buộc phải thực thi đầy đủ các đặc tả do Sun qui định để các lập trình viên có thể dựa vào môi trường lập trình nhất quán và thông qua sự nhất quán này, các ứng dụng được tạo ra có thể mang tính độc lập thiết bị cao nhất có thể. Ví dụ như một lập trình viên viết chương trình game cho điện thoại Samsung thì có thể sửa đổi chương trình của mình một cách tối thiểu nhất để có thể chạy trên điện thọai Nokia.. Hiện nay Sun đã đưa ra 2 dạng Configuration:
· CLDC (Connected Limited Device Configuration-Cấu hình thiết bị kết nối giới hạn): được thiết kế để nhắm vào thị trường các thiết bị cấp thấp (low-end), các thiết bị này thông thường là máy điện thọai di động và PDA với khoảng 512 KB bộ nhớ. Vì tài nguyên bộ nhớ hạn chế nên CLDC được gắn với Java không dây (Java Wireless ), dạng như cho phép người sử dụng mua và tải về các ứng dụng Java, ví dụ như là Midlet.
· CDC- Connected Device Configuration (Cấu hình thiết bị kết nối): CDC được đưa ra nhắm đến các thiết bị có tính năng mạnh hơn dòng thiết bị thuộc CLDC nhưng vẫn yếu hơn các hệ thống máy để bàn sử dụng J2SE. Những thiết bị này có nhiều bộ nhớ hơn (thông thường là trên 2Mb) và có bộ xử lý mạnh hơn. Các sản phẩm này có thể kể đến như các máy PDA cấp cao, điện thoại web, các thiết bị gia dụng trong gia đình …
· Cả 2 dạng Cấu hình kể trên đều chứa máy ảo Java (Java Virtual Machine) và tập hợp các lớp (class) Java cơ bản để cung cấp một môi trường cho các ứng dụng J2ME. Tuy nhiên, 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.
Định nghĩa về Profile:Profile mở rộng Configuration bằng cách thêm vào các class để bổ trợ các tính năng cho từng thiết bị chuyên biệt. Cả 2 Configuration đều có những profile liên quan và từ những profile này có thể dùng các class lẫn nhau. Đến đây ta có thể nhận thấy do mỗi profile định nghĩa một tập hợp các class khác nhau, nên thường ta không thể chuyển một ứng dụng Java viết cho một profile này và chạy trên một máy hỗ trợ một profile khác. Cũng với lý do đó, bạn không thể lấy một ứng dụng viết trên J2SE hay J2EE và chạy trên các máy hỗ trợ J2ME. Sau đây là các profile tiêu biểu:
· Mobile Information Device Profile (MIDP): 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)
· 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
· 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.
Định nghĩa về KVM (K Virtual Machine) : Như các bạn đã biết, cơ chế thực thi đằng sau bất kỳ ứng dụng Java nào là JVM (Java Virtual Machine). Khi bạn biên dịch mã nguồn Java thành một lớp (.class) và đặt chúng vào trong file lưu trữ .JAD của Java, máy ảo JVM sẽ biên dịch file .class này thành mã thực thi điều khiển bởi JVM. Các mã trong file .class gọi là mã bytecode
Đối với thiết bị cấu hình dạng CDC, máy ảo JVM có toàn bộ chức năng tương đương với máy ảo phục vụ môi trường J2SE. Đối với thiết bị cấu hình dạng CLDC, Sun cài đặt một phiên bản thu nhỏ hơn dành cho JVM gọi là K Virtual Machine (KVM).
Tổng kết: Để lập trình J2ME cho thiết bị di động các bạn cần nhớ kiến trúc sau đây
Profile: dùng MIDP
Configuration: dùng CLDL
JVM: KVM
Để lập trình được J2ME các bạn cần cài đặt đầy đủ 3 thành phần trên, nếu không có thể sử dụng các plugin J2ME đã đóng gói sẵn dành cho các IDE tương ứng như plugin elipseme dành cho elipse, tất nhiên là cần phải cài đặt sẵn JDK.
Nếu không có IDE hỡ trợ các bạn có thể viết code J2ME bằng bất kì chương trình soạn thảo text nào (Notepad chẳng hạn) sau đó biên dịch chảy thử từ dòng lệnh DOS.
Chương trình J2ME được viết xong được xem như là một MIDlet, một bộ MIDlet gồm một hoặc nhiều MIDlet được đóng gói cùng nhau trong file nén JAR. File nén JAR chứa tất cả những file lớp .class của Java và các file khác như hình ảnh và dữ liệu ứng dụng, bên cạnh đó file JAR còn chứa đựng một file gọi là file thống kê hay manifest fiel, file này mô tả nội dung của file JAR. Nếu đã sử dụng IDE chúng ta không cần cấu hình file dạng này vì đã có IDE hỗ trợ
Giới thiệu MIDP
a)Định nghĩa:
Đây là Profile được đị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. 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 MIDP không phải là cây đũa thần cho mọi lập trình viên vì như chúng ta đã biết, MIDP được thiết kế cho các máy di động có cấu hình rất thấp. Trong phần sau tôi sẽ liệt kê qua các tính năng mà MIDP cung cấp và những giới hạn của nó.
b)Những chức năng MIDP không thực hiện được:
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 lớp (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
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.
c)Những chức năng 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.
Hỗ trợ Timer và Aler
Cung cấp tính năng Record Management System (RMS) cho việc lưu trữ dữ liệu
Ngoài ra vào tháng 11 năm 2003 Sun đã tung ra MIDP 2.0 với hàng loạt tính năng khác được cung cấp thêm so với bản 1.0. Những cải tiến nổi bật so với MIDP 1.0
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í 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ỗ 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
Môi trường phát triển J2ME
Chúng ta đã tìm hiểu sơ qua về J2ME, vậy có những công cụ nào hỡ trợ cho việc lập trình J2ME. Có nhiều môi trường phát triển ứng dụng J2ME và mỗi hãng điện thoại cũng đưa ra những môi trường phát triển cho riêng mình. Ở đây tôi sẽ giới thiệu toolkit của Sun: J2ME Wireless Toolkit. Địa chỉ download chương trình: http://java.sun.com/j2me/download.html . Ngoài ra bạn cần phải có J2SDK 1.4 trở lên.
Toolkit này hỗ trợ cũng không trực quan lắm cho người sử dụng, nếu bạn đã từng làm quen với các IDE lập trình Java (NetBean, JCreator, Jbuilder, Eclipse…) thì mỗi IDE này đều hỗ trợ các plugin dành cho việc lập trình J2ME, các bạn có thể download tại các website về sử dụng.
Sau đây mình xin tóm gọn lại quá trình tạo một ứng dụng J2ME bằng IDE để phân phối trên thiết bị di động.
Quá trình phát triển ứng dụng MIDlet với IDE (Môi trường phát triển tích hợp-Intergrated Development Environment):
Lập trình viê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).
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à sẽ có một tập tin *.class sinh ra cho mỗi lớp Java.
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. 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.
Lập trình viên đóng gói thành file nén JAR trên IDE
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.
* 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:
* 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.
* 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.
* 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
Khung chương trình chuẩn
1) Phát biểu import: Các phát biểu import được dùng để include các lớp cần thiết từ các thư viện CLDC và MIDP.
2) Phần chính của MIDlet: MIDlet được định nghĩa như một lớp kế thừa lớp MIDlet. Trong ví dụ này MIDletExample là bắt đầu của ứng dụng.
3) Hàm tạo (Constructor): 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.
4) startApp(): 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. Nói chung, các biến toàn cục sẽ được khởi tạo lại trừ hàm tạo bởi vì các biến đã được giải phóng trong hàm pauseApp(). Nếu không thì chúng sẽ không được khởi tạo lại bởi ứng dụng.
5) pauseApp() :Phương thức pauseApp() được gọi bởi bộ quản lý ứng dụng mỗi khi ứng dụng cần được tạm dừng (ví dụ, trong trường hợp có cuộc gọi hoặc tin nhắn đến). Cách thích hợp để sử dụng pauseApp() là giải phóng tài nguyên và các biến để dành cho các chức năng khác trong điện thoại trong khi MIDlet được tạm dừng. Cần chú ý rằng khi nhận cuộc gọi đến hệ điều hành trên điện thoại di động có thể dừng KVM thay vì dừng MIDlet. Việc này không được đề cập trong MIDP mà đó là do nhà sản xuất quyết định sẽ chọn cách nào.
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ương thức destroy() được gọi.
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.
notifyDestroyed(): Sẵn sàng để hủy
Ví dụ: Xử lý nút nhấn Exit
Lập trình viên có thể yêu cầu tạm dừng MIDlet trong khi đợi một sự kiện timer hết hạn. Trong trường hợp này, phương thức notifyPaused() sẽ được dùng để yêu cầu bộ quản lý ứng dụng chuyển ứng dụng sang trạng thái tạm dừng.
1.3 Tập tin JAR
Các lớp đã biên dịch của ứng dụng MIDlet được đóng gói trong một tập tin JAR (Java Archive File). Đây chính là tập tin JAR được download xuống điện thoại di động.
Tập tin JAR chứa tất cả các tập tin class từ một hay nhiều MIDlet, cũng như các tài nguyên cần thiết. Hiện tại, MIDP chỉ hỗ trợ định dạng hình .png (Portable Network Graphics). Tập tin JAR cũng chứa tập tin kê khai (manifest file) mô tả nội dung của MIDlet cho bộ quản lý ứng dụng. Nó cũng phải chứa các tập tin dữ liệu mà MIDlet cần. Tập tin JAR là toàn bộ ứng dụng MIDlet. MIDlet có thể load và triệu gọi các phương thức 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.
Tham khảo:
Lập trình Moile Games bằng J2ME – javavietnam.org
Java Tập 3 – Phương Lan, Trần Tiến Dũng
0 nhận xét:
Đăng nhận xét