[Post] Game Development 5 based on Nokia s60

In this lecture, we will discuss the communication components of Symbian OS. It must be emphasized that communication technology is very important from the perspective of a game developer. Finally, we will introduce how to receive supplemental game data.

Communication Architecture

The mobile features of smart phones and the rapid development of communication technologies determine their needs for communication modules. Smart phones are used all over the world, but communication services available in every country or region may be very different. Existing services and technologies are constantly evolving, and new technologies are emerging one after another. These facts require the flexibility and scalability of the smart phone communication module. Therefore, the communication architecture of Symbian OS is designed based on these ideas. It consists of several small modules and supports pluggable modules that can be loaded during running. The communication settings can be changed without restarting the system.

Symbian OS 6.1 supports multiple communication technologies, as described in Figure 1. The technology available for a specific smart phone depends on its hardware solution. For example, Nokia 7650 or Nokia 3650 does not have a serial data cable, but it can support serial communication through Bluetooth technology.

Figure 1 Series 60 Communication Technology

The communication architecture of Symbian OS is based on three communication servers: Etel, c32, and esock. Communication services provided by servers are asynchronous operations, so they need to be encapsulated into activity objects. A customer application generally produces three different activity objects: one for data transmission, the other for receiving data, and the other for the Application Communication engine. The Relationship 2 of the communication module is shown in.

Figure 2 communication components of Symbian OS

Etel is a telephone communication server used for applications to access various telephone hardware and services, such as GSM mobile phones, analog modem and fax communication services. This server uses a Dynamically Loaded plug-in module, the telephone communication server module (tsys), to convert hardware-specific information into an understandable format for applications. The client application programming interface of this server is defined in the Etel. h header file. It is mainly composed of rtelserver, rphone, rline, and rcall classes.

Serial Communication Server

The serial communication server (c32) provides a serial port Application Programming Interface for its client. This server uses the Communication Server plug-in Module (csys) to process the actual communication protocol. Symbian OS provides multiple CSY modules, such as processing RS232 and infrared serial communication. Application developers can also use the application programming interface of the serial protocol module to develop a custom CSY module. The custom CSY module is defined in the cs_port.h header file.

The usage of the serial communication server is similar, regardless of whether or not the CSY module is used. First, in the initialization phase, the client loads the required driver, opens the server, and loads the CSY module. After the actual device is enabled and configured, the server is ready to send and receive data. Finally, all resources need to be released. The client application programming interface of the serial communication server is defined in the header file c32comm. H, which consists of the rcomm and rcommserv classes. The following code is an example of the initialization phase of infrared serial communication.

// Load device drivers Tint err = User: loadphysicaldevice (_ L ("euart1 ")); If (Err! = Kerrnone & Err! = Kerralreadyexists) User: Leave (ERR ); Err = User: loadlogicaldevice (_ L ("ecomm ")); If (Err! = Kerrnone & Err! = Kerralreadyexists) User: Leave (ERR ); // Start serial communications server of Type rcommserv User: leaveiferror (iServer. Connect ()); // Load CSY module for ircomm User: leaveiferror (iServer. loadcommmodule (_ L ("ircomm "))); // Open port of Type rcomm User: leaveiferror (iport. Open (iServer, _ L ("" ircomm: 0 "), ecommexclusive ));

The above sample code can be used to load the ecuart CSY module to switch from ircomm mode to RS232, and use COMM: 0 to replace ircomm: 0. Rcomm: The ecommexclusive enumeration in open prevents other rcomm clients from using this port.

You can use the rcomm: Write and rcomm: Read methods to write data to and read data from the port. Both use a trequeststatus and a descriptor as parameters. When the transfer is complete, an event is generated as the activity object. The trequeststatus of the event is sent to the transfer method, which calls the runl of the activity object. The descriptor parameter is usually an 8-bit descriptor. Therefore, if the transmitted data is text, the descriptor needs to be converted to Unicode. The data transfer method may also use other parameters to specify the maximum length or time of data transmission and other features.

For applications, infrared communication is a simple method, but the main reason for supporting ircomm is that it facilitates conversion of previous applications, it makes it easier to use a serial port for communication. Ircomm does not provide all IrDA services compared to other IrDA protocols. For example, the maximum data transmission speed with ircomm is only 9600 bits/s, which is obviously not fast enough for many terminal games that transmit large amounts of data.

Socket server The socket server (esock) provides an interface for using the socket communication protocol. Client application programming interfaces are the same for all protocols and specified protocol behaviors. Socket servers use TCP/IP, IRDA, and Bluetooth protocols that can be dynamically loaded during running. A protocol module may contain multiple protocols. For example, the IrDA module may contain the original irmux, irtinytp, irlap, irlmp, and irobex protocols. The public protocol module corresponding to the tsy and CSY modules can be developed by application developers. The main classes of the client application programming interfaces of the socket server are rsocketserv and rsocket. We can see that they are very similar to rcommserv and rcomm. Rsocketserv processes a server session and provides available protocol information, but does not provide any data transmission services-they are provided by socket-class rsocket. Because the client application programming interface is the same for all protocols, the attributes and semantics of a single protocol are different from those of the tprotocoldesc structure. The rsocketserver: getprotocolinfo method can be used to read information about the currently loaded protocol. The socket server requires at least two different sockets. One is used to listen for incoming connection requests, and the other is used to establish a connection and transmit data. The client application programming interface of the socket server is defined in the es_sock.h header file. The socket server protocol that attracts the attention of game developers is Bluetooth technology. It provides a relatively fast, short-range solution and is free to use, so it is suitable for game development. Compared with infrared communication, Bluetooth has a larger active radius and does not need any visible connections between terminals. As shown in figure 3, Bluetooth is composed of a protocol group. Symbian OS 6.1 supports Bluetooth 1.0 and provides applications with full access to RFCOMM, L2CAP, and SDP protocols. The RFCOMM protocol simulates serial communication, which simplifies the conversion from the original application to the use of Bluetooth technology. Generally, applications use Logical Link Control and Adaptation Protocol (L2CAP) to provide more powerful functions for applications to control Bluetooth connections. The Service Discovery Protocol (SDP) allows applications to query services and service providers. Generally, when creating a new connection, SDP searches for the required terminal and establishes connection settings. Symbian OS also provides a complete user interface component to search for available Bluetooth terminals. It uses the notification framework of Symbian OS to generate a dialog component in the application window and display available terminals as a list. Figure 3 Bluetooth Stack Game data reception To support games to receive additional game data, Series 60 allows third-party games to register their data file formats in the OS using the MIME type. MIME types are used by communication applications such as WML browsers and message applications to figure out the path in which a file of a specific type should be stored. For example, this file can contain new levels, weapons, or graphics for a game. In Series 60, the MIME type used for the game is in the following format: Application/X-nokiagamedata-<application-ID>, <application-ID> indicates the last eight digits of the UID of the Symbian OS game application. The MIME type is declared in the AIF file of the Symbian OS Application Information document: Resource aif_data { App_uid = 0x12345678; // application uid Datatype_list = { Datatype { Priority = edatatypepriorityhigh; Type = "application/x-NokiaGame-Data-12345678 "; } }; } The priority in the datatype structure specifies how the current application processes the data format. Edatatypepriorityhigh is applied to data formats that cannot be processed by other applications. The destination path for receiving data is specified in the INI file named <application-ID>. ini. This file must be in unicode format and contain sddatadir = <game-path>. Here <game-path> is the path used to receive files. This path is relative to the default game data directory c:/Nokia/games. When a game is installed, the INI file needs to be copied to the/system/shareddata Directory, which can be achieved by specifying a path in the PKG file of a game. Series 60 specifies a standard header structure that complies with the MIME type for game data files. The structure of the Header Format is described in figure 4. The data type field can be used to specify the file type inside the game. The name string is a unicode string used to specify a user-visible text to display data options in the menu. The data ID and data version are used to specify the type and version number of the file data. The ngdx field must contain the ASCII string "ngdx ". Figure 4 Standard Header for game data files Prepared by Wayne Li Juan Time: 2004-04-16 Source: yesky