The document provides an overview of Symbian OS GUI architectures, including the control-based architecture and Avkon framework. It discusses key elements like controls, compound controls, the control stack, and handling user input. The traditional Symbian approach uses control-based views owned by the AppUi, with child-parent relationships and view switching via stack methods. Avkon is the standard framework for building control-based UIs on S60.

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