As in this site there are many articles about some or the other implementation of certain aspects of a Symbian application, but there is not many on how a Symbian application is formed from a designing point of view. In the following article I have tried to throw some lights on how the Observer pattern (refer GoF book on Design Pattern) is usually implemented in a normal Symbian application. I have tried to simulate the whole design using meaningful names of the classes so that one can visualize the normal flow of a Symbian application. In this application I have tried to model how an engine and the front end UI interacts to present a responding UI to the user of a certain application. In this article I have given one way of solution. In the next article I will present the other way of doing it through nested classes. Lets start with the Engine class of an application and its Observer. Lets say we have an Observer interface called MObserver which has been defined as follows:
class MObserver
{
public:
virtual void CallbackFunction1() = 0;
};
As this is an interface having a pure virtual function, this has to be implemented by a concrete class. In our case the Engine class will implement it as follows.
class Engine : public MObserver
{
public: Engine(CAppUi& aAppUi);
void CallbackFunction1();//From MObserver
void DoSomething();
Subject& GetSubject();
private: Subject* iSubject;
CAppUi& iAppUi;
};
As it is becoming clear from the naming of thse classes, the Engine class has reference to the Subject class which will actually do the work in the background and the CAppUi class which is actually the Front End class of the application. It’s the engine whhich actually create its subject class. In normal Symbian application this CAppUi class is responsible for rendering data in the UI through the View class.
Now lets talk about the Subject class which has been declared as follows:
class Subject
{
public:
Subject(MObserver& aObserver);
void DoSomething();
private:
MObserver& iObserver;
};
As it is obvious that the subject is linked with its observer. In normal scenario of a Symbian application, this Subject class will be derived from CActive class to do the work in the background through some Asynchronous function. Here the function called DoSomething() will call some of the Asynchronous functions. This function will also call the CallbackFunction1() of the MObserver. Hence it is basically working as the function Notify as mentioned in the GoF book. This CallbackFunction1 will actually update the AppUi regarding the present state of application/engine and the UI will look responsive. So lets look how the CAppUi class has been declared.
class CAppUi
{
public:
CAppUi();
Engine& GetEngine();
void PrintToUI(char* msg);
virtual ~CAppUi();
private:
Engine* iEngine;
};
The responsibility of the AppUi class is to create the engine of the application. Please remember that the Application and the Engine has cyclic reference to each other. So the flow whole flow goes like this:
AppUi will create the Engine.
The engine will create the Subject.
The AppUi will call the DoSomething function of the Engine through some of its Menu command.
The engine will delegate this task to the DoSomething function of the Subject.
The DoSomething function of the Subject will notify the concrete observer (which is the engine) through the CallbackFunction1.
The DoSomething function of the Subject will look something like this:
void Subject::DoSomething()
{ //Call the Asynchronous function
//Now Notify the Observer regarding this.
iObserver.CallbackFunction1();
}
And this Callback function of the Observer will actually print the message in the AppUi through the function PrintToUi. In actual scenario this function will actually render the message gotten from Engine in the View.
I hope this article will clarify some of the doubts of a newbee Symbian programmer about how the Ui actually responds when there is some background processing going on.
【
原文地址】
