hSenid's blog on Outsourcing

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.

One of the defining features of the Java environment is its built-in support for threads. Threads let an application perform multiple activities simultaneously. When used properly, threads let the application’s user interface remain responsive while it performs lengthy operations like network communication or very complicated computations. While user interface responsiveness is important no matter what the platform, it’s even more so on the handheld and consumer-oriented devices that the J2ME platform targets. A basic understanding of how to use threads is a key to write effective J2ME applications, whether you’re using the more limited facilities of the Connected Limited Device Configuration (CLDC) or the fuller features of the Connected Device Configuration (CDC). This article explains the concepts behind threads and how you can use them in your own applications.

What is a Thread?

The Java Tutorial defines a thread as “a single sequential flow of control within a program.” Threads are the fundamental units of program execution. Every running application has at least one thread. An application consisting of two or more threads is known as a multithreaded application.

Each thread has a context associated with it. The context holds information about the thread, such as the address of the currently executing instruction and storage for local variables. The context is updated as the thread executes. The context also stores the thread’s state. A thread can be in any of the following states:

• A running thread is executing code.
• A ready thread is ready to execute code.
• A suspended thread is waiting on an external event. For example, it may be waiting for data to arrive from another device. After the event occurs, the thread transitions back to the ready state.
• A terminated thread has finished executing code.

A thread that is running, ready, or suspended is a live thread. A terminated thread is also known as a dead thread.

Although an application may have many threads, the underlying device has a small, fixed number of processors (often just one or two) available for code execution. Threads share these processors by taking turns being in the running state. This arrangement is called thread scheduling.

Thread scheduling is a complicated affair over which the application has little control. The system (either the underlying operating system or the Java virtual machine, depending on how the threads are implemented) gives each ready thread a chance to run for a short time (the suspended threads are ignored), switching rapidly from one thread to another. This context switching can occur at any time. The only real influence the application has over thread scheduling is via the thread’s priority level: higher-priority threads execute more often than those with lower priority.

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).