1 File thực thi
Trên Symbian hỗ trợ 2 hệ thống chương trình ứng với các kiểu file khác nhau.
• Chương trình .exe: được lưu trữ trong các file thực thi có phần mở rộng là exe. Đây là chương trình với một đầu vào chính từ hàm E32Main(). Khi hệ thống nạp một chương trình .exe mới, đầu tiên nó tạo một tiến trình mới. Trong tiểu trình chính của tiến trình này, điểm vào sẽ được gọi để thực thi chương trình đó. Thông thường đây là các server hay các ứng dụng console.
• Thư viện liên kết động (Dynamic link library-DLL): một thư viện chứa các mã chương trình với nhiều điểm đầu vào. Hệ thống sẽ nạp một DLL vào trong ngữ cảnh hoạt động của tiểu trình. Có 2 loại DLL quan trọng:
- Shared DLL: cung cấp một nhóm API nhất định cho một hay nhiều chương trình sử dụng. Hầu hết các thư viện này nằm trong các file có phần mở rộng là .dll. Một chương trình thực thi sẽ được nối với thư viện dùng chung mà nó yêu cầu và khi hệ thống nạp chương trình thực thi, thư viện dùng chung cần cho chương trình này sẽ được nạp tự động.
- Polymorphic DLL: cung cấp một nhóm hàm API được lưu trữ trong các file có phần mở rộng khác nhau phục vụ cho các chức năng riêng như điều khiển máy in (.prn), giao thức socket (.prt), hay đó là một ứng dụng đồ họa GUI (.app). Trong hệ điều hành Symbian, polymorphic DLL thường chỉ có một điểm vào, nó khai báo và khởi tạo một lớp dẫn xuất từ các lớp cơ sở trong DLL này. Thư viện DLL loại này được nạp bởi chương trình sử dụng nó.
Hệ điều hành Symbian quản lý chương trình .exe và DLL khác nhau: chương trình .exe là không thể chia sẻ trong khi DLL thì hoàn toàn có thể.
2 Nạp chương trình khi thực thi
Các file thực thi chứa 3 loại dữ liệu nhị phân: mã chỉ thị, dữ liệu chỉ đọc (hằng) và dữ liệu động (thay đổi được).
• Chương trình .exe: Khi chương trình .exe được nạp vào RAM từ file .exe được lưu trên RAM (đĩa C) hoặc từ thẻ nhớ (đĩa D), thì nó được cấp một vùng nhớ riêng cho mã, dữ liệu chỉ đọc, dữ liệu động. Nếu một phiên bản thứ 2 của chương trình được nạp vào RAM thì một vùng nhớ mới sẽ được cấp cho nó. Với file chương trình .exe chứa trong ROM (ổ đĩa Z) thì chỉ có dữ liệu động được nạp vào RAM, mã chỉ thị và dữ liệu chỉ đọc được đọc trực tiếp từ ROM.
• Thư viện DLL: Khi một thư viện DLL lần đầu tiên được nạp vào RAM, nó được cấp một vùng nhớ riêng, khi được yêu cầu sử dụng lần thứ hai, nó không nạp tiếp DLL này vào RAM mà đơn giản chỉ gắn địa chỉ nó trên RAM cho tiểu trình yêu cầu. Hệ điều hành Symbian kiểm tra số lượng tiểu trình tham khảo DLL này và giải phóng nó khi không còn tiểu trình nào sử dụng nó nữa. (Đó là lý do mà các ứng dụng đồ họa Symbian, là một loại polymorphic DLL, không hề có chức năng exit, nhất là các ứng dụng hệ thống vì việc thoát nó sẽ do hệ thống đảm trách khi thiếu RAM cho các ứng dụng khác) Với các DLL chứa trên ROM thì nó không cần nạp vào RAM nữa mà được sử dụng trực tiếp trên ROM.
Việc các ứng dụng lưu trữ trên ROM không cần nạp vào RAM khi thực thi là đặc điểm của Symbian để phù hợp với tài nguyên bộ nhớ giới hạn của điện thoại. Ngoài ra để tối ưu hóa kích thước chương trình, hệ điều hành Symbian sử dụng điểm vào của DLL là một số thứ tự, trên các hệ điều hành khác có thể dùng số thứ tự hay tên. Do đó khi nâng cấp DLL thì số thứ tự phải giống như phiên bản trước.
3 Thực thi ứng dụng và server
• Các server được lưu trữ trong các file .exe, như ewsrv.exe là window server, hay efsrv.exe là file server. Để giảm chi phí chuyển đổi ngữ cảnh các server có cùng nhóm chức năng được dùng chung một tiến trình. Một server chính sẽ tạo tiến trình và các server khác sẽ thực thi tiểu trình của nó với tiểu trình của server chính.
• Ứng dụng console (không có giao diện đồ họa) được thực thi qua file chương trình .exe. Các ứng dụng dạng này phải tạo một console riêng để tương tác với người dùng.
• Các ứng dụng có giao diện đồ họa (GUI) là những thư viện polymorphic DLL với phần mở rộng là .app. Điểm vào của ứng dụng này là NewApplication() tạo và trả về một đối tượng dẫn xuất từ lớp CEikApplication (Series 80/9200Series/Series90) hay các lớp dẫn xuất từ CEikApplication phù hợp theo từng dòng điện thoại Symbian như CQikApplication (UIQ), CAknApplication (Series 60). Tiến trình ứng dụng được tạo bởi một chương trình nhỏ .exe, Apprun.exe, và tên của file chương trình ứng dụng .app được chuyển làm tham số cho Apprun.exe.
Định danh file
Symbian không quản lý các file dựa trên tên và phân biệt loại file dựa trên phần mở rộng như các hệ điều hành khác vẫn làm mà quản lý dựa trên một tổ hợp 3 số 32bit. Mỗi một số như vậy được gọi là định danh file (Unique Identifier-UID). UID được dùng để phân biệt và xác nhận, chọn lựa đúng các loại đối tượng khác nhau tại thời điểm nạp và thực thi, như phân biệt ứng dụng console, DLL, server, v.v...UID cũng là thành phần cơ bản để liên kết ứng dụng với tài liệu, ví dụ, tài liệu ứng với một ứng dụng sẽ yêu cầu hệ thống nạp ứng dụng khi tài liệu đó được mở.
3 UID này (UID1, UID2 và UID3) có giá trị hằng ứng với các tên gọi do Symbian quy định, nhưng cũng có thể sử dụng số hệ 10 hay hệ 16.
- UID1: định danh cấp hệ thống, chương trình thực thi .exe hay DLL được phân biệt nhờ UID1: với các giá trị tương ứng KExecutableImageUid=0x1000007A và KDynamicLibraryUid=0x10000079.
- UID2: định danh cấp giao tiếp, phân biệt các đối tượng cùng UID1, ví dụ UID2 được dùng để phân biệt thư viện dùng chung .dll và thư viện polymorphic (như .app, .mdl, .fep hay .ctl) qua các giá trị: KSharedLibraryUid=0x1000008d cho thư viện dùng chung và KUidApp=0x100039CE cho một ứng dụng đồ họa .app, recognizer(auto start)=0x10003A19, front-end procesors=0x10005E32, hay control panel=0x10003A34.
- UID3: định danh cấp chương trình thực thi, phân biệt các đối tượng có cùng UID2, chẳng hạn các ứng dụng đồ họa khác nhau sẽ có UID3 khác nhau. Do đó, có một tổ chức quản lý UID3 này cho toàn môi trường Symbian. Để có nó, lập trình viên phải gởi mail về uid@symbiandevnet.com để xin một số UID3 duy nhất trên môi trường Symbian.
Tổ hợp 3 số UID sẽ là duy nhất trên toàn môi trường Symbian. Nếu bạn sử dụng UID3 tùy tiện thì chương trình của bạn vẫn có thể chạy được nhưng nếu trên 1 máy nào đó có sẵn chương trình khác cùng loại và có cùng UID3 (nghĩa là trùng cả 3 số) thì chương trình của bạn sẽ không chạy vì chương trình cài trước đó sẽ được ưu tiên.
Một đối tượng hay một file trong Symbian có thể có một, hai, ba hay không cần UID.
- Để sử dụng thuận tiện trong việc tương tác và chuyển đổi dữ liệu với các hệ thống khác, hệ điều hành cho phép không cần sử dụng UID. Khi không có UID, Symbian sẽ phân biệt dựa vào quy ước đặt tên.
- Ứng dụng thực thi .exe thường chỉ có UID1 với giá trị KExecutableImageUid.
- Ứng dụng DLL: các ứng dụng này có UID1 là KDynamicLibraryUid. Với các thư viện dùng chung .dll, UID2 sẽ là KSharedLibraryUid. Với các thư viện polymorphic , UID2 sẽ có nhiều giá trị khác nhau tùy từng loại. UID3 thì các DLL hầu như không cần, chỉ có các loại thư viện polymorphic là cần đến.
- Đối với các loại tài liệu thì UID1 là KDirectFileStoreLayoutUid hoặc KPermanentFileStoreLayoutUid ứng với tài liệu độc lập và tài liệu cơ sở dữ liệu. UID2 và UID3 phụ thuộc ứng dụng mà tài liệu phục vụ.
Vì UID là giá trị được sử dụng để phân biệt nên cần sự chính xác. Đối với UID3 dùng trong ứng dụng đồ họa, trong quá trình phát triển, có thể sử dụng một giá trị bất kỳ trong khoảng 0x01000000 và 0x0fffffff. Nhưng khi cài ứng dụng vào điện thoại thì nhất định đó phải là con số được cấp chính xác và duy nhất.
Project file
Thông thường các project được xây dựng trên các IDE hỗ trợ nhưng trên Symbian thì khác. Vì có nhiều loại điện thoại, nhiều nền hệ thống và nhiều bộ công cụ phát triển khác nhau nên hệ điều hành Symbian đã cho phép project được đặc tả trong một định dạng độc lập. Sau đó, với các công cụ đi kèm trong các bộ công cụ phát triển hay trên các IDE hỗ trợ, các file project này được định dạng lại thành các file project phù hợp với IDE cho dòng điện thoại cụ thể và bộ SDK cho điện thoại đó.
1 File định nghĩa project (.mmp)
File này mô tả các thông tin của project. Đây là một file project độc lập, nó sẽ được chuyển thành file phù hợp môi trường phát triển cụ thể với các công cụ makmake hay lệnh abld.bat. Nó định nghĩa các file tài nguyên và file thông tin ứng dụng cần cho quá trình biên dịch. Cấu trúc file .mmp: gồm các dòng khai báo với các loại câu khai báo khác nhau. Thông thường chỉ một số ít khai báo được dùng. Sau đây là cú pháp các khai báo thông dụng qua ví dụ project HelloWorld với file HelloWorld.mmp:
• Aif: aif target-file source-path resource [color-depth] source-bitmap-list
Với:
+ target-file: tên file đích, thường viết luôn phần đuôi và nằm trong thư mục ứng dụng.
+ source-path: đường dẫn đến nơi chứa file tài nguyên mà aif cần
+ resource: tên các file tài nguyên mà aif cần với tên đầy đủ.
+ color-depth: đặc tả cho tất cả các file bitmap và ở dạng [c][digit] với c là color bitmap và "digit" thể hiện độ sâu.
aif helloworld.aif \helloworld\aif\ helloaif.rss c8 hello.bmp hellom.bmp
• Target: target filename.ext.
target HelloWorld.app
• TargetType: targettype target-type
Với target-type được hỗ trợ bao gồm: ani, app, ctl, dll, ecomiic, epocexe, exe, exedll, fsy, kdll, kext, klib, ldd, lib, mda, mdl, notifier, opx, pdd, pdl rdl, var, wlog.
targettype app
• UID: uid uid2 [uid3]
Mỗi ứng dụng thực thi có 3 loại UID, UID thứ nhất là targettype ở trên. Loại thứ hai và thứ ba là tùy chọn. UID được viết dưới dạng số hệ 10 hoặc hệ 16.
uid 0x100039CE 0x10004299
• TargetPath: targetpath target-path
targetpath \system\apps\HelloWorld
• SourcePath: sourcepath directory
Có thể có nhiều sourcepath nhưng đối với file mã và tài nguyên công cụ biên dịch chỉ quan tâm đến trong khai bao sourcepath **ối cùng.
sourcepath ..\group
• Source: source source-file-list
source HelloWorld_Main.cpp
• UserInclude: userinclude directory-list
userinclude ..\inc
• SystemInclude: systeminclude directory-list
systeminclude \epoc32\include
• Resource: resource resource-file-list (khai báo tên nên đầy đủ phần mở rộng)
resource HelloWorld.rss
• Library: library filename-list
library euser.lib apparc.lib cone.lib eikcore.lib
File HelloWorld.mmp hoàn chỉnh:
TARGET HelloWorld.app
TARGETTYPE app
UID 0x100039CE 0x10004299
TARGETPATH \system\apps\HelloWorld
SOURCEPATH .
SOURCE HelloWorld_Main.cpp
SOURCE HelloWorld_Application.cpp
SOURCE HelloWorld_Document.cpp
SOURCE HelloWorld_AppUi.cpp
SOURCE HelloWorld_AppView.cpp
USERINCLUDE .
SYSTEMINCLUDE \epoc32\include
RESOURCE HelloWorld.rss
LIBRARY euser.lib apparc.lib cone.lib eikcore.lib
AIF helloworld.aif \helloworld\aif\ helloaif.rss c8 hello.bmp hellom.bmp
2 File mô tả thành phần bld.inf
File này luôn luôn có tên là bld.inf. Nó liệt kê danh sách các file project (thường chỉ 1), file xuất, các nền hệ thống và các file xuất với phần kiểm tra. Nó được công cụ bldmake thực thi để tạo ra file bó abld.bat và các file thực thi khác. Thông thường chỉ có khai báo prj_mmpfiles cho các file project được sử dụng.
Ví dụ: Với project HelloWorld trên, file bld.inf có cấu trúc như sau:
// Project files
prj_mmpfiles
HelloWorld.mmp
Chú ý: - Mỗi câu khai báo xuất hiện trên một hàng riêng
- Sử dụng cách ghi chú của C++ cho phần ghi chú(// hoặc /* */)
- Các file nên khai báo đầy đủ phần mở rộng.
- Dấu \ được sử dụng để xác định sự liên tục dòng (dòng dưới cũng thuộc câu lệnh với dòng trên, do dài được cắt xuống), do đó khi khai báo đường dẫn, dấu \ sau cùng phải bỏ đi. Ví dụ nên viết SYSTEMINCLUDE \epoc32\include chứ không phải là SYSTEMINCLUDE \epoc32\include\.
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 Cleanup:opAnd 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.
Tiếp theo tôi sẽ giới thiệu mô hình thiết kế được lựa chọn là mô hình thiết kế chủ đạo trong Symbian: mô hình MVC (Model View Control)
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.
To bggroup: Trong bộ cài SDK UIQ 2.1 có một phần rất quan trọng là Perl mà bạn đã quên chọn lúc cài đặt. Perl được dùng để chạy các tool cho Symbian như biên dịch, tạo sis hay các tool tiện ích khác. Nếu thiếu Perl bạn sẽ không làm được gì cả. Nên chọn phần perl trong bộ SDK thay vì lên trang perl mà nickyboy chỉ bởi lẽ có thể phiên bản perl bạn down về không phù hợp. Một điểm lưu ý là SDK Series60 v2.0 thiếu phần cài đặt perl.
Reflink: http://my.opera.com/nhadautu/blog/2008/01/06/chuong-trinh-hoat-dong-tren-symbian