Nghiên cứu và xây dựng ứng dụng gửi nhận E-Mail trên điện thoại blackberry

Là phương pháp chuyển mã sử dụng các kí tự in được để chuyển dữ liệu dạng 8-bit qua các đường đi chỉ hỗ trợ 7-bit. Phương pháp này ánh xạ một byte bất kì thành một dãy các kí tự ASCII. Cách chuyển đổi: Bất kì byte nào sẽ được ánh xạ thành 3 kí tự (bắt đầu bằng dấu =, theo sau là 2 kí tự hexa). Những kí tự in được (33-60 và 62-126) không cần encode. Dấu = (mã 61) được encode thành =3D. Dấu TAB và SPACE được encode thành =09 và =20. Dấu xuống dòng được encode thành =0D=0A.

pdf133 trang | Chia sẻ: lylyngoc | Lượt xem: 2917 | Lượt tải: 0download
Bạn đang xem trước 20 trang tài liệu Nghiên cứu và xây dựng ứng dụng gửi nhận E-Mail trên điện thoại blackberry, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
ình thiết bị. Chương 7: Phân tích và thiết kế 89  Dòng sự kiện:  Dòng sự kiện chính 1. Người dùng chọn E-mail trong danh sách E-mail. 2. Thiết bị kết nối với server và lấy nội dung E-mail. 3. Thiết bị hiển thị nội dung E-mail lên màn hình.  Các dòng sự kiện khác 2a. Nếu lấy nội dung E-mail bị lỗi thì hiển thị lỗi cho người dùng. 3a. Nếu hiển thị nội dung E-mail không được thì hiển thị lỗi cho người dùng.  Các yêu cầu đặc biệt: Không có  Trạng thái hệ thống khi bắt đầu Use-case:  Phải có 1 mail được chọn.  Chương trình đang kết nối với server.  Trạng thái hệ thống khi kết thúc Use-case:  Thiết bị hiển thị nội dung E-mail lên màn hình.  Điểm mở rộng:  Save attachment: Lưu trữ tập tin đính kèm E-mail.  Delete E-mail: Xóa E-mail đang đọc. 7.4.3 Manage Accounts:  Tóm tắt: Tác nhân: Người sử dụng chương trình Use-case này quản lý các cấu hình E-mail có sẵn  Dòng sự kiện:  Dòng sự kiện chính 1. Lấy danh sách cấu hình E-mail từ hệ thống. 2. Hiển thị danh sách cấu hình E-mail cho người dùng chọn  Các dòng sự kiện khác 1a. Nếu danh sách cấu hình E-mail trống thì thông báo cho người dùng.  Các yêu cầu đặc biệt: Không có Chương 7: Phân tích và thiết kế 90  Trạng thái hệ thống khi bắt đầu Use-case: Không có  Trạng thái hệ thống khi kết thúc Use-case:  Danh sách cấu hình E-mail hiển thị lên màn hình thiết bị.  Điểm mở rộng:  Delete Account: Xóa cấu hình E-mail được chọn.  Update Account: cập nhật thông tin cấu hình E-mail được chọn.  New Account: Thêm cấu hình E-mail mới. 7.4.4 Compose E-mail:  Tóm tắt: Tác nhân: Người sử dụng chương trình Use-case này cho phép người dùng soạn thảo E-mail và gởi E-mail cho một hay nhiều địa chỉ E-mail.  Dòng sự kiện:  Dòng sự kiện chính 1. Lấy các cấu hình E-mail có sẵn hiển thị cho người dùng. 2. Người dùng chọn cấu hình E-mail để gởi thư đi, điền đầy đủ thông tin trong màn hình soạn thảo. 3. Người dùng chọn gởi mail đi. 4. Chương trình kết nối với Server dựa trên cấu hình E-mail. 5. Chương trình đóng gói E-mail và gởi đi. 6. Hiển thị thông báo cho người dùng nếu mail được gởi đi.  Các dòng sự kiện khác 1a. Nếu không có cấu hình E-mail thì thông báo cho người dùng. 2a. Người dùng chọn thêm địa chỉ E-mail từ sổ địa chỉ: 1. Lấy số địa chỉ trong máy. 2. Hiển thị sổ địa chỉ cho người dùng chọn. 3. Thêm địa chỉ người dùng chọn vào danh sách địa chỉ gởi đi. 2b. Người dụng chọn sử dụng mẫu mail(Template): 1. Lấy danh sách mẫu mail có sẵn. 2. Hiển thị danh sách mẫu mail cho người dùng chọn. 3. Thêm mẫu mail được chọn vào nội dung mail. 4a. Nếu không thể kết nối với Server thì hiển thị lỗi cho người dùng. Chương 7: Phân tích và thiết kế 91 5a. Nếu không thể gởi mail thì hiển thị lỗi cho người dùng.  Các yêu cầu đặc biệt: Không có  Trạng thái hệ thống khi bắt đầu Use-case:  Danh sách cấu hình E-mail phải có ít nhất 1 cấu hình E-mail.  Trạng thái hệ thống khi kết thúc Use-case:  Mail của người dùng được gởi đi.  Điểm mở rộng:  Add attachment: Thêm tập tin đính kèm trong quá trình gởi mail. 7.4.5 Manage Configuration:  Tóm tắt: Tác nhân: Người sử dụng chương trình. Use-case này cho phép người dùng cấu hình các thông tin chung của chương trình như ngôn ngữ, sử dụng wifi, tự động nhận mail.v.v.  Dòng sự kiện:  Dòng sự kiện chính 1. Lấy cấu hình có sẵn và hiển thị lên cho người dùng. 2. Người dùng sửa cấu hình. 3. Lưu trữ cấu hình và áp dụng cấu hình cho chương trình.  Các dòng sự kiện khác 1a. Nếu không có cấu hình có sẵn thì sử dụng cấu hình mặc định, hiển thị lên cho người dùng. 3a. Nếu không thể lưu trữ cấu hình hoặc thông tin cấu hình sai thì hiển thị lỗi cho người dùng.  Các yêu cầu đặc biệt: Không có.  Trạng thái hệ thống khi bắt đầu Use-case: Không có.  Trạng thái hệ thống khi kết thúc Use-case:  Cấu hình được lưu trữ và áp dụng cho chương trình. Chương 7: Phân tích và thiết kế 92  Điểm mở rộng:  Auto Receive Mail: Chọn cấu hình E-mail muốn tự động nhận mail và áp dụng cho chương trình. 7.4.6 Show About & Help  Tóm tắt: Tác nhân: Người sử dụng chương trình. Use-case này hiển thị thông tin về chương trình và phần giúp đỡ người dùng.  Dòng sự kiện:  Dòng sự kiện chính 1. Lấy thông tin về chương trình và phần giúp đỡ người dùng từ hệ thống. 2. Hiển thị thông tin về chương trình và phần giúp đỡ lên màn hình thiết bị.  Các dòng sự kiện khác Không có  Các yêu cầu đặc biệt: Không có  Trạng thái hệ thống khi bắt đầu Use-case: Không có  Trạng thái hệ thống khi kết thúc Use-case:  Thông tin về chương trình và phần giúp đỡ được hiển thị lên màn hình.  Điểm mở rộng:  Không có 7.4.7 Manage Template  Tóm tắt: Tác nhân: Người sử dụng chương trình. Use-case này lấy danh sách các mẫu E-mail trong hệ thống và hiển thị cho người dùng.  Dòng sự kiện:  Dòng sự kiện chính 1. Chương trình lấy danh sách các mẫu E-mail trong hệ thống. Chương 7: Phân tích và thiết kế 93 2. Hiển thị các mẫu E-mail lên màn hình thiết bị.  Các dòng sự kiện khác 1a. Nếu danh sách mẫu E-mail trống thì hiển thị thông báo cho người dùng.  Các yêu cầu đặc biệt: Không có  Trạng thái hệ thống khi bắt đầu Use-case: Không có  Trạng thái hệ thống khi kết thúc Use-case:  Danh sách các mẫu E-mail có sẵn được hiển thị lên màn hình thiết bị.  Điểm mở rộng:  Delete Template: Xóa mẫu E-mail được chọn.  Update Template: Cập nhật mẫu E-mail được chọn.  New Template: Thêm một mẫu E-mail mới. 7.4.8 Delete E-mail:  Tóm tắt: Tác nhân: Người sử dụng chương trình. Use-case này cho phép người dùng xóa một E-mail được chọn trong danh sách mail.  Dòng sự kiện:  Dòng sự kiện chính 1. Người dùng chọn hoặc đọc E-mail. 2. Người dùng chọn xóa E-mail. 3. Chương trình kết nối với server để xóa E-mail. 4. Chương trình xóa E-mail ra khỏi server và chương trình. 5. Chương trình hiển thị thông báo cho người dùng.  Các dòng sự kiện khác 1a. Nếu E-mail không tồn tại thì thông báo cho người dùng. 3a. Nếu không thể kết nối với Server thì thông báo cho người dùng. 4a. Nếu không thể xóa E-mail thì hiển thị thông báo cho người dùng. Chương 7: Phân tích và thiết kế 94  Các yêu cầu đặc biệt: Không có  Trạng thái hệ thống khi bắt đầu Use-case:  Thiết bị phải kết nối Internet.  Phải có ít nhất 1 cấu hình E-mail đang được lựa chọn.  Thiết bị đang kết nối với server mà cấu hình E-mail đã cấu hình.  Trạng thái hệ thống khi kết thúc Use-case:  E-mail được chọn bị xóa khỏi Server và chương trình.  Điểm mở rộng: Không có 7.4.9 Save Attachment:  Tóm tắt: Tác nhân: Người sử dụng chương trình. Use-case này cho phép người sử dụng lưu tập tin đính kèm trong một E-mail vào bộ nhớ máy.  Dòng sự kiện:  Dòng sự kiện chính 1. Chương trình đọc E-mail và tìm tập tin đính kèm. 2. Nếu tồn tại tập tin đính kèm thì tải tập tin đính kèm về. 3. Hiển thị màn hình cho người dùng chọn đường dẫn lưu trữ. 4. Ghi tập tin đính kèm vào đường dẫn mà người dùng chọn. 5. Hiển thị thông báo cho người dùng.  Các dòng sự kiện khác 1a. Nếu E-mail không có tập tin đính kèm thì không thể thực hiện chức năng này. 2a. Nếu không thể tải tập tin đính kèm thì hiển thị lỗi cho người dùng. 4a. Nếu không thể ghi tập tin đính kèm vào bộ nhớ máy thì hiển thị lỗi cho người dùng.  Các yêu cầu đặc biệt: Không có  Trạng thái hệ thống khi bắt đầu Use-case:  Người dùng đang đọc một E-mail trong danh sách E-mail. Chương 7: Phân tích và thiết kế 95  Chương trình đang kết nối với server được cấu hình trong cấu hình E-mail hiện tại.  Trạng thái hệ thống khi kết thúc Use-case:  Tập tin đính kèm được tải và lưu trữ trong bộ nhớ máy.  Điểm mở rộng: Không có 7.4.10 Add Attachment:  Tóm tắt: Tác nhân: Người sử dụng chương trình Use-case này cho phép người dùng đính kèm một tập tin từ bộ nhớ máy để gởi kèm theo E-mail.  Dòng sự kiện:  Dòng sự kiện chính 1. Người dùng chọn tập tin từ bộ nhớ máy. 2. Chương trình đọc và ghi thông tin tập tin vào nội dung E- mail.  Các dòng sự kiện khác 2a. Nếu không thể đọc tập tin thì hiển thị lỗi cho người dùng.  Các yêu cầu đặc biệt: Không có.  Trạng thái hệ thống khi bắt đầu Use-case:  Người dùng đang trong màn hình soạn thảo E-mail.  Trạng thái hệ thống khi kết thúc Use-case:  Tập tin được đính kèm trong nội dung E-mail để gởi đi.  Điểm mở rộng: Không có. 7.4.11 Auto Receive E-mail:  Tóm tắt: Tác nhân: Người sử dụng chương trình. Use-case này cho phép người dụng lựa chọn một địa chỉ E-mail trong danh sách cấu hình E-mail để chương trình tự động nhận E-mail khi có E-mail mới. Chương 7: Phân tích và thiết kế 96  Dòng sự kiện:  Dòng sự kiện chính 1. Người dùng chọn tự động nhận mail. 2. Chương trình lấy cấu hình E-mail từ hệ thống và hiển thị lên cho người dùng chọn. 3. Người dùng chọn cấu hình E-mail. 4. Chương trình lưu trữ và áp dụng cho chương trình. 5. Chương trình tự động lấy mail mới theo chu kỳ nhất định và hiển thị thông báo cho người dùng.  Các dòng sự kiện khác 2a. Nếu không có cấu hình E-mail nào thì không áp dụng tự động nhận mail.  Các yêu cầu đặc biệt: Không có  Trạng thái hệ thống khi bắt đầu Use-case:  Người dùng đang ở trong màn hình chỉnh sửa tùy chọn.  Phải tồn tại ít nhất 1 cấu hình E-mail cho phép chế độ tự động nhận mail.  Trạng thái hệ thống khi kết thúc Use-case:  Chương trình tự động nhận mail mới theo một chu kỳ nhất định.  Điểm mở rộng: Không có 7.4.12 Search E-mail:  Tóm tắt: Tác nhận: Người sử dụng chương trình Use-case này cho phép người dùng tìm kiếm E-mail trong một hộp thư đã được cấu hình sẵn trong danh sách cấu hình E-mail.  Dòng sự kiện:  Dòng sự kiện chính 1. Người dùng điền nội dung tìm kiếm thư. 2. Chương trình kết nối với server E-mail hiện tại và tìm kiếm thư. 3. Chương trình hiển thị kết quả lên màn hình thiết bị.  Các dòng sự kiện khác 1a. Nếu nội dung tìm kiếm sai thì hiển thị lỗi cho người dùng. Chương 7: Phân tích và thiết kế 97 2a. Nếu không thể tìm kiếm thư thì hiển thị lỗi cho người dùng.  Các yêu cầu đặc biệt: Không có  Trạng thái hệ thống khi bắt đầu Use-case:  Người dùng đang trong màn hình đọc E-mail.  Chương trình phải đang kết nối với Server E-mail hiện tại.  Trạng thái hệ thống khi kết thúc Use-case:  Kết quả tìm kiếm được hiển thị lên màn hình thiết bị.  Điểm mở rộng: Không có 7.4.13 Add Account:  Tóm tắt: Tác nhân: Người sử dụng chương trình. Use-case này cho phép người dùng thêm một cấu hình E-mail vào danh sách cấu hình E-mail.  Dòng sự kiện:  Dòng sự kiện chính 1. Người dùng điền thông tin cấu hình E-mail. 2. Chương trình thêm cấu hình E-mail vào danh sách cấu hình E-mail có sẵn.  Các dòng sự kiện khác 2a. Nếu thông tin cấu hình bị sai hoặc không thể thêm cấu hình E-mail thì hiển thị lỗi cho người dùng.  Các yêu cầu đặc biệt: Không có  Trạng thái hệ thống khi bắt đầu Use-case:  Thông tin cấu hình E-mail phải chính xác.  Trạng thái hệ thống khi kết thúc Use-case:  Cấu hình E-mail được thêm vào danh sách cấu hình E-mail.  Điểm mở rộng: Không có Chương 7: Phân tích và thiết kế 98 7.4.14 Delete Account:  Tóm tắt: Tác nhân: Không có. Use-case này cho phép người dùng xóa một cấu hình E-mail từ danh sách cấu hình E-mail có sẵn trong hệ thống.  Dòng sự kiện:  Dòng sự kiện chính 1. Người dùng chọn cấu hình E-mail cần xóa trong danh sách cấu hình E-mail. 2. Chương trình xóa cấu hình E-mai ra khỏi hệ thống. 3. Chương trình hiển thị thông báo lên cho người dùng.  Các dòng sự kiện khác 1a. Nếu không có cấu hình E-mail nào thì hiển thị thông báo cho người dùng.  Các yêu cầu đặc biệt: Không có  Trạng thái hệ thống khi bắt đầu Use-case:  Phải tồn tại ít nhất 1 cấu hình E-mail.  Trạng thái hệ thống khi kết thúc Use-case:  Cấu hình E-mail bị xóa khỏi danh sách cấu hình E-mail.  Điểm mở rộng: Không có 7.4.15 Update Account:  Tóm tắt: Tác nhân: Người sử dụng chương trình. Use-case này cho phép người dùng cập nhật thông tin của một cấu hình E-mail có sẵn.  Dòng sự kiện:  Dòng sự kiện chính 1. Lấy cấu hình E-mail từ hệ thống và hiển thị thông tin lên màn hình thiết bị. 2. Người dùng chỉnh sửa cấu hình E-mail. Chương 7: Phân tích và thiết kế 99 3. Chương trình cập nhật thông tin cấu hình E-mail vào danh sách cấu hình E-mail.  Các dòng sự kiện khác 1a. Nếu không thể lấy thông tin cấu hình E-mail thì lấy thông tin cấu hình E-mail mặc định. 3a. Nếu không thể cập nhật thông tin cấu hình E-mail thì hiển thị lỗi cho người dùng.  Các yêu cầu đặc biệt: Không có  Trạng thái hệ thống khi bắt đầu Use-case:  Phải có một cấu hình E-mail đang được chọn.  Thông tin cấu hình E-mail phải chính xác.  Trạng thái hệ thống khi kết thúc Use-case:  Cấu hình E-mail được cập nhật trong danh sách cấu hình E-mail.  Điểm mở rộng: Không có 7.4.16 Add Template:  Tóm tắt: Tác nhân: Người sử dụng chương trình. Use-case này cho phép người dùng thêm một mẫu E-mail vào danh sách mẫu E-mail.  Dòng sự kiện:  Dòng sự kiện chính 1. Người dùng điền thông tin mẫu E-mail. 2. Chương trình thêm mẫu E-mail vào danh sách mẫu E-mail có sẵn.  Các dòng sự kiện khác 2a. Nếu thông tin mẫu E-mail bị sai hoặc không thể thêm mẫu E- mail thì hiển thị lỗi cho người dùng.  Các yêu cầu đặc biệt: Không có  Trạng thái hệ thống khi bắt đầu Use-case:  Thông tin mẫu E-mail phải chính xác. Chương 7: Phân tích và thiết kế 100  Trạng thái hệ thống khi kết thúc Use-case:  Mẫu E-mail được thêm vào danh sách mẫu E-mail.  Điểm mở rộng: Không có 7.4.17 Delete Template:  Tóm tắt: Tác nhân: Không có. Use-case này cho phép người dùng xóa một mẫu E-mail từ danh sách mẫu E- mail có sẵn trong hệ thống.  Dòng sự kiện:  Dòng sự kiện chính 1. Người dùng chọn mẫu E-mail cần xóa trong danh sách mẫu E-mail. 2. Chương trình xóa mẫu E-mai ra khỏi hệ thống. 3. Chương trình hiển thị thông báo lên cho người dùng.  Các dòng sự kiện khác 1a. Nếu không có mẫu E-mail nào thì hiển thị thông báo cho người dùng.  Các yêu cầu đặc biệt: Không có  Trạng thái hệ thống khi bắt đầu Use-case:  Phải tồn tại ít nhất 1 mẫu E-mail.  Trạng thái hệ thống khi kết thúc Use-case:  Cấu hình E-mail bị xóa khỏi danh sách mẫu E-mail.  Điểm mở rộng: Không có 7.4.18 Update Template:  Tóm tắt: Tác nhân: Người sử dụng chương trình. Use-case này cho phép người dùng cập nhật thông tin của một Mẫu E-mail có sẵn. Chương 7: Phân tích và thiết kế 101  Dòng sự kiện:  Dòng sự kiện chính 1. Lấy Mẫu E-mail từ hệ thống và hiển thị thông tin lên màn hình thiết bị. 2. Người dùng chỉnh sửa Mẫu E-mail. 3. Chương trình cập nhật thông tin Mẫu E-mail vào danh sách Mẫu E-mail.  Các dòng sự kiện khác 1a. Nếu không thể lấy thông tin Mẫu E-mail thì lấy thông tin Mẫu E-mail mặc định. 3a. Nếu không thể cập nhật thông tin Mẫu E-mail thì hiển thị lỗi cho người dùng.  Các yêu cầu đặc biệt: Không có  Trạng thái hệ thống khi bắt đầu Use-case:  Phải có một Mẫu E-mail đang được chọn.  Thông tin Mẫu E-mail phải chính xác.  Trạng thái hệ thống khi kết thúc Use-case:  Mẫu E-mail được cập nhật trong danh sách Mẫu E-mail.  Điểm mở rộng: Không có 7.5 Thiết kế kiến trúc: 7.5.1 Mô hình hoạt động: Hình 7.2 – Mô hình hoạt động của ứng dụng • Ứng dụng chạy trên điện thoại BlackBerry. Ứng dụng viết bằng ngôn ngữ Java, sau khi biên dịch sẽ tạo ra file *.cod. Chương 7: Phân tích và thiết kế 102 • Ứng dụng kết nối với các mail server thông qua Internet, sử dụng các giao thức SMTP, POP3 và IMAP. • Có thể thiết lập kênh truyền với SSL hay TLS. • Sau khi kết nối, ứng dụng sẽ giao tiếp với server bằng các lệnh để đọc e-mail, gửi e-mail, xóa e-mail, ... 7.5.2 Kiến trúc phía ứng dụng BlackBerry: Hình 7.3 – Kiến trúc thành phần ứng dụng phía Client Kiến trúc phía Client bao gồm các thành phần:  Thành phần nhận e-mail (receive e-mail component):  Bao gồm các lớp hỗ trợ việc nhận e-mail và hiển thị cho người dùng.  Thành phần gửi e-mail (send e-mail component): Receive E-mail Component Send E-mail Component Connection Component Configuration & Support Component Data Store Component Chương 7: Phân tích và thiết kế 103  Bao gồm các lớp hỗ trợ việc soạn thảo và gửi e-mail đến các địa chỉ.  Thành phần kết nối (connection component):  Bao gồm các lớp thực hiện việc kết nối, gửi /nhận dữ liệu trên mạng giữa client và server.  Thành phần quản lý cấu hình và hỗ trợ (Configuration & Support Component):  Bao gồm các lớp thực hiện chức năng quản lý cấu hình ứng dụng, lưu file, đính kèm file, ...  Thành phần lưu trữ thông tin (Data Store Component):  Các lớp chứa thông tin và lưu trữ thông tin trên điện thoại 7.6 Thiết kế lớp: 7.6.1 Các lớp dùng chung: Hình 7.4 – Các lớp quản lý màn hình Chương 7: Phân tích và thiết kế 104 7.6.2 Thành phần gởi & nhận e-mail: Hình 7.5 – Các thành phần lưu trữ và xử lý Message Hình 7.6 – Sơ đồ các lớp quản lý E-mail Chương 7: Phân tích và thiết kế 105 7.6.3 Thành phần quản lý cấu hình và lưu trữ: Hình 7.7 – Thành phần các lớp quản lý cấu hình và lưu trữ 7.7 Thiết kế xử lí: 7.7.1 Nhận e-mail: Hình 7.8 – Quá trình nhận E-mail bằng giao thức IMAP Chương 7: Phân tích và thiết kế 106 Hình 7.9 - Quá trình nhận E-mail bằng giao thức POP Hình 7.10 – Xử lý và hiển thị nội dung E-mail Chương 7: Phân tích và thiết kế 107 Hình 7.11 – Xử lý Attachment trong E-mail 7.7.2 Gửi e-mail: Hình 7.12 – Đóng gói và gởi E-mail Chương 7: Phân tích và thiết kế 108 7.7.3 Trạng thái chuyển đổi của chương trình Hình 7.13 - Các trạng thái chuyển đổi của chương trình Chương 8: Cài đặt và thử nghiệm 109 Chương 8: Cài đặt và thử nghiệm 8.1 Môi trường phát triển: Ứng dụng gởi và nhận mail trên điện thoại BlackBerry được phát triển sử dụng các công cụ và môi trường sau: Công cụ phân tích và thiết kế: Star UML v5.0 Môi trường cài đặt ứng dụng: Research In Motion OS. Môi trường lập trình: Eclipse và BlackBerry API Plug-in cho Eclipse. Môi trường thử nghiệm và cài đặt: Máy ảo BlackBerry 9000, 9550, 9700. 8.2 Cài đặt: 8.2.1 Yêu cầu phần mềm: Yêu cầu phần mềm:  Tập tin .alx và .cod để cài đặt chương trình.  Hệ điều hành Research In Motion phiên bản 5.0 trở lên.  Chương trình quản lý thiết bị của Research In Motion: BlackBerry Desktop Manager. 8.2.2 Yêu cầu phần cứng: Yêu cầu phần cứng:  Thiết bị BlackBerry đang sử dụng hệ điều hành Research In Motion phiên bản 5.0 trở lên.  Cable mini USB hoặc loại cable phù hợp để kết nối thiết bị vào máy tính.  Máy tính để lưu trữ và cài đặt chương trình. 8.2.3 Hướng dẫn cài đặt: Sau khi build chương trình, chương trình sẽ phát sinh cho người dùng tập tin .alx. Để cài đặt trên máy thật, thực hiện các bước sau: 1. Kết nối thiết bị với máy tính. 2. Khởi động chương trình BlackBerry Desktop Manager. Chọn Application Loader như hình: Chương 8: Cài đặt và thử nghiệm 110 Hình 8.1 – Giao diện BlackBerry Desktop Manager 3. Chọn Add/Remove Application, chọn Start, chương trình BlackBerry Desktop Manager sẽ hiện ra danh sách các chương trình đã cài trong máy. Để cài chương trình mới. Chọn Browse.. Lựa chọn tập tin .alx đã build ở trên, nhấn ok. Chọn Next và bắt đầu cài đặt. Thiết bị sẽ tự khởi động lại, quá trình cài đặt hoàn tất. Hình 8.2 – Danh sách chương trình trong thiết bị 8.3 Thử nghiệm: Chương trình gởi và nhận mail trên BlackBerry thử nghiệm trên máy ảo giả lập cho ra các kết quả thử nghiệm sau: Chương 8: Cài đặt và thử nghiệm 111 STT Tính năng thử nghiệm Đánh giá 1 Khả năng kết nối mạng Tốc độ kết nối ổn định, tùy thuộc vào mạng sử dụng. 2 Nhân và gởi dữ liệu Tốc độ truyền dẫn dữ liệu tương đối nhanh. 3 Tiêu thụ bộ nhỏ Chương trình khởi động chiếm dưới 500 KB bộ nhớ, tương đối thập và nằm trong phạm vi cho phép của một chương trình BlackBerry. Không bị quả tải đối với các máy đời cũ, bộ sử lý yếu. 4 Lưu trữ bộ nhớ Chương trình lưu trữ các thông tin của chương trình và dữ liệu dùng để sử dụng chiếm ít, tăng dần khi người sử dụng tăng dữ liệu lên. Dữ liệu lưu trữ không bị xóa trong quá trình khởi động lại máy, dữ liệu lưu trữ chỉ bị xóa khi Master Reset máy – Làm mới lại hệ điều hành. 5 Tốc độ hiển thị hình ảnh Tốc độ hiển thị hình ảnh nhanh, đầy đủ. 6 Nhận mail Chương trình nhận mail đầy đủ các thông tin và tất cả các E-mail trong hộp mail. Chức năng phân trang đầy đủ. 7 Gởi mail Chương trình đóng gói mail tốc độ khá nhanh. Tốc độ gởi mail tùy thuộc vào đường truyền mạng đang sử dụng. Khi gởi mail bằng mẫu E-mail(Template) tốc độ gởi sẽ chậm hơn do cần phải thực hiện nhiều lần. 8 Quản lý cấu hình Chương trình quản lý và lưu trữ các cấu hình E-mail đầy đủ, cho phép người sử dụng thêm, xóa, sửa các thông tin trong cấu hình. 9 Quản lý mẫu E-mail Chương trình quản lý và lưu trữ các mẫu E- mail đầy đủ, lưu trữ các mẫu E-mail trong bộ nhớ máy để sử dụng lần sau, cho phép người sử dụng thêm, xóa, sửa các thông tin của mẫu E-mail. 10 Quản lý cấu hình Chương trình quản lý cấu hình đây đủ, có lưu trữ trong bộ nhớ máy để tải lại vào lần sử dụng tiếp theo. 11 Tự động nhận mail Tự động nhận mail nhanh, hiển thị chính xác số mail chưa được đọc. Cho phép người dùng đọc mail mới ngay lập tức. 12 Hiển thị ngôn ngữ Chương trình cho phép hiển thị ngôn ngữ tiếng Anh và tiếng Việt. Chuyển đổi ngôn ngữ để dàng trong phần cấu hình, việc chuyển đổi ngôn ngữ được áp dụng lập tức hoặc sau khi người dùng khởi động lại chương trình. Chương 8: Cài đặt và thử nghiệm 112 13 Cho phép gõ tiếng Việt trong E-mail. Chương trình cho phép người dùng gõ tiếng Việt trong khi soạn E-mail bằng bộ gõ Telex. 14 Chạy ngầm trong hệ thống. Chương trình chạy ngầm trong hệ thống ổn định, không bị ảnh hưởng đến các chương trình khác trong máy. Bảng 8.1 - Kết quả thử nghiệm trên máy ảo của chương trình Thử nghiệm trên máy thật: Vì chưa thể ký chương trình để triển khai trên máy thật nên chương trình hiện nay chưa thể thử nghiệm trên máy thật. Chương 9: Tổng kết 113 Chương 9: Tổng kết 9.1 Kết luận: 9.1.1 Kết quả đạt được: Sau khi thực hiện đề tài, chúng em đã thu được một số kết quả sau:  Tìm hiểu được các công nghệ gởi và nhận E-mail, một trong những công nghệ có tầm ứng dụng mạnh mẽ nhất hiện nay. Chúng em đã tìm hiểu được cách thức hoạt động, đặc điểm kỹ thuật và khả năng của các công nghệ dùng để gởi và nhận mail.  Tìm hiểu được hệ điều hành Research In Motion và lập trình trên hệ điều hành Research In Motion. Bằng cách xây dựng một ứng dụng trên hệ điều hành Research In Motion, chúng em đã tiếp thu được kiến thức về Research In Motion cũng như BlackBerry, thiết bị di động đã và đang phát triển mạnh mẽ trong các thiết bị di động thông minh.  Tìm hiểu được cách lập trình giao tiếp với các E-mail Server trên BlackBerry. Từ lý thuyết(tìm hiểu về các công nghệ giúp cho việc gởi và nhận mail), chúng em đã tiếp tục thực tế bằng cách tìm hiểu cách lập trình để gởi, nhận và phân tích E-mail trên hệ điều hành Research In Motion.  Xây dựng một chương trình gởi và nhận mail thông qua điện thoại BlackBerry, phục vụ cho việc gởi và nhận mail. Với chương trình này người dùng có thể gởi và nhận mail một cách nhanh chóng và tiện lợi. Ngoài phục vụ cho mục đích gởi và nhận mail thông thường, chương trình còn phục vụ cho nhiều mục đích khác như thông báo E-mail mới, gởi E-mail cho nhiều người với nội dung khác nhau. 9.1.2 Hạn chế: Mặc dù đã cố gắng hết sức nhưng ứng dụng vẫn còn một số hạn chế nhất định:  Tốc độ của ứng dụng còn phụ thuộc vào rất nhiều yếu tố như tốc độ mạng, dung lượng và cấu trúc của E-mail.v.v. Nếu tốc độ mạng chậm ứng dụng có thể không thể hiện đầy đủ và chính xác nội dung E-mail.  Ứng dụng chưa thể hiện hết 3 chế độ của IMAP là Disconnect, connect và offline, ứng dụng chỉ mới thực hiện được chức năng connect.  Ứng dụng chưa thể triển khai trên thực tế vì còn vướng phải vấn đề ký chương trình của Research In Motion.  Ứng dụng đọc E-mail trực tiếp trên ứng dụng, chưa thể đồng bộ với chế độ E- mail và tin nhắn trên thiết bị BlackBerry. 9.2 Hướng phát triển: 9.2.1 Phát triển trên các dòng máy BlackBerry: Với những kết quả đặt được và những hạn chế nêu trên, đề tài có thể mở rộng theo các hướng sau:  Xây dựng ứng dụng sao cho có thể đồng bộ với các chế độ nhắn tin và E-mail trên BlackBerry. Chương 9: Tổng kết 114  Xây dựng ứng dụng có khả năng đồng bộ cao với các E-mail Server hiện tại.  Tăng khả năng kết nối của ứng dụng, cho người dùng tự định nghĩa về ngôn ngữ cũng như nội dung các mẫu E-mail.  Xây dựng ứng dụng có thể hỗ trợ Push Mail thật sự. 9.2.2 Phát triển trên các dòng máy khác: Với những kết quả đặt được và những hạn chế nêu trên, đề tài có thể mở rộng theo các hướng sau: o Vì chương trình viết dựa trên nền tảng lập trình socket trên ngôn ngữ Java. Chương trình có thể thay đổi các giao diện và mã nguồn phụ thuộc vào BlackBerry API để triển khai trên các thiết bị di động khác hỗ trợ Java và kết nối mạng. 115 PHẦN 4: PHỤ LỤC Phụ lục A: Phát triển chương trình BlackBerry A.1 Kiến trúc mạng BlackBerry BlackBerry được cung cấp bởi nhiều nhà mạng khác nhau như Nextel, Telus, T-mobile, Viettel.v.v. Nhưng tất cả các thiết bị BlackBerry đều liên kết tới Network Operating Center(NOC) của Research In Motion. Trung tâm này kết nối tất cả nhà mạng và từ các BlackBerry Enterprise Server(BES) phân phối khắp nơi. BlackBerry Enterprise Server là một middleware liên kết thiết bị tới các dịch vụ E-mail như Microsft Exchange và Lotus Notes. Hình A.1 - Kiến trúc mạng của BlackBerry (Nguồn: developers.sun.com) Được cài đặt sau tường lửa của danh nghiệp, một BES có thể được cung cấp thêm nhiều dịch vụ khác. Mobile Data Server(MDS) cung cấp cho thiết bị khả năng truy cập vào mạng toàn cục của doanh nghiệp. Để có được quyền lợi này người dùng cần cài đặt để có thể sử dụng BES khi người dùng cài đặt chương trình quản lý Desktop Software Manager của Research In Motion. Chương trình quản lý này giúp người dùng có thể kết nối thiết bị với máy tính. Một khóa mã hóa sẽ được tạo ra để bảo mật quá trình giao tiếp giữa thiết bị và BES. Nếu thiết bị không liên kết với BES, E-mail sẽ được nhận thông qua một Web Client. 116 Hình A.2 - Cài đặt để kết nối BES (Nguồn: developers.sun.com) A.2 Mô hình của chương trình BlackBerry BlackBerry cung cấp cho nhà phát triển ứng dụng 2 mô hình để phát triển ứng dụng BlackBerry: o Mô hình dựa trên trình duyệt:Cho phép nhà phát triển phát tirển ứng dụng bằng một ngôn ngữ đánh dấu, ví dụ như Wireless Markup Language(WML) hoặc compact Hypertext Markup Language(cHTML). Việc sử dụng các khả năng của các trình duyệt giúp người phát triển ứng dụng không phải lo về giao diện người dùng, nhưng nó giới hạn khả năng làm việc của người dùng theo khả năng trình duyệt có thể cung cấp, và không hỗ trợ tính năng văn phòng. o Mô hình ứng dụng dựa trên nền Java: Cho phép người phát triển ứng dụng phát triển giao diện người dùgn tùy biến, hỗ trợ mạnh mẽ tính năng văn phòng và hình ảnh. Nhà phát triển cũng có thể xây dựng ứng dụng mà người dùng có thể tải về và cài đặt trên các thiết bị di động để họ có thể tiếp tục sử dụng mà không cần phải kết nối mạng. Một số thiết bị BlackBerry còn cung cấp cho người phát triển ứng dụng một bộ API để phát triển ứng dụng dựa trên nền Java. A.3 Những mở rộng của BlackBerry từ J2ME BlackBerry hỗ trợ hoàn toàn các API CLDC và MIDP. Ngoài ra Research In Motion còn cung cấp một số mở rộng cho phép người phát triển ứng dụng phát triển 117 ứng dụng tùy biến và mạnh mẽ hơn. Giúp người phát triển ứng dụng có thể truy cập và sử dụng các tính năng của BlackBerry về giao diện người dùng, mạng, bảo mật.v.v. Người phát triển ứng dụng có thể sử dụng CLDC, MIDP và Blackberry API trong cùng một ứng dụng. Tuy nhiên, một chương trình không nên sử dụng cả 2 thư viện javax.microedition.ldcui và net.rim.device.api.ui vì có thể gây xung đột giao diện người dùng. A.4 Phát triển chương trình bằng JDE Trong JDE được cung cấp, chọn menu File, chọn New workspace để tạo một vùng làm việc JDE có thể quản lý, điền tên và chọn thư mục lưu trữ: Hình A.3 - Tạo Workspace để quản lý công việc Trong menu Project, chọn Create New Project để tạo một chương trình mới. Điền tên và chọn nơi lưu trữ để lưu trữ chương trình: Hình A.4 - Tạo chương trình mới Để tạo một tập tin mới để lập trình, chọn New trong menu File. Điền tên(thường kết thúc bằng đuôi mở rộng .java), chọn đường dẫn lưu trữ: 118 Hình A.5 - Thêm một tập tin mới vào chương trình Trong màn hình sửa tập tin, nhấp chuột phải và chọn Insert Into Project để đưa tập tin vào chương trình: Hình A.6 - đưa một tập tin vào chương trình Sau đó có thể lập trình chương trình bình thường, sau đây là chương trình mẫu HelloWorld: import net.rim.device.api.ui.*; import net.rim.device.api.ui.component.*; import net.rim.device.api.ui.container.*; import net.rim.device.api.system.*; public class HelloApp extends UiApplication { public static void main(String argv[]) { HelloApp app = new HelloApp(); app.enterEventDispatcher(); 119 } public HelloApp() { pushScreen(new HelloScreen()); } } class HelloScreen extends MainScreen { public HelloScreen() { super(); LabelField title = new LabelField ("BlackBerry App", LabelField.ELLIPSIS | LabelField.USE_ALL_WIDTH); setTitle(title); add(new RichTextField("Welcome to Developing BlackBerry Apps Tutorial")); } public boolean onClose() { Dialog.alert("Visit Again!"); System.exit(0); return true; } } Bảng A.1 - Chương trình HelloWorld Để build ứng dụng và triển khai ứng dụng, chọn menu Build, chọn Build all, JdE sẽ tạo ra 3 file .jad, .jar, .cod. Người phát triển ứng dụng có thể sử dụng 3 file này để triển khai hoặc chạy thử trên máy ảo. Để triển khai trên máy thật, có thể sử dụng công cụ javaloader và chạy câu lệnh command: javaloader -usb load “tên chương trình”.cod A.5 Triển khai chương trình bằng Blackberry Desktop Manager Như đã nói ở trên, BlackBerry Desktop Manager là một chương trình dùng để kết nối thiết bị với máy tính. Ngoài ra chương trình này còn cung cấp cho người dùng các tiện ích như: Triển khai chương trình trên thiết bị, tạo tập tin với đuôi mở rộng của Research In Motion là .alx để triển khai. Tập tin có đuôi mở rộng .alx là một tập tin định nghĩa dựa trên ngôn ngữ XML, nó cung cấp các thông tin về ứng dụng, để tạo tập tin này. Chọn menu Project, chọn Generate ALX File. Nếu chương trình có tên là FirstApp, thì file alx sẽ có dạng: 120 MyCompany Copyright (c) 2010 MyCompany MyCompany FirstApp.cod Bảng A.2 - cấu trúc một tập tin .alx Để triển khai chương trình bằng công cụ Blackberry Desktop Manager: Khởi động chương trình Blackberry Desktop Manager, chọn Application Loader, chọn tập tin .alx đã tạo ở trên và cài đặt vào thiết bị. 121 Phụ lục B: Tống hợp các giao thức mail B.1 Cấu trúc MIME Có 2 loại cấu trúc MIME: cấu trúc đơn giản (discrete media) và cấu trúc phức tạp (composite media). o Cấu trúc đơn giản: text, video, audio, image, application. o Cấu trúc phức tạp: multipart, message. Các thành phần cơ bản của MIME (được miêu tả trong RFC-2045): 1. MIME-Version: Mỗi message yêu cầu có 1 trường MIME-Version trong header. Thông tin này nhằm cho biết message được chuyển mã sang dạng MIME và cho biết phiên bản MIME được sử dụng. Cú pháp: MIME-Version: 1*DIGIT“.”1*DIGIT (1.0) 2. Content-Type: Dùng để cho biết cách nội dung phần thân được biểu diễn, nhờ đó tác nhân nhận gói tin biết cách để hiểu thị nội dung với người dùng. Trường này gồm 2 thông tin kiểu (type) và kiểu con (subtype) đi kèm nhau theo cấu trúc type/subtype và có thể kèm thêm các tham số khác như charset, name, ... Tên type, subtype, parameter không phân biệt hoa thường. Tuy nhiên giá trị các parameter thường phân biệt hoa thường. Một số content type chính : application, multipart, text, message, audio, video, image và extension-token. Chú ý thông tin subtype là bắt buộc vì không có subtype mặc định cho các type trên. Một số subtype ứng với các type: 1. text: plain (primary), richtext. 2. multipart: mixed (primary), alternative, parallel, digest, related, signed. 3. message: rfc822 (primary), partial, External-body. 4. image: jpeg, gif 5. audio: basic. 6. video: mpeg 7. application: octet-stream, PostScript. Khi tác nhân đọc mail không nhận ra được giá trị của Content-Type, thường nên xem như là một application/octet-stream. Cấu trúc: Content-Type: /[; parameter1; paramenter2; ...] 122 Text: là Content-Type mặc định, dùng để gửi dữ liệu đang text. Content-Type mặc định cho Internet mail là “text/plain; charset=us-ascii”. Tham số “charset” có thể được dùng để chỉ tập kí tự được dùng. Giá trị của tham số này không phân biệt hoa thường như các tham số khác. Các giá trị bao gồm: “us-ascii” / “iso-8859-1” / “iso-8859-2” /“iso-8859-3” /“iso-8859-4” /“iso-8859-5” /“iso- 8859-6” /“iso-8859-7” /“iso-8859-8” /“iso-8859-9” / extension-token. Application: dùng để gửi những dữ liệu cần được xử lí bằng một ứng dụng trên máy tính, thường là các chương trình. Hai loại thường được sử dụng là “application/octet-stream” và “application/PostScript”. o application/octet-stream: là subtype chính dùng trong “application” Content-Type cho biết thân của message chứa dữ liệu nhị phân. Các tham số thường dùng : type, padding và name. o application/PostScript: cho biết nội dung dữ liệu là một chương trình PostScript (Một ngôn ngữ lập trình để chỉ ra cách bố trí (layout) của một trang được in). Image: cho biết nội dung của phần này là một hình ảnh. Giá trị subtype cho biết định dạng của file ảnh được sử dụng. Một số subtype hỗ trợ: g3fax / gif / ief / jpeg / tiff. Nhưng 2 loại thường phổ biến là jpeg và gif. Cấu trúc header: image-type := “image” “/” (“gif” / “jpeg” / extension-token) Audio: cho biết nội dung của phần này là một file âm thanh. Subtype được sử dụng là “basic” Cấu trúc header: audio-type := “audio” “/” (“basic” / extension-token) Video: nội dung của phần này là một file phim ảnh. Cấu trúc header: video-type := “video” “/” (“mpeg” / extension-token) Multipart: phần thân bao gồm 1 hay nhiều phần dữ liệu khác nhau (body part) kết hợp với nhau. Phần định nghĩa “multipart” Content-Type phải xuất hiện trên header, phần thân gồm 1 hay nhiều phần. Mỗi phần phân biệt cách nhau bằng đường biên (boundary). Boundary không được xuất hiện trong phần thân của body part, do đó phải có cách phát sinh ra boundary duy nhất. Mỗi phần gồm phần header của chính nó, một dòng trống và theo sau là phần thân. Chỉ những header bắt đầu bằng Content- mới có ý nghĩa trong phần header của body part. o boundary không được dài quá 70 kí tự (không bao gồm 2 dấu ‘-‘ dầu dòng. Với boundary theo sau part cuối cùng sẽ được gắn thêm 2 dấu ‘-‘ vào cuối. o Tham số boundary bắt buộc phải có trong “multipart” Content-Type. .... MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="exampledelimtext123" This is a multipart message in MIME format 123 --exampledelimtext123 Content-Type: text/plain Jane, here is the photo you wanted me for the new client. Here are some notes on how it was processed. (Blah blah blah…) Talk to you soon,Joe. --exampledelimtext123 Content-Type: image/jpeg; name="clientphoto.jpg" Content-Transfer-Encoding: base64 SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs … zv/wAARCADIARoDASIAAhEBAxEB/8QAHAAAAQUBA --exampledelimtext123-- Bảng B.1 – Ví dụ về tập tin MIME Cấu trúc của boundary được định nghĩa như sau: boundary := 0*69 bcharsnospace bchars := bcharsnospace / " " bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /"_" / "," / "-" / "." / "/" / ":" / "=" / "?" Multipart/mixed: được dùng khi các body part độc lập với nhau và cần được giữ theo một trật tự. Bất kì subtype của multipart không thể nhận biết phải được xem như “mixed”. Multipart/alternative: mỗi body part được xem như là một bản thay thế biểu diễn cùng một nội dung thông tin. Hệ thống sẽ chọn ra cách tốt nhất để hiển thị nội dung. Thứ tự của các part trong “multipart/alternative” mang ý nghĩa rằng tính chính xác của dữ liệu gốc tăng dần. Và thường hệ thống sẽ chọn ra phần sau nhất được hỗ trợ để hiển thị nội dung. Mỗi phần nên có một Content-ID, giá trị này giống nhau khi nội dung các phần giống hệt nhau và nên khác nhau khi nội dung của các phần không giống nhau hoàn toàn. Các Content-ID này khác với Content-ID của toàn bộ entity “multipart/alternative”. Multipart/digest: được dùng để gửi tập các message dạng văn bản. Nhưng giá trị mặc định của Content-Type trong mỗi phần là “message/rfc822”. Multipart/parallel: dùng để hiển thị tất cả các phần đồng thời trên cả phần cứng và phần mềm mà nó hỗ trợ. Ví dụ, hiển thị một hình ảnh trong khi đang chơi một bản nhạc. 124 Hình B.1 - Cấu trúc của một message kiểu multipart (Nguồn: The TCP/IP Guide - www.tcpipguide.com) Message: cho phép message có thể chứa các messages khác hoặc chứa các con trỏ trỏ tới các message khác. message/rfc822: Phần thân của message chứa một message khác theo cấu trúc của RFC822 message. Tuy nhiên phần thân của “message/rfc822” không yêu cầu các trường “From”, “Subject”, “To”. Một message “message/rfc822” cũng có thể là một MIME message. message/partial: được định nghĩa nhằm cho phép gửi các đối tượng dữ liệu có kích thước lớn qua nhiều đoạn message khác nhau, sau đó tự động hợp lại với nhau thành một message hoàn chỉnh. Chỉ có 7bit Content-Transfer-Encoding được dùng trong trường hợp này. Có 3 tham số bắt buộc phải có khi dùng “message/partial” Content-Type là id, number và total. Id là một giá trị duy nhất để kết hợp các phần lại với nhau. Nếu như id cho biết các phần thuộc về cùng một message thì number cho biết thứ tự của các phần và có giá trị là một số tự nhiên. Tham số cuối cùng là total, một số tự nhiên cho biết tổng số phần được tách ra của message. Tham số này buộc phải có trong phần cuối cùng nhưng nên dùng trong tất cả các phần. Chú ý giá trị của tham số number 125 bắt đầu từ 1. Khi phát sinh và hợp các phần của một message, các header của message được gói gọn phải được kết hợp với các header của message bao quanh bên ngoài theo các quy tắc sau: (1) Tất cả các trường trong header của part 1 (enclosing entity), ngoại trừ các trường bắt đầu bằng “Content-“ và các trường “Message-ID”, “Encrypted” và “MIME-Version” phải được sao chép theo thứ tự sang message mới. (2) Chỉ những trường trong header của (enclosed message) bắt đầu bằng “Content-” và các trường “Message-ID”, “Encrypted”, “MIME- Version” phải được thêm theo thứ tự vào header của message mới. (3) Tất cả các trường trong header của các message tiếp theo bắt đầu từ message thứ 2 sẽ bị bỏ qua. Ví dụ: Một message được tách thành 2 phần, phần thứ nhất có nội dung: X-Weird-Header-1: Foo From: Bill@host.com To: joe@otherhost.com Subject: Audio mail Message-ID: MIME-Version: 1.0 Content-type: message/partial; id="ABC@host.com"; number=1; total=2 X-Weird-Header-1: Bar X-Weird-Header-2: Hello Message-ID: MIME-Version: 1.0 Content-type: audio/basic Content-transfer-encoding: base64 ... first half of encoded audio data goes here... Phần thứ 2 có nội dung: Enclosing entity Enclosed message 126 From: Bill@host.com To: joe@otherhost.com Subject: Audio mail MIME-Version: 1.0 Message-ID: Content-type: message/partial; id="ABC@host.com"; number=2; total=2 ... second half of encoded audio data goes here... Theo các quy tắc trên thì message được hợp nhất có nội dung: X-Weird-Header-1: Foo From: Bill@host.com To: joe@otherhost.com Subject: Audio mail Message-ID: MIME-Version: 1.0 Content-type: audio/basic Content-transfer-encoding: base64 ... first half of encoded audio data goes here... ... second half of encoded audio data goes here... message/external-body: Cho phép nội dung của message nằm bên ngoài của message và chỉ được tham chiều tới message đó. Tham số buộc phải có khi sử dụng “message/external-body” là “access-type”, cho biết cơ chế truy cập file. Một số cơ chế thường sử dụng: (1) “FTP” và “TFTP”: truy cập file thông qua giao thức FTP và TFTP. Với các truy cập này, có thể sử dụng các tham số NAME, SIZE, DIRECTORY và MODE (NETASCII, OCTET và MAIL cho TFTP; ASCII, EBCDIC, IMAGE, LOCAL8 cho FTP). Nếu tham số MODE không được chỉ định, mặc định giá 127 trị này sẽ là NETASCII cho TFTP và ASCII cho FTP. (2) “non-ftp”: giống như FTP ngoại trừ không dùng username và password để đăng nhập và mà đăng nhập dạng ẩn danh (anonymous) với password ứng với tài khoản email sử dụng. (3) “local-file” và “afs”: “local-file” chỉ cho biết file được truy cập nằm trên máy cục bộ trong khi “afs” cho biết file được truy cập thông qua hệ thống file AFS. Tham số bắt buộc là NAME có giá trị là tên của file. Có thể dùng thêm tham số SITE để chỉ ra các máy tính có quyền truy cập nội dung của file. (4) “mail-server”: nội dung thực sự nằm trên mail server. Tham số bắt buộc là SERVER chứa địa chỉ mail của mail server chứa nội dung dữ liệu. “message/external-body” phải sử dụng trường Content-ID trong header với một giá trị duy nhất để tham chiếu tới phần dữ liệu bên ngoài. Content-Transfer-Encoding: Dùng để chỉ ra cơ chế biến đổi được dùng để biểu diễn nội dung phần thân thành dạng có thể truyền được trên các protocols giới hạn tập kí tự chuyển qua. Nhờ đó bên nhận biết cách để chuyển ngược lại dữ liệu gốc ban đầu. Một số cơ chế thường dùng: o “7bit” (phân biệt hoa thường): o “quoted-printable” o “base64” o “8bit” o “binary” o x-token 7bit là giá trị mặc định. 7bit, 8bit và binary chủ yếu dùng để chỉ loại dữ liệu chứa trong đối tượng. 7bit bao gồm các dòng ngắn (<1000) với các kí tự US-ASCII. 8bit gồm các dòng ngắn bao gồm các kí tự không phải ASCII. Binary gồm các kí tự không phải ASCII và không giới hạn độ dài của mỗi dòng. Có thể định nghĩa thêm cơ chế mới với cấu trúc x-my-new-encoding. Tuy nhiên, chỉ có 2 bên trong hệ thống mới hiểu cơ chế này. Nếu Content-Transfer-Encoding xuất hiện trong header của message thì có ảnh hưởng trên toàn bộ message đó. Nếu xuất hiện trong header của một phần của message thì chỉ ảnh hưởng trên phần đó của message. Nếu một message (hoặc body part) loại “multipart” hoặc “message” thì chỉ có 7bit, 8bit và binany được dùng. 3. Content-ID: Là một giá trị duy nhất cũng gần giống với Message-ID. Content-ID là không bắt buộc, tuy nhiên khi sử dụng trong message có Content-ID là “message/external-body” thì bắt buộc phải có để cache dữ liệu được tham chiếu tới. 4. Content-Description: Được dùng để bổ sung một số thông tin miêu tả cho nội dung của message, thường dùng dạng US-ASCII. 128 5. Content-Disposition: Hai giá trị thường sử dụng là “inline” và “attachment”, có thể kèm thêm các tham số khác. “inline” cho biết nội dung của phần message đó sẽ tự động hiển thị giống như các phần khác. Trong khi “attachment” cho biết nội dung phần message bị tách riêng khỏi phần nội dung chính (xem thêm RFC-2183). 6. Content-Location: Thông tin URI (uniform resource identifier) mà phần message sử dụng. 7. Content-Length: Tổng số byte dữ liệu chứa trong thực thể MIME (MIME entity). B.2 Cấu trúc mã trả về và ý nghĩa các chữ số Mỗi mã trả về gồm một dãy 3 chữ số liên tiếp nhau “xyz” với ý nghĩa như sau: Chữ số đầu tiên (“x”): Chữ số đầu tiên cho biết kết quả của lệnh thành công hay thất bại, lệnh đã hoàn thành hay chưa hoàn thành. Các giá trị có thể của chữ số này như sau: Định dạng Ý nghĩa 1yz Lệnh được chấp nhận và đang được xử lí. 2yz Lệnh được thực hiện thành công và kết thúc. 3yz Lệnh được chấp nhận, quá trình xử lí tạm dừng chờ cung cấp thêm thông tin. 4yz Lệnh không được chấp nhận và không có hành động nào được thực hiện, nhưng lỗi xảy ra chỉ là tạm thời và có thể thử thực hiện lại lệnh. 5yz Lệnh không được chấp nhận và không có hành động nào được thực hiện, thường do lệnh không đúng. Bảng B.2 - Chữ số “x” Chữ số thứ hai (“y”): Định dạng Ý nghĩa x0z Lỗi cấu trúc x1z Thông tin trạng thái lệnh. x2z Thông tin trạng thái kết nối client-server. x3z Không được chỉ định. x4z Không được chỉ định. x5z Thông tin liên quan đến dịch vụ (giao thức). Bảng B.3 – Chữ số “y” B.3 Base64 và Quoted-printable Encoding B.3.1 Base64: Phương pháp chuyển mã sử dụng các kí tự a-z, A-z, /, + và = để biểu diễn dữ liệu sau khi encode. 129 Các byte cần encode sẽ được biểu diễn dưới dạng nhị phân (nguyên vẹn 8 bit). Với mỗi 6 bit liên tiếp nhau trong dãy mã nhị phân tương ứng với một giá trị thập phân từ 1-63, giá trị này được ánh xạ vào bảng chuyển đổi bên dưới sang giá trị được encode. Khi số kí tự cần encode là bội của 3 (24 bit) thì kết quả encode không có phần padding (các dấu =). Khi số kí tự cần encode chia 3 dư 2 thì kết quả sẽ có một dấu = ở cuối. Nếu số dư là 1 thì sẽ có 2 dấu = ở cuối kết quả encode. Bảng mã chuyển đổi: Value Char Value Char Value Char Value Char 0 A 16 Q 32 g 48 W 1 B 17 R 33 H 49 X 2 C 18 S 34 I 50 Y 3 D 19 T 35 J 51 Z 4 E 20 U 36 K 52 0 5 F 21 V 37 L 53 1 6 G 22 W 38 M 54 2 7 H 23 X 39 N 55 3 8 I 24 Y 40 O 56 4 9 J 25 Z 41 P 57 5 10 K 26 a 42 Q 58 6 130 11 L 27 b 43 R 59 7 12 M 28 C 44 S 60 8 13 N 29 D 45 T 61 9 14 O 30 E 46 U 62 + 15 P 31 F 47 V 63 / Bảng B.4 – Bảng mã chuyển đổi Ví dụ: Text content M A n ASCII 77 97 110 Bit pattern 0 1 0 0 1 1 0 1 0 1 1 0 0 0 0 1 0 1 1 0 1 1 1 0 Index 19 22 5 46 Base64-encoded T W F u Bảng B.5 – Ví dụ về chuyển đổi mã B.3.2 Quoted-printable: Là phương pháp chuyển mã sử dụng các kí tự in được để chuyển dữ liệu dạng 8-bit qua các đường đi chỉ hỗ trợ 7-bit. Phương pháp này ánh xạ một byte bất kì thành một dãy các kí tự ASCII. Cách chuyển đổi: Bất kì byte nào sẽ được ánh xạ thành 3 kí tự (bắt đầu bằng dấu =, theo sau là 2 kí tự hexa). Những kí tự in được (33-60 và 62-126) không cần encode. Dấu = (mã 61) được encode thành =3D. Dấu TAB và SPACE được encode thành =09 và =20. Dấu xuống dòng được encode thành =0D=0A. 131 Một dòng dữ liệu dạng quoted-pritable chỉ có tối đa 76 kí tự, do đó dấu xuống dòng mềm (soft line break) được sử dụng để cắt bớt kí tự trong trường hợp có nhiều hơn 76 kí tự. Ví dụ: If you believe that truth=3Dbeauty, then surely=20= mathematics is the most beautiful branch of philosophy. Đoạn trên là kết quả sau khi encode chuỗi sau: If you believe that truth=beauty, then surely mathematics is the most beautiful brach of philosophy. B.4 Cách đánh số các thành phần trong MIME Để có thể lấy đúng phần dữ liệu mong muốn khi dùng IMAP, ta cần phải hiểu cách các phần dữ liệu đó được đánh địa chỉ như thế nào trong cấu trúc MIME. Ví dụ dưới đây miêu tả cách xác định địa chỉ các phần trong một message dang multipart. HEADER ([RFC-2822] header of the message) TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED 1 TEXT/PLAIN 2 APPLICATION/OCTET-STREAM 3 MESSAGE/RFC822 3.HEADER ([RFC-2822] header of the message) 3.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED 3.1 TEXT/PLAIN 3.2 APPLICATION/OCTET-STREAM 4 MULTIPART/MIXED 4.1 IMAGE/GIF 4.1.MIME ([MIME-IMB] header for the IMAGE/GIF) 4.2 MESSAGE/RFC822 4.2.HEADER ([RFC-2822] header of the message) 4.2.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED 4.2.1 TEXT/PLAIN 4.2.2 MULTIPART/ALTERNATIVE 4.2.2.1 TEXT/PLAIN 4.2.2.2 TEXT/RICHTEXT Bảng B.6 – Cách đánh số các thành phần trong MIME 132 Trong đó: HEADER là toàn bộ phần header của message, TEXT là toàn bộ nội dung phần thân của message (hoặc một part của message). Mỗi part sẽ được đánh số, các part bên trong một part khác sẽ được đánh số theo chiều sâu. Ví dụ: Part 3 dạng MULTIPART/MIXED, bên trong chứa 2 part TEXT/PLAIN và APPLICATION/OCTET-STREAM sẽ được đánh số lần lượt là 3.1 và 3.2. Biết được cách đánh địa chỉ này ta dễ dàng lấy được nội dung của bất kì phần nào trong message thông qua lệnh FETCH đã đề cập ở trên. 133 Tài liệu tham khảo Tài liệu dạng văn bản: [1] BlackBerry Forum – Blackberry Development Documents – Research In Motion. [2] BlackBerry JDE 4.7 API References – BlackBerry 4.7 SDK. [3] BlackBerry Forum – Writing You Frist Application V5 – Research In Motion. [4] BlackBerry Forum – How And When To Sign V2 – Research In Motion. [5] BlackBerry Forum – Storing Persistent Data V2 – Research In Motion. [6] BlackBerry Developer Journal Team – BlackBerry Developer Journal Volume 2, issue 2 [7] Josh Schiffman – BlackBerry OS Report 2 – Network and security Research Center, Department of computer Science and engineering, pennsylvania State Univercity, University Park PA. [8] Logic mail – Logicmail Development Blog – 2008 - 2009 Các website: [9] www.Blackberry.com [10] www.codeproject.com [11] www.java2s.com [12] www.wikipedia.org [13] www.thinkingblackberry.com [14] [15] [16] ncapsulatedMes-4.htm [17] https://www.logicprobe.org/proj/logicmail/ [18] /developers/

Các file đính kèm theo tài liệu này:

  • pdfluan_van_final_2010_2_0292.pdf
Luận văn liên quan