Symbian Introduces Open Source Release Plan 92
volume4 brings news that David Wood of the Symbian Foundation has made a post detailing their plans for a release schedule, with new versions due out every six months. We discussed Nokia's acquisition of Symbian for the purpose of open sourcing the popular mobile OS last year. Quoting:
"There's a lot of activity underway, throughout the software development teams for all the different packages that make up the Symbian Platform. These packages are finding their way into platform releases. The plan is that there will be two platform releases each year. ... Symbian^2, which is based on S60 5.1, reaches a functionally complete state at the middle of this year, and should be hardened by the end of the year. This means that the first devices based on Symbian^2 could be reaching the market any time around the end of this year — depending on the integration plans, the level of customisation, and the design choices made by manufacturers. Symbian^3 follows on six months later — reaching a functionally complete state at the end of this year, and should be hardened by the middle of 2010."
Re:Android (Score:4, Interesting)
Simple. We talked about, how people like what they are used to, in earlier news.
Well, I must say, judging the user-interface alone, I liked Symbian. Here in Germany, Nokia phones (with Symbian on them) pretty much dominated the market for a decade. Only recently have the SonyEricsson models taken over.
I know, that the programming interface of Symbian is a horrible horrible joke, that lets the Microsoft Internet Explorer pale in comparison.
So open-sourcing might make it possible to re-implement the horrible part, while leaving the user-interface intact, and hopefully also allowing backwards-compatibility.
We all wanted to program cool stuff for the Symbian platform... until we read about the API quirks. ;)
So maybe now we can.
But do we still want? ...With Android and others out there? We will only know, when we see it happen.
Can I install it on my phone? (Score:3, Interesting)
I have a Symbian-based phone made by Nokia. What apparently happens with these is that eventually a new version of Symbian comes out, new phones ship with it, but the people with older phones are stuck with the old Symbian version. New applications will only be written for the latest Symbian version, and thus the older phones become pretty much useless over time - no matter how much potential they have hardware-wise. From what I've understood this is pretty much what happened for example with the move from S60 2nd edition to S60 3rd edition.
My phone is S60 3rd FP1 (Symbian 9.2), and there already exists S60 3rd FP2 (Symbian 9.3) and S60 5th edition (Symbian 9.4). So I guess my phone will become useless soon.
Will this Open Sourcing in any way help me with getting a longer lifetime for my phone? Or do I need to keep buying new phones just to get the latest Symbian version?
Re:Big news for Symbian developers! (Score:5, Interesting)
Re:Android (Score:3, Interesting)
Symbian does very well in running on small device. It gives the program features to keep their application using small amounts of systems resources and tries to keep them robust.
Too bad these "features" actually make Symbian heavier than other operating systems. CleanupStack leads to bigger binaries than auto_ptr, you need write of code to do anything related to UI, you need heavyweight client / server architecture for many simple things (lots of context switchs), active objects are much heavier weight (and more error prone) than normal callbacks, ...
The fact is that Symbian's relative success has been mostly due to financial, rather than technical reasons.
And it's not like there has been much choice in the mobile space previously. We've had the simple proprietary OS's of every manufacturer, half-assed locked down linux variants of Motorola, MSFT products and Symbian.
Now we have the new entrants: Maemo, Android, the iPhone's OS. All based on Unix.
Symbian development (Score:5, Interesting)
If anyone here's interested in coding for an embedded operating system, I'd strongly recommend running the hell away from Symbian. It's awful.
Let us gloss over the lousy documentation (in which it's impossible to find anything, and where there are no links between chapters --- so, e.g., you can't follow a superclass chain up through the S60 chapter into the Symbian core chapter). Let us also gloss over the lousy build system (a horrible maze of crappy perl scripts, which, apart from being so hideously slow that our project takes the best part of ten minutes to build even if no source files have changed, doesn't allow you to have two source files in the same project with the same name. Even if they're in different directories). Let us also pass quickly over the debugger, trying not to make eye contact, that's unreliable, will only let you debug one task at a time, and which tends to crash if you do the wrong thing.
No, let's talk about the language.
You program for Symbian in C++. Good, you might think. No. This is C++ with all the good bits taken out and replaced by badly designed bits.
Let's take exceptions. There are no C++ exceptions. What there are instead are Leave codes; a macro-and-longjmp framework that replaces exceptions which allows you to throw an integer value and then catch it further up the call stack. Unfortunately because this is implemented without compiler assistance it doesn't unwind the stack frame, so destructors of locals aren't called! All is not lost, though: there's a complicated and easy-to-get-wrong manual cleanup stack on which you can push stuff that you want the system to free for you in such situations. God help you if you forget to push something, or pop something at the wrong point...
Let's take strings. There's no standard string class, of course. What there are are an even dozen different classes for storing strings in different ways: on the heap, on the stack, constant strings owned by someone else, etc. There are some superclasses that will allow you to pass references to these things around without having to worry about the implementation.
Except... it doesn't actually work. The various different string superclasses are incompatible. You can cast a TDes (mutable abstract string) to a TDesC (immutable abstract string). You can't cast a TPtr (mutable pointer to mutable string data) to a TPtrC (mutable pointer to immutable string data). Some of their system functions require you to pass in a reference to a concrete string type, so god help you if want to use a different implementation. You can't use certain implementations in certain contexts. The result is that for some operations you have to allocate a fixed-size buffer on the stack, call a system function to populate it, then copy the buffer into another buffer on the heap, because the buffer-on-heap object is immutable! Despite being resizeable and assignable!
Things get even worse when you want to store multiple strings. There's a labyrinthine maze of string array classes: arrays of fixed sized strings, arrays of descriptors, arrays of pointers to strings, arrays of pointer strings (which are different)... add this to Symbian's bizarre convention where a data storage class allocates memory in its constructor but does not free it in its destructor (which means the user must manually Close() method on all member variables) and simply figuring out who's responsible for freeing a particular object becomes non-trivial. I once spent three days trying to find out how to store an array of strings without leaking them. I kid you not.
(To be fair, they have been trying to fix this with OpenC++, a new programming environment based on, like, standards. It doesn't actually work. The interface to Symbian C++ code is patchy and poorly specced which means it's only really useful for running chunks of third-party code in a sandbox --- you still need to write your actual application in Symbian C++.)
Now lets move on to the OS proper. Like the languag
Re:Big news for Symbian developers! (Score:1, Interesting)
Re:Symbian development (Score:3, Interesting)
Sorry for replying to my own post, but I forgot to mention something.
Nokia also has Maemo, that is a linux based platform. It is only natural that the two somehow "integrate". So maybe this could also be an advantage.