hSenid's blog on Outsourcing

A composite view is really a view containing widgets.

We have to communicate with the container to say how many widgets we contain. So consider the simpler case of a single widget, we have to define CountComponentControl as follows:

TInt CDemoContainer::CountComponentControls() const

{

return 1; // return nbr of controls inside this container

}

So we know how many widget we have, but we have also the need to get each widget in turn. This is done by ComponentControl(TInt aIndex) that will return in turn each widget access by an index. Here is the code for the simplest case:

CCoeControl* CDemoContainer::ComponentControl(TInt aIndex) const {

switch ( aIndex ) {

case 0: return iLabel;

default: return NULL;

}

}

You can easily imagine what will happen: for each index the method will be called to obtain the corresponding widget. The sizes (the really missing piece) are in the widget itself.

You assign the sizes at the construction time or (better) in the SizeChanged method, as follows:

void CDemoContainer::SizeChanged()

{

iLabel->SetRect(Rect());

}

Note that this method will be called at least once, so there is always the opportunity to set the size of the widgets. Each widget must know where it is going to be drawn.

Literals provide a simple method of defining strings in a program. They can be defined and used as follows:

_LIT(KMyName, “Helen”);

TBuf<KMaxItemLength> myName;

myName.Append(KMaxItemLength);

Literals are easily changed if they are situated at the top of a .cpp file, just like macro definitions. The predecessor to _LIT was _L; you may see it being used as:

myName.Append(_L(“Helen”));

_L can still be used in test programs (non-release versions) where clarity is more important than efficiency but it has now been deprecated as _LIT is more efficient. The string supplied to _LIT is stored once per unit of compilation (.cpp file) unlike the string supplied to _L, which is inserted in the code each time it is used. Therefore _LIT consumes less memory if the string is used more than once and its use is encouraged by Symbian in creating memory-efficient applications.

The S60 App Wizard (supplied with the S60 SDK) is the recommended way to start a new application project. The wizard creates an empty application with a menu, which is ready for you to add features and run.

The wizard removes the repetitive task of creating concrete instances of the foundation base classes of the Symbian OS application framework. Figure 4.1 demonstrates the structure of a Symbian OS application.

The structure contains the following classes:

• The application class is responsible for setting up and executing the application. It supplies a globally unique 32-bit identifier (UID) which is always associated with the application (both in the build project and at run time). Changing the UID during the lifetime of the project is not advisable since it is used in a number of places through the application source files.

• The document class is created by the application class. It usually has strong ownership of application data and is responsible for persisting and internalizing the data. This class also instantiates the application user interface (AppUi) class. It is feasible for the document class not to implement anything other than creating the application’s instance of the AppUi.

• The application user interface is used for event handling. The AppUi acts as a global event, and command, handler. It processes key presses and menu selections and can pass these events on to the views and container classes that make up an application. The AppUi is a controller that has no visible presence on the screen.

• Views and container classes provide the screens of the application. They are handled by the view architecture. A view is essentially   a container class associated with an ID. A particular view can be activated from within the application or from another application by supplying the UID of the application and the ID of the view. For very simple applications, a single container class is used, rather than a view.

Figure above shows the minimum number of classes that need to be created to run an application. More classes may be added as the application evolves and other screens or views are needed. As well as the source files, a fully fledged application includes .hrh files, .rss application resource files  and files for building the application installer package (the SIS file).