Slashdot Mirror
Symbian Introduces Open Source Release Plan
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."
> Not only that, but there are many different versions (V9, V9.1, S60 3rd Ed, S60 FP1, S60 FP2, 9.4, 9.5 and that's just the recent ones) and they are mostly binary and source incompatible.
That's balony. I (helped) develop an S60 application, and the differences were significant between S60 2nd and 3rd editions (there was a big OS-break then - akin to OS9/OSX), but otherwise there were very few OS version specific changes needed to the source. The main things I remember were that the 2nd edition phones and the first few of the 3rd edition phones had a WAP browser; and the newer ones have the webkit ones (yes, before the iPhone). The other difference that came to mind was that S60 3rd edition came with an OpenGL driver, while for 2nd edition, we had to package one with our app.
Actually, our code base was common for both S60 2nd edition and S60 3rd edition...the differences there were for SDK differences (like having to get things signed/etc/etc).
In the end, we had just two versions for users to install - one for 2nd edition, and one for 3rd edition. From the user's point of view, it didn't matter which of the 2nd edition or 3rd edition phones they had...and a web/wap page could easily tell from the user-agent which one to provide for the user to install.
Really, not rocket science at all.
Calling them 'mostly binary and source incompatible' is just rubbish and plainly FUD.
Also, what's wrong with having different versions? Even something like the iPhone OS has two (soon to be three) versions. It's mostly a symptom of having a successful platform and many different target phones. Perhaps when there are many different iPhones and Android phones, then they will have the same issues.
Yes, the development platform is not so much fun to use, but that's a different thing to the target OSes being different. I even got the SDK working on Linux the other day and plan to do some applications in my spare time, in the hope that I can sell stuff on the soon-to-open Ovi Store. It seems like the SDKs will even work on OSX for all you Apple guys. Personally, I find it kind of refreshing to actually understand what's going on, instead of have a GUI 'protect' me from it all.
I think the Ovi Store could well be very significant. The prospect of having access to such a large user base has to turn some heads, surely. It *is* huge, especially if they can enable it on existing phones too. I guess they could do that by using the Download! application somehow - the Download! application is what might be called the 'app store' that's been around for many years (yes, way before iPhone even was a twinkle in any Jobs' eye) on S60 phones - since it's already on probably well over a hundred million phones already.
We'll see, I guess.
Max.
The good old symbian myths:
- No c++ exceptions, below the rebuttal:
http://developer.symbian.com/main/downloads/papers/Exception_Handling_in_Symbian_OS-v1.02.pdf
- Descriptors: yes, they are weird, but they do make sense:
http://descriptors.blogspot.com/
- Standards: Open C, pips (posix compliancy), S60Python. Is hard to build an OS on a language which was not standard when it was being designed.
- there are more runtimes than symbian c++ (if that is too hard for you):
http://blogs.forum.nokia.com/blog/hartti-suomelas-forum-nokia-blog/2007/05/17/slides-for-the-s60-runtimes-presentation-on-svsig
plus: QT for s60 is around the corner and will remove some of the pain for developers.
http://www.qtsoftware.com/developer/technical-preview-qt-for-s60
about the debugger: I still don't see the problem with carbide.c++ 2.0 and trk to debug symbian phones. You can also go fancy an use lauterbach or any other ICE that you like. Also you can use the emulator for 90% of app developement, so unless you are making something tied to the HW your target debugging should be a breeze (if you know what you are doing).
and about android: Please go on an read the code, run a grep for "fixme", then another for "??" and another for "hack". I specially like the TI AT command workarounds in the their telephony RIL reference implementation. This guys have put it together with gum and tape, product quality my ass.
Yes, they have good ideas, they are not reinventing the wheel and is easier to use (sometimes), but feature wise, production quality wise, android is not just there...yet.