Symbian Application Development Concepts

  • Uploaded by: Fahad_Mudassar
  • 0
  • 0
  • November 2019
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Symbian Application Development Concepts as PDF for free.

More details

  • Words: 1,106
  • Pages: 28
Symbian:

Application Development Concepts

Application Components • Application • Document • AppUI • View • Container

Application Components: Application Class • Entry Point for Symbian Operating

System • Contains Application Unique Identifier (UID) – Development UID automatically assigned by Carbide C++ – Get UIDs for Public Applications at http://www.symbiansigned.com/

• Responsible for Creation of Document

Application Components: Document Class • Manages Application Data Model • Responsible for Creation of AppUI Class Object

Application Components: AppUI Class • Not a Visual Class i.e. its Objects are Not Visible • Serves as Controller for the Application • Manages Views (Container) • Responsible for Application Wide Event Handling

Application Components: View Class • Provide Screens for the Application • View Specific Command Handling • View Has a Unique ID • A View Can be Activated from – Within the Same Application or – From Another Application by Providing UID of the Application and ID of the View

Application Components: Container Class • Responsible for Handling UI Components

ExpApp

Application Structure Overview in S60 CExpApplication CExpDocument

CExpAppUi

CExpView CExpContainer

Series 60

CAknViewAppUi

CAknApplication CAknDocument

CAknAppUi

CAknView

Symbian OS

CAknAppUiBase

CEikApplication CEikDocument

CEikAppUi

CApaApplication CApaDocument

CCoeAppUi

CCoeControl

Symbian Data Types Standard C++ int unsigned int float double boolean void* void char

Symbian OS TInt TUint TReal32 TReal64 TBool TAny* Void TChar

Symbian Classes • Class Names

– Prefix+Class Name+Suffix

• C Classes (C is Prefix in Class Name)

– Derived Directly or Indirectly from CBase – Constructed on Heap and Require Cleanup

• T Classes (T is Prefix in Class Name) – – –

Also Called Data Type Classes Encapsulates a Value of Specific Type e.g. TChar Generally Do Not Use Dynamic Data i.e. Created on Stack but May also Use Heap if Required

Symbian Classes • R Classes (R is Prefix in Class Name)

– Also Called Resource Classes – Owns a Resource Handle – Can be Instantiated on Heap or Stack

• M Classes (M is Prefix in Class Name)

– Also Called Interface Classes – Equivalent to an Abstract Interface (Contains Pure Virtual Functions) – Used to Define Callback Interfaces

• Static Classes (No Prefix Attached to Static Classes) – Contains Only Static Functions – Cannot be Instantiated into an Object

Exception Handling • Standard C++ Exception Handling in

Symbian OS v9 (try/catch mechanism) • Lightweight Exceptions for Previous Symbian OS (before OS v9) – Leaves are Alternative to C++ Exceptions – Leaves are Lightweight Exception Handling Mechanism

Exception Handling: Leaves • A Leave – Suspends Code Execution at the Point where Leave Occurs – Resumes Execution where Leave is “Trapped”

• Leaves May Occur while Performing Operations that May not Succeed

– Allocation of Memory – File Creation

• Traps are used to Catch Leaves and Allow them to be • •

Handled Functions that May Leave have “L” as Suffix in their Name Panics Cannot be Caught and Handled

Cleanup Stack • The cleanup stack is used to store

pointers that may become orphaned if a leave occurs – Push Pointer to Objects on Cleanup Stacks – In case of a Leave, All Objects whose Pointers are Pushed on Cleanup Stack will be Properly Destroyed

Two Phase Construction of Objects 1. Make All Constructors Private or Protected. 2. Provide Static Factory Function(s) to Create Objects e.g.

• •

NewL() NewLC()

• Code that May Leave is Placed in Factory Methods

No Code within a Constructor Should Ever Leave.

Descriptors • Strings in Symbian OS are Called

Descriptors • May Contain Text and Binary Data • TPtr8—8 bit Characters—Narrow Descriptors • TPtr16—16 bit Characters—Wide Descriptors • Descriptors Can be – Constant (Contents are Constant)

Pointer Descriptors • Can Point to Text on the Heap, Stack or

ROM Length • Constant: TPtrC Pointer 6

0x123456

• Modifiable: TPtr H E Max Length Lengt h

6 1 0x23456 0 7

H

L

L

E

O

L

!

L

O

!

Buffer Descriptors • Stack Based, Useful for Relatively Small Strings • Directly Contain the String TBufC<6> • Constant: Length 6

H

E

L

L

• Modifiable: TBuf<8> 6

Length

8

Max

H

E

L

O

!

L

O

!

Dynamic Descriptors (Heap Based) • Can be Used for Strings – That are Too Big to be Placed on Stack – For Which Size is Not Known at Compile Time

• Constant: HBufC Heap

0x34567 8

6

H

E

L

L

O

!

Dynamic Descriptors (Heap Based) • RBuf is Modifiable and Dynamically Allocated Descriptor

Threading and Active Objects • Symbian Allows Application Programs to Create Threads • However, Recommendation is to Use Active Objects where Possible • Alternative to Threads and Preferred Option is Using

– Asynchronous Functions along with Active Objects

Active Object Framework • Active Object Framework – –

Active Objects Active Scheduler

• Active Object Framework is Used for Event Driven Multitasking

Active Object • An Active Object: – Requests an Asynchronous Service and – Handles the Resulting Completion of Event Sometime After the Request. – May Ask to Cancel a Request – Is Listed with Active Scheduler

Active Scheduler • When Asynchronous Service Completes, It Generates Events • Active Scheduler

– Detects Events – Determines Associated Active Object – Calls the Active Object to Handle the Event.

Submitting an Asynchronous Request • Each Active Object Can Only Have One

Outstanding Request • Check for previous outstanding requests. If a Request has Already been Placed, the Code may – Panic – Refuse – Cancel Outstanding Request and Submit New One

• Issue the Request • Mark Active Object as Waiting

Active Object Event Handling • Active Object Implements the Event Handling Function • Active Object Event Handler is the Function for • • • •

Handling Completion of Asynchronous Call Active Object Handler is Not Pre-Empted Control Returns to the Active Scheduler When Event Handler Returns If multiple events have occurred before control returns to the scheduler, they are handled sequentially in order of their Priority Active Scheduler Calls the Event Handling Function of Associated Object

Asynchronous Request Handling Process Overview Active Object Check for Outstanding Requests

Asynchronous Service Provider

Issue Request Sets the Request Status to Pending and Starts the Service

Active Scheduler Calls Event Handler of Active Object. Event Handler Cannot be Preempted Event Handler Returns and Control is Given Back to Active Scheduler

Service Completes and Service Provider Notifies the Active Scheduler with Results

Process Boundary

References • Mobile computing : technology, applications,

and service creation by Asoke K. Talukder, Roopa R. Yavagal • S60 Programming by Paul Coulton and Reuben Edwards • Developing Software for Symbian OS by Steve Babin • The Accredited Symbian Developer Primer by Mark Jacobs and Jo Stichbury

Related Documents