Скачать презентацию Symbian OS Programming Tampere Polytechnic University of Applied Скачать презентацию Symbian OS Programming Tampere Polytechnic University of Applied

c99e9e249b0db23ce93d65e9ba2110c0.ppt

  • Количество слайдов: 174

Symbian OS Programming Tampere Polytechnic University of Applied Sciences Tony Torp (tony. torp@tamk. fi) Symbian OS Programming Tampere Polytechnic University of Applied Sciences Tony Torp (tony. [email protected] 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 Intro to Symbian OS www. mobedu. org

History • 1980 Psion Ltd. (founded by David Potter) – The main purpose was 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 Psion Organizer II Source: en. wikipedia. org www. mobedu. org

. . . history • 1991 Psion Series 3 – 16 bit SIBO-devices (sixteen-bit-organizer) . . . 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 • 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 . . . 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 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 . . . 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 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 • 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 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%) 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 Licenses www. mobedu. org

Symbian Limited • Gartner predicts that a billion cell phones will ship in 2009 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 % 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 Worldwide market shares Q 2 2006 www. mobedu. org

Different Mobile Phone Series • • • Series 20 Series 30 Series 40 Series 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 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 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 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, 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, 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, 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 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, 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 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. 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 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 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 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 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), 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 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), 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 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 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 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: 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 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 • 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 Tools and SDKs www. mobedu. org

IDEs for Symbian C++ development www. mobedu. org IDEs for Symbian C++ development www. mobedu. org

Tools to be installed • SDK, Software Development Kit, is chosen according to compiler: 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 www. forum. nokia. com www. mobedu. org

Downloading the SDK www. mobedu. org Downloading the SDK www. mobedu. org

Carbide C++ Demo • Objectives of the demo: 1. Create a basic S 60 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 S 60 Application Framework www. mobedu. org

Series 60 Application Structure User commands / interaction 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. 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. 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) • 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) 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 Application Startup www. mobedu. org

Vector Graphics in Container www. mobedu. org Vector Graphics in Container www. mobedu. org

About drawing • • • Draw method is called by system whenever some part 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 = 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 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) 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 Symbian SDK and Project File Hierarchy www. mobedu. org

Folders in Symbian project Icons of Application Resource files Construction files of Symbian project 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 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 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 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) 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 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 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 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 Epoc 32 Folders Visual Studio projects Configuration files of Emulator Binary files of Emulator www. mobedu. org

Symbian OS C++ www. mobedu. org Symbian OS C++ www. mobedu. org

Conventions as a table www. mobedu. org Conventions as a table www. mobedu. org

T type classes • Basic data types TInt, TChar, TReal, TText, TUint, TInt 8, 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 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 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 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 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. 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 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, 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 App. Ui and Event Handling www. mobedu. org

Event handling in App. Ui class • App. Ui class is responsible of handling 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 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 . . . 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 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 UI and the resource files www. mobedu. org

Resource files • Resource files contains data separate from the executable code • Resource 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 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 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 Example of resource file www. mobedu. org

. hrh files • . hrh file defines the commands used in resource file. . 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 Hello. World. hrh www. mobedu. org

. rh files • Resource structures are defined in the. rh files • The . 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 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 ) 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 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. 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 • 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 Options menu Sub Menuitem Sub Menupane www. mobedu. org

Submenu example www. mobedu. org Submenu example www. mobedu. org

Handling menu selections • The App. Ui class will be informed of the user’s 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 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 Example of resource file www. mobedu. org

Hello. World. hrh www. mobedu. org Hello. World. hrh www. mobedu. org

Handling menu selections in App. UI 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. 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 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 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 2. Launching the query: #include #include // Resource definitions (compiled resource identifiers) #include … 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 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> // 2. Launching the query from the code: #include #include // Resource definitions (compiled resource identifiers) #include … 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 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 #include … 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 Leaves (”exceptions”) www. mobedu. org

What are exceptions? • Exception = indication of some error or problem during execution. 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 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 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’ 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 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: : 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 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) • 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 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 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 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 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 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 • 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. 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 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. • 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 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, 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 // File Own. Classes. h #include 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(); 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 #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 // 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. // 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. 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. 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. Links to explanation articles and material • Tutorials and white papers: http: //www. symbian. com/developer/ www. mobedu. org

Descriptors www. mobedu. org Descriptors www. mobedu. org

Descriptors (Symbian OS “Strings”) • Descriptors are used for safety handling of strings and 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 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 Descriptor class hierarchy www. mobedu. org

The three categories of descriptors • 1. 2. 3. Descriptor types can be divided 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 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 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 – 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 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 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 Client/Server Framework www. mobedu. org

Need for Client/Server framework • • In Symbian devices, many OS resources are in 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 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 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 A Synchronous Client/Server Example www. mobedu. org

Inter-Process communication • In Symbian OS, clients and servers run in separate processes so 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 Active Objects www. mobedu. org

Background and need for Active Objects • Typically, Symbian OS applications are event based: 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 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 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 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 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 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 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 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 Dynamic behaviour www. mobedu. org

The life-cycle of an Active Object 4. The service provider completes the request and 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 { 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( 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 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 – – – < 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 Symbian OS Structure and Services www. mobedu. org

www. mobedu. org www. mobedu. org

www. mobedu. org www. mobedu. org

www. mobedu. org www. mobedu. org