A discussion on Symbian Active Object framework

1. Active Objects of
Symbian in the lights
of Client-Server
architecture
by
Somenath Mukhopadhyay
som.mukhopadhyay@gmail.com
When I started understanding Active Object framework in Symbian, it was difficult for me to
grasp the idea how the front end UI is not frozen, in the event of long running task, even
when we don't use multiple threads. But when i started understanding the active object
framework in conjunction with the client-server architecture of symbian, I got the idea. I
would like to share it with you.
Before we start, i want to throw some lights on the definition of Asynchronous Service
Provider and Asynchronous functions in Symbian Active Object and Client-Server
architecture. Asynchronous Service Providers are the functions which are fired from a client
and returns immediately in that client. However, this function causes another function in the
server to run. This server function may be blocking in server side. So we get two sides of a
function. We get a non-blocking function in the client-side which initiates another function in
the server side, which may be blocking, in the server side. Once the function in the server
side finishes, it notifies the client side (which actually initiates the whole chain) about this.
These asynchronous functions have TRequestStatus as one of the parameters which is
passed as a reference from the client to the server.
These are all theoretical aspects of the Active object and Client-Server framework. Let me
give you one practical scenario where this can be used. In this context i would also like to
share what actually happens in a normal multi threaded application.
Suppose, we have a communication port which is continuously receiving data from an
external source. Suppose we need to develop an application which will read the data and at
the same time will render that data in some short of graphical form. So how is it possible?
In symbian environment, we can realize this scenario by employing the Active object
framework in conjunction with the client-server architecture. Let me explain it in more

2. details. We may delegate the task of reading the data from the communication port to a
server application which will run as a different process than the front end UI application. Of
course there are such functionalities already developed in the Symbian and related
frameworks. But just for the sake of explanation, we will have to create an asynchronous
function in the server which will actually read the data from the communication port. So in
the server this function will be blocking. However, we may create an UI application using the
active object framework, which will initiate this call to the server and will immediately return
in the UI application (non-blocking). The moment, the server finishes reading certain amount
of data (say 1024 Kb) and copying it to the UI application's memory area, (remember the UI
application and the server are across the process boundary), it will notify the front end UI
about this and again start reading the data from the port in the background. On the other
hand, the UI application will render the data in the graphical format.
Now let me tell you how this is possible in an Windows application. Once I had developed one
such application using the Windows asynchronous I/O pattern and windows event
mechanism. There the task of reading of the data from the communication port was
delegated to a background thread. The background thread used to read the data and when it
finishes some specific amount it used to fire an event to the front end UI, which then
rendered the data in the front end UI.
This is all about theories and scenarios. Now, let me give you a real life symbian code which
has got two applications. One is an UI application which has got an engine. This engine is
working as an active object for this UI application. Then we have a Symbian Client-Server
application. This application has got a client side interface which is a DLL and a Server side
implementation which is developed as an EXE. The server has an Asynchronous function
which will eventually be called from the UI application.The UI application is linked with the
dynamic link library (DLL) of the client-server application.
Let us start from the client-server application. The client has just three exported functions.
One is an Asynchronous function and the other if we cancel that function. And the third one
is to connect to the server. It looks like the following:
//client.h
class RClient : public RSessionBase
{
public:
IMPORT_C TInt Connect();
IMPORT_C void GetNotifiedWhenEventCompleted(TInt aCount, TDes& aData,
TRequestStatus& aStatus);
IMPORT_C void CancelGetNotifiedWhenEventCompleted();
};
The implementation of the client looks like the following:
// client.cpp
#include "client.h"
#include "client-server.h"
#include <e32math.h>

3. // Runs client-side and starts the separate server process
static TInt StartTheServer()
{
RProcess server;
TInt r=server.Create(KServerBinaryName, KNullDesC);
if (r!=KErrNone)
return r;
TRequestStatus stat;
server.Rendezvous(stat);
if (stat!=KRequestPending)
server.Kill(0);
// abort startup
else
server.Resume(); // logon OK - start the server
User::WaitForRequest(stat);
// wait for start or death
// Check the exit type.
// We can't use the 'exit reason' because if the server panicked this
// is set to the panic 'reason' (which may be '0' and cannot thus be distinguished
// from KErrNone)
r = server.ExitType();
if (EExitPanic==r)
r = KErrGeneral;
else
r = stat.Int();
server.Close(); // This is no longer needed
return r;
}
EXPORT_C TInt RClient::Connect()
{
TInt retry=2;
for (;;)
{// Uses system-pool message slots
TInt r=CreateSession(KServerName,TVersion(1,0,0));
if ( (KErrNotFound!=r) && (KErrServerTerminated!=r) )
return (r);
if (--retry==0)
return (r);
r=StartTheServer();
if ( (KErrNone!=r) && (KErrAlreadyExists!=r) )
return (r);
}
}
EXPORT_C void RClient::GetNotifiedWhenEventCompleted(TInt aCount, TDes& aData,
TRequestStatus& aStatus)
{
TIpcArgs args(aCount,&aData);
SendReceive(EGetNotifiedWhenEventCompleted, args, aStatus);

4. }
EXPORT_C void RClient::CancelGetNotifiedWhenEventCompleted()
{
SendReceive(ECancelGetNotifiedWhenEventCompleted, TIpcArgs());
}
These are pretty staright forward. I am not going in details about the client server
architecture of a symbian application. I am more interested in explaining you about how an
asynchrounous function is handled in the client-server and active object framework.
Now let me focus on the server side implementation of this application.
The server header file looks like the following:
// server.h
#ifndef __SERVER_H__
#define __SERVER_H__
#include <e32base.h>
#include "client-server.h"
enum TServerPanic
{
EPanicBadDescriptor,
EPanicNotSupported
};
void PanicClient(const RMessage2& aMessage,TServerPanic TMyPanic);
const TInt KShutdownDelay=200000; // approx 2 seconds
class CShutdown : public CTimer
{
public:
inline CShutdown();
inline void ConstructL();
inline void Start();
private:
void RunL();
};
inline CShutdown::CShutdown()
:CTimer(-1)
{CActiveScheduler::Add(this);}
inline void CShutdown::ConstructL()
{CTimer::ConstructL();}
inline void CShutdown::Start()
{After(KShutdownDelay);}
class CMyServer : public CServer2
{

5. public:
static CServer2* NewLC();
void AddSession();
void RemoveSession();
private:
CMyServer();
void ConstructL();
// From CServer2
virtual CSession2* NewSessionL(const TVersion& aVersion,const RMessage2& aMessage)
const;
private:
TInt iSessionCount;
CShutdown iShutdown;
};
inline CMyServer::CMyServer()
:CServer2(CActive::EPriorityStandard)
{}
class CAsyncHandler; // Active object class for asynchronous requests
class CMyServerSession : public CSession2
{
public:
CMyServerSession();
void CreateL();
public:
virtual void ServiceL(const RMessage2& aMessage); // From CSession2
virtual void ServiceError(const RMessage2& aMessage, TInt aError); // From CSession2
private:
void GetNotifiedWhenEventCompletedL(const RMessage2& aMessage);
void CancelGetNotifiedWhenEventCompletedL(const RMessage2& aMessage);
private:
~CMyServerSession();
private:
CAsyncHandler* iAsyncRequestHandler;
HBufC8* iClientBuf;
};
inline CMyServerSession::CMyServerSession()
{}
// Skeleton active object, for asynchronous server requests
// Uses a very basic timer for asynchronicity
class CAsyncHandler : public CActive
{
public:
static CAsyncHandler* NewL();
static CAsyncHandler* NewLC();
~CAsyncHandler();

6. public:
void ServiceAsyncRequest(const RMessage2& aMessage);
protected:
CAsyncHandler();
void ConstructL();
private:
void DoCancel();
void RunL();
private:
RTimer iTimer;
RMessage2 iMessage;
};
#endif //__SERVER_H__
And the server implementation file looks like the following:
// server.cpp
#include "server.h"
#include <e32base.h>
_LIT(KDesMsgToServer, "To Server;");
// Called by the CServer framework
void CMyServerSession::CreateL()
{
CMyServer* server = static_cast<CMyServer*>(const_cast<CServer2*>(Server()));
ASSERT(server);
server->AddSession();
iAsyncRequestHandler = CAsyncHandler::NewL();
}
CMyServerSession::~CMyServerSession()
{
CMyServer* server = static_cast<CMyServer*>(const_cast<CServer2*>(Server()));
ASSERT(server);
server->RemoveSession();
delete iAsyncRequestHandler;
delete iClientBuf;
}
// A bad descriptor error implies a badly programmed client, so panic it
// Report other errors to the client by completing the outstanding request with the error
void CMyServerSession::ServiceError(const RMessage2& aMessage, TInt aError)
{
if (KErrBadDescriptor==aError)
PanicClient(aMessage,EPanicBadDescriptor);
else
aMessage.Complete(aError);
}

7. // Handle a client request
void CMyServerSession::ServiceL(const RMessage2& aMessage)
{
switch (aMessage.Function())
{
case EGetNotifiedWhenEventCompleted:
GetNotifiedWhenEventCompletedL(aMessage);
break;
case ECancelGetNotifiedWhenEventCompleted:
CancelGetNotifiedWhenEventCompletedL(aMessage);
break;
default:
PanicClient(aMessage,EPanicNotSupported);
break;
}
}
// Asynchronous method
// message slot 0 contains TInt
// message slot 1 contains TDes8&
void CMyServerSession::GetNotifiedWhenEventCompletedL(const RMessage2& aMessage)
{
TInt val0 = aMessage.Int0();
if (val0!=10)
aMessage.Complete(KErrGeneral);
// Determine the length of the client descriptor passed to the server
TInt clientDesMaxLen = aMessage.GetDesMaxLength(1);
if (iClientBuf)
{
delete iClientBuf;
iClientBuf = NULL;
}
//
//
//
//
}
Make an asynchronous request
for the purpose of example here don't worry about passing the
descriptor retrieved above or modifying it
iAsyncRequestHandler->ServiceAsyncRequest(aMessage);
iClientBuf is destroyed by later call to this method or destructor
void CMyServerSession::CancelGetNotifiedWhenEventCompletedL(const RMessage2&
aMessage)
{
// Calls Cancel() on the CAsyncHandler active object
// which must complete the outstanding async activity and complete
// the original client-server request
iAsyncRequestHandler->Cancel();
aMessage.Complete(KErrNone);
}
CServer2* CMyServer::NewLC()

8. {
CMyServer* self=new(ELeave) CMyServer;
CleanupStack::PushL(self);
self->ConstructL();
return self;
}
// Starts the server and constructs the shutdown object, starting the timer to ensure that
// the server will exit even if the starting client connection fails
void CMyServer::ConstructL()
{
StartL(KServerName);
iShutdown.ConstructL();
iShutdown.Start();
}
// Example doesn't bother checking the version
CSession2* CMyServer::NewSessionL(const TVersion& /*aVersion*/,const RMessage2&
/*aMessage*/) const
{
return new(ELeave) CMyServerSession();
}
// Cancel the shutdown timer now, the new session is connected
void CMyServer::AddSession()
{
++iSessionCount;
iShutdown.Cancel(); // Cancel any outstanding shutdown timer
}
// Decrement the session counter and start the shutdown timer if the last client has
disconnected
void CMyServer::RemoveSession()
{
if (--iSessionCount==0)
iShutdown.Start();
}
// Initiates server exit when the timer expires
void CShutdown::RunL()
{
CActiveScheduler::Stop();
}
void PanicClient(const RMessage2& aMessage,TServerPanic aPanic)
{
_LIT(KPanic,"MyServer");
aMessage.Panic(KPanic,aPanic);
}
// Initialize and run the server
static void RunTheServerL()
{// First create and install the active scheduler

9. CActiveScheduler* scheduler = new (ELeave) CActiveScheduler;
CleanupStack::PushL(scheduler);
CActiveScheduler::Install(scheduler);
// create the server
CMyServer::NewLC();
// Naming the server thread after the server helps to debug panics
User::LeaveIfError(User::RenameThread(KServerName));
RProcess::Rendezvous(KErrNone);
// Enter the wait loop
CActiveScheduler::Start();
// Exited - cleanup the server and scheduler
CleanupStack::PopAndDestroy(2, scheduler);
}
// Server process entry-point
TInt E32Main()
{
__UHEAP_MARK; // Heap checking
CTrapCleanup* cleanup=CTrapCleanup::New();
TInt r=KErrNoMemory;
if (cleanup)
{
TRAP(r,RunTheServerL());
delete cleanup;
}
__UHEAP_MARKEND;
return r;
}
The class CAsyncHandler has been implemented as the following:
// asynchandler.cpp
// Skeleton active object, for asynchronous server requests
#include <e32base.h>
#include "server.h"
CAsyncHandler* CAsyncHandler::NewL()
{
CAsyncHandler* me = CAsyncHandler::NewLC();
CleanupStack::Pop(me);
return (me);
}
CAsyncHandler* CAsyncHandler::NewLC()

10. {
CAsyncHandler* me = new (ELeave) CAsyncHandler();
CleanupStack::PushL(me);
me->ConstructL();
return (me);
}
CAsyncHandler::~CAsyncHandler()
{
Cancel();
iTimer.Close();
}
CAsyncHandler::CAsyncHandler()
: CActive(EPriorityStandard)
{
CActiveScheduler::Add(this);
}
void CAsyncHandler::ConstructL()
{
User::LeaveIfError(iTimer.CreateLocal());
}
void CAsyncHandler::ServiceAsyncRequest(const RMessage2& aMessage)
{// Only allow one request to be submitted at a time
_LIT(KOutstandingRequestPanic, "InUse");
__ASSERT_ALWAYS(!IsActive(), User::Panic(KOutstandingRequestPanic, KErrInUse));
iMessage = aMessage;
iTimer.After(iStatus, 2000000); // Set the RTimer to expire in 2 seconds
SetActive(); // Mark this object active
}
void CAsyncHandler::DoCancel()
{
iTimer.Cancel();
iMessage.Complete(KErrCancel);
}
void CAsyncHandler::RunL()
{
iMessage.Complete(iStatus.Int());
}
The client-server.h file looks like the following:
// client-server.h
#ifndef CLIENTSERVER_H__
#define CLIENTSERVER_H__
#include <e32std.h>
#include <s32std.h>

11. _LIT(KServerName,"TestServer");// The server's identity within the client-server framework
_LIT(KServerBinaryName,"server"); // The name of the server binary (dll or exe)
#ifdef __WINS__
const TInt KMinServerHeapSize=0x1000;
const TInt KMaxServerHeapSize=0x1000000;
#endif
enum TClientServerCommands
{
EGetNotifiedWhenEventCompleted,
ECancelGetNotifiedWhenEventCompleted
};
#endif // CLIENTSERVER_H__
So this is all about the client-server application of the example. This client-server application
will provide the basis of the Asynchronous signal handling in the Active Object framework.
Please see the function void CMyServerSession::GetNotifiedWhenEventCompletedL(const
RMessage2& aMessage).
Towards the end of this function we are calling
iAsyncRequestHandler->ServiceAsyncRequest(aMessage). Please remember I am not
interested what the server is doing with the data that the client passes to it. I am more
interested in explaining to you how the Asynchronous function is being handled by the server
and in turn how it signals the Front-end UI.
If we delve into the function
void CAsyncHandler::ServiceAsyncRequest(const RMessage2& aMessage)
{// Only allow one request to be submitted at a time
_LIT(KOutstandingRequestPanic, "InUse");
__ASSERT_ALWAYS(!IsActive(), User::Panic(KOutstandingRequestPanic, KErrInUse));
iMessage = aMessage;
iTimer.After(iStatus, 2000000); // Set the RTimer to expire in 2 seconds
SetActive(); // Mark this object active
}
we will find that it initiates a delay (iTimer.After (iStatus, 2000000) and at the end it calls
SetActive which initiates the Active Scheduler of the server to call the RunL().
This RunL() function is implemented as the following:
<code>
void CAsyncHandler::RunL()
{
iMessage.Complete(iStatus.Int());
}
We find that it calls Complete on the iMessage. This function Complete actually initiates an

12. inter process communication and signals the front end UI application about the completion of
the server-side task.
Now let us concentrate on the front end UI application. This is a simple UI helloworld
application created through the carbide c++ wizard. This application has got an engine which
looks like the following:
//engine.h
#ifndef __ENGINE_h__
#define __ENGINE_h__
#include <e32base.h>
#include "../../clientserver/inc/client.h"
//forward declaration
class CActiveObjectTestAppView;
class MObserver
{
public:
virtual void CallbackFunction_BeginProcessing() = 0;
virtual void CallbackFunction_EndProcessing() = 0;
};
class CEngine : public CActive
{
public:
~CEngine();
static CEngine* NewL(MObserver& aObserver);
private:
//construction
CEngine(MObserver& aObserver);
void ConstructL();
public:
//from CActive
virtual void RunL();
virtual void DoCancel();
//new function.. Asynchronous service provider
void MakeAsyncCall(TRequestStatus& aStatus);
private:
//not owned
MObserver& iObserver;
RClient session;

13. };
#endif
As you can see, this is working as an active object for the Front end UI. There is another M
class called MObserver which provides the necessary call back functionalities for this UI
application. This MObserver class will be realized by the CActiveObjectTestAppUi class of the
application.
The engine class implementation will look like the following:
//engine.cpp
//#include <e32base.h>
#include "engine.h"
#include "ActiveObjectTestAppView.h"
//#include "client.h"
_LIT(KDesMsgToServer, "To Server;");
CEngine::CEngine(MObserver&
aObserver):CActive(CActive::EPriorityStandard),iObserver(aObserver)
{
}
CEngine::~CEngine()
{
Cancel();
}
void CEngine::ConstructL()
{
CActiveScheduler::Add(this);
TInt ret = session.Connect();
User::LeaveIfError(ret);
}
CEngine* CEngine::NewL(MObserver& aObserver)
{
CEngine* self = new(ELeave) CEngine(aObserver);
CleanupStack::PushL(self);
self->ConstructL();
CleanupStack::Pop(self);
return self;
}
void CEngine::MakeAsyncCall(TRequestStatus& aStatus)
{
TBuf<20> myBuf(KDesMsgToServer);
session.GetNotifiedWhenEventCompleted(10, myBuf, aStatus);
iObserver.CallbackFunction_BeginProcessing();
SetActive();

14. }
void CEngine::RunL()
{
iObserver.CallbackFunction_EndProcessing();
}
void CEngine::DoCancel()
{
Cancel();
}
As this is clear the task of the engine is to establish a connection with the client-server
application and issue an asynchronous call through its MakeAsyncCall(TRequestStatus&
aStatus) function.
Now if you look into the MakeAsyncCall function, we will find that after issuing the exported
function GetNotifiedWhenEventCompleted of the client interface of the client-server
application, it is calling the Observer's CallbackFunction_BeginProcessing(). This function
actually makes the UI look responding with some message. In the example application I have
rendered the text in the view as "Beginning...".
So, now the processing in the server of the client-server application has started. As in the
server side CAsyncHandler::ServiceAsyncRequest function it creates some delay and then
signals active scheduler of the fron end UI application. This active scheduler will then call the
RunL function. Here this RunL() function simply refreshes the screenwith the message
"End...".
Hence you will find two messages in the UI application - "Beginning..." and after some delay
"End...". Thus the UI looks responding when thw server does some background task.
Let me show you how the AppUi class has been created in the application. It looks like the
following:
/*
====================================================================
========
Name : ActiveObjectTestAppUi.h
Author
: som
Copyright : Your copyright notice
Description : Declares UI class for application.
====================================================================
========
*/
#ifndef __ACTIVEOBJECTTESTAPPUI_h__
#define __ACTIVEOBJECTTESTAPPUI_h__
// INCLUDES
#include <aknappui.h>
#include "engine.h"

15. // FORWARD DECLARATIONS
class CActiveObjectTestAppView;
class CEngine;
// CLASS DECLARATION
/**
* CActiveObjectTestAppUi application UI class.
* Interacts with the user through the UI and request message processing
* from the handler class
*/
class CActiveObjectTestAppUi : public CAknAppUi, public MObserver
{
public:
// Constructors and destructor
/**
* ConstructL.
* 2nd phase constructor.
*/
void ConstructL();
/**
* CActiveObjectTestAppUi.
* C++ default constructor. This needs to be public due to
* the way the framework constructs the AppUi
*/
CActiveObjectTestAppUi();
/**
* ~CActiveObjectTestAppUi.
* Virtual Destructor.
*/
virtual ~CActiveObjectTestAppUi();
private:
// Functions from base classes
/**
* From CEikAppUi, HandleCommandL.
* Takes care of command handling.
* @param aCommand Command to be handled.
*/
void HandleCommandL(TInt aCommand);
/**
* HandleStatusPaneSizeChange.
* Called by the framework when the application status pane
* size is changed.
*/
void HandleStatusPaneSizeChange();
/**
* From CCoeAppUi, HelpContextL.
* Provides help context for the application.
* size is changed.

16. */
CArrayFix<TCoeHelpContext>* HelpContextL() const;
CEngine* GetEnginePtr();
//from MObserver
void CallbackFunction_BeginProcessing();
void CallbackFunction_EndProcessing();
private:
// Data
/**
* The application view
* Owned by CActiveObjectTestAppUi
*/
CActiveObjectTestAppView* iAppView;
//The engine is owned by CActiveObjectTestAppUi
CEngine* iEngine;
};
#endif // __ACTIVEOBJECTTESTAPPUI_h__
// End of File
And the implementation looks like the following:
/*
====================================================================
========
Name : ActiveObjectTestAppUi.cpp
Author
: som
Copyright : Your copyright notice
Description : CActiveObjectTestAppUi implementation
====================================================================
========
*/
// INCLUDE FILES
#include <avkon.hrh>
#include <aknmessagequerydialog.h>
#include <aknnotewrappers.h>
#include <stringloader.h>
#include <f32file.h>
#include <s32file.h>
#include <hlplch.h>
#include <ActiveObjectTest_0xEB0B3448.rsg>

17. //#include "ActiveObjectTest_0xEB0B3448.hlp.hrh"
#include "ActiveObjectTest.hrh"
#include "ActiveObjectTest.pan"
#include "ActiveObjectTestApplication.h"
#include "ActiveObjectTestAppUi.h"
#include "ActiveObjectTestAppView.h"
//#include "engine.h"
_LIT(KFileName, "C:privateEB0B3448ActiveObjectTest.txt");
_LIT(KText, "Active Object Test");
_LIT(KBeginningProcessingText, "Beginning...");
_LIT(KEndProcessingText, "End...");
// ============================ MEMBER FUNCTIONS
===============================
// ----------------------------------------------------------------------------// CActiveObjectTestAppUi::ConstructL()
// Symbian 2nd phase constructor can leave.
// ----------------------------------------------------------------------------//
void CActiveObjectTestAppUi::ConstructL()
{
// Initialise app UI with standard value.
BaseConstructL(CAknAppUi::EAknEnableSkin);
// Create view object
iAppView = CActiveObjectTestAppView::NewL(ClientRect() );
// Create a file to write the text to
TInt err = CCoeEnv::Static()->FsSession().MkDirAll(KFileName);
if ( (KErrNone != err) && (KErrAlreadyExists != err))
{
return;
}
RFile file;
err = file.Replace(CCoeEnv::Static()->FsSession(), KFileName, EFileWrite);
CleanupClosePushL(file);
if (KErrNone != err)
{
CleanupStack::PopAndDestroy(1); // file
return;
}
RFileWriteStream outputFileStream(file);
CleanupClosePushL(outputFileStream);
outputFileStream << KText;
CleanupStack::PopAndDestroy(2); // outputFileStream, file
//instantiation of the engine
iEngine = CEngine::NewL(*this);
}

18. // ----------------------------------------------------------------------------// CActiveObjectTestAppUi::CActiveObjectTestAppUi()
// C++ default constructor can NOT contain any code, that might leave.
// ----------------------------------------------------------------------------//
CActiveObjectTestAppUi::CActiveObjectTestAppUi()
{
// No implementation required
}
// ----------------------------------------------------------------------------// CActiveObjectTestAppUi::~CActiveObjectTestAppUi()
// Destructor.
// ----------------------------------------------------------------------------//
CActiveObjectTestAppUi::~CActiveObjectTestAppUi()
{
if (iAppView)
{
delete iAppView;
iAppView = NULL;
}
}
// ----------------------------------------------------------------------------// CActiveObjectTestAppUi::HandleCommandL()
// Takes care of command handling.
// ----------------------------------------------------------------------------//
void CActiveObjectTestAppUi::HandleCommandL(TInt aCommand)
{
switch (aCommand)
{
case EEikCmdExit:
case EAknSoftkeyExit:
Exit();
break;
case ECommand1:
{
//Here we are calling the Asynchronous function
iEngine->MakeAsyncCall(GetEnginePtr()->iStatus);
}
break;
//The rest of the function has not been touched. its the default created by the wizard
case ECommand2:
{
RFile rFile;
//Open file where the stream text is
User::LeaveIfError(rFile.Open(CCoeEnv::Static()->FsSession(), KFileName,
EFileStreamText));//EFileShareReadersOnly));// EFileStreamText));

19. CleanupClosePushL(rFile);
// copy stream from file to RFileStream object
RFileReadStream inputFileStream(rFile);
CleanupClosePushL(inputFileStream);
// HBufC descriptor is created from the RFileStream object.
HBufC* fileData = HBufC::NewLC(inputFileStream, 32);
CAknInformationNote* informationNote;
informationNote = new ( ELeave ) CAknInformationNote;
// Show the information Note
informationNote->ExecuteLD( *fileData);
// Pop loaded resources from the cleanup stack
CleanupStack::PopAndDestroy(3); // filedata, inputFileStream, rFile
}
break;
case EHelp:
{
CArrayFix<TCoeHelpContext>* buf = CCoeAppUi::AppHelpContextL();
HlpLauncher::LaunchHelpApplicationL(iEikonEnv->WsSession(), buf);
}
/*
TRequestStatus status;
iAppView->iEngine->MakeAsyncCall(status);
*/
break;
case EAbout:
{
CAknMessageQueryDialog* dlg = new (ELeave)CAknMessageQueryDialog();
dlg->PrepareLC(R_ABOUT_QUERY_DIALOG);
HBufC* title = iEikonEnv->AllocReadResourceLC(R_ABOUT_DIALOG_TITLE);
dlg->QueryHeading()->SetTextL(*title);
CleanupStack::PopAndDestroy(); //title
HBufC* msg = iEikonEnv->AllocReadResourceLC(R_ABOUT_DIALOG_TEXT);
dlg->SetMessageTextL(*msg);
CleanupStack::PopAndDestroy(); //msg
dlg->RunLD();
}
/*
TRequestStatus status;
iAppView->iEngine->MakeAsyncCall(status);
break;
*/
break;
default:
Panic(EActiveObjectTestUi);
break;
}
}

20. // ----------------------------------------------------------------------------// Called by the framework when the application status pane
// size is changed. Passes the new client rectangle to the
// AppView
// ----------------------------------------------------------------------------//
void CActiveObjectTestAppUi::HandleStatusPaneSizeChange()
{
iAppView->SetRect(ClientRect() );
}
CArrayFix<TCoeHelpContext>* CActiveObjectTestAppUi::HelpContextL() const
{
#warning "Please see comment about help and UID3..."
// Note: Help will not work if the application uid3 is not in the
// protected range. The default uid3 range for projects created
// from this template (0xE0000000 - 0xEFFFFFFF) are not in the protected range so that
they
// can be self signed and installed on the device during testing.
// Once you get your official uid3 from Symbian Ltd. and find/replace
// all occurrences of uid3 in your project, the context help will
// work.
CArrayFixFlat<TCoeHelpContext>* array =
new(ELeave)CArrayFixFlat<TCoeHelpContext>(1);
CleanupStack::PushL(array);
//array->AppendL(TCoeHelpContext(KUidActiveObjectTestApp,
//KGeneral_Information));
CleanupStack::Pop(array);
return array;
}
//Gets a pointer to the engine object
CEngine* CActiveObjectTestAppUi::GetEnginePtr()
{
return iEngine;
}
void CActiveObjectTestAppUi::CallbackFunction_BeginProcessing()
{
iAppView->UpdateScreenText(KBeginningProcessingText);
}
void CActiveObjectTestAppUi::CallbackFunction_EndProcessing()
{
iAppView->UpdateScreenText(KEndProcessingText);
}
// End of File
Please look at the void CActiveObjectTestAppUi::HandleCommandL(TInt aCommand)
funnction.
Go to case ECommand1:

21. Here it becomes clear how we call the Asynchronous function through the menu commands.
I have changed the Draw function of the View class as following:
void CActiveObjectTestAppView::Draw(const TRect& /*aRect*/) const
{
// Get the standard graphics context
CWindowGc& gc = SystemGc();
// Gets the control's extent
TRect drawRect(Rect());
// Clears the screen
gc.Clear(drawRect);
const CFont* font;
font = iEikonEnv->TitleFont();
gc.UseFont(font);
TInt baseLineOffset = drawRect.Height()/2;
gc.DrawText(iScreenText,drawRect, baseLineOffset, CGraphicsContext::ECenter,0);
}
There is another function added in the view class which is as follows:
void CActiveObjectTestAppView::UpdateScreenText(const TDesC16& msg)
{
iScreenText.Copy(msg);
DrawNow();
}
So let me recapitulate the basic functionalities of the Active object, Asynchronous function
and Client-Server framework.
The steps are as follows;
1. The front end UI calls some asynchronous function of the engine through its menu
2.
3.
4.
5.
6.
command
The Observer's callback function is called to notify the UI about this state
The engine delegates the task to a background server application
The server finishes this task asynchronously and signals the Active Scheduler of the UI
application through inter process communication
The Active Scheduler of the UI application calls the RunL() function
Inside this RunL() function we update the Screen again stating the status of the task
Actually we implement this RunL() function of the UI to implement a state pattern wherein
we call different Asynchronous functions of the server in each state and update the UI
accordingly.

22. There is another point that I want to touch about. See how the cyclic reference between
two concrete classes of the front end UI (CEngine and the CActiveObjectTestAppUi) has
been implemented through an M class (MObserver).
I hope I am able to throw some lights on the haziness of Active Object and Client-Server
Architecture. If this helps people, specifically the newbies of Symbian, I will feel good.
Reference: The book for Accredited Symbian Developer exam and the associated code