Symbian messages, asynchronous services, and activity objects

[Message, asynchronous service, and activity object]

MFC is doing well in hiding Windows message examples for senior programmers who are both beginner and understand the message loop and Scheduling Mechanisms driving their applications. In the Symbian operating system, a set of completely different and powerful mechanisms are used to drive applications, which are called activity objects. It is closely integrated with the client-server structure of the Symbian operating system and provides various system services, at the same time, programmers can also establish clean and standard interfaces for any asynchronous services they may need to create for their applications.

In short, cactivescheduler executes a Windows message loop and provides shared multitasking within a given thread. cactive acts as a message processor. In the UI framework of Symbian, this is better than MFC to hide messages: messages received are always scheduled by the Framework to pre-defined methods that can be reloaded by applications, such as offerkeyeventl (processing keyboard input ).

A timer is an instance of simple system services that use the active object framework. Different from calling starttimer in Windows to trigger wm_timer messages, in the Symbian operating system, a ctimer object interacts with the system clock service, rtimer and its runl function are called according to the specified time interval of the API. The programmer inherits from ctimer to an object and reloads the runl method.

Other asynchronous system services, such as camera functions on Nokia 7650, are also provided in a similar way. Ccameramanager defines a request for an activity object to take a photo and receive a notification immediately. The actual asynchronous service is provided by rcameraserv, but typical programmers do not need to deal with any client-server-side or explicit inter-process communication issues.

When using activity objects, it is very important to keep in mind when the activity objects will be executed as scheduled. That is to say, when will the cactivescheduler call the runl method of a cactive object?

· The cactive object must be "active. This is implemented by calling cactive: setactive, which is usually completed in the response of the activity object to a request of the application.

· The status of the cactive object, as shown in the member variable istatus, must not be krequestpending. This value indicates that the object is waiting for the service to complete. The variable istatus is usually set by the service provider as krequestpending when a service request is made. Istatus was subsequently updated by the provider at the end of the service.

· Cactivescheduler receives a signal, which is sent by the asynchronous Service at the end.

When the asynchronous process sends an end signal to the application, but the cactive object is not ready, it will generate a "lost" signal. This may occur in the following situations:

· You forgot to use cactive: setactive to make the activity object "active.
· When sending the operation completion signal, the service provider forgets to set istatus to a non-krequestpending value. This will only happen when you write an incorrect service provider -- a typical application uses a system-defined service.
· The service provider sends more than one termination signal to the same operation.

The third case may occur when the service provider is not carefully designed. For example, the client sends a request to cancel a service that has ended and notified the client. The service provider must ignore this unreasonable request. What if the service provider does not ignore this request but responds to it and gives an additional signal saying it is over? In this case, the attached signal will eventually become a "lost" signal and cause program errors. This is very difficult for error correction, because the "lost" signal is detected by cactivescheduler and does not show the responsibility of cactive objects.

The cactive object must ensure that the termination signal associated with the service is appropriate in various circumstances. In the release program, a cactive: Cancel call should be typical. If cancel is not called and the object is deleted when the request is still suspended, an error occurs. Additionally, each cactive object must execute cactive: docancel to ensure that any service requested by this object is canceled. Otherwise, cactive :: cancel will always wait for the termination signal of the service provider. These two errors are hard to be detected because they are only detected when there are obvious requests.