All About Symbian Forums

All About Symbian Forums (http://www.allaboutsymbian.com/forum/index.php)
-   Symbian C++ (http://www.allaboutsymbian.com/forum/forumdisplay.php?f=26)
-   -   Why should Document hold engines/models and not AppUI? (http://www.allaboutsymbian.com/forum/showthread.php?t=9147)

nawkboy 16-03-2003 02:55 AM

Why should Document hold engines/models and not AppUI?
 
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
example?

Thank you for your time and effort spent reading and replying to this
posting.

Sincerely,
James Carpenter
Email: nawkboy@yahoo.com
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
not only

provide the framework for launching applications, but also a rich array of
standard control

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
four distinct

components, each with a corresponding class within the UIKON/EIKON
framework. They

are:

! 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
then

creates.

! 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
applications

are file based. That is, they may not need to offer the user the ability to
create,

open, or edit documents. In such non-file-based applications, such as the

Telephone application, the instance of the document class is little more
than a

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
class

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,
control

creation, access to many useful system calls, etc. The CEikAppUi-derived
class

is typically responsible for creating one or more application views.

! The view - provides what the user actually sees on the screen. All
applications

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
HelloWorld)

or to collect data from the user in more interactive applications. For
example, in

many data-entry applications the data editors are simply standard controls

provided by Uikon contained within the view. In the majority of applications
the

view(s) are derived from CCoeControl i.e. they are controls in their own
right.


All times are GMT. The time now is 10:15 AM.

Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.