Jim Moy

I’ve recently completed a project writing code for two devices based on the Symbian OS platform, specifically the Sony Ericsson P800 and the Nokia 60 Series phones. I gained from the experience of many others in the form of forum posts and sample code, so I thought I’d share a few notes for prospective Symbian coders coming from other platforms like I did.

• If you’re the “just jump in” type of coder like I am, the first two hurdles you’ll bump into are two-stage construction and its associated memory management, and descriptors. They’re everywhere.

  The first is seen elsewhere as a “best practice” for handling resource acquisition in object construction, but it’s a required pattern of usage on Symbian.

  The second is Symbian’s string class equivalent. If you’ve got a lot of C++ experience, you’ll probably be able to figure them out on your own from the online docs that come with the various device SDKs. They’re different enough from MFC’s CString or STL’s string classes that you’ll want to refer to someplace like Chapter 5 in Professional Symbian Programming as a good place to get the concepts straight in your head.

• If you’re using CodeWarrior, which integrates things pretty nicely, you may still need to get to know some of the utility programs like bmconv and aiftool. For example, I built my own toolbar since the ones under UIQ didn’t satisfy my needs, and the bmconv tool was essential for automating the builds.
• There are some free apps out there with source code. Use them, they can be more helpful than the generally okay docs when something is missing. As of the posting date, here’s one example you might take a look at, and here’s another.
• When you get crashes, keep track of the cryptic “panic” numbers and codes. They’re somewhat documented in both the UIQ and Series 60 SDK’s, and the descriptions there may give you good hints as to what section of code is messing up. If anyone knows where to find a more complete reference to these Panics, I’d appreciate a pointer.
• When you’re stuck and don’t understand why it’s misbehaving, just change things around, because it’ll provide clues. There are interesting interactions between the view architecture and the various pieces of the control framework in particular that will do unexpected things if you haven’t got the code or resource definitions quite right.

  Maybe I’m crashing while switching views, or activation doesn’t do quite what I expected, or key presses are dissappearing, or a member function call occurs on an object after it looks like I’ve correctly timed a deletion — whatever. Move some code somewhere else, make it do things in a different order, leave a memory leak so you can see what happens if you don’t delete an object in question. Think of weird ways you might be able to make it “tell” you something interesting, because it’s really a big black box and that’s one of the tools you have to figure out how it’s behaving.

  This is good advice for any object oriented framework that has been bundled up into a black box that you can’t step through, but I’ve found I needed it more on Symbian that other places. It may also be the slight differences between the emulator and device. Or maybe it’s just because I’m a relative beginner on the platform… I understand that becoming a development partner with Symbian can get you access to the OS source code, and that would be a big help, but we decided not to invest in that at this point.

• Set up logging. Since you can’t debug on the device, you’re bound to run into something that behaves a bit differently on the emulator than on the device. The first thing I do is set up a pointer in thread local storage that’s accessible from everywhere (because you can’t have modifiable globals in DLL, this is well documented) and hold a handle to a log file in C:\System. From then on it’s printf debugging until we get native device debugging (not holding my breath).
• Symbian has a searchable knowledge base that appears to be useful, but I’ve never found the answers to my specific problems there. I’m not sure why, maybe because the underlying OS is documented and been battle tested just fine, it’s just the layered UIQ and Series 60 interfaces on the top that I had problems figuring out.