Dialog-Based Architecture - free Symbian OS tutorials

Symbian OS 

GUI Architectures 

1 Andreas Jakl, 2008 

v2.0b – 22 May 2008

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. 

2 

Andreas Jakl, 2008

Contents 

● GUI Frameworks 

● Structure of a GUI application 

● Architectures 

Views, Controls, Dialog 

● Seperating UI and engine 

3 

MVC 

ECom 

Andreas Jakl, 2008

4 

Symbian OS – UI Framework 

UI Toolkit 

UI Framework 

Application Services 

Messaging, Browsing, PIM, App. Framework, Data Sync, … 

Generic OS 

Services 

Telephony 

Services 

Licensee Platforms 

S60 Avkon UIQ Qikon 

** FEP = Front End Processor: 

Input of characters not directly 

supported by hardware keys. 

UI Application Framework 

Uikon UI LAF* Cone FEP Base** 

Comms Services 

Serial Comm & 

Short Link 

Services 

Base Services 

Networking 

Services 

Kernel Services & Hardware Abstraction 

Andreas Jakl, 2008 

Multimedia 

& Graphics 

Services 

JavaME 

Connectivity 

Services 

* LAF = Look & Feel. Allows changing 

appearance of Uikon controls without 

modifying Uikon-code itslef

5 

S60 (previously: Series 60) 

Nokia N96 

● Owner: Nokia 

● Licensed to: Samsung, LG, 

Panasonic, Lenovo 

● Designed for: 


One-handed use 

No touch screen, however: 

– 2 softkeys, 5-way navigation 

(4 directions + center), number-keys, 

special keys (menu) 

Portrait and landscape 

● Touch-Screen support starting 

with S60 5.0

6 

Series 80 


● Owner: Nokia 

● Designed for: 

Interaction through full 

QWERTY-keyboard, joystick 

and 4 softkeys 

● Has been superseded by 

S60 (Device: E90)

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) 

7 


SonyEricsson P1i

UIQ 3 

● Since UIQ3 support for multiple UI configurations, e.g.: 

8 

Pen-Style 


Softkey-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, ... 

9 

Andreas Jakl, 2008

Structure of the UI framework 

Architecture 

10 

Andreas Jakl, 2008

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 

11 

Andreas Jakl, 2008

Structure 

Custom application 

implementation 

S60 (Avkon) / UIQ (Qikon)specific 

implementation 

Common Symbian OS 

implementation, shared 

for specific UI Platforms 

Many abstract classes, 

define interface for 

UI framework APIs 

12 


Manages access to 

screen and input devices

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 

13 


Application 

xkon 

Uikon 

AppArc CONE 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“ 

14 

Framework for creating UI-controls 

Framework for handling user interface events 

Interaction mainly with the Window Server 


Application 

xkon 

Uikon 

AppArc CONE WServ

Uikon 

● Uikon: Basic UI library 

15 

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) 


Application 

xkon 

Uikon 

AppArc CONE WServ

xxkon 

● Avkon / Qikon 

16 

S60 / UIQ-specific UI functionality (menu, …) 

Additional controls and adapted / extended versions of 

Uikon-controls 


Application 

xkon 

Uikon 

AppArc CONE WServ

Common 

Elements of a GUI-Application 

17 

Andreas Jakl, 2008

Elements of a GUI-App. 

● Common required functionality: 

18 

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, …) 


View 

AppUi / View 

AppUi 

Document 

Application 

Application

Architecture – Overview 

● Traditional (Control-Based) S60 application: 

Application 

Avkon 

19 

CMyApplication 


Cone 

CAknApplication CAknDocument CAknAppUi CCoeControl 

Stores 

application 

properties 

Engine 

can be owned by the Document, AppUi or Container 

CMyDocument CMyAppUi CMyContainer 

Manages 

persistent data 

storage 

Direct events to 

the correct 

control 

(e.g. key input) 

Many pre-defined 

controls available 

(dialogs, forms, lists, ...) 

Compound 

control that can 

contain one or 

more controls 

= view

Framework 

20 

Initialisation 

(1) E32Main() 

(2) NewApplication() 

(3) 

(4) AppDllUid() 

(5) CApaDocument* 

CreateDocumentL() (6) NewL() 

(7) CEikAppUi* CreateAppUi() 

CMyApplication CMyDocument CMyAppUi 


(8) AppUi Constructor()

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() 

21 

GLDEF_C TInt E32Main() { 

return EikStart::RunApplication( NewApplication ); 

} 

LOCAL_C CApaApplication* NewApplication() { 

return new CMyApplication; 

} 

Creates and returns Application-class 

The cleanup stack doesn’t exist 

yet, therefore there’s no (ELeave) 

when creating the object! 

Andreas Jakl, 2008

Application 

● Sends UID3 to the framework 

Has to be identical to UID defined in the .mmp-file 

● Creates Document 

● Functionality of AppUi base classes: 

22 

Framework can query Capabilities, App.-name 

class CMyApplication : public CAknApplication { 

public: 

TUid AppDllUid() const; 

protected: 

CApaDocument* CreateDocumentL(); 

}; 


Application

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 

23 

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 ); 

}; 


Document

AppUi 

● Creates default view 

● Logic for handling events 

● No direct graphical 

representation 

24 

… but owner of 

Softkey/Title/…-Bar and 

Views 


CMyAppUi 

Application specific features 

Event handling, View construction, … 

CAppUi 

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

AppUi 

● Most important functions: 

Function Description 

HandleCommandL() Called when the user issues commands (menu command events). 

May be the only event-handling function that is implemented. 

25 


AppUi 

HandleKeyEvent() Handling user key presses, when no other control on the control stack has 

already handled it. 

HandleForegroundEventL() Called when application switches to or from the foreground. 

(Default: Keyboard-focus) 

DynInitMenuPaneL() Called right before the application menu is displayed. Allows the 

application to modify the contents of the menu on the fly, e.g. by hiding 

currently unnecessary options – not used anymore in UIQ 3.

View / Container 

● View defined as generic concept for displaying data on the 

screen 

● S60 

● UIQ 

26 

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 

Recommended: view based 


View

RunApplication 

Avkon 

Uikon 

AppArc 

27 

App Startup (S60 Views) 

CMyApplication CMyDocument CMyAppUi CMyView1 CMyContainer1 

CAknApplication CAknDocument 

CEikApplication 

CreateDocumentL() CreateAppUiL() ConstructL() DoActivateL() 

Avkon View Switching Application 

CEikDocument 

CAknViewAppUi 

Cone 

CAknAppUi 

CAknAppUiBase 

CEikAppUi 


CAknView 

CApaApplication CApaDocument CCoeAppUi 

CCoeControl

Build the User Interface using 

Controls 

28 

Andreas Jakl, 2008

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: 

29 

Simple Control: Does not contain other controls 

Container/Compound Control: Contains and owns other 

controls 


CCoeControl

Compound Controls 

● Parent control contains 

child controls, e.g.: 

30 

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, 2008


● Old way (pre-Symbian OS 9.1) 

31 

Compound control (=parent) saves 

component controls (=children) as instance variables 

Compound Control has to override two functions: 

– TInt CCoeControl::CountComponentControls() 

Returns the number of contained component controls 

– CCoeControl* CCoeControl::ComponentControl(TInt aIndex) 

Returns the component control with the specified index 

Andreas Jakl, 2008

32 

Old Way – Example 

TInt CMyContainer::CountComponentControls() const 

{ 

// Return the number of controls this compound control (container) contains 

return 2; 

} 

CCoeControl* CMyContainer::ComponentControl( TInt aIndex ) const 

{ 

// Return the component control with the specified index 

switch ( aIndex ) 

{ 

case 0: 

return iLabel; 

case 1: 

return iImage; 

} 

return NULL; 

} 

Andreas Jakl, 2008

Compound Controls – New! 

● Simplified control handling – base class does the 

counting and cleanup work! 

● Available since Symbian OS 9.1 

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 ); 

33 

Andreas Jakl, 2008

Control 

● Window-Owning 

View of the application is windowowning 

(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) 

34 

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 


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: 

35 

Priority 

Same priority: order of putting on the stack 


CCoeControl

36 

Control Stack – Example 

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; 

} 

} 

Andreas Jakl, 2008

Control Stack 

● 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 


37 

Distribute key press 

events depending on 

keyboard focus 

Events 


ECoeStackPriorityDefault (=0) 

ECoeStackPriorityMenu (=10) 

ECoeStackPriorityDialog (=50) 

ECoeStackPriorityDialog (=50) 

CCoeControl 

Control X 

Control Y 

Keyboard Focus 

Control Z 

Stack position 0 

Controls put on the stack in the order: A, B, C, D

Handling Key Events 

TKeyResponse CMyContainer::OfferKeyEventL(const TKeyEvent& aKeyEvent, TEventCode aType) 

{ 

// 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; 

38 

Andreas Jakl, 2008

The traditional Symbian OS-way 

Control-Based Architecture 

39 

Andreas Jakl, 2008

● 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() 

40 

Andreas Jakl, 2008

Avkon 

Uikon 

AppArc 

41 


Control-Based Application Architecture 

CMyApplication CMyDocument CMyAppUi CMyContainer1 

CMyContainer1 

CAknApplication CAknDocument CAknAppUi 


CEikDocument 

CAknAppUiBase 

Cone 

CEikAppUi 


CCoeControl 

Andreas Jakl, 2008

Predefined controls 

Dialog-Based Architecture 

42 

Andreas Jakl, 2008

Dialogs 

● Dialog = Control(s) with predefined framework for layout, 

command handling, etc. 

● Can be defined through resource files (instead of in the 

source code) 

● Examples: 

43 

Note Query Dialog List Dialog Form 

Andreas Jakl, 2008


● 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 

44 

Andreas Jakl, 2008

Dialogs 

● Most important properties: 

45 

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, 2008

Avkon 

Uikon 

AppArc 

46 


Dialog-Based Application Architecture 

CMyApplication CMyDocument CMyAppUi 

CAknApplication CAknDocument CAknAppUi 


CEikDocument 

CAknAppUiBase 

Cone 

CEikAppUi 

CApaApplication CApaDocument CCoeAppUi CCoeControl 


CMyDialog 

CAknDialog 

CEikDialog 

CEikBordererd 

Control

The most flexible solution 

Avkon View-Switching Architecture 

47 

Andreas Jakl, 2008

48 

Using Views 

Menu View Game View 

Andreas Jakl, 2008

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 

49 

Andreas Jakl, 2008

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 

50 

Allows access to views of other applications 

(e.g. contact list, video playback, ...) 

Reduces complexity of individual applications 

Andreas Jakl, 2008

Avkon View-Switching Archit. 

● Differences to Control-Based Architecture: 

Avkon-View Based 

CAknViewAppUi 

51 

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 

View Server 

CAknView 

CAknView 


Container 

(Compound 

Control) 

Container 

(Control) 

Control 

Control

Example 

● Creating two views, setting the first as default 

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 ); 

Andreas Jakl, 2008

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(TUid aViewId) 

● Remote view switching 

53 

Activate a view in another application 

Specify the UID of target application and target view 

CCoeAppUi::ActivateViewL(const TVwsViewId& aViewId) 

Andreas Jakl, 2008

View 

● Most important functions: 

Function Description 

Construction ConstructL() – passes the view ID to the base class. 

Destruction Same functionality as DoDeactivate() 

DoActivateL() Called on view activation. Creates view’s containers and adds it to the 

AppUi’s stack. 

DoDeactivate() Called on view deactivation: When the application exits or another view is 

activated (only one view can be active at a time). Deletes the view’s 

container, removes it from the AppUi’s stack. Must not leave! 

Id() Returns the unique ID of the view (defined in its header-file) 

HandleForegroundEventL 

(TBool aForeground) 

54 

Parameter: ETrue when the application moves to the foreground. 

HandleCommandL(...) Handle commands from menus / soft keys 


View

View - Menu 

● Each view has associated resource 

Defines menu 

and/or Command Button Array (CBA) 

● Commands are passed in this order: 

1. HandleCommandL() of the active view 

2. AppUi::HandleCommandL() 

55 

.rss 

RESOURCE AVKON_VIEW r_my_view 

{ 

cba = R_AVKON_SOFTKEYS_OPTIONS_EXIT; 

menubar = r_my_options_menu; 

} 

Andreas Jakl, 2008

Avkon 

Uikon 

AppArc 

56 

Architechture – S60 Views 

Avkon View Switching Application 

CMyApplication CMyDocument CMyAppUi CMyView1 CMyContainer1 

CAknApplication CAknDocument 


CEikDocument 

CAknViewAppUi 

Cone 

CAknAppUi 

CAknAppUiBase 

CEikAppUi 


CAknView 

Container(s) 

contain visible 

content 


CCoeControl

When to use which architecture? 

Choosing the optimal architecture 

57 

Andreas Jakl, 2008

Control Based 

AppUi 

Dialog Based 

AppUi 

Avkon-View Based 

AppUi 

58 

Architectures – Overview 

View Server 

Compound 

Control 

Control 

Dialog 

Dialog 

View 

View 

… 


Control 

Control 

Control 

Control 

Container 

(Compound 

Control) 

Container 

(Control) 

Control 

Control

● Use if: 

59 

Control Based? 

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, 2008

● Use if: 

Dialog Based? 

(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 

60 

Most of the time a dialog is a 

self-contained system, returns 

after dialog is dismissed 


Multipage-Dialog 

1a 1b 

2 

3 4 

Navigation 1a 2 1b 1a 

not allowed! Dialog 1a would be 

instantiated twice. 

Rule: After navigating downwards 

in the hierarchy, return through the 

same path when navigating upwards.

Avkon View-Switching? 

● Allows access to views of other applications 

● Use if: 

61 

e.g. user gets an email, wants to save address of sender 

messaging-app. calls view of the contacts-app. 

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, 2008

Mixing Architectures 

● In many cases this is the optimal solution 

62 

e.g. combine Dialog-based architecture with others 

Dialogs are used for general navigation or simpler 

screens, custom views implemented with Viewarchitecture 

Andreas Jakl, 2008

Qikon 

Uikon 

AppArc 

Architecture – UIQ 3 

● ... more about UIQ in an individual module! 

UIQ Application 

CMyApplication CMyDocument CMyAppUi CMyView 

CQikApplication CQikDocument CQikAppUi CQikViewBase 


63 

CEikDocument 

Cone 

CEikAppUi 

CApaApplication CApaDocument CCoeAppUi CCoeControl 


(…)

Code structure 

UI and Engine 

64 

Andreas Jakl, 2008

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 

65 

View 

Controller 


Model

Model 

● Out-source data and algorithms to the model (engine) 

● MVC-Pattern: AppUi = Controller 

Application 

1 

Document 

1 

1 

AppUi 

1 

View 

● Additional Controller (e.g. when the engine has its own 

asynchronous services) 

66 

Model 

Application 

1 

Document 

1 

AppUi 

1 

View 

1 

1 

Model 


Controller

● Engine: 

● UI: 

67 

Seperating UI / Engine 

Algorithms for managing and processing data 

Routines for loading and saving 

e.g. Chess: status of the board, rules for movement, AI 

Displays data for the user 

Transfers user-requests to the engine 

e.g. Chess: representation of the game status, user 

interaction 

Andreas Jakl, 2008

Seperating UI / Engine 

● Advantages: 

Prevent unnecessary dependencies 

Maximise code reuse 

Parallel development of UI and engine 

Good application structure 

● Implementation: 

68 

Put engine in its own dll or .exe-server 

or: ECom-Plugin 

Andreas Jakl, 2008

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 

1. Plug-in registers itself at ECom 

69 

Your code is in a dll 

Data (name, ID, …) and connection 

interface/implementation defined through resource file 

Andreas Jakl, 2008

ECom 

2. Client requests implementation of an interface 

70 

Through UID or text (name of the implementation) 

ECom searches through its saved meta-information 

database, returns best results („resolution“) 

ECom instantiates desired object through its factory 

function, loads object in the process of the client 

ECom uses reference counting for resource 

management 

Andreas Jakl, 2008

71 

Basic ECom Architecture 

Client 

instantiates 


 

InterfaceDefinition 

NewL() 

~InterfaceDefinition() 

Implementation 1 ECom

… any questions? 

Quiz 

72 

Andreas Jakl, 2008

Quiz I 

● What about those UI components: 

73 

Options menu 

Window-Owning 

Container in Avkon View-Architecture 

Window-Owning Compound Control 

Label-Control 


Andreas Jakl, 2008

Quiz I – Solution 

● What about those UI components: 

74 

Options menu 

Window-Owning 

Container in Avkon View-Architecture 


Label-Control 


Andreas Jakl, 2008

Quiz II 

● Which application architectures are created through 

the following Carbide.c++ wizards? 

S60 3.x GUI Application 

75 

Control-based Dialog-based Avkon-Views 

S60 nth Ed. GUI App. with UI Designer (+ Support view switching) 


Andreas Jakl, 2008

Quiz II – Solution 

● Which application architectures are created through 

the following Carbide.c++ wizards? 

S60 3.x GUI Application 

76 


S60 nth Ed. GUI App. with UI Designer (+ Support view switching) 


Andreas Jakl, 2008

Quiz III 

● … these dialogs are: 

77 

Modal Modeless 

Waiting Nonwaiting 



Andreas Jakl, 2008

Quiz III – Solution 

● … these dialogs are: 

78 





Andreas Jakl, 2008

Try it for your own 

… let’s move to the Challenges! 

79 

Andreas Jakl, 2008

Dialog-Based Architecture - free Symbian OS tutorials

Create successful ePaper yourself

Delete template?

Save as template?