1. Programming Handheld and Mobile devices 1 Programming of Handheld and Mobile Devices Lecture 22 Symbian Rob Pooley rjp@macs.hw.ac.uk

2. Programming Handheld and Mobile devices 2 Symbian OS™ - summary Targeted at ARM-based handsets. Multitasking-Multithreading allows for background applications and multithreaded applications. Shared libraries – DLLs User Interface –Provides support for check boxes, radio buttons, lists, scrollbars, and other components. –Symbian OS UIQ supports one –application presented to the user at a time – other tasks can run in the background. Infrared, Serial, HTTP, HTTPS, TCP, UDP, Bluetooth, socket API, SSL, SMS, Telephony, dual WAP, IPv4/IPv6 stack, etc. Connectivity Software Development Kit to write data synchronization converters and plug-ins. –Supports SyncML. Native programming in C++ language. Java programming using PersonalJava 1.1.1 and MIDP.

3. Programming Handheld and Mobile devices 3 History Symbian itself grew out of Psion Software (hence many of the similarities between Psion's EPOC operating system and modern Symbian software platforms). Recognising that the future was a connected one, with messaging, email and web central, mobile phone giants Ericsson and Nokia (plus a few others) were involved in setting up the new consortium with the Psion staff. Today (2005), Psion itself has more or less ceased to exist, leaving Nokia as the dominant partner in Symbian, at least in terms of investment and new products.

4. Programming Handheld and Mobile devices 4 Structure of Symbian OS applications Symbian OS applications are –object-oriented –based on the Model-View-Controller (MVC) model that allows for a clean separation of the user interface from the application logic. A Symbian OS application consists of C++ header and source files that define and implement the classes that together make up the application, These classes are –the application class, –the document (and a data model) class, – a user interface class. In addition UIQ applications have one or more view classes;

5. Programming Handheld and Mobile devices 5 Symbian application structure (from http://www.metrowerks.com/pdf/IntroSymbianOSforPalmDevelopers.pdf) Model View Controller

6. Programming Handheld and Mobile devices 6 The Symbian OS is an event-based operating system Symbian OS applications communicate with the system by implementing event handlers, –but using an object-oriented approach. the application consists of –an application class that creates the document data model and the user interface, communicates with the system via the application and control frameworks (not shown in figure) through event-handlers implemented in the user interface class.

7. Programming Handheld and Mobile devices 7 Symbian OS UIQ Application Screen Layout A typical UIQ application has menu bar, folders, dialogs, a button bar displaying one or more controls, and/or one or more tabs that enable users to switch between pages – similar to a Palm OS application. For a complete list of all the UI objects supported by UIQ refer to the online documentation that comes with Symbian OS UIQ SDK.

8. Programming Handheld and Mobile devices 8 More on UIQ The user interface in the Palm OS platform is centered on Forms, in UIQ it is centered on Views –both are similar in concept. A View is a control that occupies the screen area between the Menu bar and the Status bar, shown as “Application Space”. A View is owned and constructed by the application’s User Interface object, and is responsible for displaying/drawing data to the screen. It allows the user to interact with the application. Like Forms in Palm OS, Views contain user interface components such as text fields, checkboxes, and scrollbars. All are defined via the resource file or at runtime by using the UIQ API. To handle user interface events, the UIQ User Interface class implements an event command handler, HandleCommandL(), that is analogous to the event handlers in the Palm OS platform.

9. Programming Handheld and Mobile devices 9 Views Views are a very important concept on Symbian OS UIQ applications. All UIQ user interfaces have a base or list view, and a details view. The base or list view displays a summary list of items, and the details view, as the name implies, displays the details for a particular item that was selected from the list view;

10. Programming Handheld and Mobile devices 10 List and Detail Views The idea behind the List/Detail views is simplicity. It provides a consistent look-and-feel across applications. Applications first display a base list view, using text or graphics, providing a summary of items. In the example, the base list view displays a text summary of shapes. In our example the user can choose either a text or a graphics list view of shapes. Selecting an item from the list view brings the details view for that particular entry, ( a blue circle). The application can provide many different details views using tabs. Currently there are no GUI builder tools for UIQ.

11. Programming Handheld and Mobile devices 11 The Application’s Entry Point #include "HelloWorld.h" // The entry point for the application code. It creates // an instance of a CApaApplication. // EXPORT_C CApaApplication* NewApplication() { return new CExampleApplication; } // This function is required by all EPOC32 DLLs. In this // example, it does nothing. // GLDEF_C TInt E32Dll(TDllReason) { return KErrNone; }

12. Programming Handheld and Mobile devices 12 The Application Class The Application Class is responsible for bootstrapping the application itself. It is responsible for returning the application unique id and creating the document object. It must derive from the UIQ Application base class, CQikApplication. To return the application unique id, the Application Class must overload method CQikApplication::AppDllUid(). To create the document object, it must overload method CQikApplication::CreateDocumentL(), passing the application class as an argument.

13. Programming Handheld and Mobile devices 13 Simple example Application’s.h file CExampleApplication : public CQikApplication { private: //CreateDocumentL calls for NewL in //CExampleDocument CApaDocument* CreateDocumentL(); //Returns the Uid of the application. TUid AppDllUid() const; };

14. Programming Handheld and Mobile devices 14 Simple example Application’s.cpp file // Gets the application UID TUid CExampleApplication::AppDllUid() const { return KUidViewApp; // The same UID as is in the mmp file. } // Create the document object. CApaDocument* CExampleApplication::CreateDocumentL() { return CExampleDocument::NewL(*this); // pass this app. object }

15. Programming Handheld and Mobile devices 15 A Basic Document Class.h File: CExampleDocument : public CQikDocument { public: // Constructor. CExampleDocument(CEikApplication& aApp); static CExampleDocument* NewL(CEikApplication& aApp); // Gets the Model. TQExampleAppModel& Model(); private: // Implements CEikDocument. CEikAppUi* CreateAppUiL(); // Second phase constructor. void ConstructL(); private: } ;

16. Programming Handheld and Mobile devices 16 Document class The Document Class must provide a constructor that takes the application object as an argument and that calls the base CQikDocument constructor with the application object as an argument. It must also implement the NewL()method, which completes the construction of the data model. It must also implement the method CEikDocument::CreateAppUiL(), which creates the application’s user interface. To automatically save and restore information, implement CQikDocument SaveL and RestoreL methods. Note that applications should save their data as they go into background, and should restore their state when launched.

17. Programming Handheld and Mobile devices 17 A Basic User Interface Class.h File: CExampleAppUi : public CQikAppUi { public: // Construction and destruction. CExampleAppUi(); void ConstructL(); // Destructor. ~CExampleAppUi(); private: // From CEikAppUi. // Handle commands. void HandleCommandL(TInt aCommand); private: // A View. CExampleAppView* iAppView; };

18. Programming Handheld and Mobile devices 18 The View Class This class implements the user interface that the user actually sees and interacts with. It must derive from the Control framework base class, CCoeControl and from the view architecture class, MCoeView.

19. Programming Handheld and Mobile devices 19 A Basic View Class.h File: class CExampleView : public CCoeControl { public: // Construction, destruction. CExampleAppView(); ~CExampleAppView(); static CExampleAppView* NewL(const TRect& aRect); void ConstructL(const TRect& aRect); private: // Inherited from CCoeControl void Draw(const TRect& /*aRect*/) const; private: // Data internal to View. HBufC* iExampleText; };

20. Programming Handheld and Mobile devices 20 Resource Files As in the Palm OS platform, UIQ user interface objects are defined in the application’s resource file. An application’s resource file typically has the same name as the application, with the extension.rss. The framework reads in the resource file with this name when the application is started. In addition, an.hrh header file links the resource file with the C++ source. Using resource files is always more efficient than dynamically creating UI objects. Even for dynamically modified UI objects, you should create the object itself via the resource file, and then modify it as appropriate at runtime using the UI API. Currently there is no WYSIWYG GUI builder for UIQ, so you have to manually build your resource files.

21. Programming Handheld and Mobile devices 21 Building resource files To create a resource file: Create a text file with the name of your application using the extension.rss. Enter the header information, including the NAME statement and the files to #include. Enter the application GUI configuration information into an EIK_APP_INFO resource. Optionally enter a RSS_SIGNATURE to specify version information, and enter a TBUF used to set the name of an application's default file. Enter the application GUI configuration information into an EIK_APP_INFO resource. Define the resources for the menu bar. For more than one view, define resources for each view. Define dialogs or localizable strings as appropriate.