Plug-In : Symbian phone development

Introduction | Research | Project Stage 1 | Project Stage 2 | Project Stage 3 | Results Project Stage 1 Developer Environment I chose to work in C++ and use the Nokia Series 60 sdk, the symbian sdk and the EPOC emulator. The Initial Target device is the Nokia 3650. Applications that are validated on the emulator can be recompiled for the ARM cpu on the symbian device. The resulting application is then packaged into an installation file (.SIS) which is then transferred via bluetooth to the target device. During the research stage I have investigated the following areas of programming that are of key importance to the project. 1. Graphics The 7650/3650 have a resolution of 176x208 and a 12bit Display (grouped 444). It is tricky but not impossible to access the screen buffer directly and perform per pixel operations. Unfortuanately there is no floating point processor and emulation in Symbian runs very slowly. The graphics engine supports sprite masks and different source bitmap depths. After writing a basic grid-pixel manipulator I managed to build a simple water simulation with bilinear filtering. Using the same basic template I wrote a quick voxel landscape renderer (pictured right). In terms of speed a program can acheive a quite fast rate (approx 60fps) by bypassing the windows server and drawing straight to the screen. The difficulty is that the program has to be aware of other functions the phone may require (incoming phone calls e.t.c.) so some additional functions will need to be developed. 2. Sound The chosen system supports the playback of .wav (wave) audio files. However these files can become quite large (particularly if recorded at high quality) and can bloat the size of the final appliaction. The Nokia Symbian sdk also supports playing of sine based tones however these functions do not support any level of synthesis for generating complex sounds. It seems that the use of small wave files would suit the requirements of the Operating system better. The OS does not have a timer with decent accuracy (1/64th of a second is the best you'll get), so accurate audio quantization may be difficult to acheive. 3. Control Control is a major problem aspect when developing for mobile platforms. Primarily designed as a communication device mobile phone keypads operate digitally (as opposed to discrete analogue controllers) and respond better to repeated presses rather than keys held over time. To add to this issue different devices have different key layouts, to account for this an application must implement a simple but flexible control method. Such a method should only involve a minimum amount of keys and not require absolute precision from the user. Conclusion Although further research would be beneficial it is obvious from the initial findings that the Symbian platform offers a familiar programming system and (for a mobile device) a powerful graphics engine. The issue with control would be a problem when writing for any mobile device (except one specifically designed to play games GBA for example) but a simple and elegant solution should be defined (with a minimal set of keys). In terms of sound the application may have to deal with unstable timing but there is a possibility to use MIDI instruments in order to reduce filesize (only supported on the 3650). All these concerns will be taken into account when defining a technical & design document for the chosen project idea. Setting up for compilation The method of developing for symbian based systems is fairly logical, but can seem complex (especially when compared to traditional (single system) developer environments. What the SDK actually does is to create a symbian Operating System on your PC hard drive (residing in C:\Symbian....). However because mobile phones use different processors and file storage the SDK actually creates several versions of the symbian OS on your PC. One is for development and testing with an emulator (ie all compilation and execution takes place on the PC) called WINS. The other version is used for final compilation of code prior to uploading your application to the phone, called ARMI (and also a reduced instruction set version THUMB). This is further complicated by the fact that symbian applications often use resource files that have to be in the right path of whichever system you are using. The SDK demonstration applications come with a few batch files (.bat) which extract/copy and compile demo applications to the correct locations. There are several versions of these batch files, one for each OS (WINS,Armi and Thumb). Unfortunately this can lead to tedious long paths such as C:\Symbian\6.1\Series60\Epoc32\BUILD\SYMBIAN\6.1\SERIES60\SERIES60EX\HELLOWORLD\GROUP\HELLOWORLD\WINS These hold the workspace project files ( I am assuming Visual C++ is the compiler). These project files reference source code in a seperate (higher) part of the tree C:\Symbian\6.1\Series60\Series60Ex\HelloWorld (Notice the workspace files creation duplicates the whole path within the Symbian home directory). This can make it difficult to keep track of which files are current and makes backups difficult. I found it easier to create a single directory to contain both the project files and the source code (including resources). Backups are easier to make and files are more readily accessible. You can change the actual compilation directories too if you like but since you never need access them (they just contain compiler link objects etc) you can leave them as part of the symbian build subtree. Now you should be able to compile and test on the emulator easily. If you want to compile for the target device you must do so from the command line compiler (Visual C++ wont compile for anything other than the WINS windows platform). You can execute a 'abld build armi urel' command from the dos prompt (you may need to check the path in abld.bat is correct) or create a batch file to run this for you. This will generate your target specific application in the appropriate directory (the ARMI subset of the symbian tree for instance). \Symbian\6.1\Series60\Epoc32\release\armi\urel\testapp.app Now this compilation destination is the path you should use in your package file, when you want to make up an installation file for the target device (.sis) SIS files package up all the necessary files for installing an application on the target device. When making a .sis file you need to identify which files to include and where to install them to on the phone. This is done in a small information file called a package file (.pkg). Now you know the location of your compiled files (in the appropriate tree of the symbian OS path on your PC) you can use this path to tell the package file (and the resulting .sis) where to look and where to copy to. Example pkg instruction: (copy from PC to .sis and then install to target location) "\Symbian\6.1\Series60\Epoc32\release\armi\urel\testapp.app"-"!:\system\apps\testapp\testapp.app" Again I found it easier to make a batch file to do this work for me. This means I do all testing and emulation development in Visual C++ without using command line tools. When I want to compile and load to the device I can just run a batch file that compiles the code to the Symbian ARMI release directory and then run a second batch file that uses those files (via a pkg file instruction) to create a resulting .sis file. Both batch files (and pkg file) reside in the same workspace directory. The final .sis file can be easily uploaded to the target device using bluetooth or infared e.t.c. Next: Project Stage 2 >>>