Symbian OS C++ for Mobile Phones VOL 1 PHẦN 7 docx

The influence of target devices on your code is even greater when the devices are relatively limited in CPU power and display resolution. With high-resolution displays and near-infinite CPU power, you can render everything with no thought for rounding errors, scale and so on. With small displays, slower CPUs, and no floating-point processor, you have to take much more care in both graphical design and programming. In a map application, zooming introduces considerations not only of scaling, but also of visibility. In a high-level view of the map, you want to see any coastline, a few major cities, big rivers, and any borders. In a zoomed-in view of a city, you want to see district names, underground train stations, public buildings, and so on. In the high-level view, you wouldn't try to draw these details at small scale: you would omit them altogether. And this omission is device- dependent: you can include more minor features in a printed view than in an on-screen view at the same zoom level, because most printers have higher resolution than a screen. There are plenty of other complications with maps, such as aligning labels with features and transverse scaling of linear elements such as roads – and many other applications share these considerations. Fortunately, you don't usually edit maps on a handheld device, so there isn't the need for very quick reformatting code that there is with word processors. As a result, there may actually be better code sharing between printer and screen views. 15.4 GUI Systems Up to this point in the chapter, we have been looking at size and device-independence of graphical applications. Now we will look at the smartphone independence of the GUI systems supporting these graphical applications on mobile phones. The GUI determines the appearance and the interactive mechanisms of a smartphone: the 'look-and-feel'. These are clearly going to vary between smartphones: the GUI is, like the applications that use it, highly device-dependent. This section is divided into a history of the Symbian OS GUI approach and the current situation. 15.4.1 The Evolution of the Symbian OS GUI System In 1987, Psion conceived SIBO as a multiplatform operating system that would use the same system and application engines, but a different GUI (and different application GUIs) to support different devices. Within narrow parameters of variation, the concept worked for a range of quite distinct devices released between 1989 and 1997. From the beginning, Symbian OS was designed with the same system structure, most of which would be independent of the GUI. Application code would be carefully structured into engines (or models) that were also GUI independent. A replaceable GUI framework would define the system's look and feel and applications' GUIs would be separate from their engines. If the GUI were replaced, only a small proportion of the total code in the system would need to be replaced along with it: Figure 15.8 The GUI used in the Psion PDAs was called Eikon (hence CEikAppUietc.). During early development of Symbian OS, Eikon was rewritten twice, but neither event had an impact on application engines – testimony to the effectiveness of the original architectural design. The first rewrite factored the GUI (originally titled HCIL) into CONE (a key item of GUI infrastructure and yet completely independent of any specific GUI) and Eikon. CONE survives to this day, but Eikon has been reworked, as different kinds of phones must be supported. As Psion and others produced new PDAs, ports of Eikon and the applications were made. In 1997, Geofox released its Geofox One, with a 640 × 320 display and a track pad. Psion produced the netBook/Series 7 with a 640 × 480 color screen, and the Psion Revo with a 480 × 160 display, with three-button toolbars. These ports showed that Eikon could scale to a different screen with only relatively minor modifications to itself and its applications. But they also show that even a minor change in screen size can make some software look odd, or prevent it from running altogether unless modified. The Battleships game's application view would look odd on a Psion netBook (lots of spare space above and below) and may not fit on a Revo at all. To get Java certification in 1998, Symbian OS needed (among other things), to be able to run GUI applications and applets written in Java – often ones originally targeted at a much larger device. Symbian did that by adding some more tweaks to Eikon and some support in the AWT implementation that links Java to Eikon. For instance, Symbian added scrolling menu panes, metaphors for emulating right-click, and scrolling app views. Although that meant that Java applications and applets could run without modification under Eikon, it did not guarantee a satisfactory experience with applications whose menus and views were too big to see all at once, and required contortions to produce frequently needed pointer gestures. So by the time Symbian split from Psion to become a mobile phone software vendor, it had became clear that different mobile phone manufacturers would have different requirements for which Eikon, however modified, would not be suitable. Replacing Eikon For some time, Symbian thought that each new device would have its own GUI that would replace Eikon altogether. The first opportunity to do this was during 1997 and early 1998, with the Ilium Accent produced by Philips Consumer Communications (never generally released). With a 640 × 200 display and no keyboard, the device parameters were radically different from those that drove Eikon, as shown below: The experience of the Ilium Accent showed clearly that Eikon could be replaced, but it also demonstrated the costs and the risks involved. Figure 15.9 In 1999 a new strategy evolved, in which Symbian would support only a limited number of GUI reference designs, targeted at different types of hardware, from smartphones to higher- end communicators. The first ideas for reference designs had a range of device parameters for each design, for example,  display in the range 320+ x 120+ pixels,  optional pointer,  keypad. But it soon became clear that this kind of flexibility leads to significant nonoptimality in a design. Let's say that you design a view for exactly 320 × 120 pixels: you go to all kinds of trouble to cram in text and abbreviate words; you use icons instead of text, popup displays, very simple views that sacrifice functionality, perfect alignment of various columns and icons, and so on. A display such as this will break if you make it even a single pixel smaller, but it will look equally odd if you make it larger : Users will wonder why you didn't use the extra space. To give another example, imagine that when you design, you take the view that there may or may not be a pointer. Then you have pointer- driven ways of doing everything and alternative joystick/keypad-driven ways of doing everything. These may not be very compatible: a screen with a pointer can have many more buttons, for example, than one using a joystick or arrow keys. If we deliver a design that is obviously optimized for pointers rather than a keypad or joystick, users with only the keypad/joystick will consider it even more awkward. Worse still, we might forget to optimize the design sufficiently for the needs of keypad/joystick-only users. It's clear that a GUI – especially at the smartphone-end of the market – has to be quite inflexible in its design parameters. It must specify screen size and input devices exactly, and allow for no variation. Architectural consequences The reference design strategy required that the GUI system (previously Eikon) be split into three elements:  A core GUI framework called Uikon (Universal or Unified Eikon). This includes the Uikon Core (eikcore.dll) that contains framework classes such as CEikAppUi and CEikonEnv and the Uikon Core Controls (eikcoctl.dll) that contained a number of concrete controls, such as menus and list boxes, that are expected to be present on all devices. You could write an application using Uikon alone that would be good enough to test some engine APIs, but not much more.  the reference design itself that would add more concrete controls,  a look-and-feel (LAF) module, which could differ for each device. The LAF allows the manufacturer to specify such things as system fonts and bitmaps. In terms of applications, the application engines would continue to be part of the core OS, while reference designs would supply appropriate application user interfaces. Symbian OS reference designs There are several broad categories of smartphone:  a design for keyboard-based mobile phones  a design for a pen-based mobile phone with input via a touch screen  a phone design for one-handed use, with interaction via a keypad. A GUI for keyboard-based mobile phones was developed closely with Nokia for a top-of-the- range communicator device that was launched as the Nokia 9210. Key aspects of the design were keyboard input, a full-color landscape display, a device status pane area, and soft hardware keys that made for quick access to common commands. Figure 15.10 A reference design for pen-based mobile phones is developed by a dedicated team (and Symbian subsidiary) called UIQ Technology, based in Ronneby, Sweden. This design has a tabletlike screen with stylus operation and handwriting recognition. The initial design was completed for the launch of Symbian OS v6.0. For Symbian OS v7.0, it was released under the commercial name UIQ. We've been using this GUI throughout this book. Open platform development Reference designs for one-handed use smartphones are seen by mobile phone manufacturers as an area in which product differentiation is most vital. Here, Symbian offers just the core of Symbian OS, allowing mobile phone manufacturers complete freedom to innovate with Symbian OS as a common starting point. To make sure that GUI innovation is encouraged, Symbian OS source code is open to key parts of the development community to engage and compete in platform development. A platform can include not just a GUI framework, but also new applications, and tools and source code to enable customization and application development. The outstanding initial success here has been the Nokia Series 60 Platform, a design for a color-screen smartphone, optimized for one-handed use. In Europe, Nokia has already released a Series 60 phone, the Nokia 7650, and announced two more – the Nokia 3650 and N-Gage. Series 60 Platform and Symbian OS have also been licensed to manufacturers including Matsushita (Panasonic), Samsung, Sendo and Siemens. In Japan, NTT DoCoMo has launched the F2051 FOMA phone, built by Symbian OS licensee, Fujitsu. 15.4.2 Major GUI Components The major GUI components of Symbian OS are:  CONE: the UI control framework, which provides a general-pur- pose application user interface and controls for this interface. This component is essential to the GUI but independent of any specific GUI. Comprises the classes CCoeAppUi, CCoeEnv and CCoeControl.  Uikon: this ties together CONE and the Application Architecture to give a framework for applications and a set of core controls that are present on all UI variants. Application developers can use the Uikon APIs directly, as we have in the 'drawing' example, or use a more appropriate device-specific API available in the UI variant's own libraries. We did not need to, but we could have used CQikApplication, CQikDocument, and CQikAppUi in our example. Uikon and the application architecture are documented in the Symbian Developer Library.  A phone UI framework: this provides a specific set of custom UI components used by a licensee for their device, including items such as widget libraries, fonts, status bars, and indicators. Mobile phone manufacturers can either build their own, which they can then license so that it is available to other manufacturers, or customize one of the existing frameworks.  the phone UI: the collection of application UIs provided on the phone, which defines the 'UI' as the user understands it. In most cases, the phone UI constituents will be constructed out of components provided by the phone UI framework. The current phone UI frameworks are as follows:  UIQ which supports a touch screen with stylus operation and handwriting recognition and is developed by UIQ Technology (Sony Ericsson P800);  Nokia Series 60 Platform, a design for a color-screen smartphone, optimized for one- handed operation (Nokia 7650, Nokia 3650, Nokia N-Gage);  Nokia Series 80 Platform, a design for keyboard-based mobile phones (Nokia 9210I, Nokia 9290);  Techview – a Symbian-developed framework for testing purposes only;  other – largely specialized frameworks for Japanese phones. An application developed for a given UI Framework will be compatible with all phones using that framework. It is possible to dramatically change the look and feel of the phone whilst maintaining compatibility. Mobile phone manufacturers may substitute new application UIs without affecting the operation of other applications. So, phones can be enhanced and branded through: modifying the existing application UIs, changing application skins (colors, appearance, icons), introducing new applications, or adding dynamic web content. Further, the fact that the UI frameworks available for Symbian OS are based on Symbian's GUI foundation means that porting an application from one UI platform to another is a relatively straightforward task. 15.5 Summary The theme of size and device-independent graphics has taken us through several topics related to UI applications, namely zooming, printing, fonts, rich text, colors, blitting, and web browsing. It has also taken us through a discussion of whole GUI systems. After reading this chapter, you will hopefully be able to write applications that support the above-mentioned capabilities and are portable between smartphones using the same UI Framework. Resources, in the shape of CONE and Uikon, are available to reduce the cost involved for writing new UI frameworks. The writing of these frameworks has increasingly become a licensee responsibility, because of the too high costs of maintaining a family of reference designs within Symbian. The expense of writing a new framework may be avoidable by using UIQ or Nokia Series which can be customized for a new look and feel. Chapter 16: A Multiuser Application Overview So far in this book, we've been learning mainly about how to program the GUI aspects of Symbian OS applications. Now, we're going to move on to a new set of topics: communications and system programming. The attractiveness of Symbian OS as an application platform arises both from the portability of Symbian OS phones, and from their ability to use wireless communications at short range (via infrared and Bluetooth) and long range, using various communications technologies over mobile networks (SMS, MMS and TCP/IP amongst others). I'll start this chapter with a brief review of the communications facilities in Symbian OS. Then, I'll say a little more about the two-player version (tp-ships, that we first met near the end of Chapter 9), which was written without any communications support. Finally, I'll introduce the communications issues faced by Battleships. I'll be describing the full Battleships application and incorporating the transaction-oriented games stack (TOGS) that is specified in Appendix 3. I'll also give a brief account of the TOGS components, which are described in more detail in Chapters 19 and 20. Together with the active object and client-server system programming frameworks (the subjects of Chapters 17 and 18 respectively) they demonstrate the abilities of Symbian OS with short- and long-range communication. If you're not already familiar with communications programming, there are two ways you can approach the following chapters:  avoid communications: just read Chapters 17 and 18, so you can learn about the Symbian OS active object and client-server frameworks, which are useful for all kinds of system programming tasks, whether or not they are communications-related,  take this as an opportunity to learn a few things about communications: you'll find parts of the last couple of chapters a heavy read, and you may need to refer to other communications literature for better explanations of some of the ideas. 16.1 Communications in Symbian OS Symbian OS offers a wide-ranging communications infrastructure, including serial communications over RS232 and infrared, Bluetooth, TCP/IP, IrDA, USB, fax, and communication via GSM and GPRS. Future releases of Symbian OS will offer an even wider range of possibilities, with further support for 3G communications. The main communications facilities that are currently available are seen in Figure 16.1 Figure 16.1 The servers are:  C32 – the serial communications server, which drives the communications ports and also runs serial-like protocols that use other communications services.  ESOCK – the sockets server, which provides a sockets-based API that's used for dial- up TCP/IP, IrDA via the infrared port and Bluetooth.  ETEL – the telephony server, which is used to control phone-like devices including landline and mobile-phone modems, enabling them to make fax, data, and voice calls.  Messaging – provides SMS and MMS send/receive, and Internet e-mail using dial-up TCP/IP for SMTP send, POP3/IMAP4 receive. The first three of these servers work closely together to offer communications facilities to higher-level programs, including the communications applications included in Symbian OS: Battleships uses two communications protocols:  Bluetooth sockets, for short-range links  SMS (short message service) text messages, for long-range links. I'll give descriptions for the implementations for drivers for both these protocols in Chapters 19 and 20. By reading these chapters, you'll gain specific insight into how the main communications components of Symbian OS fit together. You can also find good overview technical information on the communications facilities in technical papers on Symbian's website, and detailed API references in the product-specific SDKs available from the product manufacturers. 16.2 Battleships without Communications The main problem with communications is that it's complicated. The final Battleships application has over 70 classes. There is simply no way to produce an application like that without planning carefully how to get from here to there. Figure 16.2 The starting point for Battleships was the two-player game, tp-ships for short. The purpose of tp-ships was to prove that the Battleships idea would work. Here are some screenshots of a game that's just begun, showing my view of the opponents fleet and my own: You play this game as follows:  Player 1 starts the game by launching it from the menu. The initial view is player 1's view of the opponent's fleet. The player can use the View menu to change the view to My fleet, as shown in the second picture. Player 1 requests a hit on the 'opponent's fleet', and then chooses Hide from the View menu.  Player 1 passes the game over to player 2.  Player 2 can then select eitherTarget fleet for selecting a location to hit or My fleet to view any hits on their fleet before selecting Hide and handing back over. And so play continues. The hide system is good enough to make a playable game between friends, though it isn't really coded to stop determined cheats. The game design in UML is given in Figure 16.3. Figure 16.3 If you compare this with the Solo Ships design described in Chapter 9, you'll notice that  instead of the document owning the controller, and the app UI owning the view, the app UI owns the controller, and the controller owns the view,  the engine and view classes perform the same function as in Solo Ships,  there are actually five views in this application: each player's fleet view and their view of the opponent's fleet plus a hider view. There are two interesting aspects to this program:  It does some interesting Uikon tricks: it has five app views, and it manipulates its menu options. It's useful to know this kind of trick, so we'll have a closer look at the code.  It doesn't use communications to get information about the other player's fleet : instead, it uses object-oriented plumbing. We'll have a look at the code involved, and we'll explain why changing the ten or so lines of plumbing to support communications is going to take several hard chapters to explain a suitable replacement for them. Or, put another way, we'll understand why I wanted to take the tp-ships shortcut before doing all that communications work. Let's look at these two things in turn. 16.2.1 View and Menu Tricks As we saw in Chapter 9, a GUI application can have more than a single view. Many of the built-in Symbian OS applications have more than one view:  Agenda can have day, week, month, year, to-do, and anniversary views  Contacts has card and list views  Messaging supports various types of message types and has appropriate views for each of them. In a Symbian OS GUI application, it's very easy to change views without changing the app UI, because the view is quite a distinct entity from the app UI. The app UI has seven members, five of which are views: CGameController* iController; //Controller for both players COppFleetView* iP1OppFleetView; //Fleet views for P1 fleet and target fleet CMyFleetView* iP1MyFleetView; COppFleetView* iP2OppFleetView; //Fleet views for P2 fleet and target fleet CMyFleetView* iP2MyFleetView; CHiderView* iHiderView; //Hider view CFleetView* iActiveView; There are also three associated flags that control whether the views are visible. The Hide menu option calls CmdHideL() which is coded as: void CGameAppUi::CmdHideL() { ActivateViewL(TVwsViewId(KUidTpShips,KHiderViewUID)); iActiveView = NULL; // toggle player turn if (iController->Engine().IsMyTurn()) iController->Engine().SetSecondPlayer(); else iController->Engine().SetFirstPlayer(); } This function calls ActivateViewL with the UIDs for the application and a view, which causes the framework to change the view, and then sets the flags in the engine that control the visibility of the menu options: void CGameAppUi::DynInitMenuPaneL(TInt aResourceId, CEikMenuPane* aMenuPane) { if (aResourceId != R_GAME_VIEW_MENU) return; // toggle menu item dimming on view displayed TBool view = ((iActiveView == iP1MyFleetView)||(iActiveView == iP2MyFleetView)); aMenuPane->SetItemDimmed(EGameCmdMyFleet,view); view = ((iActiveView == iP1OppFleetView)||(iActiveView == iP2OppFleetView)); aMenuPane->SetItemDimmed(EGameCmdOppFleet,view); // if hider view is active, can't zoom or hide if (iActiveView == NULL) { aMenuPane->SetItemDimmed(EEikCmdZoomOut,ETrue); aMenuPane->SetItemDimmed(EEikCmdZoomIn,ETrue); aMenuPane->SetItemDimmed(EGameCmdHider,ETrue); } } Controlling the visibility of menu options is more interesting. In the code above, you can see that I check the iActiveView member against each type of view and then dim the appropriate menu options depending on the value of the corresponding flag. This is reflected in the application when the framework calls ViewActivatedL: void CFleetView::ViewActivatedL(const TVwsViewId& /*aPrevViewId*/, Tuid /*aCustomMessageId*/,const TDesC8& /*aCustomMessage*/) { Window().SetOrdinalPosition(0); (static_cast<CGameAppUi*>(iEikonEnv->EikAppUi()))- >SetActiveView(*this); } 16.2.2 Object-oriented Plumbing [...]... (Ctrl+N) can be seen in Figure 6 .7 Your options here are related to the communications possibilities, and the way things work through the GSDP server are shown in Figure 16 .8 As this diagram shows, you can play for real using Bluetooth or SMS, or for test purposes using loopback 16 .4 .1 Playing for Real If you are playing for real against someone else, with a real Symbian OS phone, then your easiest option... could do to improve the facilities for games in general, as provided by both Symbian OS and the TOGS stack Symbian OS v7.0 and TOGS as they stand provide an attractive enough platform for turnbased games played at both short and long distance TOGS is designed specifically for two-player turn-based games and can also support twoplayer chat For multiplayer games, or for real-time games, GDP and GSDP will... format that I use to communicate between the two games I will have to change to external format when sending, and change back into internal format when receiving data Furthermore, if I wish to play this game against an implementation running on a non -Symbian OS device, I will have to publish these formats in sufficient detail that someone else will be able to reproduce them using a non -Symbian OS format... probably need to be a networked GDP protocol, and will need to use a friendly form of Symbian OS device address rather than the transient Bluetooth node address 16 .7 Summary In the book so far, we've concentrated on the basic Symbian OS C++ APIs, concentrating mainly on graphics and the GUI In this chapter, we've used an evolution of the Battleships application to introduce the topics of communications... overview of the Symbian OS communications facilities – and of the TOGS stack, which helps to ease the task of writing a communicating application Chapter 17 : Active Objects Overview Back in Chapter 2, we saw that the system design of Symbian OS is optimized for event handling and that all events are handled by active-object RunL() functions We noted that the major frameworks in Symbian OS – CONE's application... has obvious application to games In the longer term, it's possible that many aspects of the Symbian OS architecture may evolve to support real-time games; this requires sound, graphics, and communications improvements, some of which will be delivered in software, some on silicon Here are some more ideas for taking TOGS forward with Symbian OS Better long-distance messaging GDP-SMS provides a messaging... (weeks, for instance), it should allow the machine to be backed up during the course of a game: since backup closes all applications, this means it should save the state of a game in a file and allow it to be restored again It also had some objectives for the book: TOGS should be a good demonstration of Symbian OS capabilities as a communications platform it should provide excellent example code for the Symbian. .. programs 16 .3.3 GSDP – Game Session Datagram Protocol We could have written RGCP as a layer directly over GDP Then, loopback would be useful simply for testing GDP test code, and real communication with Bluetooth would be used for playing a single game between two Symbian OS phones: Figure 16 .5 Admittedly you could play another game using another GDP protocol, say SMS But having only one game on each Symbian. .. controller, to play a game against a different player 16 .6 Taking Battleships Further We had a lot of fun developing Battleships as the flagship example program for the book We aimed to deliver an example that would show the capabilities of Symbian OS as a communications platform and provide lots of excellent code for you to use as a starting point for your own programs With Battleships as it is, I think... real TOGS game 16 .5 .1 The Status View Before we get involved in the communications code, let's look at the status view There's not much to learn from its code, but there are a couple of reminders of the realities of graphic design here My choice for the design of the status view was primarily determined by the capabilities of the device it was designed for, in particular the portrait screen format used . into a history of the Symbian OS GUI approach and the current situation. 15 .4 .1 The Evolution of the Symbian OS GUI System In 19 87, Psion conceived SIBO as a multiplatform operating system. was completed for the launch of Symbian OS v6.0. For Symbian OS v7.0, it was released under the commercial name UIQ. We've been using this GUI throughout this book. Open platform development. keyboard-based mobile phones  a design for a pen-based mobile phone with input via a touch screen  a phone design for one-handed use, with interaction via a keypad. A GUI for keyboard-based mobile phones