According to the "Introduction to Series 60 Applications for C++ Developers"
document available on Nokia's website, a typical Symbian application using
Symbian's version of an MVC framework creates any engine or model components
in the Document (CEikDocument dervied) class. This appears to be true even
for applications that are not file based and act as "little more than a
shell required by the framework to create an instance of the AppUi class".
I have looked at the SnapShot example application shipped with the Series 60
SDK and noticed a few things.
1) The view class of the snapshot example is responsible for creating and
sending requests to the CCameraManager class (an engine).
2) The AppUi (CEikAppUi derived) class does not use typical Symbian two
phase construction with a static NewL() or NewLC() method. Rather the
document class calls the AppUi classes's constructor directly.
I am willing to write up item 1 to the fact this is just a simple example
application focusing on the camera APIs in which good encapsulation took a
back seat to expediency. I conjecture that the call to CCameraManager to
request a picture be taken should have been made directly from the AppUI
class. The instance of the CCameraManager that would be used by the AppUi
class after such a redesign would be created in either the AppUi class or
be created in the Document class and passed along to the AppUi during its
construction (in the CSnapShotDocument::CreateAppUiL() method). If anyone
disagrees with this conclusion or has relevant input please say so and
elaborate on your answer.
What I am still unclear about is how the view class (derived from
CCoeControl) should be notified of changes in the model (or results of the
engine). Should the AppUi class relay the information when it is notified
of a change or should the view class be registered with the model as a
listener. Assuming there is more than one listener this requires the
model/engine to support having a list of listeners; probably by using the
Symbian dynamic array classes. Are there any utility classes providing more
direct support for multiple listeners than the array utilities? Can anyone
provide greater clarity as to how to approach update events?
I am also concerned with the "Introduction to Series 60 Applications for C++
Developers" suggestion that the document class construct any engines or
models. If the application is not file based, why shouldn't the AppUI class
construct any necessary engines and/or models? What arguments for and
against creating the models/engines in the AppUi verses the Document class
can be made?
On page 41 of "Programming for the Series 60 Platform and Symbian OS"
published by Digia, ISBN 0-470-84948-7, figure 3.3 "A simplified application
architecture using MVC" there is a class diagram of the various classes
involved. The Application, Document, and AppUI classes are all considered
to be part of the controller. Although I am familar with the MVC design
pattern, I am still a bit confused as to what roles the various classes in
the controller should play and why they should do so. I would probably
benefit from seeing a well designed example of a somewhat more complex
application. Can anyone point me to a better example than the SnapShot
Thank you for your time and effort spent reading and replying to this
AOL IM: nawkboyrules
P.S.: I have copied the relevant snipt of the document below:
5.4 The Symbian OS Application Framework
UIKON and Standard EIKON are key parts of the application framework. They
provide the framework for launching applications, but also a rich array of
components (e.g., dialog boxes, number editors, date editors, etc.) that
applications use at
runtime. A typical application written for Symbian OS actually consists of
components, each with a corresponding class within the UIKON/EIKON
! The application shell - is derived from CEikApplication. This class is
instantiated first by the framework. Once created, it has responsibility for
initializing the rest of the code. The new CEikApplication-derived class
! The document - is derived from CEikDocument. All applications have a
CEikDocument-derived class and by default CEikDocument will create a default
document file the first time an application is run. However, not all
are file based. That is, they may not need to offer the user the ability to
open, or edit documents. In such non-file-based applications, such as the
Telephone application, the instance of the document class is little more
shell required by the framework to create an instance of the AppUi class and
typically a model/engine instance. In file-based applications the document
also manages the saving and restoring of data from persistent storage.
! The application UI - is derived from the Uikon class CEikAppUi. This class
provides major functionality to all applications such as event handling,
creation, access to many useful system calls, etc. The CEikAppUi-derived
is typically responsible for creating one or more application views.
! The view - provides what the user actually sees on the screen. All
have one default view; more complex ones, such as Calendar can offer many
views. The view can be used simply to display data (exemplified in
or to collect data from the user in more interactive applications. For
many data-entry applications the data editors are simply standard controls
provided by Uikon contained within the view. In the majority of applications
view(s) are derived from CCoeControl i.e. they are controls in their own