Porting Code to Symbian

symbian.gifThis week, several things have made me think back to previous projects I have worked on where I have had to port code to Symbian. One thing stands out – if at all possible avoid porting code that’s still unstable and changing significantly. Otherwise, depending how you do it, you will may up doing the porting exercise lots of times. Also, debugging unstable code on the phone as opposed to the donor platform will always take significantly longer.

If code is changing or is likely to change at all in the future, ensure you modify the donor code rather than creating a Symbian branch. You can do this by, for example, adding  #ifdef _SYMBIAN_ for the Symbian specific code. This will prevent you having to do the same porting lots of times. Also, this may even get the donor code writer into thinking what to do to make the code less platform specific!

Finally, here’s a tip I got from the Nokia S60 WebKit. When porting C++ code to Symbian, it can be difficult to detect and report out of memory conditions (in a Symbian way) during donor code object construction without putting lots of Symbian code in the donor code. The solution is to overload new and delete. In the WebKit this can be seen as the OOM_NEW_DELETE macro used throughout the code and declared in oom.h   This uses an ObjectBase to allocate memory which, in turn, uses a MemoryManager that takes care of out of memory issues. MemoryManager does a lot more including logging and Javascript garbage collection and instead it’s possible to just do the allocation and error checking in something like ObjectBase.inl.