Why Symbian OS Development is Very Difficult
Development December 19th. 2005, 1:37amSymbian OS is currently the most popular operating systems for smart phones (read also my blog about Symbian OS versus Windows Mobile). The number of third party applications for Symbian OS is growing quite fast too. However, there are many complaints from the developers that Symbian OS development is very difficult. What I mean here is development of native applications using C++ language, not Java applications.
In fact, it is not only for third party developers. Some mobile phone manufacturers have difficulties producing Symbian OS phones because the development cost is too high and the development time is too long. Panasonic even recently announced that they will migrate from Symbian OS to Linux.
Why is Symbian OS development very difficult? Can we make it easier? If Symbian or their licensees don’t make it easier, I am afraid that Symbian OS won’t be an attractive platform any more. I have listed some items to answer that question. They are based on my 3 years programming experience in Symbian OS and 15 years programming experience in total.
- Too many “strange” programming paradigms. Actually they are not really strange; most developers are just not used to it. Active object is an example. Many new developers don’t really know how active object works. We are more familiar with multi-threading paradigm. It took me quite some time to understand active object. The SDK documentation does not clearly explain what active object is (or the developers are too stupid to understand it).
- The SDK documentation is very poor. Many classes and methods contain short explanations only. Many of them even don’t have explanations at all. When I read the Symbian OS documentation, the first question that will pop up in my mind is “how can I use this class/function”? Fortunately, Symbian OS documentation is still better than their licensee documentation, i.e. S60 and UIQ. S60 has the worst API Reference I have ever seen.
- Not enough example codes. Having poor documentation might be okay if there are tons of example codes. The example codes in Symbian OS SDKs are below developers’ expectation. Just an example, ask to any Symbian OS developers, how many hours did they spend to display their “first” list boxes? They can tell you how complex it is.
- The worst development tools. Symbian OS has the worst development tools. For example, it is so difficult to debug on the real phone. They do have emulator, but it is actually only simulator. Sometimes, a code running in the “emulator” will not run in the real phone because the compiler and generated binary files are really different.
The next question is: can we make Symbian OS development easier? There are several signs for that, but it is still a long way to have same level as Microsoft’s MSDN or Borland’s RAD tools. Symbian has migrated their “pre-historic” compiler to the compiler in Symbian 9 (which is very good news). Nokia is developing Carbide.C++, a new development tool that is supposed to be user friendly yet very powerful. Unfortunately, I am still not satisfied with the quality of Carbide.C++ beta version.
Let’s hope that Symbian and their licensee are actively improving their development platform.
Update (6-Jan-06): Some related links about Symbian OS development:
20 Responses to “Why Symbian OS Development is Very Difficult”
Comments are disabled.
December 19th, 2005 at 10:36 pm
Actually, the currently available Carbide.c++ version not a beta — it’s an alpha, which means it’s not feature complete. Although the alpha may be an indication of what’s coming, I at least am not going to judge the product until it’s actually released…
December 19th, 2005 at 10:55 pm
Interesting. I thought it is already a beta version. AllAboutSymbian.com mentioned that Carbide.C++ is already in beta version.
Although I am still not satisfied with Carbide.C++, but it is still much better than CodeWarrior…
Antony
December 28th, 2005 at 12:56 am
I was testing also the version alfa of Carbide C++. It looks good, I would really like to use it instead of Codewarrior. However at the moment it doesn´t want to work with my UIQ 2.1 distribution, it takes the runtime device instead of the real. Just see if it performs better with series 60 SDK.
May 7th, 2006 at 5:29 am
I regard Symbian (and Series 60, I don’t know about UIQ) as the worst software architecture I have ever seen. In my opinion the developers can endure even more hostile development environments if only the system they are developing on is well thought and there is a sufficient compiler support.
Well regarded common knowledge of software engineering is that low coupling and high cohesion are highly desirable in any architecture. Low coupling follows (in case of C++ and relative languages) from delegation and, in general, using the PIMPL idiom. In Symbian and Series 60 the inheritance hierarchies run several levels deep introducing high coupling. The classes usually include also a multitude of methods thus also discouraging high cohesion. The symptoms showing for the developers are brittle base classes that break when one tries to inherit something to introduce new functionality. The classes usually assume some internal state whilst conducting their operations and an unexpected state usually shows just as a mysterious crash of the software.
The problem with Symbian to developers isn’t that Symbian has some “hard to understand” idioms such as active objects, descriptors or clean-up stack. I haven’t met a single developer who has said active objects are somehow difficult to understand as a concept – and as far as I know, similar constructs has been used elsewhere also. To many developers the problem with this system is that, as pointed in some of the other writings, the development for Symbian is not intuitive. Symbian (and Series 60) development consists of “just knowing” at which spot in which piece of code one just has to do something in some predefined order. Failure to meet these demands include the program just closing down when one is trying to start it up with no indication of any error whatsoever or an abrupt crash at some point. People can’t or do not want to remember every obscure detail just to produce a few dialogs.
What comes to descriptors and the clean-up stack construct, I really fail to understand their superior design. Saving space by introducing more classes and inheritance? Does someone really think that the compiler with a virtual table wouldn’t do a better job (as the virtual table is already introduced with the inheritance)? Also, the code needed to handle the descriptor related actions also take-up some space. And in addition, the clean-up stack mechanism really sucks. It was evident already in 1996 that is really isn’t any problem (http://cpptips.hyperformix.com/cpptips/new_except_eff) and one also read about the implementation of exception handling mechanisms from various papers there are available in www.open-std.org (like http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf if I recall correctly).
I really, really fail to understand the problem with the scoped memory management idioms C++ library offers (auto_ptr, shared_ptr, weak_ptr etc.). Can somebody really, seriously claim that writing “auto_ptr myClassManager(new myClass)” is somehow more difficult than using clean-up stack? Unfortunately there are many Symbian and Series 60 developers that really make such claims and go on explaining about the robust memory handling routines Symbian has as if it was not possible to do otherwise. Indeed, there are some people that defend Symbian (and Series 60) development style die hard.
I find it incredible that in every new Symbian book the authors are praising the design of the system and make some points why the design is superior compared to others. They fail to recognize that the systems they are comparing Symbian to aren’t being designed with handheld systems in mind or that their problems are already recognized and perhaps already alleviated. I have developed for Windows (Win32 and .NET), Palm OS and Unix and I can say that none of these systems is as repulsive to work with as is Symbian.
Have you ever wondered why it takes a team of five engineers and a week to produce something one can in a day with .NET? Why Nokia’s phones are constantly delayed due to software related problems (the enterprise series, for instance)? And no, the reason isn’t all the “robust” localisation support or the like. For Symbian developers it may be hard to believe that internationalisation and localisation are easier to do in other systems. The problem with Symbian development lies also in the fact that no self-conscious developer want to do too long Symbian development as it hinders professional development. No modern C++ idioms, no learning great architectural or design principles, no STL, no boost, nothing. At least many people in Finland do Symbian and Series 60 only for the shortest possible time to earn a living and try to find something else. Doing Symbian doesn’t teach anything new but Symbian and those skills aren’t that much of applicable in any other problem domain. Also, in Symbian world the time is usually consumed trying to figure out how to solve something in the context of the system, not the actual problem itself.
No measure of improving the documentation or providing code snippets will change the fact that a great deal of developers and development houses abandon Symbian and Series 60 as soon as it is financially possible. I genuinely (as a Finn) hope the management of Nokia has also realised this and they are just trying to milk the last euros from the Series 60 cow by licensing their IP to interested parties – if there are any. There are also many good intentions and ideas, for instance, regarding to security. Unfortunately the implementation is impossible or very contrived and anyone writing a a shared dll can notice in which way, in effect, the security permissions have to be granted.
June 13th, 2006 at 5:55 am
check wirelexsoft , the have an intresting tool
http://www.wirelexsoft.com
July 24th, 2006 at 5:55 am
I’ve recently purchased my first Symbian-based smartphone and I was excited by the possibility of writing software for my own phone. Unfortunately it took me just two hours to realize how frustrating Symbian programming can be for a C++ developer… It is practically impossible to apply good and robust design patterns and paradigms because the Symbian API itself enforces bad coding style. I can port almost nothing of my existing C++ code which is of course based on the STL, Boost and other widely recognized libraries. This is a shame if compared with the Windows Mobile world where developers can seamlessy port their applications to the mobile platform with very little effort.
However, I still have one unanswered question. I’ve read almost everywhere that Symbian doesn’t support C++ exceptions (and in fact they’re not being used in Symbian/S60 APIs), but I’ve tried a simple test app that does use exceptions and it seems to work fine both in the emulator and in the real device: exceptions are thrown and caught with no problems. What am I missing? I’m using latest Nokia SDK for S60 3rd edition.
July 24th, 2006 at 8:08 am
@Marco: Symbian OS supports exception since version 9. Before this version, it doesn’t support exception.
Since you are using S60 3rd Edition (which is based on Symbian 9), you can use exception too.
Hope this explains…
July 24th, 2006 at 9:16 am
Thanks for the explanation, Antony. This is a very good news as it probably increases the chances of getting the STL into Symbian. I’ll look into that.
July 24th, 2006 at 1:12 pm
I heard rumors that STL is planned to be implemented, but I don’t have any idea when this is going to happen.
August 1st, 2006 at 5:01 am
STLPort is a very effiecient version of STL, suitable also in embedded development. As far as I know, it is also widely in use, for instance, in Windows CE world.
I hope you are not thinking of using exceptions with your Symbian code. Ljmps (long jump), the thing which leaves are essentially about and exceptions won’t mix.
Seeing STL in Symbian or Series 60 is not possible without massive re-engineering since all of the system code in all levels is using leaves and other curious mechanisms. Consequently Nokia is involving in projects like Maemo and there are indications they may actually actively hire developers to do Linux development in the future.
August 1st, 2006 at 5:07 am
Also, if you are interested on architectures and structures, you will notice that Symbian code isn’t the cleanest stuff there is.
Or what would you think of using enumerations to do essentially what RTTI is supposed to do? Or that there are enumerations dwelling in the global namespace (this has been cleaned quite a lot in the recent years, though).
You also will notice that the build system is very unfriendly. Take a look to the Symbian system folders and you’ll notice that having simultaneous projects could be a no-no since your resources could be replaced during some other compilation (they are there with their real names) and you actually could link the wrong resources to your software.
August 1st, 2006 at 8:01 am
@Naurava: Yes, you are right. We should not mix exception and leave. That will just make confusion.
August 18th, 2006 at 7:03 am
@Antony and Naurava: I’ve read in a UIQ forum that when C++ exceptions were introduced in UIQ 3.0, Leaves have been reimplemented as actual exceptions instead of long jumps. Are you sure they didn’t apply the same change to S60 3rd edition? It would make sense…
August 18th, 2006 at 8:50 am
@Marco: Yes you’re right, since Symbian 9, leave is implemented as exception (this includes S60 3rd too). This blog was actually posted before the first Symbian 9 SDK is released to public.
August 19th, 2006 at 5:52 pm
@Antony: I’ve recently purchased a Nokia N80. I’m obsessed with this phone and would like to explore the possibility of developing my own programs. I have no programming experience with C++ or any language for that matter. However, I have a lot of ambition and free time on my hands. Can you recommend the best books (websites too) I can buy to learn the basics to get started?
August 19th, 2006 at 6:13 pm
@shizane: If you don’t have experience in C++, I would recommend using a simpler approach, for example Flash Lite or Python. You can start from http://forum.nokia.com. Flash Lite or Python is much simpler than C++ or Java.
If you want to try C++ development, then I would recommend “Developing Series 60 Applications: A Guide for Symbian OS C++ Developers (Nokia Mobile Developer)” book from Leigh Edwards, et. al.
October 1st, 2006 at 8:10 pm
It seems me Carbide.c++ Pro and Developer Edition is not good tool yet. I use it. But always disturb me. Many UI properties is setted manually. It seems any way to make easy its. For example listbox properties! I spend many time to configure find pane, scrollbar e.t…
October 1st, 2006 at 9:13 pm
@nyamga: I agree with you. I have tried Carbide.c++ Developer Edition in the last couple of days. My first impression, it runs so slow in my machine (I think that is because of Java things)…
About UI interface, it is not as good as Microsoft or Borland’s products. However, they have made some improvements (if we compare to any previous Symbian OS IDE’s).
November 21st, 2006 at 5:25 am
Hi…I have just come out of college and I am very curious to learn this Symbian OS…but i dont know where to start from???Can anybody suggest me a website or book which gives a very easy way to learn symbian….thanks
November 21st, 2006 at 8:39 am
@rajdeep: Welcome to the world of Symbian OS. This has been a question to many new developers, where do I start. Firstly, I would like to recommend you visiting the web sites of two most popular platforms for Symbian OS, i.e. S60 (http://forum.nokia.com) and UIQ (http://www.uiq.com). Download the UIQ and try the examples.
Don’t forget… a good book about Symbian OS is highly recommended. There are some good books out there (http://www.symbian.com/developer/books/index.html).
Good luck.