|
|
ActiveObjects
The Active Object concept is a specificity of the Symbian Operating System that allows you to handle several asynchronous requests "at the same time" and in the same thread. It can be also defined as a kind of cooperative scheduling framework. Of course, the OS does support the multithreading. But most applications spend most of their time waiting for events (user input, network events,...), it is really important for the OS to present an optimized ans simple way to handle asynchronicity.
Overview
Here is an overview of the entities involved in an active object :
The thread box represents the unit of execution. It can also be seen as your application (whether a graphical app or a background exe).
The Active Scheduler is a kind of manager for the Active Objects you create.
The Active Objects is what you are reading this article for. You can notice that several AOs can coexist in the same thread and will depend of the same Active Scheduler.
The servers are remote service provider. Most of the time you will communicate with them through a specific DLL API. They are most likely running in another thread/process.
Creation of the Active Object
You create an active object by deriving a class from CActive. Your derived class must fulfill a few requirements, the mos obvious one being to implement two primitives:
RunL()
DoCancel() :
Here is a sample class definition that encapsulates a RTimer data member:
{
public:
static CMyActiveObject* NewL();
static CMyActiveObject* NewLC();
~CMyActiveObject();
void StartL(TTimeIntervalMicroseconds32 aDelay);
protected:
CMyActiveObject();
void ConstructL();
private:
void RunL();
void DoCancel();
...
private:
RTimer iTimer;
}
There is not much to say on the NewL() and NewLC() primitives as they are defined like for any other C-class.
The C++ constructor shall pass the Active Object priority to the base CActive class:
: CActive(CActive::EPriorityStandard)
{
}
You will be able to change this priority later on by a call to the CActive::SetPriority() primitive but it is generally sufficient to leave it to the standard value.
The 2nd pase constructor ConstructL() shall also be used as for other C-classes. A common practice however is to register your CActive-derived object to the Active Scheduler :
{
// Do your leaving initialisation
...
// Register the object to the Active Scheduler
CActiveScheduler::Add(this);
}
... To be continued....
> ActiveObjects
> ActiveObjects
> ActiveObjects
hi eric
why didnt u continue this interesting part
> ActiveObjects
> ActiveObjects
Hi Eric,
Your article - is it a joke?
Here is example of my article in this case:
"Using TRequestStatus" A request status object is used to carry the completion status of an asynchronous request.
Typically, an asynchronous request is made by an active object, an instance of a CActive derived class, to a service provider. When an asynchronous request completes, the service provider stores a completion code in the request status object and signals the caller's thread. When the active object handles the completed request, it can check the completion code.
The request status object is always a data member of the active object.
{
void RunL();
void IssueRequest();
...
TRequestStatus iStatus;
RTimer iTimer;
}
The active object does not need to initialise the request status object in any way; it simply passes it to the service provider's request function when making the request. The service provider is responsible for changing the completion code; in particular it sets the code to KRequestPending before initiating the request. For example:
{
timer.CreateLocal(); // created for this thread
...
timer.After(iStatus,5000000); // Notification after 5 seconds
SetActive();
...
}
The active object's completed request handler, i.e. its RunL() function can check the completion code as the code fragments show. While not particularly useful for timers, it shows the general principle:
// Extracting the completion code value
//
void RunL()
{
...
User::LeaveIfError(iStatus.Int());// leave on bad return code
...
}
// Using a comparison operator
//
void RunL()
{
...
if (iStatus == KErrCancel);// check for a specific value
...
}
... To be continued....
(reference: http://www.symbian.com/developer/techlib/v70sdocs/doc_source/reference/cpp/AsynchronousServices/UsingTRequestStatus.guide.html)
> ActiveObjects
Re: > ActiveObjects
Yes, if u redefine the TReqStatus then u have to manage that...which is an overhead