SymbianOS, the Symbian operating system that's specifically designed for mobile phones, is currently being implemented on three families of mobile devices:
- Smartphones (codenamed "Pearl").
- PDAs ("Quartz").
- Communicators ("Crystal").
Smartphone/Pearl devices look like typical cell phones, with one-handed operation and a phone-type keyboard. An example of a Smartphone-type device running SymbianOS is Panasonic's x800. PDA/Quartz devices look like PDAs, typically have a stylus/pen, and support handwriting recognition. An example of such a device running SymbianOS is Sony Ericsson's P910 or the Motorola A1000. Communicator/Crystal devices might look like cell phones, but feature a clamshell design which unfolds to display a qwerty keyboard. An example Crystal phone is the Nokia 9300 or 9500. Again, what all of these devices from different companies have in common is that they run the same operating system--SymbianOS.
As the licensees of SymbianOS released SymbianOS-based devices, it became apparent that certain portions of the OS were specific to the device family. For example, handwriting recognition might not make sense for one-handed smartphones that lack pen-type input. The issue of how to make software apply to a wide variety of devices is not a problem faced solely by Symbian. Java, for example, split into J2EE, J2SE, and J2ME (and profiles within J2ME). And taking an operating system example, there are several Microsoft Windows operating system variants, such as Windows XP Tablet PC edition, Windows NT Embedded, Windows Mobile 2003 for Smartphone, Windows Automotive, and the like. Symbian responded by offering additional user interface layers specific to the device family.
SymbianOS, however, is the same operating system across all these devices. For instance, SymbianOS shares a common universal UI layer known as "Uikon/EikStd" across the device families. Sticking to the common UI layer lets you create applications that work across device families (though this also limits the ability to take advantage of features native to the device). At the risk of straying too far afield, there is a thin upper UI layer on top that is specific to each device family. Furthermore, since SymbianOS is object-oriented and customizable, licensees are free to implement custom classes derived from the SymbianOS base classes and brand these custom classes on top of the SymbianOS layers. Nokia, for example, has done this with its Series60 layer on top of SymbianOS. Another example is UIQ, a graphics layer on top of SymbianOS developed by UIQ (a Symbian subsidiary).
That said, my focus here is not on the thin UI layer, but on the database component, which admittedly has nothing directly to do with the UI layer. Thus this discussion is relevant to the variety of SymbianOS phones and companies licensing SymbianOS--Arima, BenQ, Fujitsu, Motorola, Nokia, Panasonic, Samsung, Sanyo, Sendo, Siemens, and SonyEriccson, to name a few. The sample applications and code I present in this article work on devices running SymbianOS from all these companies.
Symbian Philosophy: Small Footprint
Throughout the design, SymbianOS is designed with a variety of assumptions, foremost among them that memory is precious. When there is an opportunity to save memory, the benefits of a smaller footprint are weighed strongly against the costs. SymbianOS is a rich, object-oriented, 32-bit real-time OS that previously used a microkernel architecture. As of version 8.0b and beyond, however, a nanokernel architecture makes it possible to get SymbianOS up and running in a 500KB footprint, (though realistically for more functionality a larger footprint is typical). Furthermore, the kernel does not assume the presence of persistent storage--it can run entirely in ROM.
Operating systems such as SymbianOS, PalmOS, and earlier generation in-house proprietary phone operating systems developed by phone manufacturers were designed for memory-constrained devices. That philosophy requires a careful weighing of memory costs for each additional feature. That is a different approach than an operating system such as Windows or Solaris, for example, which are designed to run on machines with lots of memory and don't need to apply a rigorous discipline to weighing footprint costs. For that reason, the footprint/functionality of operating systems such as SymbianOS and PalmOS have a natural advantage over a retrofitting approach; that is, taking an OS such as Windows or Solaris, and attempting to squeeze the OS onto a memory-constrained device. Just as new features of the operating system as a whole are weighed carefully against the increased memory usage, the internal SymbianOS database component functionality is carefully weighed--the results are database components with a tiny footprint. With the tiny footprint comes limitations in functionality; the goal of the SymbianOS internal database is not how many features can be added, but which are the essential features that can create a viable product, in a tiny footprint.
