Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 17 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
17
Dung lượng
539,9 KB
Nội dung
Chương 2 : Giới thiệu khái quát về chuẩn J2ME 35 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. Chương 3 : Những khó khăn do hạn chế của J2ME 36 Chương 3 : NHỮNG KHÓ KHĂN DO HẠN CHẾ CỦA J2ME Như chương 2 đã đề cập, J2ME được thiết kế nhắm đến thị trường các thiết bị di động có cấu hình thấp, hạn chế về năng lực xử lý và khả năng lưu trữ. Cũng vì vậy, bộ thư viện lớp của J2ME cũng được giản lược để trở nên đơn giả n và gọn nhẹ hơn rất nhiều so với J2SE. Những hàm, lớp ít khi sử dụng, không cần thiết hoặc không thể cài đặt được do khả năng hạn chế của phần cứng thiết bị đều được loại bỏ. Tuy vậy, việc loại bỏ quá nhiều thư viện hàm cũng gây không ít khó khăn cho nhóm trong quá trình thực hiện đề tài, đặc biệt là việc thiếu thốn các hàm về đồ h ọa. Điều này đặt ra yêu cầu tìm kiếm giải pháp khắc phục hoặc các giải pháp thay thế. 3.1. Các hàm tô màu : Thư viện đồ họa của J2ME – MIDP 1.0 chỉ hỗ trợ các hàm tô màu sau : fillArc : tô màu cho vùng giới hạn bởi một cung fillRect : tô màu cho một hình chữ nhật fillRoundRect : tô màu cho một hình chữ nhật có góc tròn Nhằm giúp người xem bản đồ dễ dàng phân biệt được các đơn vị hành chính (trong đề tài này, đó là các quận), hầ u hết trong mọi bản đồ, người ta thường tô màu cho mỗi đơn vị sao cho hai vùng kế cận nhau không cùng màu với nhau. Nếu như trong Visual C++, chúng ta có thể sử dụng ít nhất là 1 trong 3 hàm FillRgn, FillPolygon, FloodFill để thực hiện được việc này. Trong phiên bản Java chuẩn (J2SE) cũng có cung cấp hàm FillPolygon nhưng đáng tiếc là trong J2ME, hàm này lại bị lược bỏ và chuẩn J2ME cũng không cung cấp hàm nào giúp tô màu Chương 3 : Những khó khăn do hạn chế của J2ME 37 cho một vùng kín có hình dạng bất kỳ. Nếu chỉ sử dụng 3 hàm tô màu như trên thì không thể nào thực hiện được. Tuy vậy, một điều may mắn là trong phiên bản MIDP 2.0, thư viện đồ họa lại được thêm vào 1 hàm mới, đó là fillTriangle. Đó là một cơ hội mà chúng ta có thể tận dụng được. Theo một quy tắc trong đồ họa máy tính, một mặt phẳng bất kỳ, kể cả hình tròn đều có thể được lợp kín từ nhiều tam giác (với số lượng tam giác đủ lớn). Như vậy, nếu chúng ta có thể tạo được các tam giác từ dữ liệu về ranh giới của các quận rồi áp dụng hàm fillTriangle thì vấn đề tô màu cho các quận sẽ được giải quyết. Tuy nhiên, cách này có một hạn chế đó là chỉ có thể thực hiện được nếu điện thoại di động sử dụng MIDP 2.0 3.2. Các hàm vẽ đường : Thư viện đồ họa trong J2ME chỉ hỗ trợ hàm vẽ đường thẳng có độ dày là 1 pixel, ngoài ra không có hàm nào khác cho phép thay đổi độ dày này, điều mà chúng ta có thể thay đổi được chỉ là dạng nét vẽ : nét liền (SOLID) hay nét đứt (DOTTED). Nếu so với phiên bản chuẩn J2SE thì chúng ta thấy r ằng thư viện đồ họa J2ME đã bị loại bỏ hàm setStroke vốn dễ dàng thực hiện được điều này. Như vậy, khi cần vẽ các con đường trên bản đồ có độ dày mỏng khác nhau và đủ lớn để có thể vẽ tên đường trên đó cũng như để phân biệt các đại lộ với các đường nhỏ hơn, chúng ta buộc phải vẽ liên tiếp nhiều đoạn th ẳng xếp cạnh nhau. Chương 3 : Những khó khăn do hạn chế của J2ME 38 Đây là các giải quyết đơn giản nhất, tuy nhiên, việc gọi nhiều hàm vẽ liên tục cũng có hạn chế là làm giảm tốc độ của chương trình. Do đó, chương trình cần phải so sánh để loại bỏ việc vẽ những những đường không nhìn thấy và hạn chế đến mức thấp nhất số đoạn thẳng cần vẽ. 3.3. Vấn đề font chữ : J2ME không cho phép chúng ta thay đổi loại font chữ cho đối tượng Graphics, có nghĩa là không cho phép chúng ta quy định font family, font size… Điều này có thể là do font hệ thống trong thiết bị là có giới hạn và chỉ có một số điện thoại di động cho phép cài đặt thêm font chữ vào máy. Khi tạo một đối tượng thuộc lớp Font để sử dụng, chúng ta chỉ có một cách, đó là : Font font = Font.getFont(int face, int style, int size) Trong đó, các tham số truyền vào bắt buộc phải là các hằng số sau : face : FACE_SYSTEM, FACE_MONOSPACE, FACE_PROPORTIONAL style : STYLE_PLAIN, hoặc tổ hợp từ các dạng STYLE_BOLD, STYLE_ITALIC, STYLE_UNDERLINED size : SIZE_SMALL, SIZE_MEDIUM, SIZE_LARGE Đặc điểm này gây ra một bất lợi cho chương trình, đó là khó xác định được chính xác kích thước của font chữ được sử dụng để lựa chọn cho phù hợp vì đối với một số điện thoại, font với kích thước trung bình có thể đẹp, nhưng với một số đi ện thoại khác thì quá to hoặc quá nhỏ hay quá cao. Mặt khác, khi phóng to bản đồ đến một mức nào đó thì font chữ có kích thước tối đa cũng sẽ trở nên quá nhỏ và không còn phù hợp nữa. Đây là một vấn đề thuộc về hệ thống cho nên nhóm thực hiện đề tài không khắc phục được triệt để mà Chương 3 : Những khó khăn do hạn chế của J2ME 39 chỉ có thể chọn lựa được dạng font cùng với kích thước thích hợp nhất phù hợp với phần lớn điện thoại phổ biến trên thị trường Việt Nam hiện nay. 3.4. Vấn đề vẽ chuỗi ký tự : Trong J2ME, việc vẽ một chuỗi ký tự được thực hiện thông qua hàm sau : public void drawString(String str, int x, int y, int anchor) với x, y là tọa độ bắt đầu vẽ và anchor là chế độ căn lề . Anchor được tổ hợp từ 1 hằng số căn lề theo chiều ngang (LEFT, HCENTER, RIGHT) và 1 hằng số nhằm căn lề theo chiều dọc (TOP, BASELINE, BOTTOM). Nếu như trong Visual C++, chúng ta có thể vẽ chuỗi ký tự xoay theo mọi hướng nhờ vào 2 trường lfEscapement và lfOrientation của struct LOGFONT thì trong J2ME, chúng ta không được cung cấp bất cứ một hàm, một đối tượng nào có chức năng tương tự như thế. Mọi chuỗi ký tự do thư viện đồ h ọa của J2ME vẽ ra đều có chiều nằm ngang. Như vậy, nếu một con đường trên bản đồ có chiều không nằm theo phương ngang (hầu hết các đường đều như vậy) thì chúng ta không thể sử dụng hàm vẽ chuỗi ký tự nêu trên để vẽ tên đường cũng như không thể xoay tên theo hướng của đường như trong các bản đồ bình thường khác : Chương 3 : Những khó khăn do hạn chế của J2ME 40 Để khắc phục việc này, chúng ta có thể sử dụng một giải pháp thay thế, đó là phân rã chuỗi tên đường thành các ký tự rồi trực tiếp tính toán để xác định vị trí của mỗi ký tự trên bản đồ, sau đó sử dụng hàm vẽ ký tự để hiển thị từng ký tự này ra màn hình : public void drawChar(char character, int x, int y, int anchor) ý nghĩa của các tham số tương tự như hàm drawString. Sau khi áp dụng phương pháp trên, kết quả đạ t được như sau : Nhận xét : Giải pháp này cũng chưa thật sự tốt do buộc chương trình phải xử lý, tính toán nhiều. Ngoài ra, việc vẽ các ký tự trong tên đường một cách rời rạc như vậy cũng có thể khiến người sử dụng khó theo dõi nếu một vùng nào đó có số lượng đường giao thông nhiều và nằm gần nhau. Tuy vậy, trong điều kiện thiếu thốn các hàm về xử lý font chữ, các hàm vẽ ký tự của thư viện đồ họa thì đây là giải pháp duy nhất, tốc độ thực hiện cũng có thể chấp nhận được. 3.5. Vấn đề về số thực : Như chương 2 đã trình bày, J2ME đã loại bỏ kiểu dữ liệu số thực (float, double). Từ lý do này chương trình gặp phải một số khó khăn sau : - Phải xây dựng lại hàm tính căn bậc 2 để phụ c vụ cho mục đích xác định khoảng cách giữa 2 tọa độ. - Vì không hỗ trợ số thực cho nên J2ME cũng không hỗ trợ các hàm tính sin, cos của một góc. Như vậy, chúng ta không thể vẽ được mũi tên cho các đoạn đường một chiều bởi vì để xác định được 2 đoạn thẳng trên đầu mũi tên, Chương 3 : Những khó khăn do hạn chế của J2ME 41 chúng ta bắt buộc phải sử dụng đến công thức lượng giác. Hiện nay, có nhiều lập trình viên trên thế giới xây dựng một thư viện bổ sung để xử lý các số thực : http://bearlib.sourceforge.net http://henson.newmail.ru/j2me/Float.htm Tuy nhiên, xét thấy việc sử dụng thêm các thư viện hàm bổ sung sẽ làm tăng đáng kể kích thước và việc tính toán nhiều trên số thực cũng khiến cho chương trình chạy chậm đ i, hơn nữa, đây cũng không phải là tính năng thực sự quan trọng nên nhóm thực hiện đề tài không cài đặt phần này. Chương 4 : Phân tích – Thiết kế ứng dụng 42 Chương 4 : PHÂN TÍCH – THIẾT KẾ ỨNG DỤNG 4.1. Khảo sát hiện trạng : Hiện nay, trên thế giới cũng như tại Việt Nam, các điện thoại di động đang được sử dụng ngày càng nhiều. Chiếc điện thoại di động tuy nhỏ bé nhưng hết sức tiện lợi, ngoài chức năng liên lạc, nó còn là một phụ tá không thể thiếu và là một phương tiện phục vụ cho gi ải trí rất lý thú. Do đó, điện thoại di động ngày càng khẳng định được vị trí của nó trong cuộc sống của chúng ta. Các điện thoại di động hiện nay có thể chạy được rất nhiều phần mềm, phần lớn các ứng dụng này là trò chơi, chỉ có một số ít là ứng dụng tiện ích như máy tính, từ điển, chương trình nghe nhạc, xem phim Thị trường phần mềm trên đ iện thoại di động đang dần dần phát triển và ngày càng trở nên hấp dẫn. Tuy nhiên, với ứng dụng bản đồ điện tử trên điện thoại di động (chạy trên nền Java) thì rất ít. Ứng dụng bản đồ cụ thể cho mạng giao thông ở Việt Nam nói chung, cho thành phố Hồ Chí Minh thì hiện chỉ có một vài sản phẩm, nhưng có rất ít chức năng và rất cồng kềnh, không thể sử dụng được cho các máy có ít bộ nhớ. Do đó, việc xây dựng một ứng dụng bản đồ điện tử cho các máy điện thoại di động dựa trên nền Java là hết sức cần thiết. Ứng dụng này sẽ giúp cho người dùng xem bản đồ, tìm đường, tìm các địa điểm (trường học, khách sạn, bệnh viện…), tìm đường đi giữa hai địa điểm khi cần. Trong bối cảnh Việt Nam đang hội nhập với thế giới, thành phố Hồ Chí Minh lại là một trong những vùng kinh tế trọng điểm của cả nước. Việc cho ra đời một sản phẩm bản đồ trên điện thoại di động như thế sẽ giúp ích rất nhiều cho các thương gia, du khách trong và ngoài nước cũng như người dân thuận tiện trong việc đi lại, tham quan tìm hiểu thành ph ố. Chương 4 : Phân tích – Thiết kế ứng dụng 43 4.2. Phân tích và xác định yêu cầu : Dựa trên các yêu cầu về tìm kiếm thông tin của một người trên bản đồ giấy, nhóm thực hiện đưa ra các yêu cầu của ứng dụng bản đồ điện tử như sau. 4.2.1. Danh sách các yêu cầu nghiệp vụ : STT Chức năng Ghi chú 1 Hiển thị bản đồ 2 Phóng to, thu nhỏ bản đồ 3 Di chuyển bản đồ 4 Di chuyển nhanh đến một quận trên bản đồ 5 Tìm đường đi theo tên 6 Tìm địa điểm theo tên 7 Tìm đường đi ngắn nhất giữa hai vị trí trên bản đồ 8 Trợ giúp người dùng trong việc sử dụng bản đồ Bảng 4-1 : Danh sách các yêu cầu nghiệp vụ 4.2.2. Các yêu cầu phi chức năng : Chương trình phải chạy được trên các máy điện thoại thông thường. Tốc độ duyệt, tốc độ tìm kiếm chấp nhận được. Kích thước của chương trình không được quá lớn. Chương 4 : Phân tích – Thiết kế ứng dụng 44 4.3. Thiết kế ứng dụng : 4.3.1. Lược đồ sử dụng : Hình 4-1 : Lược đồ sử dụng [...]... Use Case - Hệ thống thực hiện tăng/giảm tỉ lệ vẽ của bản đồ - Hệ thống tính toán lại các thông số dùng để vẽ bản đồ - Use case kết thúc c Yêu cầu đặc biệt : - Không có d Điều kiện đầu : - Không có e Điều kiện sau : - Hệ thống vẽ lại bản đồ theo các thông số mới f Điểm mở rộng : - Không có 46 Chương 4 : Phân tích – Thiết kế ứng dụng Move map : a Mô tả : Người sử dụng thực hiện di chuyển bản đồ theo các... trỏ trên bản đồ - Kết thúc Use Case Dòng sự kiện nhánh : - Không có c Yêu cầu đặc biệt : - Không có d Điều kiện đầu : - Không có e Điều kiện sau : - Không có f Điểm mở rộng : - Không có 45 Chương 4 : Phân tích – Thiết kế ứng dụng Zoom map : a Mô tả : Người sử dụng muốn phóng to, thu nhỏ bản đồ b Dòng sự kiện : Dòng sự kiện chính : - Use case bắt đầu khi người sử dụng nhấn nút phóng to hay thu nhỏ - Nếu... lên trên, xuống dưới, lên góc trên bên phải, lên góc trên bên trái, xuống góc dưới bên phải, xuống góc dưới bên trái b Dòng sự kiện : Dòng sự kiện chính : - Use case bắt đầu khi người sử dụng nhấn các phím di chuyển bản đồ - Hệ thống thực hiện tính lại tọa độ bản đồ - Hệ thống tính lại tọa độ con trỏ - Use case kết thúc c Yêu cầu đặc biệt : - Không có d Điều kiện đầu : - Không có e Điều kiện sau : -. ..Chương 4 : Phân tích – Thiết kế ứng dụng 4. 3.2 Đặc tả Use Case : View map : a Mô tả : Người sử dụng muốn hệ thống vẽ lại thông tin của bản đồ b Dòng sự kiện : Dòng sự kiện chính : - Use case bắt đầu khi hệ thống được yêu cầu vẽ lại bản đồ - Hệ thống xóa thông tin cũ của bản đồ - Dịch chuyển tới tọa độ lưu trong máy - Hệ thống vẽ thông tin quận, đường và địa điểm nằm trong vùng bản đồ được nhìn thấy - Vẽ... tính lại tọa độ con trỏ - Use case kết thúc c Yêu cầu đặc biệt : - Không có d Điều kiện đầu : - Không có e Điều kiện sau : - Hệ thống vẽ lại bản đồ theo các thông số mới f Điểm mở rộng : - Không có 48 Chương 4 : Phân tích – Thiết kế ứng dụng Move to district : a Mô tả : Người sử dụng thực hiện di chuyển nhanh đến một quận nào đó trong thành phố b Dòng sự kiện : Dòng sự kiện chính - Hệ thống hiển thị danh... sự kiện nhánh A2: Người sử dụng trở về màn hình trước mà không tìm quận - Hệ thống tắt màn hình tìm kiếm quận - Use Case kết thúc c Yêu cầu đặc biệt : - Không có d Điều kiện đầu : - Không có 49 Chương 4 : Phân tích – Thiết kế ứng dụng e Điều kiện sau : - Hệ thống vẽ lại bản đồ theo tọa độ mới f Điểm mở rộng : - Không có 50 Chương 4 : Phân tích – Thiết kế ứng dụng Search place : a Mô tả : Người sử dụng... vẽ lại bản đồ theo các thông số mới f Điểm mở rộng : - Không có 47 Chương 4 : Phân tích – Thiết kế ứng dụng Move cursor : a Mô tả : Người sử dụng thực hiện di chuyển con trỏ theo các hướng qua trái, qua phải, lên trên, xuống dưới b Dòng sự kiện : Dòng sự kiện chính : - Use case bắt đầu khi người sử dụng nhấn các phím di chuyển con trỏ - Nếu con trỏ đã chạm biên màn hình thì kết thúc Use Case - Hệ thống... phố - Nếu người sử dụng gõ tên quận để tìm thì thực hiện luồng nhánh A1 - Nếu người sử dụng không muốn tìm nữa thì thực hiện luồng nhánh A2 - Người sử dụng chọn quận cần đến từ danh sách - Hệ thống cập nhật lại tọa độ bản đồ theo tọa độ của quận cần đến - Tắt màn hình tìm kiếm quận - Use Case kết thúc Dòng sự kiện nhánh A1: Người sử dụng gõ tên quận để tìm - Người sử dụng nhập tên quận cần di chuyển -. .. nhánh A3 - Người sử dụng chọn địa điểm cần đến từ danh sách - Hệ thống cập nhật lại tọa độ bản đồ theo tọa độ của địa điểm cần đến - Tắt màn hình tìm kiếm địa điểm - Use Case kết thúc Dòng sự kiện nhánh A1 : người sử dụng không muốn tìm kiếm nữa - Tắt màn hình danh sách các loại địa điểm - Kết thúc Use Case Dòng sự kiện nhánh A2 : người sử dụng muốn quay trở lại màn hình danh sách các loại địa điểm - Tắt... sự kiện : Dòng sự kiện chính : - Hệ thống hiển thị danh sách các loại địa điểm trong thành phố - Nếu người sử dụng không muốn tìm nữa thì thực hiện luồng nhánh A1 - Người sử dụng chọn loại địa điểm cần tìm từ danh sách - Hệ thống hiển thị danh sách các địa điểm thuộc loại này - Nếu người dùng không muốn tìm các địa điểm thuộc loại này thì thực hiện dòng sự kiện nhánh A2 - Nếu người sử dụng gõ tên địa . dụng bản đồ điện tử trên điện thoại di động (chạy trên nền Java) thì rất ít. Ứng dụng bản đồ cụ thể cho mạng giao thông ở Việt Nam nói chung, cho thành phố Hồ Chí Minh thì hiện chỉ có một. nhưng có rất ít chức năng và rất cồng kềnh, không thể sử dụng được cho các máy có ít bộ nhớ. Do đó, việc xây dựng một ứng dụng bản đồ điện tử cho các máy điện thoại di động dựa trên nền Java. cầu của ứng dụng bản đồ điện tử như sau. 4. 2.1. Danh sách các yêu cầu nghiệp vụ : STT Chức năng Ghi chú 1 Hiển thị bản đồ 2 Phóng to, thu nhỏ bản đồ 3 Di chuyển bản đồ 4 Di chuyển nhanh