Wiley.Developing.Software.for.Symbian.OS.2nd.Edition.Dec.2007 (779887), страница 29
Текст из файла (страница 29)
This includes supporting different device screen sizes andall possible resolutions, input devices, and graphical user interface. Usingyour application on the emulator is very similar to using it on the targetphone – not only functionally, but aesthetically as well.Compiling and running on the emulator is straightforward.
First, buildyour software for one of the supported emulator build targets (e.g.,abld build winscw udeb), then launch the emulator via the epoccommand and run it. The emulator emulates the entire smartphoneenvironment – you select and run your program as you would on theactual device.138SYMBIAN OS BUILD ENVIRONMENTAlthough the emulator is fairly similar to the target device, there aresome differences that will be discussed in section 5.6.2.
First, let’s look athow the emulator is configured.5.6.1 Emulator ConfigurationThe emulator is configured through a file called epoc.ini. This fileis located in the <SDK installation location>\epoc32\data\directory of your SDK. You’ll normally not need to touch it, but it can beused to customize emulator behavior.Virtual drivesThe emulator simulates the ROM and flash drives on the smartphone bymapping the Z and C drives as directories on the PC.The combined files in SDK directories epoc32\release\emulatorbuild, target\build type\z (e.g., epoc32\winscw\udeb\z),and epoc32\data\z make up the simulated Z drive.
Files are combined on a directory basis. For example, the simulated smartphonedirectory z:\resource for a WINSCW UDEB build target will contain the combined files of the epoc32\release\winscw\udeb\z\resource and epoc32\data\z\resource directories.By default, the simulated C drive of the smartphone is mapped to theSDK’s epoc32\winscw\c directory.Customizing virtual drivesThe virtual drives can be customized via the EPOC DRIVE ? locationstatements in epoc.ini.
For example, you can add a D drive to point toa specific PC directory by adding the following to epoc.ini:EPOC_DRIVE_D c:\myMMCCardThis results in the simulated phone’s D drive being mapped toc:\myMMCCard on the PC.You can also change the C and Z drives to map to where you want, butnote that, for the Z drive, the specified PC directory must be named z.Memory capacityThe default maximum heap size for your software running in the emulatoris determined by the following statement in the epoc.ini file:MegabytesOfFreeMemorysize_in_MBTHE EMULATOR139If this statement is not there, the emulator uses 64 MB.
Check your SDK’sepoc.ini to see what size is being used. You can change it as neededto simulate the limited memory conditions of the device. Some SDKs setit to realistic settings already. The S60 3rd Edition SDK, for example, setsthis to 32MB, although you can set it lower to stress test low-memoryhandling functionality.The emulator always claims 1 MB to account for general system usage,so to simulate an 8 MB device, use MegabytesOfFreeMemory 7.Other emulator configurationsThere are a variety of other settings in epoc.ini that you can use tocustomize emulator behavior. For example, you can define the text inthe emulator title bar via the WindowTitle statement.
You can alsodefine virtual buttons and hotkeys for the emulator, mapping them tokey code events via the VirtualKey and KeyMap statements. The individual SDKs use these settings to simulate specific phones, so normallyyou would not modify them – however you may want to customizethem in developing specific tests or demos, particularly when testing code that requires platform security capabilities, as discussed insection 7.4.5.Here is an example epoc.ini:# S60 in emulator title bar.WindowTitle S60# button at defined rect pixel area simulates 0 on keyboard.VirtualKey 0rect 126,568 64,28# Following causes left Alt-1 to send EstdKeyDevice0# keycode (keycodes in e32keys.h).KeyMap LeftAlt 1 EStdKeyDevice0See the Symbian OS Library Tools and Utilities guide in the SDK documentation for more details of how to set these configurations.5.6.2 Emulator versus Device FunctionalityThe emulator behaves very similarly to a real device.
The entire SymbianOS code is compiled for both the target device and emulator buildtargets using the same source code – with some required deviations(e.g., if you have any assembly language functions, you must obviouslyprovide both x86 and ARM versions). So, not only can the emulator beused for GUI applications, but you can use it to develop system-levelcode.Will everything that works on the smartphone also work on theemulator? Not everything – no emulator is that good. But for the most140SYMBIAN OS BUILD ENVIRONMENTpart it is equivalent. Here are the main differences between the emulatorand the device:•HardwareThe most obvious difference is that the underlying hardware of theemulator is different from that of the device.
The PC processor instruction sets are different – the PC uses x86 and the device uses ARM – butthis is easily hidden via the C/C++ language. More importantly, however, the peripheral hardware is different, so you cannot use the samedevice driver and hardware abstraction layer code on both. On theemulator, hardware accesses are mapped to appropriate WindowsAPI calls.Note that this differs from Windows Mobile, where the emulatoractually emulates the ARM instruction set and therefore the samebinary can be run on both emulator and device.•Pixels and fontsAlthough, in most cases, the display of a GUI application will be verysimilar on the emulator and on the device, there are likely to be slightdifferences in pixel sizing between the two. For instance, it is possiblefor text to be truncated on the emulator and not on the real device, orvice versa. This can be an issue, if you rely on the emulator alone toperform language translation testing, for example.•Single process versus multiple processesThe emulator runs as a single process, while the device supports themultiprocessing capabilities of Symbian OS.
In Symbian OS v8 andabove, this difference is hidden and the APIs that start and controlprocesses are emulated. However, in Symbian OS versions before that,you need to have special logic (enclosed by #ifdef WINS ) thatuses threads to emulate the processes. Thankfully, there is not muchcode needed to implement this.• Writable static variables in shared librariesWritable static variables are allowed in the emulator, and also onthe real device with Symbian OS v9 (although not on the devicebefore v9). However, there is a limitation on using writable staticdata in shared libraries on the emulator. This limitation is that onlyone Symbian OS process can access a shared library DLL that hasnon-constant static data in it; if multiple processes use that sameshared library, an error will occur. This is because of the singleWindows process model described in the previous bullet, and asingle Windows process cannot contain two copies of the samewritable data.• On the emulator the stack size is not restricted, thus some executablesthat run fine on the emulator may cause panics on a device.BUILDING SHARED LIBRARIES1415.6.3 Debug LoggingYou can print debug output from your program to a file in the emulatorusing RDebug::Print().
You need to include e32debug.h to accessthis. For example:#include <e32debug.h>...TInt ret = Somefunc();_LIT(KDebugmsg,"Somefunc() called, returning %d");RDebug::Print(KDebugmsg,ret);The output is written to the file epocwind.out in a Windows temp directory, typically c:\Documents and Settings\<user name>\LocalSettings\temp. To enable RDebug logging to this file, you need thefollowing line in epoc.ini.LogToFile 1You can also have your RDebug output show up on your IDE console.To do this, place the following in epoc.ini:LogToDebugger 1Note that in release builds, RDebug is not automatically disabled. Formaximum performance it’s best not to call RDebug in release builds, soyou should either surround the calls by an #ifdef DEBUG statement,or create a debug print macro that is defined as RDebug when DEBUGis defined and is empty otherwise.5.7 Building Shared LibrariesIn this section, I show how to build shared library DLLs and describesome of the issues involved.
Some aspects of building a DLL can beconfusing at first, but once you understand how it works, and the issueshave been addressed, you’ll find it straightforward to use.5.7.1 MMP File for Shared LibraryTo build a shared library, set targettype to dll in your DLL’s MMPfile. Then, set the first number in the UID statement to indicate the typeof DLL to build. The static interface DLL is the most popular and basicDLL, and is what we’ll cover in this section. For this DLL type, set the142SYMBIAN OS BUILD ENVIRONMENTUID to 0x1000008d.
The following shows a sample shared library MMPfile from section 4.6.1://MMPTARGETTARGETTYPEUIDSOURCEPATHSOURCEUSERINCLUDEUSERINCLUDESYSTEMINCLUDEEXPORTUNFROZENmydll.dlldll0x1000008d 0x10004264..\srcmydll.cpp...\include\Epoc32\includeOnce you create the MMP, run the bldmake bldfiles and abldbuild build target build type commands as you would with otherprojects.
At some point, you will also need to use the abld freezecommand to freeze the interface to your DLL for release. I discuss thisin more detail in section 5.8. During development, however, you shouldadd EXPORTUNFROZEN to your MMP file (as shown in the exampleabove) to disable interface freezing. The abld freeze command is notrequired when this option is set.Building a DLL produces two outputs: the DLL itself and the importlibrary (this is a LIB or DSO file, depending on the build target, seeProg1 ExecutableImport LibraryFunctions(Frommydll.lib)mydll.dllShared LibraryProg2 ExecutableImport LibraryFunctions(Frommydll.lib)Figure 5.2Import and DLL LibrariesBUILDING SHARED LIBRARIES143previously).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
