Summary
If you have C++ background and some experience with Model-View-Controller architecture, the structure of a basic Symbian GUI app will be surprisingly familiar.

What I always want to know when beginning to investigate a new technology is which parts I don’t already know. Seriously. I’d love to be able to do a brain/resume dump, send it off, and get back a list saying "This will look familiar right away, and that thing over there will look familiar after you realize it’s something you know by a different name. But here’s a part that is going to seem completely bizarre for a while, so humble yourself and approach it with an open mind and a really large amount of colorful Post-It notes." So. Friend to friend, colleague to colleague, one explorer to another, here's my personal synopsis of the Sure/Oh, It’s One of Those/How’s That Again? list for new Symbian Programmers. In the next half dozen posts, we'll explore basic application architecture which, for many, will definitely fall into the "Sure" category; Symbian specific data types, which are relatively digestible if you are a C++ fan; and Leaves and Leave Safety, which are the heart and soul of the Symbian programming model, but for most of us will induce a few Maalox Moments.

Touring the Simplest Case Symbian GUI App

For starters, if you aren’t in top form with C++ this week, the first and last word on pretty much everything can be found in Bruce Eckel’s Thinking in C++ Books. Also, if it’s been a while since you had cause to contemplate the MVC Model, here is a quick refresher. Fortified with these prerequisites, you’ll find the basic structure of a simplest case, graphical user interface Symbian app readily recognizable. "Simplest case" means one where the user interacts with a single app UI screen.

Implementing four classes produces the basic, single view application.

• Application class- defines the application’s properties , which at minimum must include a unique ID (UID ) for the app. The application class also manufactures a new, blank document.

• Document class- This is the application’s data model, and if there is file I/O, it is orchestrated from here. The document creates the application’s UI.

• Application User Interface class- This class creates an application view and processes commands that are generated by events. Events include things like user menu selections. The user interface class has no visual representation.

• Application View class-This class is the tangible interface with which application users interact. It processes input to its controls, handles drawing, and displays application data.

Walking the App Launch

Last post we generated a simplest case GUI HelloWorld app using the Carbide.c++ build tools. We’ll use this code and the debugger to explore Symbian app structure.

Expand the source node in the Carbide.c++ project pane and you’ll notice that there are five files. Four of them correspond to the elements in the list above and the fifth one takes the app name, HelloWorld.cpp.

Walk through application launch by setting breakpoints on the opening brace of the HelloWorld functions shown below. (Use the Carbide.c++ source pane to set breakpoints--double click in the grey bar at the extreme left of the line where you want to break. ):

In HelloWorld.cpp:

LOCAL_C CApaApplication* NewApplication()

GLDEF_C TInt E32Main()

In HelloWorldApplication.cpp:

CApaDocument* CHelloWorldApplication::CreateDocumentL()

In HelloWorldDocument.cpp:

CHelloWorldDocument* CHelloWorldDocument::NewL( CEikApplication& aApp )

CHelloWorldDocument* CHelloWorldDocument::NewLC( CEikApplication& aApp )

CEikAppUi* CHelloWorldDocument::CreateAppUiL()

In HelloWorldAppUI.cpp, set a breakpoint on creation of the view object:

iAppView = CHelloWorldAppView::NewL( ClientRect() );

Launch with the project pane Debug As... command. A couple of trips through assimilates the timing of object creation and the relationships between elements of the HelloWorld application architecture. What will certainly stand out if you step the functions or examine the code around the breakpoints is that a lot of function names end with a terminal "L"”. The Ls are a Symbian naming convention signifying that the function to which they apply may leave.

Looking Ahead:

Leaves and leave safety are subjects unto themselves, and in the next post we’ll look more closely at them.

Talk Back!

Have an opinion? Readers have already posted 4 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Nancy Nicolaisen adds a new entry to her weblog, subscribe to her RSS feed.

Digg | del.icio.us | Reddit

About the Blogger