Now blogging at diego's weblog. See you over there!

diego's excellent symbian adventure, part one

Mobitopia

in which diego discovers that navigating a sea of acronyms requires some patience

This is the first in a series of articles that describe my experiences learning my way around the Symbian platform. Going into it, what I knew wasn't much. One of my interests was using Java to develop applications for Symbian phones. I had played with the first versions of the KVM (The Kilobyte Virtual Machine, which is at the core of J2ME) when it was first released for Palm in JavaOne 1999 but since then I had lost touch with the platform. I did know that Java's Micro Edition (J2ME) wasn't enough for many applications, and that related to its limitations was something mysterious called MIDP 1.0. I knew that I preferred to stay with Java but that it was likely that I'd have to develop native applications, most probably on C++, so, where to begin?

I first evaluated Symbian as a development platform years ago when it was mainly known as EPOC. Back then the main choices for development in it were C++ and OPL (a relatively simple high level language that is unique to Symbian OS), and Java (the full 1.x JRE) would be available for it soon afterwards on some devices. "Back then" there was, that I remember, a single SDK that you could get from Symbian and use with an IDE. I thought that the situation couldn't have changed that much since then.

I was wrong.

The best starting point for Symbian development is, at the moment, the website of the Symbian Developer Network (which is commonly referred to as 'DevNet' throughout the site even though the name DevNet appears mentioned only once in the homepage, in the 'About DevNet' link). DevNet contains a lot of information, but its organization is a bit confusing. For example, in the homepage we can see links for SDKs, Tools, Languages (C++, Java, OPL and VB). Clicking into one of the options shows even more options, which require some context. In the next few paragraphs I'll outline some of the technologies available and how they relate to each other. I will consider options available for development with C++ and Java, because that's what I know. OPL is a favourite of many in the Symbian development community, so it shouldn't be discounted (Ewan maintains a cool OPL site here).

The idea is to structure things as follows: an introduction (this section), then move on to high-level looks at C++ development and Java, and finally an overview of the different tools for both C++ and Java development.

going native

Starting off with C++, DevNet has a page for "getting started". Again, lots of information, not much context, which I'll try to provide here.

First, at the moment there are development toolkits for three versions of Symbian OS: 5.0, 6.0 and 7.0 (Additionally, there are multiple SDKs for each OS, sometimes multiple SDKs --from different vendors-- for the same language for a single platform combination!). 5.0 is a legacy product, as far as I could see, so we can safely ignore it (It is used basically on Psion handhelds at the moment).

If your interest is (like mine) development for Symbian phones, then Symbian 6/6.1 is the way to go right now, as the list of Symbian phones shows, all but two of the Symbian phones out there or soon to be released run Symbian 7.0. A few interesting devices that won't be released until closer to the end of the year (e.g., the Nokia n-gage) will run v6.x, so it's not as if the platform is being phased out.

But the real question is: if I develop a native application for, say, OS 6, will it run on OS 7?

The short answer to that is: It depends.

Binary compatibility isn't yet the issue, because the compatibility problems are still happening at a higher level. The most popular Symbian phones today use different user interface toolkits, and here is where two new acronyms come in: S60 (Short for Series 60) and UIQ.

S60 is a UI toolkit original developed by Nokia and freely licensed to other manufacturers, although the licensing has to far been, shall we say, a bit limited (to only one other manufacturer so far: Samsung). S60 phones currently on the market include the Nokia 7650, the Nokia 3650, and the Samsung SGH-D700. Well, the S60 platform is primarily oriented towards "one-hand browsing" (that is, typical cell phone use), and it includes browsing, multimedia services, messaging, PIM functions and a UI library. Sounds useful, yes. But, technically, it's not a standard since other handset manufacturers using Symbian have to license it from Nokia first, albeit for free.

UIQ on the other hand, was originally developed by Symbian and then spun off into a company called UIQ Technology and initially adopted by SonyEricsson for its P800 phone. One of the main points of UIQ is that it is a UI designed for larger, touch-sensitive screens (i.e., pen-based interfaces), and maybe devices that are a bit more powerful. UIQ runs, at the moment, only on Symbian OS 7.0.

While both UI toolkits are C++, and they are in fact very similar, they are not source-code or binary-compatible. Moving an application from S60 to UIQ implies changing the libraries you're compiling against, include files, and possibly some of the functions themselves. Another option is to use a toolkit like the recently announced S2S from Peroon, which also provides Symbian-to-PocketPC compiler tools. At the moment, then, the best you could wish for is to have to recompile from one platform to another, using this additional toolkit (Pricing or availability of S2S is unclear, since the site doesn't have downloads or information--maybe it's not ready yet).

Reading documentation for some of this technologies can be sometimes be a baffling ordeal. Consider for example this paragraph from a paper describing UIQ's approach to user interfaces: "On top of the generic technologies are the application UIs and a few other reference design-specific libraries. There’s one library of particular interest that straddles this gap, called Qikon. Qikon is the UI library for UIQ, and is derived from Uikon, the generic UI library across all of the DRFDs. Uikon in turn was an iteration of Eikon from Symbian OS Release 5." (Note that this article, while still applicable is a bit old: it applies to an older version of UIQ, 1.x, while the P800 uses UIQ 2.0--which is why the mention of Symbian 5). If you think that the "Eikon" mention is strange, consider this step-by-step introductory tutorial for developing a Hello World application for Series 60. Quote: "From the wizard dialog you can select which type of application you would like to create. Leave the "EIKON Control" option selected and specify "Hello World" as the Application Title." You see, EIKON shows up again here. We are supposed to "leave the EIKON option selected" but we have no idea why (in fact, the tutorial does not explain what EIKON is at all, but we get the impression that this Eikon fellow was quite something-- and a bit of digging tells us that EIKON was Psion's UI framework for EPOC).

It might sound a bit unfair of me to take paragraphs out of context, but I wanted to show it as an example of what one can regularly run across when reading Symbian development documents of any kind. You're happily reading and suddenly you get a sentence (like in the first example) that says: "Qikon is the UI library for UIQ, and is derived from Uikon, the generic UI library across all of the DRFDs". That leaves you thinking: DRFDs? What the hell is a DRFD???" A google search on the acronym appears to imply that it's a Demolition Remote Firing Device, but I'm sure that's not the case. Searching for "Symbian DRFD" gives only three results, but google suggests "Symbian DFRD" --note the transposition of the F and the R, which yields more results, and after a few clicks and searches we discover that a DFRDs are "Device Family Reference Designs" which are variations of Symbian OS tailored for different types of mobile devices. The Symbian FAQ at Nokia's Site (PDF) has some useful information on the acronyms and such. When clicking on Symbian articles, be careful: a surprising amount of them exist only in PDF and so you'll end up waiting quite a bit to see anything at all. Better to look at the file type on the link and download them if necessary.

The point of this digression is to give an example of what you are likely to find as you delve into Symbian development. Keep in mind that Symbian is responding to the needs of different manufacturers that compete with each other but are all shareholders in Symbian; this is bound to create some conflicts. Additionally, there are still "historical leftovers" like the EIKON references that tend to be confusing and only known to those that have been working with Symbian/EPOC for a long time.

Russ pointed me to this presentation (PDF) from the Symbian Exposium '03 on "Targeting multiple Symbian OS Phones", which is a good summary of how portability can be handled between phones running the different toolkits. Highlights are "Some application components have to be altered", and "80% of code can be kept unchanged between ports".

Things are getting better though, and we are still in an early stage of this process (For example, a few months ago Nokia and SonyEricsson announced that they'd align their developer tools for S60 and UIQ, so you'll be able to use a single toolset to target applications for both environments.)

close, but no dice

The conclusion is that, at the moment, there aren't any options for developing a cross-platform application in C++ that would port across all Symbian 6.0/7.0 devices. The rational choice is to target S60 or UIQ (and then possibly use another toolkit to recompile the sources to target the other platform). In any case, S60 is not yet supported by all Symbian phones, so you should check whether the phone you want to target supports it.

The last point in particular means that for true cross-platform applications you will have to use Java. J2ME and its flavors (with Symbian-specific information) will be the topic of the next part in this series. Until then!

Categories: soft.dev
Posted by diego on July 27, 2003 at 12:43 PM

Copyright © Diego Doval 2002-2011.