In this lecture, the communication components of the Symbian OS will be discussed. It must be emphasized that from a game developer's perspective, communication technology is very important. Finally, describe how to receive supplementary game data. The mobile characteristics of the communication architecture smart phone and the development of communication technology have determined their demand for the communication module. The whole world is using smartphones, but communication services available in each country or region may have a big difference. Existing services and technologies continue to develop, and new technologies are endless. These facts require smart phone communication modules with flexibility and scalability, so the Symbian OS communication architecture is designed based on these ideas. It consists of several small modules and supports a pluggable module that can be loaded during operation. Moreover, the communication settings can be changed without restarting. Symbian OS 6.1 supports a variety of communication technology, in Figure 1. Available techniques for specific smartphones depends on its hardware solution. For example, Nokia 7650 or Nokia 3650 does not have a serial data line, but serial communication can be supported by Bluetooth technology. Figure 1 SERIES 60 communication technology Symbian OS communication architecture is based on three communication servers: Etel, C32, and ESOCK. The communication service provided by the server is an asynchronous operation, so they need to be encapsulated into the active object. A client application typically generates three different activity objects: a for transmitting data, one for receiving data and has an application-end communication engine. The relationship between the communication module is shown in Figure 2. Figure 2 Communication component Etel of Symbian OS is a telephone communication server that is used to access various telephone hardware and services, such as GSM mobile phones, analog modems, and fax communication services. This server uses a dynamically loaded plug-in-Telephone Communication Server Module (TSYS) to convert hardware-specific information to the application understandable format. The client application programming interface of this server is defined in the etel.h header file, which is mainly composed of RTELSERVER, RPHONE, RLINE, and RCALL classes. Serial Communication Server 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 serial protocol module to apply programming interfaces to develop custom CSY modules, custom CSY modules definition in the CS_Port.h header file. The serial communication server usage is very similar, regardless of whether the CSY module is used. First, in the initialization phase, the client loads the required driver, open the server and load the CSY module. After the actual device has been opened and configured, the server is ready to send and receive data. Finally, you need to release all resources. The serial communication server client application programming interface is defined in the C32Comm.h header file, mainly consisting of RCOMM and RCOMMSERV classes. The following code is an example of an infrared serial communication initialization phase.
// load device drivers tint err = user :: loadphysicalDevice (_l ("euart1")); if (err! = Kerrnone && Err! = KerraLReadyexists) User :: Leave (err); err = user :: loadingLogicalDevice (_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.loadCommodule)); // Open port of type rcomm user :: Leaveiferror (iServer, _l ("Ircomm :: 0" ), Ecommexclusive)); The above sample code can be switched from the IRCOMM mode to RS232 by loading the ECUART CSY module, while using the COMM: 0 port instead of IRCOMM: 0. RCOMM :: Open EcommexClusive enumeration enumerates to prevent other RCOMM clients from using this port. You can write data to port data and read data from ports using RCOMM: WRITE and RCOMM::: :: read methods, which are all uses a TREQUESTSTATUS and a descriptor as a parameter. When the delivery is completed, an event is generated as an active object. The TREQUESTATUS for this event is transmitted to the transfer method, which makes the runner of the active object call. The descriptor parameter is usually an 8-bit descriptor, so if the data transmitted is text, this descriptor needs to be converted to Unicode. Data transfer methods may also use other parameters to specify the maximum length or time of data transfer. For applications, communicating with infrared rays is a very simple way, but the main reason for supporting IRCOMM is convenient for previous applications to make it easier to communicate using serial ports. Compared to other IRDA protocols, IRCOMM is unfavorable to provide all IRDA services. For example, the maximum data transfer speed using IRCOMM is only 9600 bits, which obviously is not fast enough for terminal games that transfer large amounts of data.
Setting Server Sockets Server (ESOCK) provides an interface for communication protocols using a socket. For all protocols and specified protocol behaviors, the client application programming interface is the same. Set of TCP / IP, IRDA, and Bluetooth These protocol modules can be dynamically loaded during operation. 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 interface of the socket server are RSocketServ and RSocket. It can be seen that they are very similar to Rcommserv and RCOMM. RSocketServ processes a session of a server, providing information of available protocols, but does not provide any data transfer services - they are provided by the socket class RSocket. Because the client application programming interface is the same for all protocols, the properties and semantics of a single protocol are different from the TProtocolDesc structure. RSocketServer :: GetProtocolinfo method can be used to read information about the currently loaded protocol. The socket server requires at least two different sockets. A use to listen to the access connection request and the other for establishing a connection and transfer data. The client application programming interface of the socket server is defined in the ES_Sock.h header file. The socket server protocol that is the most attractive game developer is Bluetooth technology. It provides a relatively fast, short-range solution and is free to use, so it is suitable for development games. Compared to infrared communication, Bluetooth advantage is that it has a larger activity radius and no visible connections between terminals. The Bluetooth is composed of a protocol group as shown in Figure 3. Symbian OS 6.1 supports Bluetooth version 1.0 and provides permissions to the application fully access RFCMM, L2CAP, and SDP protocols. RFCOMM protocol simulates serial communication, thereby simplifying the transformation from the original application to using Bluetooth technology. The usual selection of the application is to use the Logical Link Control and Adaptation Protocol (L2CAP) to provide a more powerful function to the application to control the Bluetooth connection. Service Discovery Protocol (SDP) allows applications to query services and service providers. Usually, when a new connection is created, the SDP search required terminal and establishes a connection setting. Symbian OS also provides a complete user interface component to search for available Bluetooth terminals. It uses the Symbian OS notification framework to generate a dialog type component on the application window and display the available terminals as a list. Figure 3 Bluetooth Stack Game Data Receive To support game receiving additional game data, Series 60 enables third-party games to register their data file formats in the OS using MIME types. The MIME type is used by a communication app such as a WML browser and a message application, which is used to clarify the path that a certain type of specified type should be saved. For example, this file can contain new levels, weapons, or graphics for a game. In Series 60, the MIME type for the game is the following format: Application / X-NokiaGameData-