Wiley.Developing.Software.for.Symbian.OS.2nd.Edition.Dec.2007 (779887), страница 70
Текст из файла (страница 70)
At the time ofwriting, there are no S60 3rd Edition smartphones with touchscreens,so the S60 UI is optimized for one-handed operation. S60 is a verypopular platform and is the platform used on the majority of Symbian OSsmartphones. Smartphones running S60 3rd Edition include the Nokia5500, E61i, N95, and E90 (which is the first communicator device forS60 – previous communicator devices used a separate UI platform, basedon Symbian OS, called Series 80).
Nokia also licenses the S60 platformto other smartphone manufacturers such as Samsung and LG. Examplesof non-Nokia S60 smartphones for S60 3rd Edition include the SGH-i520and SGH-i400 from Samsung.Figure 12.4 shows an example S60 application screen.The entire screen is devoted to displaying information related to thecurrent application, and is divided into the following areas:•Status paneThe status pane is at the top of the screen and displays the currentapplication’s title and system status information, such as the signalstrength shown in Figure 12.3.
As with UIQ, the layout and systemstatus content of this pane is determined by the phone manufacturer.•Main panelThe main panel is situated below the status pane and occupies thebulk of the screen. As with UIQ, it is dedicated to displaying the dataand controls that make up an application’s view.•Control paneThe control pane occupies the bottom area of the screen. It containstwo softkey tabs, which are selected by depressing the hardwarebuttons aligned below them. The control pane displays an Optionssoftkey that, when selected, presents the application’s menu.User inputA four-way controller key, rather like a joystick, is used to navigatebetween screen fields.
Text input is accomplished through the phone’snumeric pad, or, if the phone has one, through the QWERTY keyboard.S60 dialogsAs in UIQ, S60 dialogs are pop-up windows that overlay the application’sview. Dialogs usually consist of a set of GUI controls, but they can alsobe a simple message pop-up. Within a dialog, individual controls areANATOMY OF A GUI APPLICATION365Figure 12.4 S60 3rd Edition Application Screen (E61)Figure 12.5 S60 Dialog (E61)selected by using the hardware controller key, as opposed to tapping ona touchscreen.
Furthermore, S60 dialogs do not contain a row of GUIbuttons, but use the two softkeys instead. Figure 12.5 shows an exampleof an S60 dialog.12.2 Anatomy of a GUI ApplicationIn Chapter 2, I presented a basic example GUI application, and providedsteps to build it and load it to the phone (see section 2.3). To recap, abasic GUI application project consists of the following parts:•The MMP and bld.inf files needed to build the application (orappropriate IDE project file if using an IDE instead of the command line).366GUI APPLICATION PROGRAMMING•A resource file (RSS file) to define the various GUI components,dialogs, and text strings your application uses.•A resource registration file (normally named <application name>reg.rss) required to register the application with the device so itis selectable by a user.•The application source code.•A PKG file to build a SIS file that can be stored on the phone.In addition, an application will usually also have:• A set of bitmaps to define the application’s icon (at various sizes, asdefined by the UI platform used).
In S60 this can be a single scalablebitmap (in what is known as SVT-G format).Source files (.cpp .h etc)Application binarysimpleEx.exein \sys\binInstallation packagesimpleEx.pkgApplicationinstallationfile (simpleEx.sis)simpleEx.mmpResource header filesimpleEx.hrhCompiled resourcesimpleEx.rscin \resource\appsResource filesimpleEx.rssLocalization filessimpleEx.rlsRegistration informationsimpleEx_reg.rsc in\private\10003a3f\import\appsLocalizable registration datasimpleEx_loc.rscin \resource\appssimpleEx.mbmin \resource\appsRegistration resource filesimpleEx_reg.rssLocalizable registrationresource filesimpleEx_loc.rssIcon bitmapsFigure 12.6 Application Project Elements and Build FlowAPPLICATION CLASSES•367A localizable application information resource file (normally named<application name> loc.rss) to define the application’s caption, number of icons, and other information (this, together with theicon bitmaps, is used to generate the RSC file for download to thephone along with the application).Figure 12.6 shows how all of these elements come together to buildan application (using SimpleEx as an example application name).12.3 Application ClassesIn Chapter 2, I also gave a basic tour of the key functions and classes ofa GUI application, using the SimpleEx example (see section 2.3).
Let’slook at this again, but go into more detail, as needed.12.3.1 E32Main() Entrypoint and NewApplication()A Symbian OS GUI application is a process executable (EXE file) andtherefore must contain an E32Main() entrypoint function. For a GUIapplication this just calls EikStart::RunApplication(), passing ita pointer to a function that returns the application object to run.
Beloware these two functions for SimpleEx:EXPORT_C CApaApplication* NewApplication(){return (static_cast<CApaApplication*>(new CSimpleExApplication));}GLDEF_C TInt E32Main(){return EikStart::RunApplication( NewApplication );}The next section describes the basic classes used to implement yourapplication, including the application class.12.3.2 Examining the GUI Application ClassesHere are the classes each application defines as a minimum:1. Application classAs mentioned above, this is the first thing the GUI framework creates. This class is used to identify the application (by returning theapplication’s UID) and to instantiate, and return a pointer to, yourapplication’s document class.2. Document class368GUI APPLICATION PROGRAMMINGThis class represents the application’s data model.
It is also responsible for instantiating, and returning a pointer to, an instance of yourapplication’s UI class.3.UI classThis class handles all UI events, and is responsible for creating theapplication’s default view.4.View classThe view class implements the application’s screen display, includingdrawing the window and the creation of the initial screen controls.An application can have multiple view classes.These classes contain the basic functionality of your application, as well asproviding the interface needed for the GUI framework to start, and drive,your application.
UIQ and S60 have their own platform-specific versionsof these classes, but they derive from a common set of application classesas shown in Figures 12.7 and 12.8. Note that in S60, I show the view classinherited from CCoeContol, but for applications with multiple views(which I do not cover in this book), you would inherit from CAknView(see section 12.7) for the view class and CAknViewAppUi for the UIclass.Symbian OS base application classesCEikApplicationCEikAppUiCEikDocumentCCoeControlS60 platform layerCAknApplicationCAknAppUiCAknDocumentCSimpleExApplicationCSimpleExAppUiCSimpleExDocumentCSimpleExAppViewS60 SimpleExFigure 12.7S60 Application Class HierarchyAPPLICATION CLASSES369Symbian OS base application classesCEikApplicationCEikAppUiCEikDocumentCCoeControlUIQ platform layerCQikApplicationCSimpleExApplicationCQikAppUiCSimpleExAppUiCQikDocumentCQikViewBaseCSimpleExDocumentCSimpleExAppViewUIQ SimpleExFigure 12.8 UIQ Application Class HierarchyThe application classThe declaration for the UIQ version of SimpleEx’s application class isas follows:class CSimpleExApplication : public CQikApplication{private:CApaDocument* CreateDocumentL();TUid AppDllUid() const;};S60 declares it in the same way, except that the class is derivedfrom CAknApplication.
Here is the implementation of this class forSimpleEx:#include "SimpleEx.h"CApaDocument* CSimpleExApplication::CreateDocumentL(){return new(ELeave) CSimpleExDocument(*this);}TUid CSimpleExApplication::AppDllUid() const{return KUidSimpleExApp;}370GUI APPLICATION PROGRAMMINGAfter the GUI application is started, and the framework has obtaineda pointer to the application object, via the call to NewApplication(),it calls that object’s AppDllUid() method to get the application’sUID. It does this as a sanity check to make sure that the UID matchesthe one it expects.
Thus, you must ensure that AppDllUid() returnsthe same UID as the one you specify in the application’s MMP file(KUidSimpleExApp is defined to be the application’s UID in a headerfile) – this can be a very difficult-to-debug problem if these do notmatch. Once the framework has verified the UID, it calls the applicationobject’s CreateDocumentL() method, which returns a pointer to yourapplication’s document class instance.The document classThe document class has two purposes, the first of which is to representyour application’s persistent data. The other is to create the application UIinstance in which this data (if any) can be manipulated.