Symbian OS Programming Tampere Polytechnic University of Applied Sciences Tony Torp (tony. torp@tamk. fi) www. tamk. fi/~torton The course is supported by the project "The assurance of information technology education quality in the University of Tartu and Tartu Vocational Education Centre". www. mobedu. org
Intro to Symbian OS www. mobedu. org
History • 1980 Psion Ltd. (founded by David Potter) – The main purpose was to innovate and create electronical PDA devices (Personal Digital Assistant) • 1984: first PDA Psion Organizer • 1986 Psion Organizer II – – 64 k. B RAM & ROM 8 bit CPU Connection with PC Programming: Assembler & OPL (Organizer programming language) www. mobedu. org
Psion Organizer II Source: en. wikipedia. org www. mobedu. org
. . . history • 1991 Psion Series 3 – 16 bit SIBO-devices (sixteen-bit-organizer) – The kernel was named EPOC (from word epoch) www. mobedu. org
• Psion Series 3 OPL contained an editor and compiler for 3 rd party SW developers – > possibility to create effective 3 rd party applications – > thousands of applications available by different vendors • 1996 Psion Software Ltd. – the main goal was to make EPOC the leading WID operating system of the world (Wireless Information Device) – the goal was also to licenciate EPOC to many hardware vendors www. mobedu. org
. . . history • 1997 Psion Series 5 – 32 BIT EPOC –operating system – 1998 Symbian OS founded www. mobedu. org
The simultaneous history of mobile networks • In the 70’s and 80’s the amount of mobile phone users were small • There were many networks of different standards around the world (e. g. NMT (Nordic Mobile Telephony) in the Nordic Countries) • Kickoff for GSM planning in the early 80’s • July 1991: the world’s first GSM call held in Radiolinja (Elisa) network in Finland • Now: over 1 Billion GSM subscribers in almost 200 countries around the world (and still growing) www. mobedu. org
. . . and developement of mobile phones • The first phones were made just for making reliable calls (which was a a real challenge) • Competition created needs for new services • 1996: SMS (short message services) supported in new models • Different ringing tones, increasing amount of user memory etc. . . • 1996 -2000: many new features (e. g. games, tones, calendar, clock, alarm clock, small applications. . . ) • Because of new applications and services the mobile phones started to look more and more a PDA device www. mobedu. org
The fusion of mobile phones and PDAs. . . • 1997: The first version of new EPOC operating system • Psion Software was named Symbian Ltd. ’The main goal to licenciate the operating system for as many hardware vendors as possible’ • Symbian Ltd. is owned by Nokia (~48% share), Ericsson, Motorola, Psion (the original PDA company) and some others. • Summer 2001: The first Symbian GSM –based PDA by Nokia, Nokia Communicator 9200 www. mobedu. org
• November 2001: the first Symbian OS based smartphone were published. Sales started on summer 2002. • Now there are several Symbian OS based smartphones by many vendors (refer www. symbian. com ) • Nokia models can be seen at www. nokia. com/phones www. mobedu. org
Symbian OS • Symbian OS is a global industry standard for mobile phones systems and build especially for mobile devices • Forum established in 1998 and owned by leading mobile phone manufacturers • Symbian offers a de-facto standard operation system for wireless devices www. mobedu. org
Symbian Consortium • • • Ericsson (15. 6%) Nokia (47. 9%) Panasonic (10. 5%) Samsung (4. 5%) Siemens (8. 4%) Sony Ericsson (13. 1%) www. mobedu. org
Symbian Licenses www. mobedu. org
Symbian Limited • Gartner predicts that a billion cell phones will ship in 2009 (July 19, 2005) • Gartner forecasts that by the end of 2006 smartphone sales will reach 87 m with Symbian OS owning 83% of the market share at 72 million • Sales of smartphones will represent about one-fifth (or 200 million) of all mobile handset sales by 2008 www. mobedu. org
Worldwide total smart mobile device market Market shares 2004, 2005 OS vendor 2004 % share 2005 % share Growth 04/05 Total 23, 488, 410 47, 078, 380 100. 4% Symbian 14, 365, 850 61. 2% 33, 160, 350 70. 4% 130. 8% Linux 6, 380, 160 27. 2% 9, 285, 550 19. 7% 45. 5% Palm. Source 1, 210, 090 5. 2% 2, 199, 360 4. 7% 81. 75% Microsoft 1, 119, 610 4. 8% 1, 426, 770 3. 0% 27. 4% RIM 135, 180 0. 6% 684, 410 1. 5% 406% Others 277, 520 1. 2% 321, 940 0. 7% 16% www. mobedu. org
Worldwide market shares Q 2 2006 www. mobedu. org
Different Mobile Phone Series • • • Series 20 Series 30 Series 40 Series 60 Series 80 Series 90 • Largest number of shipped terminals for Series 60 www. mobedu. org
Series 20 • Mobile phones with the following services – SMS • Monochrome Display – 84 x 48 Pixel www. mobedu. org
Series 30 • Mobile phones with the following services – SMS, EMS, MMS, J 2 ME, XHTML • Monochrome and color Display – 96 x 65 Pixel www. mobedu. org
Series 40 S 40 3 rd Edition S 40 1 st www. mobedu. org Edition S 40 2 nd Edition
Series 40 v 1 • Mobile phones with the following services – SMS, EMS, MMS, J 2 ME, XHTML • Display – 96 x 65/68 Pixel – 128 x 128 Pixel www. mobedu. org
Series 40 v 2 • Mobile phones with the following services – SMS, EMS, MMS, J 2 ME, XHTML – Unique cover design • Display – 128 x 128 Pixel – 128 x 160 Pixel – 208 x 208 Pixel www. mobedu. org
Series 40 v 3 • Mobile phones with the following services – SMS, EMS, MMS, J 2 ME, XHTML • Display – 240 x 320 Pixel www. mobedu. org
Series 45 • Mobile phones with the following services – First 3 G phones • 6650 • 7600 • Display – 128 x 160 www. mobedu. org
Series 60 1 st Edition • Mobile phones with the following services – SMS, EMS, MMS, J 2 ME, XHTML • Operating System – Symbian • Display – 176 x 208 Pixel www. mobedu. org
Series 60 2 nd Edition • Mobile phones with the following services • Operating System • Display – – – – • 176 x 208 Pixel (Standard) 208 x 176 Pixel [Landscape] 240 x 320 Pixel (Quarter QVGA) 320 x 240 Pixel [Landscape] 352 x 416 Pixel (Double) 416 x 352 Pixel [Landscape] HTML Browser-Extensions EDGE support Feature Pack 2: – • Symbian Feature Pack 1: – – • As before with UI metrics and unique icons etc Support for WCDMA (UMTS) Feature Pack 3: – – Scalable UI Larger resolutions (240 x 320 und 352 x 415 Pixel) www. mobedu. org
Series 60 3 rd Edition • As before for the 2 nd edition www. mobedu. org
Series 60 Evolution Some migration needed FP 1 Binary break FP 1 FPX FP 1 FP 2 FP 3 S 60 3 rd Edition S 60 1 st edition www. mobedu. org S 60 Future Edition S 60 2 nd edition FPX S 60 3 rd edition S 60 Future
Series 80 • Mobile phones with the following services – SMS, EMS, MMS, Personal Java, XHTML, PIM • Operating System – Symbian • Display – 462 x 200 Pixel (92 x) – 640 x 200 Pixel (93 x/95 x) • External Display – Series 30/40 www. mobedu. org
Series 90 • Mobile phones with the following services – SMS, EMS, MMS, J 2 ME, XHTML • Operating System – Symbian • Display – 640 x 320 Pixel – Touchscreen www. mobedu. org
Intermediate Discussion • Large number of series for the mobile phones • Largest number of shipped mobile phones for Series 40 and 60. • Evolution of Series 80 and Series 90 are not the future in terms of wide spread application. • To cover the highest number of phones, JAVA should be the target platform • May be soon the Series 60 • Focus on Series 60 www. mobedu. org
Series 60 Evolution • Series 60 1 st Ed (V 09 -V 1. 2), Symbian OS v 6. 1 – – – – – Nokia 7650 (development name Calypso) Nokia 3600 Nokia 3620 (GSM 850/1900 successor of the 3650) Nokia 3650 Nokia 3660 (GSM 900/1800/1900 successor of the 3650) Nokia N-Gage and N-Gage QD Samsung SGH-D 700 Sendo X 2 Siemens SX 1 www. mobedu. org
Series 60 Evolution • Series 60 2 nd Ed (V 2. 0), Symbian OS v 7. 0 s – Nokia 6600 (development name Calimero) – Samsung SGH-D 710 • Series 60 2 nd Ed, FP 1 (V 2. 1), Symbian OS v 7. 0 s – – – Nokia 3230 (development name Blitz) Nokia 6260 (development name Lightning) Nokia 6620 (development name Calvin) Nokia 6670 (development name Lara) Nokia 7610 (development name Catalina) www. mobedu. org
Series 60 Evolution • Series 60 2 nd Ed, FP 2 (V 2. 6), Symbian OS v 8. 0 a – Nokia 6630 (development name Charlie) – Nokia 6680 (development name Milla (from "Milla Magia", the Finnish name for Magica De Spell)) – Nokia 6681 (development name Cho) – Nokia 6682 (development name Ginny) • Series 60 2 nd Ed, FP 3 (V 2. 8), Symbian OS v 8. 1 a – Nokia N 70 (development name Rolf) – Nokia N 90 (development name Gromit) www. mobedu. org
Nokia 6682 • Operating System: – Symbian OS v 8. 0 a • Developer Platform: – S 60 2 nd Edition – Feature Pack 2 • Network Data Support: – CSD – EGPRS – GPRS • PC Connectivity: – Bluetooth – USB www. mobedu. org
N 90 • Operating System: – Symbian OS v 8. 1 a • Developer Platform: – S 60 2 nd Edition – Feature Pack 3 • Network Data Support: – – – CSD EGPRS HSCSD WCDMA • PC Connectivity: – Bluetooth – USB www. mobedu. org
Series 60 Evolution • S 60 3 rd Edition (V 3. 0) Symbian OS v 9. 1 – – – – Nokia 3250 (development name Thunder) Nokia E 60 (development name Mars) Nokia E 61 (development name Smailer) Nokia E 70 (development name Zeus) Nokia N 71 (development name Isetta) Nokia N 80 (development name Miro) Nokia N 91 (development name Nemo) Nokia N 92 (development name Magnum) www. mobedu. org
N 71 • Operating System: – Symbian OS v 9. 1 • Developer Platform: – S 60 3 rd Edition • Network Data Support: – – – CSD EGPRS HSCSD WCDMA • PC Connectivity: – Bluetooth – Infrared – USB www. mobedu. org
Mapping Series 60 and Symbian OS Edition and FP 1 st Ed 2 nd Ed FP 1 2 nd Ed FP 2 2 nd Ed FP 3 3 rd Ed www. mobedu. org Symbian OS → → → OS v 6. 1 OS v 7. 0 s OS v 8. 0 a OS v 8. 1 a OS v 9. 1
• How to program on the Series 60? • What are the supported languages? • What are the tools? www. mobedu. org
Tools and SDKs www. mobedu. org
IDEs for Symbian C++ development www. mobedu. org
Tools to be installed • SDK, Software Development Kit, is chosen according to compiler: • Microsoft Visual Studio Net • Borland C++ Builder or Borland X • Metrowerks Code Warrior • Carbide Express from March 2006 • Carbide Developer and Pro from Sept 2006 Other SW to be installed: • • Active. Perl 5. 1. 8 or newer http: //www. activestate. com/ Java runtime environment 1. 3. 1 or newer www. sun. com Read the installation instructions carefully! www. mobedu. org
www. forum. nokia. com www. mobedu. org
Downloading the SDK www. mobedu. org
Carbide C++ Demo • Objectives of the demo: 1. Create a basic S 60 application using Carbide. c++ and the S 60 Application Wizard 2. Get to know is the S 60 application architecture (application framework) 3. Get to know the basic ideas of vector craphics in Symbian 4. Get introduced to Symbian C++ www. mobedu. org
S 60 Application Framework www. mobedu. org
Series 60 Application Structure User commands / interaction www. mobedu. org
1. Application (e. g. class CExample. App) • Application class is inherited from CEik. Application • When starting an application, the OS does the following procedures: 1. Starts the application by creating an instance object of this class 2. Calls the Create. Document. L method of the created object www. mobedu. org
2. Document (e. g. class CExample. Document) • Document class is inherited from CEik. Document. • The main task of the document is to write and read data from the file system. • If files are not used by the application, document contains only one method 1. Create. App. Ui. L() which creates the App. Ui object. • The basic task of document object is thou to create App. Ui object www. mobedu. org
3. App. Ui – user interface object (e. g. class CExample. App. Ui) • The main task of App. Ui is to handle events generated by user actions. These events are mainly: 1. Menu events. The user selects a command from an application menu (defined in resource file. rss) 2. Key events. The user presses a key. • The methods handling those events are as follows: 1. Handle. Key. Event() for key event handling 2. Handle. Command() for menu generated events • The operating system takes care of calling these methods. You only have to implement the functionality in the code (polymorphic DLL ) www. mobedu. org
4. Views or containers (e. g. class CExample. App. Container or CExample. App. View) • Views or containers are inherited from CCoe. Control class. • Container is a user interface view • The most important method is Draw(), where you can implement drawing by using pen, brush, shapes and colors. • Draw –method is called by system when the drawing area needs an update or when Draw. Now() is called from the code. www. mobedu. org
Application Startup www. mobedu. org
Vector Graphics in Container www. mobedu. org
About drawing • • • Draw method is called by system whenever some part of the display needs to be updated (e. g. in case a ’Battery Low’ notification has appeared on the display). Draw method gets a rectangle area to be redrawn. Parameter TRect a. Rect defines the area. Drawing area starts from the up-left corner coordinates (0, 0) and ends at bottom-right coordinates (max. X, max. Y) which you can get in Draw method by; TInt max. Y = Rect(). Height(); TInt max. X = Rect(). Width(); • Note: never call Draw method straight, call Draw. Now instead (which causes System to call Draw when possible). www. mobedu. org
About drawing • • Drawing can be made through CWindow. GC object (GC = Graphics Context). Cwindow. GC offers methods for – – – • drawing points, lines, ellipses, bitmaps etc. . . change colors and styles of pen or brush etc. . . Some example methods: – – – – void void www. mobedu. org Draw. Line(const TPoint& a. Point 1, const TPoint& a. Point 2); Draw. Ellipse(const TRect& a. Rect); Draw. Poly. Line(const TPoint* a. Point. List, TInt a. Num. Points); Draw. Rect(const TRect& a. Rect); Set. Brush. Color(const TRgb &a. Color); Set. Pen. Size(const TSize& a. Size); Set. Pen. Style(TPen. Style a. Pen. Style);
Common classes needed when drawing • Structs – TPoint – point. • – TRect – rectangle • – • a construction example TRect area(20, 40, 120, 135); TRgb - color • • – Give x and y coordinates for the constructor example: TPoint dot 1( 20, 40 ); a construction example: TRgb my. Color(20, 40, 256) //RGB 0 -256 or: TRgb my. Color 2( 0 x 99 ff. CC) // hexadecimal TSize – size Some enumerations (definitions can be found from SDK documentation – check out!) – – TBrush. Style TFill. Rule – TFill. Rule www. mobedu. org
An example of Draw method implementation void CExample. Container: : Draw(const TRect& a. Rect) const { CWindow. Gc& gc = System. Gc(); // Set the brush color to Blue and style as Solid gc. Set. Brush. Color(KRgb. Blue ); gc. Set. Brush. Style(CGraphics. Context: : ESolid. Brush ); // Draw the background (the whole a. Rect) gc. Draw. Rect(a. Rect); // Set new color as RGB TRgb my. Color(0 x 99 cc. FF); gc. Set. Brush. Color( my. Color ); // Define and draw a small filled rectangle TRect area( 20, 50, 50 ); gc. Draw. Rect( area ); // Draw a dashed line TPoint point 1(40, 80); TPoint point 2(120, 140); gc. Set. Pen. Style(CGraphics. Context: : EDashed. Pen ); gc. Draw. Line( point 1, point 2 ); } www. mobedu. org
Symbian SDK and Project File Hierarchy www. mobedu. org
Folders in Symbian project Icons of Application Resource files Construction files of Symbian project (. mmp, bld. inf ) Header files (. h, . hrh ) Installation files (. pkg, . sis ) Source codes (. cpp ) www. mobedu. org
Application project files and folder hierarchy • App. Wizard creates five folders, which are as follows: 1. 2. 3. 4. 5. Aif Data Inc Install Src • Let’s go through those files www. mobedu. org
1. Aif folder (application information file) • Aif folder includes the application icon of the application. By default, it is as follows: • We can, of course, modify the bitmap. www. mobedu. org
2. Data folder • Data folder includes the user interface resource files of the application (. rss files) • Resource files define things related to application’s user interface, e. g. what are the menu items of the application and which events are generated when the user selects a row in a menu. • An example of a menu definition in. rss file (more details later): RESOURCE MENU_PANE r_example_menu { items= { MENU_ITEM { command=EAkn. Cmd. Exit; txt="Exit"; }, MENU_ITEM { command=EExample. Cmd. App. Test ; txt="Test"; } www. mobedu. org}; }
3. Inc folder • Inc folder includes the C++ header files (. h files) for the source code • Inc folder also includes. hrh –file, which is a header file for both. rss files and source code files. In example application generated by App. Wizard, the . hrh file looks as follows: #ifndef EXAMPLE_HRH #define EXAMPLE_HRH enum TExample. Command. Ids { EExample. Cmd. App. Test = 1 }; • Here the. hrh file contains constant referred in. rss file www. mobedu. org
4. Install folder • Install folder contains. pkg file which is used when generating an installation package (. sis file) for target device. • This can be done from the NDS +. NET IDE. • The command generates the. sis file which can be sent to the target device e. g. via Bluetooth or Infrared. The target device takes care of the rest of the installation process). www. mobedu. org
5. Src folder • Src – folder contains the source files of the application classes (. cpp files) www. mobedu. org
Folder construction of SDK epocroot Epoc examples Series 60 documentation Series 60 examples Series 60 tools www. mobedu. org
Epoc 32 Folders Visual Studio projects Configuration files of Emulator Binary files of Emulator www. mobedu. org
Symbian OS C++ www. mobedu. org
Conventions as a table www. mobedu. org
T type classes • Basic data types TInt, TChar, TReal, TText, TUint, TInt 8, TInt 16, … • Structs TMy. App. Struct • Simple classes class TCircle { public: TReal Calculate. Area() const; TPoint i. Origo; TReal i. Radius; }; • No dynamic allocation • No destructor • Memory taken from the stack (if not a part of C-class) www. mobedu. org
R type classes • Handles to OS servers - in Client/Server realization Rclasses act as Client interface classes • Used as proxies for instances, RFile, RTimer etc. • Not allocated dynamically • Reservation/release methods: Open, Connect then Close, Release • Cleanup. Close. Push. L or Cleanup. Release. Push. L then Cleanup. Stack: : Pop. And. Destro www. mobedu. org
C type classes • C classes are inherited CBase class • Allocated dynamically from the heap – new (ELeave) – New. L • Destructor always virtual, destructed by delete • Attributes cleared when construction phase • C-class can be compound (=can create and own other dynamically allocated members) • Cleanup. Stack used www. mobedu. org
CBase class • Constructor sets automatically zeroes for the member data • Includes the virtual destructor • Supports cleanup mechanism www. mobedu. org
M-type classes • • • interface classes no data, no methods only pure virtual functions to separate interface from the implementation the only allowed multiheritance usage in Symbian OS class MMy. Game. Engine. Observer { virtual void Notify. Engine. Event(TEngine. Event a. Event) = 0; } class CMy. Game. App. View : public CCoe. Control, public MMy. Game. Engine. Observer www. mobedu. org
M-type classes • describes an abstract interface • Example: Observer pattern realization: www. mobedu. org
Some naming conventions • Words are separated by capitol letters • Inside a variable name and method parameters the words are separated with capital letters • The parameters of methods starts by a letter ‘a’ void Do. Smthng( TInt a. My. Argument ); • The names of member variables start by a letter ‘i’ TInt i. Age; • Local variables start by a tiny letter: TChar first. Letter; www. mobedu. org
Some naming conventions • Enumerations start by a letter ‘E’ enum TColors { EWhite, EBlack, ERed }; • Consts do have a ‘K’ letter as a suffix: const TInt KAmnt. Of. Stcks( 5 ); • no underscore _ • Brackets are insided www. mobedu. org
App. Ui and Event Handling www. mobedu. org
Event handling in App. Ui class • App. Ui class is responsible of handling events occurred by user actions. • The basic actions are key events (the user presses a key) and user commands generated by e. g. user selecting a menu item. • The OS passes the events as integer values to application’s App. Ui class • App. Ui has two methods for event receiving: 1. Handle. Command. L(TInt) – handles commands. The parameter contains the command id. 2. Handle. Key. Event. L(TKey. Event, TEvent. Code) – handles key event, the first parameter contains e. g. the key code. www. mobedu. org
Creating Menu and Menu Commands • • Basic menus are defined in the resource file (. rss) of the application. Example: next piece of resource file defines the left menu of an App. Wizard default application: RESOURCE MENU_PANE r_example_menu { items= { MENU_ITEM { command=EAkn. Cmd. Exit; txt="Exit"; }, MENU_ITEM { command=EExample. Cmd. App. Test; txt="Test"; } }; } • • • The menu contains two selection rows ’Exit’ and ’Test’. If the user selects Exit, EAkn. Cmd. Exit command is sent to the App. Ui class. If the user selects Test, EExample. Cmd. App. Test command is sent to the App. Ui class. www. mobedu. org
. . . creating menus and menu commands • The system calls App. Ui’s Handle. Command. L with the command parameter. • Own command enumerations are (and must be) defined in the. hrh file of the application (the file is in inc folder). . hrh file must be included in both. rss file and App. Ui’s. cpp file. • For an example, see the Handle. Command. L method of the App. Wizard example application. www. mobedu. org
Key events • When the user presses a key, an event is sent to App. UI object of the active application. • Example of handling joystick left and right events: TKey. Response CExample. App. Ui: : Handle. Key. Event. L( const TKey. Event& a. Key. Event, TEvent. Code /*a. Type*/) { switch ( a. Key. Event. i. Code ) { case EKey. Left. Arrow: // Handling of joystick left event break; case EKey. Right. Arrow: // Handling of joystick left event break; default: // This application is not interested in other key events return EKey. Was. Not. Consumed; } return EKey. Was. Consumed; } • Key codes (e. g. EKey. Left. Arrow) are defined in system header file E 32 KEYS. H www. mobedu. org
UI and the resource files www. mobedu. org
Resource files • Resource files contains data separate from the executable code • Resource files are used for defining user interface components and text strings. • Benefits: – Less C++ code – Applications are smaler – If the appearance of application is to be changed there is no need to change the C-code only structure of the resource file • Source code is located in text file named as application_name. rss • Compiled resource file in application_name. rsc www. mobedu. org
Structure of a resource file • Each resource file has to have an unique name • Unique name enables to have more than one resource files per application • The name has to be four characters long and to be defined by using NAME statement • Comments can be written as in C-language. // and /* */ • Files can be included using the #include statement • Resources are defined by using a RESOURCE statement www. mobedu. org
Structure of a resource file • Each resource file has to begin with three standard resources – RSS_SIGNATURE (this can be blank) – TBUF defines the name of the default document file (not used) – EIKA_APP_INFO defines the resources of menu, CBAbuttons and hotkeys www. mobedu. org
Example of resource file www. mobedu. org
. hrh files • . hrh file defines the commands used in resource file. • Command values must be unique. • When user invokes a command, it is passed to Handle. Command. L-function located in App. UI-class • Function must be written so that it handles all the commands used by the application www. mobedu. org
Hello. World. hrh www. mobedu. org
. rh files • Resource structures are defined in the. rh files • The most common ones are already defined in avkon. rh and uikon. rh files • If the application requires its own structs, it has to include its own. rh file. • Example: NUMBER_EDITOR resource in uikon. rh. www. mobedu. org
Localisation files • Strings that should be localised should not be defined in the resource file itself, but in separate files with an . lxx extension. • This way the needed. lxx file can be chosen from. loc file • Strings defined in localization file can be pointed with a name defined in resource file. • String is defined with #define command www. mobedu. org
Example of. loc file • With out different language versions (. loc file ) • With different language versions (. loc file ) www. mobedu. org
Series 60 Command Buttons • Defined in EIK_APP_INFO resource • Use Avkon predefined key combinations www. mobedu. org
Options menu • The Options menu is a key component of the user interface. • Most applications will need to create an Options menu and handle the commands that it generates. • The user initiates the Options menu when he or she presses the left Command button. • Menus are typically defined in resource files. • Menus can be modified dynamically within App. Ui class Dyn. Init. Menu. Pane. L() function www. mobedu. org
Submenu • Item in the Options menu can be a submenu title • The submenu is opened by pressing either the left softkey or the Arrow right key. • When item in a submenu is selected, both the submenu and main menu windows are closed. • Only one submenu level is allowed www. mobedu. org
Options menu Sub Menuitem Sub Menupane www. mobedu. org
Submenu example www. mobedu. org
Handling menu selections • The App. Ui class will be informed of the user’s Option Menu choices via the Handle. Command. L() method. www. mobedu. org
Purpose of Resource files • Resource files are used to define UI parts and components of the application. – – Menus Note components Text strings Queries • To keep the C++ code and the UI separate • Less C++ code • Modularity www. mobedu. org
Example of resource file www. mobedu. org
Hello. World. hrh www. mobedu. org
Handling menu selections in App. UI www. mobedu. org
What else can UI resource files contain? • 1. 2. 3. 4. 5. 6. 7. • Series 60 –resource files can contain e. g. : Queries Notes Lists Menus Forms Editors Strings Next we take some examples of Queries and Notes and have an exercise. www. mobedu. org
Example 1: Queries • 1. 2. 3. 4. Use queries when you need user input Confirmation query Text. Query – inputting text Time query – asking time List query – selection list where the user selects one 5. Multiselection list query – selection list where the user can select many items www. mobedu. org
An example: implementing Confirmation Query 1. Resource file definition: RESOURCE DIALOG r_my_conf_query { flags = EAkn. General. Query. Flags; buttons = R_AVKON_SOFTKEYS_YES_NO; items = { DLG_LINE { type = EAkn. Ct. Query; id = EGeneral. Query; control = AVKON_CONFIRMATION_QUERY { layout = EConfirmation. Query. Layout; }; } www. mobedu. org
2. Launching the query: #include <aknnotedialog. h> #include <aknnotewrappers. h> // Resource definitions (compiled resource identifiers) #include <application_project_name. rsg> … CAkn. Query. Dialog* dlg = CAkn. Query. Dialog: : New. L(); dlg->Set. Prompt. L( _L("Haluatko todella tehdä näin? ") ); if( dlg->Execute. LD( R_MY_CONF_QUERY ) ) { // The user answered yes } else { // The user answared no } • Execute. LD performs the dialog. The letter D indicates that the allocated memory of the dialog is freed automatically (so you don’t have to delete it). www. mobedu. org
Example 2: implementing Text Query 1. Resource file definition: RESOURCE DIALOG r_my_text_query { flags = EAkn. General. Query. Flags; buttons = R_AVKON_SOFTKEYS_OK_CANCEL; items = { DLG_LINE { type = EAkn. Ct. Query; id = EGeneral. Query; control = AVKON_DATA_QUERY { layout = EData. Layout; control = EDWIN { }; }; } www. mobedu. org };
2. Launching the query from the code: #include <aknnotedialog. h> #include <aknnotewrappers. h> // Resource definitions (compiled resource identifiers) #include <application_project_name. rsg> … TBuf<15> user_input; // Descriptor for user input CAkn. Text. Query. Dialog* dlg = CAkn. Text. Query. Dialog: : New. L( user_input, CAkn. Query. Dialog: : EWarning. Tone); dlg->Set. Prompt. L( _L("Pelaajan X nimi? ") ); dlg->Set. Max. Length(14); dlg->Execute. LD( R_MY_TEXT_QUERY ); // The user input is now in user_input descriptor • You can set the query tone depending on the situation. The possibilities are: ENo. Tone, EWarning. Tone, EConfirmation. Tone ja EError. Tone. www. mobedu. org
Example 2: Simple notes • In case of simple standard notes you need not to use resource files. Instead, you can use the following code: // These two must be included where you use the notes #include <aknnotedialog. h> #include <aknnotewrappers. h> … CAkn. Information. Note* note = new (ELeave) CAkn. Information. Note; note->Execute. LD( _L("Kello on jo paljon!”)); CAkn. Warning. Note* note = new (ELeave) CAkn. Warning. Note; note->Execute. LD( _L(”Nyt meni väärin")); CAkn. Error. Note* note = new (ELeave) CAkn. Error. Note; www. mobedu. org note->Execute. LD( _L(”Do not do that"));
Leaves (”exceptions”) www. mobedu. org
What are exceptions? • Exception = indication of some error or problem during execution. • In Symbian OS, exceptions are used in ”lack of resource” situations. • Symbian OS ”exception” is called leave. www. mobedu. org
An example of standard C++ exception handling 1 int foo throw (int) { 2 try { 3. . . 4 throw 2; 5 throw 14; 6. . . 7 } 8 catch (int) { 9 // the code of exception handler 10 } 11 catch (. . . ) { 12 // catches all 13 throw; 14 } 15 } www. mobedu. org
Symbian OS exception mechanism • Symbian OS exception mechanism differs from standard C++ • Symbian OS does not support standard C++ throw-catch mechanism www. mobedu. org
Principals of Symbian OS exceptions 1. Throwing an exception (note. naming convention ’L -leavable’ for exception throwing method) void COwn. Class: : Some. Method. L() { … common code … problem…throw an exception User: : Leave( KErr. File. Not. Found ); // KErr. File. Not. Found exception identifier // starts going up } 2. Catching an exception void COwn. Class : : Some. Other. Method() { … TInt err = KErr. None; // If Some. Method. L throws an exception, the exception identifier is assigned // to err variable (int). If an exception is not thrown, err is still KErr. None TRAP( err, Some. Method. L() ); if( err != KErr. None ) { //Exception occurred-> check it… if( err == KErr. File. Not. Found ){ // Handle an errorous situation where file not found… } www. mobedu. org } }
Symbian OS exception mechanism • In Symbian OS, exceptions are used in ”lack of resource” situations. These can be divided into two categories: 1. Memory is tried to be allocated and there is not enough 2. Connecting a resource does not succeed. e. g. • • File server Network connections www. mobedu. org
Terms TERM MEANING exception Errorous situation leave Symbian OS ”exception”. In code: User: : Leave() which throws a leave, which causes the execution to jump up in the function call hierarchy to first trap harness, where the function was called. trap harness Macro, which catches the exception if leave occurred, e. g. TRAP( err, Some. Method. L() ); cleanup stack A stack which contains pointers to objects to free if leave occurs. Cleanup Stack stores pointers and deletes them when a leave occurs. www. mobedu. org
Out of memory situations in C++ • In C++ you allocate an object as follows: if ((my. Object = new CSome. Object() == NULL) { //Out of memory. Handle it somehow, e. g. give error message } • Out of memory situations are very uncommon in many systems • However, if memory can not be allocated, new operator returns NULL www. mobedu. org
new (ELeave) • Symbian OS has its own overloaded new operator for creating objects: new (ELeave) • new (ELeave) is similar to new but it throws KErr. No. Memory leave if new operation fails due to lack of free memory. • Next code demonstrates new (ELeave) in Symbian OS compared to standard C++: //Creating object with ’standard’ new CSome. Object* my. Object = new CSome. Object; if (my. Object == null) User: : Leave(KErr. No. Memory); //Creating object with Symbian OS new (ELeave). CSome. Object* my. Object = new (ELeave) CSome. Object; www. mobedu. org
Problem situation: • If a leave occurs, the control moves straight up to first TRAP macro. Let’s take a look at the following code. TRAPD(error, do. Example. L()); … void do. Example. L() { // Allocating memory for the first object… CSome. Object* my. Object 1=new (ELeave) CSome. Object; // Allocating memory for second… What happens if memory //is not enough… CSome. Object* my. Object 2=new (ELeave) CSome. Object; delete my. Object 1; // These lines will never be executed delete my. Object 2; // because leave occurred. } • Problem: my. Object 1 remains in memory… Ø memory leak!! www. mobedu. org
Solution: The Cleanup Stack • Cleanup. Stack is a stack where you can store pointers of allocated objects e. g. my. Object 1 pointer in the scenario in previous slide. • If a leave occurs, TRAP macro frees the memory deleting the pointers in Cleanup. Stack • You can store pointers by pushing them to Cleanup. Stack as follows: – Cleanup. Stack: : Push. L( my. Object 1 ), pushes object my. Object 1 to the Cleanup. Stack. • You can remove pointers by popping them from the Cleanup. Stack as follows: – Cleanup. Stack: : Pop() • You can pop and destroy objects in cleanup stack by calling: Cleanup. Stack: : Pop. And. Destroy() • Pop and Pop. An. Destroy operations are always for the last object put on the Cleanup. Stack. www. mobedu. org
Clean-up stack and Trap harness Program runs, when procedures call each other. More and more data ends up in program Program stack Dynamic data in the heap is referred to via pointers. www. mobedu. org Source: T. Mikkonen, 2004 Memory
Clean-up stack and Trap harness Error results in exit for several functions Memory Program stack Trap harness Source: T. Mikkonen, 2004 www. mobedu. org
Clean-up stack and Trap harness Clean. Up stack Error results in exit for several functions … but clean-up stack remembers reserved memory blocks Memory Program stack www. mobedu. org Source: T. Mikkonen, 2004
• The previous example with cleanup stack: TRAPD(error, do. Example. L()); … void do. Example. L() { // We create objects and put them to the cleanup stack. CSome. Object* my. Object 1=new (ELeave) CSome. Object; Cleanup. Stack: : Push. L( my. Object 1 ); // If out of memory occurs next, we have my. Object 1 in the // cleanup stack so it is freed automatically. CSome. Object* my. Object 2=new (ELeave) CSome. Object; Cleanup. Stack: : Push. L( my. Object 2 ); ……… // At the end we can take objects from the cleanup stack and // free the memory. Cleanup. Stack: : Pop. And. Destroy(); // Pop and delete } www. mobedu. org
Can also be used for e. g. closing sessions void Delete. File. L(const TDes. C& a. Name) { RFs fileserver; User: : Leave. If. Error(fileserver. Connect()); Cleanup. Close. Push. L(fileserver); User: : Leave. If. Error(fileserver. Delete(a. Name)); Cleanup. Stack: : Pop. And. Destroy(); // calls fileserver. close() } www. mobedu. org
Two phase construction • In some class constructors, you need to dynamically create other objects, which are owned by the class. An example of that kind of class CMy. Compound. Class : public CBase { public: CMy. Compound. Class(); ~CMy. Compound. Class(); … private: CMy. Simple. Class* i. Simple. Class 1; // owns an instance of another class CMy. Simple. Class* i. Simple. Class 2; // owns an instance of another class }; class CMy. Simple. Class : public CBase { public: CMy. Simple. Class(); ~CMy. Simple. Class(); … private: Tint i. Some. Data; www. mobedu. org };
• What happens in out of memory situation: CMy. Compound. Class: : My. Compound. Class(){ i. Simple. Class 1 = new (ELeave) CMy. Simple. Class(); // What happens if memory is out here? ? i. Simple. Class 2 = new (ELeave) CMy. Simple. Class(); } • Answer: First new (ELeave) leaves and i. Simple. Class 1 leaks. www. mobedu. org
Solution • Two phased construction: 1. Allocate the object itself without creating the dynamically allocated instances. Now we have a pointer to this object. • This is done in the ’normal’ constructor. 2. After that we create the dynamical members. • This is done in Construct. L method. – If something goes wrong, we have the pointer so we can delete allocated memory. • These two phases are done in New. L –method. www. mobedu. org
An example • In the next example we have two classes 1. CSmall. Class, which does not have dynamic members. So CSmall. Class does not need two phased constructor mechanism (New. L and Construct. L). 2. CBig. Class, which has 2 CSmall. Class instace variables. So CBig. Class needs two phased construction mechanism (New. L and Construct. L). www. mobedu. org
// File Own. Classes. h #include<e 32 base. h> class CSmall. Class : public CBase { public: CSmall. Class ( TInt a. Nr ); ~CSmall. Class (); private: TInt i. Nr; }; www. mobedu. org
class CBig. Class : public CBase { public: static CBig. Class * New. L(); ~CBig. Class (); private: CBig. Class (); void Construct. L(); private: CSmall. Class * i. Small. Class 1; CSmall. Class * i. Small. Class 2; }; www. mobedu. org
#include"Own. Classes. h" CSmall. Class: : CSmall. Class( TInt a. Nr ) { i. Nr = a. Nr; } CSmall. Class: : ~CSmall. Class() { } www. mobedu. org
// CBig. Class New. L, Construct. L, constructor and destructor CBig. Class* CBig. Class : : New. L() { CBig. Class* self = new (ELeave) CBig. Class(); Cleanup. Stack: : Push. L( self ); self->Construct. L(); Cleanup. Stack: : Pop(); return self; } // Construct. L allocates for dynamic resources. void CBig. Class : : Construct. L() { i. Small. Class 1 = new (ELeave) CSmall. Class( 3 ); i. Small. Class 2 = new (ELeave) CSmall. Class( 5 ); } www. mobedu. org
// Normal constructor. Here we can initialize other member variables. CBig. Class: : CBig. Class() {} // Destructor. Free allocated memory. CBig. Class: : ~CBig. Class() { delete i. Small. Class 1; delete i. Small. Class 2; } www. mobedu. org
Somethings to notice • Now, if you want to create an instance of CBig. Class you must do it as in following method : void Some. Method. L() { // Create CBig. Class* big = CBig. Class: : New. L(); } • CBig. Class instance is created by calling its static New. L method, which then calls constructor and Construct. L. If everything went ok, big points to the new instance. Fail causes leave. • New. L is static which means it is a so called class method meaning that it can be called without creating the instance firs. Static methods can be called by writing: CBig. Class: : New. L() www. mobedu. org
Summary of 2 -phased construction • Construct. L method creates the dynamically allocated members. (If there is no enough memory, it leaves causing New. L to leave and Cleanup. Stack to be emptied. ) • After this, the execution goes back to New. L , which pops the object from the cleanup stack and returns the pointer to the caller. • SUMMARUM: Two phased construction guarantees that memory leaks will not occur at any stage of object memory allocation!! • DISCUSSION: Is this needed in the future? ? www. mobedu. org
Links to explanation articles and material • Tutorials and white papers: http: //www. symbian. com/developer/ www. mobedu. org
Descriptors www. mobedu. org
Descriptors (Symbian OS “Strings”) • Descriptors are used for safety handling of strings and binary data. Some characteristics: – no distinction between the type of data, data (text) and binary are treated in the same way – no null termination (no end mark like ’ ’) – data length always included with data/pointer – light template based solution – memory leakage causes panic telling about serious error – but the code will not write over the memory space • They have in-build Panic mechanism so there is no possibility to make dangerous code. www. mobedu. org
Why Descriptors? • With descriptors we can not allocate the memory automatically like we can do with Java String and C++ string classes. • The programmer must take care about the allocation by himself from the stack or from the heap depending of the size of data. • Descriptors themselves save the space as well as using them. www. mobedu. org
Descriptor class hierarchy www. mobedu. org
The three categories of descriptors • 1. 2. 3. Descriptor types can be divided into three categories: Buffer descriptors (TBuf and TBuf. C) Heap descriptors (HBuf. C) Pointer descriptors (TPtr and TPtr. C) www. mobedu. org
Buffer Descriptors • Concrete classes: – TBuf – modifiable buffer descriptor – TBuf. C – non-modifiable buffer descriptor • Allocated from the program stack (or from the heap if it is as a part of dynamically created object) 3 length www. mobedu. org max length a c t u a l t e x t
Heap Descriptors • Concrete class – HBuf. C - non-modifiable heap descriptor • Allocated from the heap www. mobedu. org
Pointer Descriptors • Types – TPtr - modifiable pointer descriptor – TPtr. C – non-modifiable pointer descriptor • A pointer to descriptor data • Can be used e. g. as a function parameter a c t u a l 1 length www. mobedu. org t e x t
Descriptor types and the memory Source: New. LC. com www. mobedu. org
A code example private: TBuf<10> i. My. Name; TInt i. My. Age; }; void CMy. Class: : CMy. Class(){ // Initialising i. My. Name = _L(”Harald”); i. My. Age = 50; } void CMy. Class: : Introducing. Myself(){ // Take a 30 character buffer for the greeting TBuf<30> greeting; greeting. Insert( 0, _L(“My name is “ ); greeting. Insert( greeting. Length(), i. My. Name ); greeting. Insert( greeting. Length(), _L(" and my age is ") ); greeting. Append. Num( i. My. Age ); CAkn. Information. Note* note = new (ELeave) CAkn. Information. Note; note->Execute. LD( greeting ); www. mobedu. org }
Client/Server Framework www. mobedu. org
Need for Client/Server framework • • In Symbian devices, many OS resources are in use of the programmer by using Client/Server framework. Those resources are for example: – – – • Files Telephony issues Messaging Comms Window services Some loose definitions: – Client is a program that uses a particular service provided by a server (e. g. your application). – Server is the program that services the requests of clients. www. mobedu. org
1. Symbian Client/Server Architecture characteristics: Extensibility – Plug-in modules can be added to service new types of object 2. Efficiency – Client Multiple clients can be serviced by the same server 3. Safety – Servers and their clients exist in separated processes and communicate via messages through the OS processes. 4. Asynchronicity – Clients can register to get server events by the use of Active Objects. No polling leads to better power management. www. mobedu. org Server Client
Server Sessions • • • R-classes represent server sessions in Symbian OS. So they are client handles to servers. The base class for R-classes is RSession. Base. Some examples of server session handles in class hierarchy: www. mobedu. org
A Synchronous Client/Server Example www. mobedu. org
Inter-Process communication • In Symbian OS, clients and servers run in separate processes so there is no direct memory access between them. • Kernel thread sees the entire physical memory (all threads are clients of the Kernel server). • The client requests are packed as RMessage –instances to server side and servers can access client’s memory via Kernel. • RMessage instance is created by Kernel and passed to Server after client’s Send. Receive(). www. mobedu. org
Active Objects www. mobedu. org
Background and need for Active Objects • Typically, Symbian OS applications are event based: 1. The application is constructed and initialised. 2. The application starts waiting for events from the user or from the OS services 3. When an event occurs, the application handles the event and starts waiting for a new event. • Events can be generated by e. g: – The user • • – Service providers • • Key events Events generated by the UI (e. g. menu) Timers File server Network servers The UI events are handled by App. Ui but we need event handlers for other services. www. mobedu. org
Synchronous vs. asynchronous services • • In Symbian OS, most services are provided through servers, which can be accessed through the functions of R-classes (those are for example RFile or RCamera). R-classes provide synchronous and asynchronous service functions: 1. If your application calls synchronous function, the code (the application’s thread) stops until the service is completed and the function returns. 2. If your application calls asynchronous function, the function returns immediately, while the request itself is processed in the background. • Synchronous services should be quick operations e. g. requesting a system state information which can be responded immediately. www. mobedu. org
Asynchronous services • Many services require a lot of time to complete which makes synchronous functions unusable. Examples: – – • • An application opens a document of a big size. An application waits for an picture to be processed. Synchronous methods are not suitable in these kinds of services because the application thread is blocked until the service is completed. Instead, we use asynchronous service functions, where a service function returns immediately and the service is processed in the background. Since the application thread is not blocked, application can process other tasks like responding to user input or updating the display. When the request is complete, the program receives a notification, which will then be handled by e. g: – Threads (in many systems) – Active objects (in typical Symbian OS application) www. mobedu. org
Asynchronous services and multi-threaded applications • In many systems, applications are implemented as multithreaded processes, where asynchronous services are handled as follows: 1. For each new asynchronous task a new execution thread is spawned to handle it. 2. A scheduler makes decisions on which thread is executed. 3. A thread polls the service provider to see if the request is completed. 4. Once a service is completed the corresponding thread makes the required actions. www. mobedu. org
Asynchronous services and multi-threaded applications • Disadvantages of multi-threaded practice: – Multiple threads lead to increasing number of context switches increasing system overhead. – Programmer need to take care of synchronization, deadlock and other process management issues which make programming more complex. www. mobedu. org
Asynchronous services and Active Objects • • • A typical Symbian OS application is implemented as a single threaded process which can handle multiple asynchronous services. The technique is cooperative multitasking where there is a wait loop going through the outstanding task requests. Once the wait loop finds a completed task, it calls the event handler code of the corresponding handler object. This is done by using active object framework where each asynchronous service request has an active object waiting the request to be completed. In Symbian OS: – – The wait loop is implemented as an Active Scheduler. Handler objects are implemented as Active Objects. www. mobedu. org
The Active Scheduler • The Active Scheduler is implemented by CActive. Scheduler. • The Active Scheduler maintains a list ordered by priority, of all Active Objects of the application. • The Active Scheduler implements the wait loop for an application thread. The wait loop goes through the i. Status boolean flags of Active Objects of i. Active flag set on. • If the i. Status is other than KRequest. Pending (meaning that the request is completed), the Active Scheduler calls the Run. L method of the Active Object. www. mobedu. org
Definition of CActive class CActive : public CBase { public: ~CActive(); void Cancel(); TBool Is. Active() const; protected: CActive(TInt a. Priority); void Set. Active(); virtual void Do. Cancel() =0; virtual void Run. L() =0; public: TRequest. Status i. Status; private: TBool i. Active; }; www. mobedu. org
Dynamic behaviour www. mobedu. org
The life-cycle of an Active Object 4. The service provider completes the request and sets i. Status from KRequest. Pending to a new value. 5. The Active Scheduler recognizes the new status and calls the Run. L() method of the Active Object. 6. The response is handled in Run. L() and after that the Start() method can be called again (if applicable). www. mobedu. org
An example AO using Asynchronous Timer. class CMy. Timer. Ao : public CActive { public: CMy. Timer. Ao(); ~CMy. Timer. Ao(); void Start(); void Run. L(); private: void Do. Cancel(); private: // An integer representing a timing period TInt i. Pediod; // A hanlde to timing services RTimer i. Timer; }; www. mobedu. org
CMy. Timer. Ao: : CMy. Timer. Ao() : CActive( EPriority. Standard ), i. Period( 500 ) { // IMPORTANT: Add AO to the scheduler CActive. Scheduler: : Add( this ); // Create a timer for this thread i. Timer. Create. Local(); // Start active object Start(); } void CMy. Timer. Ao: : Start() { // Register to get asynchronous timing event. if( !Is. Active() ) { i. Timer. After( i. Status, i. Period ); Set. Active(); } } www. mobedu. org
void CMy. Timer. Ao: : Do. Cancel() { // Cancel an outstanding request from timer. i. Timer. Cancel(); } void CMy. Timer. Ao: : Run. L() { // Timing service completed. Add your code here. // Start again if applicable Start(); } CMy. Timer. Ao: : ~CMy. Timer. Ao() { Cancel(); } www. mobedu. org
Some comparison: AOs vs. Threads • Active Objects - CActive – – – < 1 k. B stack can not pre-empted no deadlocks, synchronization issues etc… long-running tasks has to be split less overhead (context-switches, swapping) • Threads – RThread – – – 4 k. B stack (kernel-side), 8 k. B stack (user-side) can be scheduled pre-emptively synchronization etc. issues must be considered suitable for long-running tasks only suitable technic in situations, where a long task cannot be split www. mobedu. org
Symbian OS Structure and Services www. mobedu. org
www. mobedu. org
www. mobedu. org
www. mobedu. org
Скачать презентацию Symbian OS Programming Tampere Polytechnic University of Applied
c99e9e249b0db23ce93d65e9ba2110c0.ppt