Symbian OS - GUI Architectures

6,970 views

Published 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 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

Published in: Technology, Education
1 Comment
8 Likes
Statistics
Notes
  • nice presentation, but cannot download for offline study which would have been great.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
6,970
On SlideShare
0
From Embeds
0
Number of Embeds
99
Actions
Shares
0
Downloads
0
Comments
1
Likes
8
Embeds 0
No embeds

No notes for slide

Symbian OS - GUI Architectures

  1. 1. Symbian OS<br />GUI Architectures<br />v2.0c – 01 March 2009<br />1<br />Andreas Jakl, 2009<br />
  2. 2. Disclaimer<br />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/ )<br />Respecting the copyright laws, you are allowed to use them:<br />for your own, personal, non-commercial use<br />in the academic environment<br />In all other cases (e.g. for commercial training), please contact andreas.jakl@fh-hagenberg.at<br />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.<br />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. <br />Andreas Jakl, 2009<br />2<br />
  3. 3. Contents<br />GUI Frameworks<br />Structure of a GUI application<br />Architectures<br />Views, Controls, Dialog<br />Seperating UI and engine<br />MVC<br />ECom<br />Andreas Jakl, 2009<br />3<br />
  4. 4. Symbian OS – UI Framework<br />Andreas Jakl, 2009<br />4<br />JavaME<br />Licensee Platforms<br /> S60<br /> UIQ<br />Avkon<br />Qikon<br />UI Framework<br />UI Application Framework<br />UI Toolkit<br />Uikon<br />UI LAF*<br />Cone<br />FEP Base**<br />Application Services Messaging, Browsing, PIM, App. Framework, Data Sync, …<br />Connectivity Services<br />Multimedia & Graphics Services<br />Generic OS Services<br />Comms Services<br />Telephony Services<br />Serial Comm & Short Link Services<br />Networking Services<br />Base Services<br />Kernel Services & Hardware Abstraction<br />** FEP = Front End Processor:Input of characters not directlysupported by hardware keys.<br />* LAF = Look & Feel. Allows changing appearance of Uikon controls without modifying Uikon-code itslef<br />
  5. 5. S60<br />Unified UI platform based on S60<br />Official UI platform of Symbian Foundation<br />Former name: Series 60<br />Touchscreen support with S60 5th Edition<br />Andreas Jakl, 2008<br />5<br />Nokia N97<br />
  6. 6. Series 80<br />Owner: Nokia<br />Designed for:<br />Interaction through full QWERTY-keyboard, joystick and 4 softkeys<br />Has been superseded by S60 (Device: E90)<br />Andreas Jakl, 2009<br />6<br />
  7. 7. UIQ<br />UIQ Technology: Owned by SonyEricsson and Motorola<br />Designed for (since UIQ 3)<br />Supported (in all combinations):<br />Portrait<br />Landscape<br />Pen-Input (Touchscreen)<br />Softkey-Input<br />Applications not closed by users<br />Licensed to: SonyEricsson, Motorola, (BenQ, Arima)<br />Andreas Jakl, 2009<br />7<br />SonyEricsson P1i<br />
  8. 8. UIQ 3<br />Since UIQ3 supportfor multiple UI configurations, e.g.:<br />Andreas Jakl, 2009<br />8<br />Softkey-Style<br />Pen-Style<br />
  9. 9. FOMA<br />Phones for NTT DoCoMo, FOMA = Freedom of Mobile Access ( 3G services)<br />Different manufacturers: Mitsubishi, Fujitsu, SonyEricsson, Sharp, ...<br />Japanese Market<br />Closed feature phones, no Smartphones!<br />Different to European market: Aromas, mobile credit cards, waterproof, capturing promotional data from coupons, fingerprint sensor, GPS not unusual, ...<br />Andreas Jakl, 2009<br />9<br />
  10. 10. Architecture<br />Structure of the UI framework<br />Andreas Jakl, 2009<br />10<br />
  11. 11. Application Architecture<br />Applications typically divided into<br />UI (View)<br />Presents data to the user<br />Engine<br />Manipulates the data<br />Symbian OS application architectures are built based on a clear separation<br />Andreas Jakl, 2009<br />11<br />UI<br />Engine<br />
  12. 12. Structure<br />Andreas Jakl, 2009<br />12<br />Custom applicationimplementation<br />S60 (Avkon) / UIQ (Qikon)-specific implementation<br />WServ<br />Common Symbian OS<br />implementation, sharedfor specific UI Platforms<br />Manages access toscreen and input devices<br />Many abstract classes,<br />define interface for<br />UI framework APIs<br />
  13. 13. Window Server (WServ)<br />Centralised access to the screen and user input devices<br />Tasks:<br />Handles draw-operations for windows and controls<br />Manages which view(s) belongs to which app<br />Forward key/pointer/redraw-events to apps.<br />WServ does not define look & feel!<br />Communication with WServ through CONE using Client/Server-Communication<br />Andreas Jakl, 2009<br />13<br />WServ<br />
  14. 14. AppArc / CONE<br />AppArc = „Application Architecture“<br />Basic application structure<br />Mechanism for sending system information to the application and for saving data (through the file server)<br />CONE = „Control Environment“<br />Framework for creating UI-controls<br />Framework for handling user interface events<br /> Interaction mainly with the Window Server<br />Andreas Jakl, 2009<br />14<br />WServ<br />
  15. 15. Uikon<br />Uikon: Basic UI library<br />All UI applications are based on Uikon<br />Generic, device-independent implementation<br />Can either be used directly – or UI specific controls are available (adapted to the platform: S60, UIQ)<br />Controls called Eikon-controls(e.g. CEikLabel and CEikImage of the Quickstart module)<br />Andreas Jakl, 2009<br />15<br />WServ<br />
  16. 16. xxkon<br />Avkon / Qikon<br />S60 / UIQ-specific UI functionality (menu, …)<br />Additional controls and adapted / extendedversions of Uikon-controls<br />Andreas Jakl, 2009<br />16<br />WServ<br />
  17. 17. Elements of a GUI-Application<br />Common<br />Andreas Jakl, 2009<br />17<br />
  18. 18. Elements of a GUI-App.<br />Common required functionality:<br />UI for displaying information + interaction<br />React to user-initiated events (e.g. select a menu item)<br />React to system events (e.g. redraw)<br />Save / load application data<br />Unique identification to the framework<br />Provide information for the framework (Capabilities, …)<br />Andreas Jakl, 2009<br />18<br />View<br />AppUi / View<br />AppUi<br />Document<br />Application<br />Application<br />
  19. 19. Architecture – Overview<br />Traditional (Control-Based) S60 application:<br />Andreas Jakl, 2009<br />19<br />Many pre-defined controls available (dialogs, forms, lists, ...)<br />Application<br />Engine<br />can be owned by the Document, AppUi or Container<br />CMyApplication<br />CMyDocument<br />CMyAppUi<br />CMyContainer<br />Cone<br />Avkon<br />CAknApplication<br />CAknDocument<br />CAknAppUi<br />CCoeControl<br />Stores application properties<br />Manages persistent data storage<br />Direct events to the correct control (e.g. key input)<br />Compound control that can contain one or more controls= view<br />
  20. 20. Initialisation<br />Andreas Jakl, 2009<br />20<br />Framework<br />(1) E32Main()<br />(2) NewApplication()<br />CMyApplication<br />CMyDocument<br />CMyAppUi<br />(3) &lt;&lt;create&gt;&gt;<br />(4) AppDllUid()<br />(5) CApaDocument* CreateDocumentL()<br />(6) NewL()<br />(7) CEikAppUi* CreateAppUi()<br />(8) AppUiConstructor()<br />
  21. 21. Start<br />E32Main()<br />Entry point for the .exe-file<br />Creates Active Scheduler, connection to File- and Window-Server. Loads libraries and resource files<br />Parameter: Function-pointer to the factory function:<br />NewApplication()<br />Creates and returns Application-class<br />Andreas Jakl, 2009<br />21<br />GLDEF_C TInt E32Main() {<br />return EikStart::RunApplication( NewApplication );<br />}<br />LOCAL_C CApaApplication* NewApplication() {<br />return new CMyApplication;<br />}<br />The cleanup stack doesn’t exist yet, therefore there’s no (ELeave) when creating the object!<br />!<br />
  22. 22. Application<br />Sends UID3 to the framework<br />Has to be identical to UID defined in the .mmp-file<br />Creates Document<br />Functionality of AppUi base classes:<br />Framework can query Capabilities, App.-name<br />Andreas Jakl, 2009<br />22<br />Application<br />class CMyApplication : public CAknApplication {<br />public:<br />TUidAppDllUid() const;<br />protected:<br />CApaDocument* CreateDocumentL();<br />};<br />
  23. 23. Document<br />Represents persistent Data of the application<br />Functions to load and save data in file stores<br />Not used by default in S60 <br />Creates instance of AppUi<br />Andreas Jakl, 2009<br />23<br />Document<br />class CMyDocument : public CAknDocument{<br />public:<br /> static CMyDocument* NewL( CEikApplication& aApp );<br /> virtual ~CMyDocument();<br />// Called by the application framework to create AppUi-Object<br />CEikAppUi* CreateAppUiL();<br />private:<br /> void ConstructL();<br />CMyDocument( CEikApplication& aApp );<br />};<br />
  24. 24. AppUi<br />Creates default view<br />Logic for handling events<br />No direct graphical representation<br />… but owner of Softkey/Title/…-Bar and Views<br />Andreas Jakl, 2009<br />24<br />AppUi<br />CMyAppUi<br />Application specific features<br />Event handling, View construction, …<br />C&lt;variant&gt;AppUi<br />Features common across all apps, eg.: Title bars, Scroll bars, Start up & shut down, Standard soft keys, …<br />CEikAppUi<br />Document handling,Menus & Pop-ups, Screen Area,Resource File<br />CCoeAppUi<br />Control stack, view management, event handling<br />
  25. 25. AppUi<br />Most important functions:<br />Andreas Jakl, 2009<br />25<br />AppUi<br />
  26. 26. View / Container<br />View defined as generic concept for displaying data on the screen<br />S60<br />Three architectures:<br />Control-Based Architecture<br />The view is a control itself<br />Dialog-Based Architecture<br />Avkon View-Switching Architecture<br />View = additional layer in between AppUi and Controls<br />UIQ<br />Recommended: view based<br />Andreas Jakl, 2009<br />26<br />View<br />
  27. 27. App Startup (S60 Views)<br />Andreas Jakl, 2009<br />27<br />CreateDocumentL()<br />CreateAppUiL()<br />ConstructL()<br />DoActivateL()<br />RunApplication<br />Avkon View SwitchingApplication<br />CMyApplication<br />CMyDocument<br />CMyAppUi<br />CMyView1<br />CMyContainer1<br />Avkon<br />CAknViewAppUi<br />CAknApplication<br />CAknDocument<br />CAknView<br />CAknAppUi<br />CAknAppUiBase<br />Uikon<br />CEikAppUi<br />CEikDocument<br />CEikApplication<br />Cone<br />AppArc<br />CCoeAppUi<br />CApaDocument<br />CApaApplication<br />CCoeControl<br />
  28. 28. Controls<br />Build the User Interface using<br />Andreas Jakl, 2009<br />28<br />
  29. 29. Control<br />Control = “Empty Canvas”<br />Rectangular area of a window<br />Can react to user input<br />e.g. views, buttons, menus, nearly all UI controls, …<br />Two types:<br />Simple Control: Does not contain other controls<br />Container/Compound Control: Contains and owns other controls<br />Andreas Jakl, 2009<br />29<br />CCoeControl<br />
  30. 30. Compound Controls<br />Parent control contains child controls, e.g.:<br />main & window-owning control contains application content (label controls, image controls, ...)<br />complex control made out of sub-controls (custom menu made out of multiple labels)<br />Andreas Jakl, 2009<br />30<br />
  31. 31. Compound Controls<br />Old way (pre-Symbian OS 9.1)<br />Compound control (=parent) saves component controls (=children) as instance variables<br />Compound Control has to override two functions:<br />TIntCCoeControl::CountComponentControls()Returns the number of contained component controls<br />CCoeControl* CCoeControl::ComponentControl(TIntaIndex)Returns the component control with the specified index<br />Andreas Jakl, 2009<br />31<br />
  32. 32. Old Way – Example <br />Andreas Jakl, 2009<br />32<br />TIntCMyContainer::CountComponentControls() const<br />{<br />// Return the number of controls this compound control (container) contains<br />return 2;<br />}<br />CCoeControl* CMyContainer::ComponentControl( TIntaIndex ) const<br />{<br />// Return the component control with the specified index<br />switch ( aIndex )<br />{<br />case 0:<br />return iLabel;<br />case 1:<br />return iImage;<br />}<br />return NULL;<br />}<br />
  33. 33. Compound Controls – New!<br />Simplified control handling – base class does the counting and cleanup work!<br />Available since Symbian OS 9.1<br />Andreas Jakl, 2009<br />33<br />void CMyContainer::ConstructL()<br />{<br />// Initialize the component array, which is defined by the CCoeControl base class<br />InitComponentArrayL();<br />// Construct all the new component controls and add them to the component array<br />CComponent* myComponent = new (ELeave) CComponent();<br />Components().AppendLC( myComponent ); // or InsertLC or InsertAfterLC(). Places item on cleanup stack.<br />myComponent-&gt;ConstructL();<br />// [Initialize the control...]<br />CleanupStack::Pop( myComponent ); <br />}<br />
  34. 34. Control<br />Window-Owning<br />View of the application is window-owning (CreateWindowL() is called in ConstructL())<br />Window has 1..1-Relationship to window-owning control<br />e.g. dialogs, menus, toolbars, top-level controls<br />Non-Window-Owning (or “lodger” controls)<br />Use window owned by the parent control (SetContainerWindowL() is called in ConstructL())<br />Controls may not overlap<br />More efficient: less Client/Server-traffic to the Window Server<br />e.g. command buttons, text boxes, labels<br />Andreas Jakl, 2009<br />34<br />Window = area of the screen, owned by the Window Server<br />CCoeControl<br />void CHourPowerAppView::ConstructL( const TRect& aRect )<br /> {<br />// Create a window for this application view<br />CreateWindowL();<br />// Set the windows size<br />SetRect( aRect );<br />// Activate the window, which makes it <br /> // ready to be drawn<br />ActivateL();<br /> }<br />
  35. 35. Control Stack<br />Control Stack (owned by AppUi) contains list of all controls that would like to receive keyboard events<br />Adding a control to the stack: CCoeAppUi::AddToStackL()<br />Order of controls on the stack depends on:<br />Priority<br />Same priority: order of putting on the stack<br />Andreas Jakl, 2009<br />35<br />CCoeControl<br />
  36. 36. Control Stack – Example<br />Andreas Jakl, 2009<br />36<br />void CMyAppUi::ConstructL()<br />{<br /> // Initialize the AppUi with standard values (-&gt; Resource file)<br />BaseConstructL( EAknEnableSkin );<br />// Create the main compound control that will own the window<br />iMyContainer = CMyContainer::NewL( ClientRect(), NULL, this );<br />// Define that the parant of the control is the AppUi<br />iMyContainer-&gt;SetMopParent( this );<br />// Add the control to the AppUi’s Control Stack<br />AddToStackL( iMyContainer );<br />}<br />CMyAppUi::~CMyAppUi()<br />{<br /> if ( iMyContainer != NULL )<br /> {<br />// Remove the control from the Control Stack<br />RemoveFromStack( iMyContainer );<br /> delete iMyContainer;<br />iMyContainer = NULL;<br /> }<br />}<br />
  37. 37. Control Stack<br />Andreas Jakl, 2009<br />37<br />CCoeControl<br />Starting at stack pos. 0, events are offered to each control until they are consumed by a control<br />Most of the time App. view or dialogs are Compound Controls<br /> Distribute key press events depending on keyboard focus<br />Stack position 0<br />Events<br />Controls put on the stack in the order: A, B, C, D<br />
  38. 38. Handling Key Events<br />Andreas Jakl, 2009<br />38<br />TKeyResponseCMyContainer::OfferKeyEventL(const TKeyEvent& aKeyEvent, TEventCodeaType)<br />{<br />// Default: We did not consume the key, framework will forward the events to other controls<br />TKeyResponse ret = EKeyWasNotConsumed;<br /> if (aType == EEventKey)<br /> {<br /> switch (aEventKey.iCode)<br /> {<br /> case EKeyLeftArrow:<br />// Handle the key event...<br /> // We have handled the event, make sure it is not handled by multiple controls!<br />ret = EKeyWasConsumed;<br /> break;<br />//...<br /> }<br /> }<br />return ret;<br />}<br />
  39. 39. Control-BasedArchitecture<br />The traditional Symbian OS-way<br />Andreas Jakl, 2009<br />39<br />
  40. 40. Control-Based Architecture<br />AppUi<br />Direct owner of view-controls(those are derived from CCoeControl)<br />Control has its own class (called Container or View), it can contain additional controls (= Compound Control)<br />AppUi is responsible for changing displayed content((de)activate container)<br />Child-Parent-Relationship defined through Container::SetMopParent() <br />Self-made view-switching possible: through AddToStack() and RemoveFromStack()<br />Andreas Jakl, 2009<br />40<br />
  41. 41. Avkon<br />Control-BasedArchitecture<br />Andreas Jakl, 2009<br />41<br />Control-BasedApplicationArchitecture<br />CMyApplication<br />CMyDocument<br />CMyAppUi<br />CMyContainer1<br />CMyContainer1<br />CAknApplication<br />CAknDocument<br />CAknAppUi<br />CAknAppUiBase<br />Uikon<br />CEikAppUi<br />CEikDocument<br />CEikApplication<br />Cone<br />AppArc<br />CCoeAppUi<br />CApaDocument<br />CApaApplication<br />CCoeControl<br />
  42. 42. Dialog-Based Architecture<br />Predefined controls<br />Andreas Jakl, 2009<br />42<br />
  43. 43. Dialogs<br />Dialog = Control(s) withpredefinedframeworkfor layout, commandhandling, etc.<br />Canbedefinedthroughresourcefiles (instead of in thesourcecode)<br />Examples:<br />Andreas Jakl, 2009<br />43<br />Note<br />Query Dialog<br />List Dialog<br />Form<br />
  44. 44. Dialog-Based Architecture<br />Predefined dialogs for common use cases:<br />Data display<br />-entry<br />-editing<br />Less development work than when directly using controls<br />Dialog automatically manages its child controls<br />Multipage dialogs possible (e.g. with tabs)<br />Example: settings application<br />Andreas Jakl, 2009<br />44<br />
  45. 45. Dialogs<br />Most important properties:<br />Modal: Prevents interaction with the rest of the app as long as it is active (e.g. note)<br />Modeless: Interaction with other parts of the UI is possible (e.g. main view in a dialog based architecture)<br />Waiting: App. is paused as long as the dialog is displayed (e.g. simple text query dialog)<br />Nonwaiting: App. continues while dialog is shown (e.g. progress note)<br />Andreas Jakl, 2009<br />45<br />
  46. 46. Avkon<br />Dialog-BasedArchitecture<br />Andreas Jakl, 2009<br />46<br />Dialog-BasedApplicationArchitecture<br />CMyApplication<br />CMyDocument<br />CMyAppUi<br />CMyDialog<br />CAknApplication<br />CAknDocument<br />CAknAppUi<br />CAknDialog<br />CAknAppUiBase<br />Uikon<br />CEikDialog<br />CEikAppUi<br />CEikDocument<br />CEikApplication<br />CEikBordererdControl<br />Cone<br />AppArc<br />CCoeAppUi<br />CApaDocument<br />CApaApplication<br />CCoeControl<br />
  47. 47. Avkon View-Switching Architecture<br />The most flexible solution<br />Andreas Jakl, 2009<br />47<br />
  48. 48. Using Views<br />Andreas Jakl, 2009<br />48<br />Application<br />Menu View<br />Game View<br />
  49. 49. Avkon View-Switching Archit.<br />Views represent different pages of the application<br />Application registers views with the view server<br />View Server takes responsibility for managing views from the AppUi<br />Application can activate / deactivate views through the view server<br />Only one view can be active at the same time<br />Allows different data representation based on the current task of the user<br />Andreas Jakl, 2009<br />49<br />
  50. 50. Why Views?<br />Each view is an own object<br />Encapsulates data and functions<br />Own activation / deactivation functions<br />Views = modules: Application can easily be adapted for future modifications<br />Views from external applications<br />Allows access to views of other applications(e.g. contact list, video playback, ...)<br />Reduces complexity of individual applications<br />Andreas Jakl, 2009<br />50<br />
  51. 51. Avkon View-Switching Archit.<br />Differences to Control-Based Architecture:<br />Additional class in-between AppUi and Container: CAknView Each view handles its own events (like small AppUi)<br />AppUi derived from CAknViewAppUi (instead of CAknAppUi)  manages views, delegates drawing and interaction<br />Andreas Jakl, 2009<br />51<br />Avkon-ViewBased<br />Container (Compound Control)<br />CAknView<br />Control<br />CAknViewAppUi<br />CAknView<br />Control<br />Container (Control)<br />View Server<br />
  52. 52. Example<br />Creating two views, setting the first as default<br />Andreas Jakl, 2009<br />52<br />void CViewTestAppUi::ConstructL()<br />{<br />// Initialize the AppUi with standard values<br />BaseConstructL( EAknEnableSkin );<br />// Construct the first view<br />iViewTestContainerView = CViewTestContainerView::NewL();<br />// Registers the view and adds it to the AppUi<br />AddViewL( iViewTestContainerView );<br />// Set the first view as the initial view<br />SetDefaultViewL( *iViewTestContainerView );<br />// Construct and register the second view<br />iViewTestFormView = CViewTestFormView::NewL();<br />AddViewL( iViewTestFormView );<br />}<br />
  53. 53. Switching Views<br />Handled by the AppUi<br />Local view switching<br />Activates another view of the same application, deactivates the current view<br />Specify the new view through its UID<br />CAknViewAppUi::ActivateLocalViewL(TUidaViewId)<br />Remote view switching<br />Activate a view in another application<br />Specify the UID of target application and target view<br />CCoeAppUi::ActivateViewL(const TVwsViewId& aViewId)<br />Andreas Jakl, 2009<br />53<br />
  54. 54. View<br />Most important functions:<br />Andreas Jakl, 2009<br />54<br />View<br />
  55. 55. View – Menu <br />Each view has associated resource<br />Defines menu<br />and/or Command Button Array (CBA)<br />Commands are passed in this order:<br />HandleCommandL() of the active view<br />AppUi::HandleCommandL()<br />Andreas Jakl, 2009<br />55<br />&lt;yourapp&gt;.rss<br />RESOURCE AVKON_VIEW r_my_view<br />{<br />cba = R_AVKON_SOFTKEYS_OPTIONS_EXIT;<br />menubar = r_my_options_menu;<br />}<br />
  56. 56. Avkon<br />Architechture – S60 Views<br />Andreas Jakl, 2009<br />56<br />Avkon View SwitchingApplication<br />CMyApplication<br />CMyDocument<br />CMyAppUi<br />CMyView1<br />CMyContainer1<br />CAknViewAppUi<br />CAknApplication<br />CAknDocument<br />CAknView<br />CAknAppUi<br />Container(s) contain visible content<br />CAknAppUiBase<br />Uikon<br />CEikAppUi<br />CEikDocument<br />CEikApplication<br />Cone<br />AppArc<br />CCoeAppUi<br />CApaDocument<br />CApaApplication<br />CCoeControl<br />
  57. 57. Choosingthe optimal architecture<br />When to usewhicharchitecture?<br />Andreas Jakl, 2009<br />57<br />
  58. 58. ControlBased<br />Architectures – Overview<br />Andreas Jakl, 2009<br />58<br />Compound Control<br />Control<br />AppUi<br />Control<br />Control<br />Dialog Based<br />Control<br />Dialog<br />AppUi<br />Dialog<br />Control<br />…<br />Avkon-ViewBased<br />Container (Compound Control)<br />View<br />Control<br />AppUi<br />View<br />Control<br />Container (Control)<br />View Server<br />
  59. 59. Control Based?<br />Use if:<br />Application only needs one view<br />Unlikely that other apps will want to access your view<br />Porting from other Symbian OS platforms that do not use the view concept<br />Andreas Jakl, 2009<br />59<br />
  60. 60. Dialog Based?<br />Use if:<br />(Nearly) all screens of the app. are dialogs (e.g. lists are dialogs as well!)<br />No cyclic navigation paths allowed!<br />Disadvantage: Dialogs not so good for communication with AppUi<br />Most of the time a dialog is a self-contained system, returns after dialog is dismissed<br />Andreas Jakl, 2009<br />60<br />Multipage-Dialog<br />1a<br />1b<br />2<br />3<br />4<br />Navigation 1a  2  1b  1anot allowed! Dialog 1a would beinstantiated twice.Rule: After navigating downwardsin the hierarchy, return through thesame path when navigating upwards.<br />
  61. 61. Avkon View-Switching?<br />Allows access to views of other applications<br />e.g. user gets an email, wants to save address of sender  messaging-app. calls view of the contacts-app.<br />Use if:<br />Other programs should be able to access your views (if more complex interactions are required: views not enough, Client/Server should be used)<br />If there are no good reasons for using other architectures<br />Andreas Jakl, 2009<br />61<br />
  62. 62. Mixing Architectures<br />In many cases this is the optimal solution<br />e.g. combine Dialog-based architecture with others<br />Dialogs are used for general navigation or simpler screens, custom views implemented with View-architecture<br />Andreas Jakl, 2009<br />62<br />
  63. 63. Architecture – UIQ 3<br />... more about UIQ in an individual module!<br />Andreas Jakl, 2009<br />63<br />UIQ Application<br />CMyApplication<br />CMyDocument<br />CMyAppUi<br />CMyView<br />Qikon<br />CQikApplication<br />CQikDocument<br />CQikViewBase<br />CQikAppUi<br />Uikon<br />CEikAppUi<br />CEikDocument<br />CEikApplication<br />(…)<br />Cone<br />AppArc<br />CCoeAppUi<br />CApaDocument<br />CApaApplication<br />CCoeControl<br />
  64. 64. UI and Engine<br />Code structure<br />Andreas Jakl, 2009<br />64<br />
  65. 65. Model View Controller Pattern<br />Model: Contains and manipulates data in the app.<br />View: Defines representation of data. Forwards events to the controller.<br />Controller: Defines how the UI should react to commands and requests<br />Andreas Jakl, 2009<br />65<br />
  66. 66. Model<br />Out-source data and algorithms to the model (engine)<br />MVC-Pattern: AppUi = Controller<br />Additional Controller (e.g. when the engine has its own asynchronous services)<br />Andreas Jakl, 2009<br />66<br />Application<br />Document<br />AppUi<br />View<br />1<br />1<br />1<br />1<br />Model<br />Application<br />Document<br />AppUi<br />View<br />1<br />1<br />1<br />1<br />1<br />Controller<br />Model<br />
  67. 67. Seperating UI / Engine<br />Engine:<br />Algorithms for managing and processing data<br />Routines for loading and saving<br />e.g. Chess: status of the board, rules for movement, AI<br />UI:<br />Displays data for the user<br />Transfers user-requests to the engine<br />e.g. Chess: representation of the game status, user interaction<br />Andreas Jakl, 2009<br />67<br />
  68. 68. Seperating UI / Engine<br />Advantages:<br />Prevent unnecessary dependencies<br />Maximise code reuse<br />Parallel development of UI and engine<br />Good application structure<br />Implementation:<br />Put engine in its own dll or .exe-server<br />or: ECom-Plugin<br />Andreas Jakl, 2009<br />68<br />
  69. 69. ECom (Short Overview)<br />Shared DLLs<br />Platform Security – Data Caging: Access not so easy<br />ECom (Epoc Component Object Model)<br />Generic framework, manages plug-ins<br />Built using Client/Server architecture<br />Plug-in registers itself at ECom<br />Your code is in a dll<br />Data (name, ID, …) and connection interface/implementation defined through resource file<br />Andreas Jakl, 2009<br />69<br />
  70. 70. ECom<br />Client requests implementation of an interface<br />Through UID or text (name of the implementation)<br />ECom searches through its saved meta-information database, returns best results („resolution“)<br />ECominstantiates desired object through its factory function, loads object in the process of the client<br />ECom uses reference counting for resource management<br />Andreas Jakl, 2009<br />70<br />
  71. 71. Basic ECom Architecture<br />Andreas Jakl, 2009<br />71<br />Client<br />request instance<br />&lt;&lt;Interface&gt;&gt;InterfaceDefinition<br />NewL()~InterfaceDefinition()<br />implements<br />Implementation 1<br />ECom<br />instantiates<br />
  72. 72. Quiz<br />… anyquestions?<br />Andreas Jakl, 2009<br />72<br />
  73. 73. Quiz I<br />Whataboutthose UI components:<br />Andreas Jakl, 2009<br />73<br />Optionsmenu<br />Window-Owning<br />Container in AvkonView-Architecture<br />Window-Owning<br />Compound Control<br />Label-Control<br />Window-Owning<br />Compound Control<br />
  74. 74. Quiz I – Solution<br />Whataboutthose UI components:<br />Andreas Jakl, 2009<br />74<br />Optionsmenu<br /><br />Window-Owning<br />Container in AvkonView-Architecture<br /><br /><br />Window-Owning<br />Compound Control<br />Label-Control<br />Window-Owning<br />Compound Control<br />
  75. 75. Quiz II<br />Which application architectures are created through the following Carbide.c++ wizards?<br />Andreas Jakl, 2009<br />75<br />S60 3.x GUI Application<br />Control-based<br />Dialog-based<br />Avkon-Views<br />S60 nth Ed. GUI App. with UI Designer (+ Support view switching)<br />Control-based<br />Dialog-based<br />Avkon-Views<br />
  76. 76. Quiz II – Solution<br />WhichapplicationarchitecturesarecreatedthroughthefollowingCarbide.c++ wizards?<br />Andreas Jakl, 2009<br />76<br />S60 3.x GUI Application<br /><br />Control-based<br />Dialog-based<br />Avkon-Views<br />S60 nth Ed. GUI App. with UI Designer (+ Support viewswitching)<br /><br />Control-based<br />Dialog-based<br />Avkon-Views<br />
  77. 77. Quiz III<br />… thesedialogsare:<br />Andreas Jakl, 2009<br />77<br />Modal<br />Modeless<br />Waiting<br />Nonwaiting<br />Modal<br />Modeless<br />Waiting<br />Nonwaiting<br />
  78. 78. Quiz III – Solution<br />… thesedialogsare:<br />Andreas Jakl, 2009<br />78<br /><br />Modal<br />Modeless<br /><br />Waiting<br />Nonwaiting<br /><br />Modal<br />Modeless<br /><br />Waiting<br />Nonwaiting<br />
  79. 79. … let’s move to the Challenges!<br />Try it for your own<br />Andreas Jakl, 2009<br />79<br />

×