×

Discussion Board

Results 1 to 3 of 3
  1. #1
    Regular Contributor
    Join Date
    Mar 2003
    Posts
    54

    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.

  2. #2
    Regular Contributor
    Join Date
    Oct 2006
    Posts
    51

    Re: Why should Document hold engines/models and not AppUI?

    Article about Model View Controller in Symbian :
    http://www.geckim.com/symbian/symbia...ontroller.aspx

    Bye...

  3. #3
    Nokia Developer Moderator
    Join Date
    Sep 2004
    Location
    Tampere, Finland
    Posts
    11,359

    Re: Why should Document hold engines/models and not AppUI?

    Keanu77, you're replying to a post from "2003-03-16, 02:54"

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×