• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Symbian OS - GUI Architectures
 

Symbian OS - GUI Architectures

on

  • 8,500 views

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

Statistics

Views

Total Views
8,500
Views on SlideShare
8,409
Embed Views
91

Actions

Likes
7
Downloads
0
Comments
1

3 Embeds 91

http://www.slideshare.net 89
http://translate.googleusercontent.com 1
http://webcache.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • nice presentation, but cannot download for offline study which would have been great.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Symbian OS - GUI Architectures Symbian OS - GUI Architectures Presentation Transcript

    • Symbian OS
      GUI Architectures
      v2.0c – 01 March 2009
      1
      Andreas Jakl, 2009
    • 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
    • Contents
      GUI Frameworks
      Structure of a GUI application
      Architectures
      Views, Controls, Dialog
      Seperating UI and engine
      MVC
      ECom
      Andreas Jakl, 2009
      3
    • 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
    • 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
    • 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
    • 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
    • UIQ 3
      Since UIQ3 supportfor multiple UI configurations, e.g.:
      Andreas Jakl, 2009
      8
      Softkey-Style
      Pen-Style
    • 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
    • Architecture
      Structure of the UI framework
      Andreas Jakl, 2009
      10
    • 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
    • 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
    • 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
    • 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
    • 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
    • xxkon
      Avkon / Qikon
      S60 / UIQ-specific UI functionality (menu, …)
      Additional controls and adapted / extendedversions of Uikon-controls
      Andreas Jakl, 2009
      16
      WServ
    • Elements of a GUI-Application
      Common
      Andreas Jakl, 2009
      17
    • 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
    • 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
    • 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()
    • 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!
      !
    • 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();
      };
    • 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 );
      };
    • 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
    • AppUi
      Most important functions:
      Andreas Jakl, 2009
      25
      AppUi
    • 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
    • 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
    • Controls
      Build the User Interface using
      Andreas Jakl, 2009
      28
    • 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
    • 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
    • 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
    • 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;
      }
    • 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 );
      }
    • 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();
      }
    • 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
    • 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;
      }
      }
    • 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
    • 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;
      }
    • Control-BasedArchitecture
      The traditional Symbian OS-way
      Andreas Jakl, 2009
      39
    • 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
    • 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
    • Dialog-Based Architecture
      Predefined controls
      Andreas Jakl, 2009
      42
    • Dialogs
      Dialog = Control(s) withpredefinedframeworkfor layout, commandhandling, etc.
      Canbedefinedthroughresourcefiles (instead of in thesourcecode)
      Examples:
      Andreas Jakl, 2009
      43
      Note
      Query Dialog
      List Dialog
      Form
    • 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
    • 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
    • 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
    • Avkon View-Switching Architecture
      The most flexible solution
      Andreas Jakl, 2009
      47
    • Using Views
      Andreas Jakl, 2009
      48
      Application
      Menu View
      Game View
    • 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
    • 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
    • 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
    • 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 );
      }
    • 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
    • View
      Most important functions:
      Andreas Jakl, 2009
      54
      View
    • 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;
      }
    • 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
    • Choosingthe optimal architecture
      When to usewhicharchitecture?
      Andreas Jakl, 2009
      57
    • 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
    • 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
    • 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.
    • 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
    • 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
    • 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
    • UI and Engine
      Code structure
      Andreas Jakl, 2009
      64
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Basic ECom Architecture
      Andreas Jakl, 2009
      71
      Client
      request instance
      <<Interface>>InterfaceDefinition
      NewL()~InterfaceDefinition()
      implements
      Implementation 1
      ECom
      instantiates
    • Quiz
      … anyquestions?
      Andreas Jakl, 2009
      72
    • 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
    • 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
    • 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
    • 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
    • Quiz III
      … thesedialogsare:
      Andreas Jakl, 2009
      77
      Modal
      Modeless
      Waiting
      Nonwaiting
      Modal
      Modeless
      Waiting
      Nonwaiting
    • Quiz III – Solution
      … thesedialogsare:
      Andreas Jakl, 2009
      78

      Modal
      Modeless

      Waiting
      Nonwaiting

      Modal
      Modeless

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