Cùng tìm hiểu về Symbian (tt)

[S-SW] - Quy ước trong Symbian

Symbian đưa ra một số quy ước trong lập trình trên Symbian. Một số quy ước bạn không nhất thiết phải theo nhưng nhưng một số thì bạn nên tuân thủ để phục vụ cho việc lập trình của bạn thuận lợi, tránh sai sót và dễ nâng cấp sau này.

1. Tên lớp:

Symbian sử dụng các quy ước đặt tên sau để xác định đặc tính cơ bản của một lớp:
• Lớp T: lớp đơn giản (tựa như typedef) thường xây dựng từ các kiểu dữ liệu cơ sở hay kết hợp chúng lại, có thể so sánh lớp T với struct đơn giản bao gồm các dữ liệu public. Nó không có destructor (có thể có constructor nhưng hiếm) và thường được lưu trên stack, có thể lưu trên heap. Kiểu liệt kê (enum) cũng thường khai báo dưới dạng lớp T. Ví dụ: TInt, TBool, TPoint, TDes, TMonthsOfYear ...
• Lớp C: Lớp có constructor và destructor và tất cả đều là dẫn xuất từ CBase. Các đối tượng của chúng được tạo bằng new và luôn được lưu trữ trên heap. Ví dụ: CConsoleBase, CActive,...
• Lớp R: Lớp R (đại diện cho Resource), thường đại diện cho một loại tài nguyên, quản lý một sesion kết nối với một server phục vụ một tài nguyên. Đối tượng lớp R thường có một hàm khởi tạo (Open() hoặc Create() hay Initialize()) và một hàm kết thúc (Close() hay Reset()) để giải phóng tài nguyên. Quên gọi hàm kết thúc khi dùng đối tượng lớp R là một lỗi thường gặp và kết quả là sẽ bị lủng bộ nhớ. Nó có thể được lưu trên heap, nhưng thường là trên stack. Ví dụ: RFile, RTimer, RWindow,...
• Lớp M (Mix-ins): Lớp ảo (abstract) giống như interface trong Java, nó chỉ bao gồm các phương thức ảo rỗng và không có dữ liệu cũng như constructor. Việc kế thừa nhiều lớp trong Symbian là cho phép tuy nhiên phải theo quy tắc là kế thừa chính từ 1 lớp C (bắt buộcphải có và viết đầu tiên) và nhiều lớp M. Ví dụ: MGraphicsDeviceMap, MGameViewCmdHandler,...
Việc phân biệt giữa T, C và R lớp là rất quan trọng, nó ảnh hưởng tới việc giải phóng bộ nhớ khi sử dụng cũng như cách thức xử lý các đối tượng thuộc các lớp này.
Ngoài ra trong Symbian còn có các lớp tĩnh (static) phục vụ cho một số chức năng riêng như lớp User hay lớp Mem. Một ngoại lệ khác là lớp HBufC, chúng ta sẽ nói đến no ssau trong phần desciptor

2 Tên dữ liệu

Tương tự, Symbian cũng dùng chữ cái đầu để phân biệt các loại dữ liệu:
• Hằng liệt kê (Enumerated constant): Bắt đầu với ký tự E, nó đại diện cho một giá trị hằng trong một dãy liệt kê. Nó có thể là một phần của lớp T. Ví dụ: (ETrue, EFalse) của TBool hay EMonday là một thành phần của TDayOfWeek.
• Hằng (constant): Bắt đầu với ký tự K, thường được dùng trong các khai báo #define hay các giá trị hằng do Symbian quy định. Ví dụ: KMaxFileName hay KErrNone.
• Biến thành phần (member variable): Bắt đầu với chữ cái i (instance), được dùng khi sử dụng các biến động là thành viên của một lớp. Đây là quy ước quan trọng, dùng cho việc hủy vùng nhớ trên heap của các đối tượng này trong destructor. Tôi thường chỉ dùng quy ước này nếu biến này sẽ được lưu trên heap, còn trên stack thì không. Ví dụ: iDevice, iX, …
• Tham số (argument): Bắt đầu bằng chữ a (argument), được dùng khi các biến làm tham số. Ví dụ: aDevice, aX, …
• Macro: Không có quy ước đặc biệt. Tất cả đều viết hoa và dùng dấu gạch dưới để phân tách từ. Ví dụ: IMPORT_C, _TEST_INVARIANT, _ASSERT_ALWAYS, v.v…
• Biến cục bộ (automatic): chữ cái đầu nên viết thường. Biến toàn cục (global): nên viết hoa chữ cái đầu nhưng để tránh nhầm lẫn nên bắt đầu tên bằng chữ cái “g”. Tuy nhiên trên Symbian không khuyến khích dùng biến toàn cục.

3 Tên hàm

Tên hàm bắt đầu bằng ký tự hoa. Khác với 2 trường hợp trên, quy ước đặt tên hàm lại dựa trên ký tự cuối cùng:
• Hàm không ngắt giữa chừng (non-leaving function): đó là hàm mà trong quá trình thực thi nó đều diễn ra suông sẻ, chi tiết tôi sẽ nói sau. Ví dụ: Draw() hay Intersects().
• Hàm ngắt giữa chừng (leaving function): là hàm bị ngắt ngang vì một lý do nào đó: lỗi,, thiếu tài nguyên, ... Hàm này kết thúc bằng ký tự L. Ví dụ: DrawL() hay RunL().
• Hàm LC: Kết thúc với cặp ký tự LC. Các hàm này trong lòng nó có khai báo một đối tượng mới, và có đặt đối tượng này lên cleanup stack (ngăn xếp chứa các đối tượng cần xóa khi có ngắt xảy ra, sẽ nói rõ sau) và có khả năng xuất hiện ngắt trong khối xử lý hàm. Bạn lưu ý là sau khi gọi hàm này sẽ phải gọi CleanuppAnd Destroy(), lý do tôi sẽ nói trong phần về cleanup stack, nếu quên gọi nó chắc chắn bạn sẽ bị lỗi 3 mà không hiểu tại sao. Ví dụ: AllocLC(), CreateLC(), OpenLC() hay NewLC(),...
• Các hàm Get và Set: trong trường hợp đơn giản thường là các hàm thành viên của một lớp. Set dùng cho việc xác lập giá trị cho một biến thành viên của lớp. Get được dùng cho các hàm sẽ trả về giá trị trên tham số. Khi hàm có giá trị trả về thì thường không dùng Get.
Ví dụ: SetThing(aData); GetThing(aData); nhưng iData = Thing();

4 Cấu trúc thư mục project

Tuy không bắt buộc nhưng Symbian khuyến khích lập trình viên xây dựng thư mục project ứng dụng thành các thư mục con với chức năng riêng biệt. Thông thường thư mục project có cấu trúc như sau:
• Thư mục project: chứa các file project .mmp, bld.inf, file tài nguyên .rss. Thư mục này cũng sẽ lưu trữ các file thông tin cụ thể cho chương trình dùng với các IDE. Thư mục này thường được đặt tên là: group.
• Thư mục các file khai báo: chứa các file khai báo cho file tài nguyên và các file mã nguồn. Thư mục này thường có tên là: inc.
• Thư mục mã nguồn: chứa các file cài đặt các lớp chương trình. Thư mục này thường có tên là: src.
• Thư mục dữ liệu: chứa dữ liệu cần cho chương trình ứng dụng và có tên là data.
• Thư mục thông tin ứng dụng: chứa file tài nguyên .rss để tạo file .aif và các hình ảnh, tài nguyên phục vụ cho ứng dụng. Tậo hợp các hình này được lưu trữ trong một file .mbm (multi bitmap). Thư mục này có tên là aif.
• Thư mục cài đặt: chứa các file .pkg, các thành phần cài đặt bổ sung cho ứng dụng. Thư mục này thường có tên là: install.
• Thư mục chương trình: lưu trữ file cài đặt .sis. Thường nó được gộp với thư mục install. Thư mục này có tên là release.
Tuy nhiên các project thường chỉ gồm các thư mục: group, inc và src.

5. Trình bày code:
Nếu lập trình trên C và Java thấy 2 phong cách trình bày quen thuộc là:
void Example()
{
.........
.........
}

và
void Example(){
.........
.........
}

thì Symbian đề xuất cách trình bày sau:
void Example()
->{
->.........
->........
->}
Bạn không nhất thiết phải theo cách này. Ban đầu tôi cũng thấy khó chịu nhưng sau một thời gian sử dụng, thấy nó mang lại một phong cách trình bày sáng sủa và dễ đọc hơn.

Cấu trúc ứng dụng Symbian


Ứng dụng đồ họa là loại chương trình chúng ta hay viết nhất và cũng là loại thực thi chủ đạo trên Symbian.

1 Phân loại

Trên Symbian, ứng dụng đồ họa được chia thành ứng dụng hướng file (file-based application) như Word hay Contact, Agenda và ứng dụng khác (non file-based application) như Calculator, các trò chơi.
• Ứng dụng file là ứng dụng phục vụ cho việc lưu trữ các thông tin, tài liệu dưới dạng các file có cấu trúc riêng. Trên Symbian, ứng dụng file lại được chia làm 2 loại khác nhau:
- Ứng dụng file tài liệu độc lập: là các ứng dụng file mà có thể nạp và lưu trữ tài liệu dưới dạng các file độc lập như Word hay Record. Khi một file tài liệu được nạp, toàn bộ dữ liệu file sẽ được lưu và xử lý trong RAM và khi lưu file xuống lại đĩa thì file cũ sẽ bị xóa và được thay thế bằng file mới. Đối với các ứng dụng file dạng này, dữ liệu thật xem như ở trên RAM, các file chỉ lưu lại các phiên bản khác nhau của tài liệu ứng dụng. Các file tài liệu này có biểu tượng của ứng dụng và chúng có chứa UID của ứng dụng. Đây là cơ sở để xác định tài liệu thuộc ứng dụng nào, chúng không dựa trên phần mở rộng của tên như trên các hệ điều hành khác. Một số file tài liệu dạng này có thể cho phép nhúng một tài liệu của một ứng dụng khác, biến tài liệu tồn tại độc lập này thành một phần tài liệu của nó. Ví dụ: tài liệu hình ảnh có thể nhúng vào một tài liệu danh bạ Contact.
- Ứng dụng file cơ sở dữ liệu: là các ứng dụng file nhưng tài liệu của nó là các file cơ sở dữ liệu như trong ứng dụng Agenda. Tại mỗi thời điểm sử dụng, chúng ta chỉ nạp và lưu các mẫu tin (record) có cấu trúc trên cơ sở dữ liệu qua việc sử dụng các đầu vào tương ứng nhờ các chỉ mục. Đối với các ứng dụng file này, dữ liệu thật lại nằm trên đĩa trong các file cơ sở dữ liệu, còn trên RAM chỉ là các đoạn dữ liệu sao chép từ file cơ sở dữ liệu.

2 Cấu trúc ứng dụng đồ họa

Cấu trúc ứng dụng đồ họa Symbian cũng gồm có 4 lớp:
• Lớp ứng dụng (application): lớp ứng dụng định nghĩa các thuộc tính ứng dụng, và tạo ra các tài liệu mới cho ứng dụng. Trong trường hợp đơn giản nhất, nó chỉ bao gồm định danh ứng dụng UID.
• Lớp tài liệu (document): đại diện cho mô hình dữ liệu của ứng dụng. Nếu ứng dụng là ứng dụng file, các ứng dụng phục vụ chính cho việc tạo các file tài liệu, lớp này sẽ đảm nhận việc nạp và lưu trữ các file tài liệu cho ứng dụng. Với các ứng dụng không phải là ứng dụng file, lớp tài liệu vẫn tồn tại với mục đích để nạp phần giao diện ứng dụng.
• Lớp giao diện ứng dụng (AppUI – application user interface): Nhiệm vụ chính của lớp này là cung cấp sự tương tác giữa ứng dụng với người dùng qua các đối tượng điều khiển như toolbar hay menu qua hàm HandleCommandL() đồng thời tạo các view, phần giao tiếp chính giữa ứng dụng và người dùng.
• Lớp hiển thị (AppView): đây thực chất là một control, mục đích chính của nó là thể hiện các dữ liệu của ứng dụng lên màn hình và cho phép người dùng tương tác với nó. Nó cung cấp các chức năng quản lý sự kiện nhập như bàn phím (OfferKeyEventL()) và con trỏ (HandlePointerEventL()).

Đây là 4 lớp rất cơ bản mà ứng dụng nào cũng phải có.
Tuy nhiên nếu chỉ với 4 lớp trên thì chương trình ứng dụng không thể thực thi được. Như đã biết thì ứng dụng đồ họa là một loại polymorphic DLL, nó được thực thi nhờ chương trình apprrun.exe. Do đó trong mỗi ứng dụng đồ họa Symbian phải có thêm các hàm đảm nhận việc khởi tạo hoạt động cho ứng dụng đồ họa. Khi ứng dụng được chọn thực thi, chương trình apprun.exe sẽ hoạt động với tên ứng dụng và tên file ứng dụng làm tham số. Chương trình apprun sẽ sử dụng kiến trúc ứng dụng APPARC để nạp ứng dụng qua việc kiểm tra UID2 là KUiApp (0x100039ce) và tạo đối tượng ứng dụng đồ họa qua hàm NewApplication(). Các hàm này bao gồm hàm NewApplication() và hàm E32Dll(TdllReason) (một hàm chỉ cài đặt, không sử dụng). Từ khóa EXPORT_C để báo hàm NewApplication là đầu vào của một DLL.
EXPORT_C CApaApplication* NewApplication()
{
return new CExampleApplication;
}
GLDEF_C TInt E32Dll(TDllReason)
{
return KErrNone;
}

Nhân đây tôi cũng xin nói về cấu trúc thư viện dùng chung (.dll). Như chúng ta đã biết, chúng có nhiều đầu vào khác nhau nhằm mục đích cung cấp nhiều hàm cho các ứng dụng đồ họa hay các dll khác sử dụng. Do đó cấu trúc của nó như sau: trong file header .h, những hàm bạn dự định cung cấp cho các chương trình khác dùng thì khai báo bắt đầu bằng từ khóa IMPORT, ngược lại trong file cài đặt .cpp thì bạn sẽ khai báo từ khóa EXPORT ở đầu các hàm này. Sau khi biên dịch, file .lib sẽ được các chương trình nào muốn xài thêm vào trong danh sách thư viện của nó còn file .dll được các ứng dụng cài đặt kèm để thực thi các hàm cần thiết.

Mô hình thiết kế MVC


Các ứng dụng đồ họa thường được phát triển theo nguyên tắc sau: những gì thể hiện trên màn hình giao tiếp với người dùng sẽ do các hàm vẽ (draw) đảm nhận. Chúng chỉ có nhiệm vụ đơn giản là vẽ lại dữ liệu của ứng dụng lên màn hình, chúng không thay đổi dữ liệu. Nếu bạn muốn thay đổi gì đó thì bạn phải sử dụng hàm khác và rồi gọi lại hàm vẽ này để vẽ lại dữ liệu đã thay đổi.
Nguyên tắc này thật ra là một mô hình thiết kế (design pattern) rất phổ biến: mô hình model-view-controller, thường viết tắt là mô hình MVC.
- Model: dữ liệu của ứng dụng, nó đảm nhận việc lưu trữ các thông tin dữ liệu của ứng dụng.
- View: nơi thể hiện dữ liệu của ứng dụng, người dùng chỉ có thể biết ứng dụng thông qua nó.
- Controller: phần này có nhiệm vụ thao tác trên dữ liệu ứng dụng: cập nhật model sau đó yêu cầu view thể hiện lại phần cập nhật.
Tuy nhiên không phải lúc nào cũng phải đầy đủ cả phần này. Tùy theo tính chất của ứng dụng mà có thể ranh giới giữa model và view không rõ ràng hay có thể thiếu đi phần controller.
Có lẽ bây giờ chắc bạn nghĩ vậy thì mô hình này có liên quan gì đến lập trình C++ trên Symbian?
Mô hình MVC và Symbian có mối quan hệ rất mật thiết. Như tôi nói trong phần cuối bài trước, MVC là mô hình thiết kế chủ đạo trong Symbian. Nếu để ý kỹ bạn sẽ thấy lớp document là hiện thân của model, lớp AppView chính là view còn AppUi sẽ đóng vai trò là controller trong mô hình MVC. Với những ứng dụng phức tạp thì sẽ có nhiều lớp đảm nhận một thành phần trong MVC.
Không những vậy, hầu hết các control trong Symbian đều được thiết kế theo mô hình MVC. Nắm bắt được điều này, bạn sẽ dễ dàng thao tác với các control trong Symbian. Tôi nhớ là có khá nhiều người mới lập trình Symbian khi làm quen với listbox đều đặt câu hỏi: làm sao để lấy dữ liệu một item trong listbox đây bởi trong lớp CEikListbox không thể tìm thấy hàm nào đảm nhận việc này. Đó là vì listbox trong Symbian cũng được thiết kế theo mô hình MVC nên nếu muốn lấy dữ liệu, bạn phải đến lớp MListBoxModel thông qua hàm Model() trong lớp CEikListbox.