• Like
  • Save
Symbian OS - GUI Architectures
Upcoming SlideShare
Loading in...5
×

Symbian OS - GUI Architectures

  • 6,289 views
Uploaded on

This course will give you an overview of the general development of an application with an UI in Symbian OS. It contains explanations of the concepts and the framework that is built directly into …

This course will give you an overview of the general development of an application with an UI in Symbian OS. It contains explanations of the concepts and the framework that is built directly into Symbian OS as well as into the UI-frameworks. The various concepts for S60 UI-apps are explained in greater detail. In the challenge you will develop a simple control and use the new Component Array introduced in Symbian OS 9.

Contents:

* GUI Frameworks
* Structure of a GUI application
* Architectures
* Views, Controls, Dialogs
* Seperating UI and engine
o MVC
o ECom

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • nice presentation, but cannot download for offline study which would have been great.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
6,289
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
1
Likes
7

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Symbian OS
    GUI Architectures
    v2.0c – 01 March 2009
    1
    Andreas Jakl, 2009
  • 2. Disclaimer
    These slides are provided free of charge at http://www.symbianresources.com and are used during Symbian OS courses at the University of Applied Sciences in Hagenberg, Austria ( http://www.fh-hagenberg.at/ )
    Respecting the copyright laws, you are allowed to use them:
    for your own, personal, non-commercial use
    in the academic environment
    In all other cases (e.g. for commercial training), please contact andreas.jakl@fh-hagenberg.at
    The correctness of the contents of these materials cannot be guaranteed. Andreas Jakl is not liable for incorrect information or damage that may arise from using the materials.
    Parts of these materials are based on information from Symbian Press-books published by John Wiley & Sons, Ltd. This document contains copyright materials which are proprietary to Symbian, UIQ, Nokia and SonyEricsson. “S60™” is a trademark of Nokia. “UIQ™” is a trademark of UIQ Technology. Pictures of mobile phones or applications are copyright their respective manufacturers / developers. “Symbian ™”, “Symbian OS ™” and all other Symbian-based marks and logos are trademarks of Symbian Software Limited and are used under license. © Symbian Software Limited 2006.
    Andreas Jakl, 2009
    2
  • 3. Contents
    GUI Frameworks
    Structure of a GUI application
    Architectures
    Views, Controls, Dialog
    Seperating UI and engine
    MVC
    ECom
    Andreas Jakl, 2009
    3
  • 4. Symbian OS – UI Framework
    Andreas Jakl, 2009
    4
    JavaME
    Licensee Platforms
    S60
    UIQ
    Avkon
    Qikon
    UI Framework
    UI Application Framework
    UI Toolkit
    Uikon
    UI LAF*
    Cone
    FEP Base**
    Application Services Messaging, Browsing, PIM, App. Framework, Data Sync, …
    Connectivity Services
    Multimedia & Graphics Services
    Generic OS Services
    Comms Services
    Telephony Services
    Serial Comm & Short Link Services
    Networking Services
    Base Services
    Kernel Services & Hardware Abstraction
    ** FEP = Front End Processor:Input of characters not directlysupported by hardware keys.
    * LAF = Look & Feel. Allows changing appearance of Uikon controls without modifying Uikon-code itslef
  • 5. S60
    Unified UI platform based on S60
    Official UI platform of Symbian Foundation
    Former name: Series 60
    Touchscreen support with S60 5th Edition
    Andreas Jakl, 2008
    5
    Nokia N97
  • 6. Series 80
    Owner: Nokia
    Designed for:
    Interaction through full QWERTY-keyboard, joystick and 4 softkeys
    Has been superseded by S60 (Device: E90)
    Andreas Jakl, 2009
    6
  • 7. UIQ
    UIQ Technology: Owned by SonyEricsson and Motorola
    Designed for (since UIQ 3)
    Supported (in all combinations):
    Portrait
    Landscape
    Pen-Input (Touchscreen)
    Softkey-Input
    Applications not closed by users
    Licensed to: SonyEricsson, Motorola, (BenQ, Arima)
    Andreas Jakl, 2009
    7
    SonyEricsson P1i
  • 8. UIQ 3
    Since UIQ3 supportfor multiple UI configurations, e.g.:
    Andreas Jakl, 2009
    8
    Softkey-Style
    Pen-Style
  • 9. FOMA
    Phones for NTT DoCoMo, FOMA = Freedom of Mobile Access ( 3G services)
    Different manufacturers: Mitsubishi, Fujitsu, SonyEricsson, Sharp, ...
    Japanese Market
    Closed feature phones, no Smartphones!
    Different to European market: Aromas, mobile credit cards, waterproof, capturing promotional data from coupons, fingerprint sensor, GPS not unusual, ...
    Andreas Jakl, 2009
    9
  • 10. Architecture
    Structure of the UI framework
    Andreas Jakl, 2009
    10
  • 11. Application Architecture
    Applications typically divided into
    UI (View)
    Presents data to the user
    Engine
    Manipulates the data
    Symbian OS application architectures are built based on a clear separation
    Andreas Jakl, 2009
    11
    UI
    Engine
  • 12. Structure
    Andreas Jakl, 2009
    12
    Custom applicationimplementation
    S60 (Avkon) / UIQ (Qikon)-specific implementation
    WServ
    Common Symbian OS
    implementation, sharedfor specific UI Platforms
    Manages access toscreen and input devices
    Many abstract classes,
    define interface for
    UI framework APIs
  • 13. Window Server (WServ)
    Centralised access to the screen and user input devices
    Tasks:
    Handles draw-operations for windows and controls
    Manages which view(s) belongs to which app
    Forward key/pointer/redraw-events to apps.
    WServ does not define look & feel!
    Communication with WServ through CONE using Client/Server-Communication
    Andreas Jakl, 2009
    13
    WServ
  • 14. AppArc / CONE
    AppArc = „Application Architecture“
    Basic application structure
    Mechanism for sending system information to the application and for saving data (through the file server)
    CONE = „Control Environment“
    Framework for creating UI-controls
    Framework for handling user interface events
     Interaction mainly with the Window Server
    Andreas Jakl, 2009
    14
    WServ
  • 15. Uikon
    Uikon: Basic UI library
    All UI applications are based on Uikon
    Generic, device-independent implementation
    Can either be used directly – or UI specific controls are available (adapted to the platform: S60, UIQ)
    Controls called Eikon-controls(e.g. CEikLabel and CEikImage of the Quickstart module)
    Andreas Jakl, 2009
    15
    WServ
  • 16. xxkon
    Avkon / Qikon
    S60 / UIQ-specific UI functionality (menu, …)
    Additional controls and adapted / extendedversions of Uikon-controls
    Andreas Jakl, 2009
    16
    WServ
  • 17. Elements of a GUI-Application
    Common
    Andreas Jakl, 2009
    17
  • 18. Elements of a GUI-App.
    Common required functionality:
    UI for displaying information + interaction
    React to user-initiated events (e.g. select a menu item)
    React to system events (e.g. redraw)
    Save / load application data
    Unique identification to the framework
    Provide information for the framework (Capabilities, …)
    Andreas Jakl, 2009
    18
    View
    AppUi / View
    AppUi
    Document
    Application
    Application
  • 19. Architecture – Overview
    Traditional (Control-Based) S60 application:
    Andreas Jakl, 2009
    19
    Many pre-defined controls available (dialogs, forms, lists, ...)
    Application
    Engine
    can be owned by the Document, AppUi or Container
    CMyApplication
    CMyDocument
    CMyAppUi
    CMyContainer
    Cone
    Avkon
    CAknApplication
    CAknDocument
    CAknAppUi
    CCoeControl
    Stores application properties
    Manages persistent data storage
    Direct events to the correct control (e.g. key input)
    Compound control that can contain one or more controls= view
  • 20. Initialisation
    Andreas Jakl, 2009
    20
    Framework
    (1) E32Main()
    (2) NewApplication()
    CMyApplication
    CMyDocument
    CMyAppUi
    (3) <<create>>
    (4) AppDllUid()
    (5) CApaDocument* CreateDocumentL()
    (6) NewL()
    (7) CEikAppUi* CreateAppUi()
    (8) AppUiConstructor()
  • 21. Start
    E32Main()
    Entry point for the .exe-file
    Creates Active Scheduler, connection to File- and Window-Server. Loads libraries and resource files
    Parameter: Function-pointer to the factory function:
    NewApplication()
    Creates and returns Application-class
    Andreas Jakl, 2009
    21
    GLDEF_C TInt E32Main() {
    return EikStart::RunApplication( NewApplication );
    }
    LOCAL_C CApaApplication* NewApplication() {
    return new CMyApplication;
    }
    The cleanup stack doesn’t exist yet, therefore there’s no (ELeave) when creating the object!
    !
  • 22. Application
    Sends UID3 to the framework
    Has to be identical to UID defined in the .mmp-file
    Creates Document
    Functionality of AppUi base classes:
    Framework can query Capabilities, App.-name
    Andreas Jakl, 2009
    22
    Application
    class CMyApplication : public CAknApplication {
    public:
    TUidAppDllUid() const;
    protected:
    CApaDocument* CreateDocumentL();
    };
  • 23. Document
    Represents persistent Data of the application
    Functions to load and save data in file stores
    Not used by default in S60
    Creates instance of AppUi
    Andreas Jakl, 2009
    23
    Document
    class CMyDocument : public CAknDocument{
    public:
    static CMyDocument* NewL( CEikApplication& aApp );
    virtual ~CMyDocument();
    // Called by the application framework to create AppUi-Object
    CEikAppUi* CreateAppUiL();
    private:
    void ConstructL();
    CMyDocument( CEikApplication& aApp );
    };
  • 24. AppUi
    Creates default view
    Logic for handling events
    No direct graphical representation
    … but owner of Softkey/Title/…-Bar and Views
    Andreas Jakl, 2009
    24
    AppUi
    CMyAppUi
    Application specific features
    Event handling, View construction, …
    C<variant>AppUi
    Features common across all apps, eg.: Title bars, Scroll bars, Start up & shut down, Standard soft keys, …
    CEikAppUi
    Document handling,Menus & Pop-ups, Screen Area,Resource File
    CCoeAppUi
    Control stack, view management, event handling
  • 25. AppUi
    Most important functions:
    Andreas Jakl, 2009
    25
    AppUi
  • 26. View / Container
    View defined as generic concept for displaying data on the screen
    S60
    Three architectures:
    Control-Based Architecture
    The view is a control itself
    Dialog-Based Architecture
    Avkon View-Switching Architecture
    View = additional layer in between AppUi and Controls
    UIQ
    Recommended: view based
    Andreas Jakl, 2009
    26
    View
  • 27. App Startup (S60 Views)
    Andreas Jakl, 2009
    27
    CreateDocumentL()
    CreateAppUiL()
    ConstructL()
    DoActivateL()
    RunApplication
    Avkon View SwitchingApplication
    CMyApplication
    CMyDocument
    CMyAppUi
    CMyView1
    CMyContainer1
    Avkon
    CAknViewAppUi
    CAknApplication
    CAknDocument
    CAknView
    CAknAppUi
    CAknAppUiBase
    Uikon
    CEikAppUi
    CEikDocument
    CEikApplication
    Cone
    AppArc
    CCoeAppUi
    CApaDocument
    CApaApplication
    CCoeControl
  • 28. Controls
    Build the User Interface using
    Andreas Jakl, 2009
    28
  • 29. Control
    Control = “Empty Canvas”
    Rectangular area of a window
    Can react to user input
    e.g. views, buttons, menus, nearly all UI controls, …
    Two types:
    Simple Control: Does not contain other controls
    Container/Compound Control: Contains and owns other controls
    Andreas Jakl, 2009
    29
    CCoeControl
  • 30. Compound Controls
    Parent control contains child controls, e.g.:
    main & window-owning control contains application content (label controls, image controls, ...)
    complex control made out of sub-controls (custom menu made out of multiple labels)
    Andreas Jakl, 2009
    30
  • 31. Compound Controls
    Old way (pre-Symbian OS 9.1)
    Compound control (=parent) saves component controls (=children) as instance variables
    Compound Control has to override two functions:
    TIntCCoeControl::CountComponentControls()Returns the number of contained component controls
    CCoeControl* CCoeControl::ComponentControl(TIntaIndex)Returns the component control with the specified index
    Andreas Jakl, 2009
    31
  • 32. Old Way – Example
    Andreas Jakl, 2009
    32
    TIntCMyContainer::CountComponentControls() const
    {
    // Return the number of controls this compound control (container) contains
    return 2;
    }
    CCoeControl* CMyContainer::ComponentControl( TIntaIndex ) const
    {
    // Return the component control with the specified index
    switch ( aIndex )
    {
    case 0:
    return iLabel;
    case 1:
    return iImage;
    }
    return NULL;
    }
  • 33. Compound Controls – New!
    Simplified control handling – base class does the counting and cleanup work!
    Available since Symbian OS 9.1
    Andreas Jakl, 2009
    33
    void CMyContainer::ConstructL()
    {
    // Initialize the component array, which is defined by the CCoeControl base class
    InitComponentArrayL();
    // Construct all the new component controls and add them to the component array
    CComponent* myComponent = new (ELeave) CComponent();
    Components().AppendLC( myComponent ); // or InsertLC or InsertAfterLC(). Places item on cleanup stack.
    myComponent->ConstructL();
    // [Initialize the control...]
    CleanupStack::Pop( myComponent );
    }
  • 34. Control
    Window-Owning
    View of the application is window-owning (CreateWindowL() is called in ConstructL())
    Window has 1..1-Relationship to window-owning control
    e.g. dialogs, menus, toolbars, top-level controls
    Non-Window-Owning (or “lodger” controls)
    Use window owned by the parent control (SetContainerWindowL() is called in ConstructL())
    Controls may not overlap
    More efficient: less Client/Server-traffic to the Window Server
    e.g. command buttons, text boxes, labels
    Andreas Jakl, 2009
    34
    Window = area of the screen, owned by the Window Server
    CCoeControl
    void CHourPowerAppView::ConstructL( const TRect& aRect )
    {
    // Create a window for this application view
    CreateWindowL();
    // Set the windows size
    SetRect( aRect );
    // Activate the window, which makes it
    // ready to be drawn
    ActivateL();
    }
  • 35. Control Stack
    Control Stack (owned by AppUi) contains list of all controls that would like to receive keyboard events
    Adding a control to the stack: CCoeAppUi::AddToStackL()
    Order of controls on the stack depends on:
    Priority
    Same priority: order of putting on the stack
    Andreas Jakl, 2009
    35
    CCoeControl
  • 36. Control Stack – Example
    Andreas Jakl, 2009
    36
    void CMyAppUi::ConstructL()
    {
    // Initialize the AppUi with standard values (-> Resource file)
    BaseConstructL( EAknEnableSkin );
    // Create the main compound control that will own the window
    iMyContainer = CMyContainer::NewL( ClientRect(), NULL, this );
    // Define that the parant of the control is the AppUi
    iMyContainer->SetMopParent( this );
    // Add the control to the AppUi’s Control Stack
    AddToStackL( iMyContainer );
    }
    CMyAppUi::~CMyAppUi()
    {
    if ( iMyContainer != NULL )
    {
    // Remove the control from the Control Stack
    RemoveFromStack( iMyContainer );
    delete iMyContainer;
    iMyContainer = NULL;
    }
    }
  • 37. Control Stack
    Andreas Jakl, 2009
    37
    CCoeControl
    Starting at stack pos. 0, events are offered to each control until they are consumed by a control
    Most of the time App. view or dialogs are Compound Controls
     Distribute key press events depending on keyboard focus
    Stack position 0
    Events
    Controls put on the stack in the order: A, B, C, D
  • 38. Handling Key Events
    Andreas Jakl, 2009
    38
    TKeyResponseCMyContainer::OfferKeyEventL(const TKeyEvent& aKeyEvent, TEventCodeaType)
    {
    // Default: We did not consume the key, framework will forward the events to other controls
    TKeyResponse ret = EKeyWasNotConsumed;
    if (aType == EEventKey)
    {
    switch (aEventKey.iCode)
    {
    case EKeyLeftArrow:
    // Handle the key event...
    // We have handled the event, make sure it is not handled by multiple controls!
    ret = EKeyWasConsumed;
    break;
    //...
    }
    }
    return ret;
    }
  • 39. Control-BasedArchitecture
    The traditional Symbian OS-way
    Andreas Jakl, 2009
    39
  • 40. Control-Based Architecture
    AppUi
    Direct owner of view-controls(those are derived from CCoeControl)
    Control has its own class (called Container or View), it can contain additional controls (= Compound Control)
    AppUi is responsible for changing displayed content((de)activate container)
    Child-Parent-Relationship defined through Container::SetMopParent()
    Self-made view-switching possible: through AddToStack() and RemoveFromStack()
    Andreas Jakl, 2009
    40
  • 41. Avkon
    Control-BasedArchitecture
    Andreas Jakl, 2009
    41
    Control-BasedApplicationArchitecture
    CMyApplication
    CMyDocument
    CMyAppUi
    CMyContainer1
    CMyContainer1
    CAknApplication
    CAknDocument
    CAknAppUi
    CAknAppUiBase
    Uikon
    CEikAppUi
    CEikDocument
    CEikApplication
    Cone
    AppArc
    CCoeAppUi
    CApaDocument
    CApaApplication
    CCoeControl
  • 42. Dialog-Based Architecture
    Predefined controls
    Andreas Jakl, 2009
    42
  • 43. Dialogs
    Dialog = Control(s) withpredefinedframeworkfor layout, commandhandling, etc.
    Canbedefinedthroughresourcefiles (instead of in thesourcecode)
    Examples:
    Andreas Jakl, 2009
    43
    Note
    Query Dialog
    List Dialog
    Form
  • 44. Dialog-Based Architecture
    Predefined dialogs for common use cases:
    Data display
    -entry
    -editing
    Less development work than when directly using controls
    Dialog automatically manages its child controls
    Multipage dialogs possible (e.g. with tabs)
    Example: settings application
    Andreas Jakl, 2009
    44
  • 45. Dialogs
    Most important properties:
    Modal: Prevents interaction with the rest of the app as long as it is active (e.g. note)
    Modeless: Interaction with other parts of the UI is possible (e.g. main view in a dialog based architecture)
    Waiting: App. is paused as long as the dialog is displayed (e.g. simple text query dialog)
    Nonwaiting: App. continues while dialog is shown (e.g. progress note)
    Andreas Jakl, 2009
    45
  • 46. Avkon
    Dialog-BasedArchitecture
    Andreas Jakl, 2009
    46
    Dialog-BasedApplicationArchitecture
    CMyApplication
    CMyDocument
    CMyAppUi
    CMyDialog
    CAknApplication
    CAknDocument
    CAknAppUi
    CAknDialog
    CAknAppUiBase
    Uikon
    CEikDialog
    CEikAppUi
    CEikDocument
    CEikApplication
    CEikBordererdControl
    Cone
    AppArc
    CCoeAppUi
    CApaDocument
    CApaApplication
    CCoeControl
  • 47. Avkon View-Switching Architecture
    The most flexible solution
    Andreas Jakl, 2009
    47
  • 48. Using Views
    Andreas Jakl, 2009
    48
    Application
    Menu View
    Game View
  • 49. Avkon View-Switching Archit.
    Views represent different pages of the application
    Application registers views with the view server
    View Server takes responsibility for managing views from the AppUi
    Application can activate / deactivate views through the view server
    Only one view can be active at the same time
    Allows different data representation based on the current task of the user
    Andreas Jakl, 2009
    49
  • 50. Why Views?
    Each view is an own object
    Encapsulates data and functions
    Own activation / deactivation functions
    Views = modules: Application can easily be adapted for future modifications
    Views from external applications
    Allows access to views of other applications(e.g. contact list, video playback, ...)
    Reduces complexity of individual applications
    Andreas Jakl, 2009
    50
  • 51. Avkon View-Switching Archit.
    Differences to Control-Based Architecture:
    Additional class in-between AppUi and Container: CAknView Each view handles its own events (like small AppUi)
    AppUi derived from CAknViewAppUi (instead of CAknAppUi)  manages views, delegates drawing and interaction
    Andreas Jakl, 2009
    51
    Avkon-ViewBased
    Container (Compound Control)
    CAknView
    Control
    CAknViewAppUi
    CAknView
    Control
    Container (Control)
    View Server
  • 52. Example
    Creating two views, setting the first as default
    Andreas Jakl, 2009
    52
    void CViewTestAppUi::ConstructL()
    {
    // Initialize the AppUi with standard values
    BaseConstructL( EAknEnableSkin );
    // Construct the first view
    iViewTestContainerView = CViewTestContainerView::NewL();
    // Registers the view and adds it to the AppUi
    AddViewL( iViewTestContainerView );
    // Set the first view as the initial view
    SetDefaultViewL( *iViewTestContainerView );
    // Construct and register the second view
    iViewTestFormView = CViewTestFormView::NewL();
    AddViewL( iViewTestFormView );
    }
  • 53. Switching Views
    Handled by the AppUi
    Local view switching
    Activates another view of the same application, deactivates the current view
    Specify the new view through its UID
    CAknViewAppUi::ActivateLocalViewL(TUidaViewId)
    Remote view switching
    Activate a view in another application
    Specify the UID of target application and target view
    CCoeAppUi::ActivateViewL(const TVwsViewId& aViewId)
    Andreas Jakl, 2009
    53
  • 54. View
    Most important functions:
    Andreas Jakl, 2009
    54
    View
  • 55. View – Menu
    Each view has associated resource
    Defines menu
    and/or Command Button Array (CBA)
    Commands are passed in this order:
    HandleCommandL() of the active view
    AppUi::HandleCommandL()
    Andreas Jakl, 2009
    55
    <yourapp>.rss
    RESOURCE AVKON_VIEW r_my_view
    {
    cba = R_AVKON_SOFTKEYS_OPTIONS_EXIT;
    menubar = r_my_options_menu;
    }
  • 56. Avkon
    Architechture – S60 Views
    Andreas Jakl, 2009
    56
    Avkon View SwitchingApplication
    CMyApplication
    CMyDocument
    CMyAppUi
    CMyView1
    CMyContainer1
    CAknViewAppUi
    CAknApplication
    CAknDocument
    CAknView
    CAknAppUi
    Container(s) contain visible content
    CAknAppUiBase
    Uikon
    CEikAppUi
    CEikDocument
    CEikApplication
    Cone
    AppArc
    CCoeAppUi
    CApaDocument
    CApaApplication
    CCoeControl
  • 57. Choosingthe optimal architecture
    When to usewhicharchitecture?
    Andreas Jakl, 2009
    57
  • 58. ControlBased
    Architectures – Overview
    Andreas Jakl, 2009
    58
    Compound Control
    Control
    AppUi
    Control
    Control
    Dialog Based
    Control
    Dialog
    AppUi
    Dialog
    Control

    Avkon-ViewBased
    Container (Compound Control)
    View
    Control
    AppUi
    View
    Control
    Container (Control)
    View Server
  • 59. Control Based?
    Use if:
    Application only needs one view
    Unlikely that other apps will want to access your view
    Porting from other Symbian OS platforms that do not use the view concept
    Andreas Jakl, 2009
    59
  • 60. Dialog Based?
    Use if:
    (Nearly) all screens of the app. are dialogs (e.g. lists are dialogs as well!)
    No cyclic navigation paths allowed!
    Disadvantage: Dialogs not so good for communication with AppUi
    Most of the time a dialog is a self-contained system, returns after dialog is dismissed
    Andreas Jakl, 2009
    60
    Multipage-Dialog
    1a
    1b
    2
    3
    4
    Navigation 1a  2  1b  1anot allowed! Dialog 1a would beinstantiated twice.Rule: After navigating downwardsin the hierarchy, return through thesame path when navigating upwards.
  • 61. Avkon View-Switching?
    Allows access to views of other applications
    e.g. user gets an email, wants to save address of sender  messaging-app. calls view of the contacts-app.
    Use if:
    Other programs should be able to access your views (if more complex interactions are required: views not enough, Client/Server should be used)
    If there are no good reasons for using other architectures
    Andreas Jakl, 2009
    61
  • 62. Mixing Architectures
    In many cases this is the optimal solution
    e.g. combine Dialog-based architecture with others
    Dialogs are used for general navigation or simpler screens, custom views implemented with View-architecture
    Andreas Jakl, 2009
    62
  • 63. Architecture – UIQ 3
    ... more about UIQ in an individual module!
    Andreas Jakl, 2009
    63
    UIQ Application
    CMyApplication
    CMyDocument
    CMyAppUi
    CMyView
    Qikon
    CQikApplication
    CQikDocument
    CQikViewBase
    CQikAppUi
    Uikon
    CEikAppUi
    CEikDocument
    CEikApplication
    (…)
    Cone
    AppArc
    CCoeAppUi
    CApaDocument
    CApaApplication
    CCoeControl
  • 64. UI and Engine
    Code structure
    Andreas Jakl, 2009
    64
  • 65. Model View Controller Pattern
    Model: Contains and manipulates data in the app.
    View: Defines representation of data. Forwards events to the controller.
    Controller: Defines how the UI should react to commands and requests
    Andreas Jakl, 2009
    65
  • 66. Model
    Out-source data and algorithms to the model (engine)
    MVC-Pattern: AppUi = Controller
    Additional Controller (e.g. when the engine has its own asynchronous services)
    Andreas Jakl, 2009
    66
    Application
    Document
    AppUi
    View
    1
    1
    1
    1
    Model
    Application
    Document
    AppUi
    View
    1
    1
    1
    1
    1
    Controller
    Model
  • 67. Seperating UI / Engine
    Engine:
    Algorithms for managing and processing data
    Routines for loading and saving
    e.g. Chess: status of the board, rules for movement, AI
    UI:
    Displays data for the user
    Transfers user-requests to the engine
    e.g. Chess: representation of the game status, user interaction
    Andreas Jakl, 2009
    67
  • 68. Seperating UI / Engine
    Advantages:
    Prevent unnecessary dependencies
    Maximise code reuse
    Parallel development of UI and engine
    Good application structure
    Implementation:
    Put engine in its own dll or .exe-server
    or: ECom-Plugin
    Andreas Jakl, 2009
    68
  • 69. ECom (Short Overview)
    Shared DLLs
    Platform Security – Data Caging: Access not so easy
    ECom (Epoc Component Object Model)
    Generic framework, manages plug-ins
    Built using Client/Server architecture
    Plug-in registers itself at ECom
    Your code is in a dll
    Data (name, ID, …) and connection interface/implementation defined through resource file
    Andreas Jakl, 2009
    69
  • 70. ECom
    Client requests implementation of an interface
    Through UID or text (name of the implementation)
    ECom searches through its saved meta-information database, returns best results („resolution“)
    ECominstantiates desired object through its factory function, loads object in the process of the client
    ECom uses reference counting for resource management
    Andreas Jakl, 2009
    70
  • 71. Basic ECom Architecture
    Andreas Jakl, 2009
    71
    Client
    request instance
    <<Interface>>InterfaceDefinition
    NewL()~InterfaceDefinition()
    implements
    Implementation 1
    ECom
    instantiates
  • 72. Quiz
    … anyquestions?
    Andreas Jakl, 2009
    72
  • 73. Quiz I
    Whataboutthose UI components:
    Andreas Jakl, 2009
    73
    Optionsmenu
    Window-Owning
    Container in AvkonView-Architecture
    Window-Owning
    Compound Control
    Label-Control
    Window-Owning
    Compound Control
  • 74. Quiz I – Solution
    Whataboutthose UI components:
    Andreas Jakl, 2009
    74
    Optionsmenu

    Window-Owning
    Container in AvkonView-Architecture


    Window-Owning
    Compound Control
    Label-Control
    Window-Owning
    Compound Control
  • 75. Quiz II
    Which application architectures are created through the following Carbide.c++ wizards?
    Andreas Jakl, 2009
    75
    S60 3.x GUI Application
    Control-based
    Dialog-based
    Avkon-Views
    S60 nth Ed. GUI App. with UI Designer (+ Support view switching)
    Control-based
    Dialog-based
    Avkon-Views
  • 76. Quiz II – Solution
    WhichapplicationarchitecturesarecreatedthroughthefollowingCarbide.c++ wizards?
    Andreas Jakl, 2009
    76
    S60 3.x GUI Application

    Control-based
    Dialog-based
    Avkon-Views
    S60 nth Ed. GUI App. with UI Designer (+ Support viewswitching)

    Control-based
    Dialog-based
    Avkon-Views
  • 77. Quiz III
    … thesedialogsare:
    Andreas Jakl, 2009
    77
    Modal
    Modeless
    Waiting
    Nonwaiting
    Modal
    Modeless
    Waiting
    Nonwaiting
  • 78. Quiz III – Solution
    … thesedialogsare:
    Andreas Jakl, 2009
    78

    Modal
    Modeless

    Waiting
    Nonwaiting

    Modal
    Modeless

    Waiting
    Nonwaiting
  • 79. … let’s move to the Challenges!
    Try it for your own
    Andreas Jakl, 2009
    79