Symbian Programming Summary-Basic article-active object Positive solution (1)-Understanding active Object

The use of active objects in Symbian OS is undoubtedly the most basic, frequent, and important. What is an active object?

When you learn a new thing, you will always compare this new thing with the things you perceive, so that you can achieve the goal of fast learning. When I started learning Symbian, I looked at a lot of Symbian books, many of the Symbian tutorials on the internet, which linked the activities to multithreading, and I always imagined the object as a thread. However, after more in-depth contact, I found that it was not as I had imagined.

Now, I hereby assure you: the Activity object and multithreading have no relation! Do not take the idea of multithreading at ordinary times to understand the activities of the object!

The active object can be understood in the following steps:

The Symbian OS offers a number of asynchronous functions, most of which are based on the server-client architecture. This is very different from the functions in the Win32 API. Such as:

In Win32, the CSOCKET::RECEIVE (recv instead of WSARecv) is the synchronization function, and the thread blocks at the receive until the socket receives a network stream to return.

Symbian OS also has a similar function, rsocket::receive, but this function is an asynchronous function, and threads do not block at the Receive and continue to execute.

How can I tell which functions in Symbian are synchronized and which ones are asynchronous? Simple: See if the function contains a formal parameter of type trequeststatus, and if so, the function is an asynchronous function. A function prototype such as Rsocket::receive is:IMPORT_C void Recv(TDes8 &aDesc, TUint flags, TRequestStatus &aStatus);

The parameter astatus is a state bit and the initial value is erequestpending (value 1), which means that the action requested by the user is completed. For example, we call an asynchronous function Rsocket::receive request to receive a network stream, and the receive function returns directly. When the process of receiving the network stream is complete, the astatus becomes eactive, so we can know whether the "receive" is complete as long as we monitor whether Astatus is not erequestpending.

We can use the following pseudocode to complete the operation described above:

TRequestStatus status(KRequestPending);
RSocket::Receive(aDesc, flags, status);
for (;;)
{
if (status != KRequestPending) break;
}
// 此处我们已经通过RSocket::Receive完成了类似CSocket::Receive的同步的工作

Symbian OS does not recommend that we use the above method, it suggests that we use asynchronous methods, rather than using our approach to force synchronization, the activity object is to help us do this thing. Activity object System to help us monitor the value of Astatus, as long as Astatus!= erequestpending, he will notify us by the way of events, tell us "socket has been received, you can go to fetch data!" "The object of activity is to do it."

To sum up: there is an "activity scheduler" in the system, we create an "active object Ao1", bind the object to an asynchronous function in a system, and then register the active object in the Activity scheduler, and the activity Scheduler waits for the completion message returned by the asynchronous function. When the completion message is received, the scheduler iterates through the registered active object and, if found status!= krequestpending, finds the active object ao1 for that status, invokes the Runl method, and tells us in the event that the asynchronous function has been completed.

I'll explain how to use the active object in the next section.