Developing for Symbian
Before I start, I should just say for the record that I’m not a Symbian developer. In fact, I’m not a developer at all. Other than writing C code back in the day, and writing some scripts when I can’t invent any plausible excuse not to, my coding skills are pretty much nonexistent. Don’t ask me about Objective C, although I did once have some comments about Objectionable C!
That said, here’s an interesting set of comments about Symbian development. I don’t know how realistic any of it is. Doing UI design isn’t particularly constrained by Symbian — or if it is, we’re so constrained by the display and input capabilities of the device that we haven’t really gotten as far as being constrained by Symbian!
Maybe some of the developers will have some more substantive contributions.
Yes, I’m a developer.
The article tells the absolute truth about symbian.
Symbian is simple ugly. The only fun you have with it after some time: I managed the beast.
Nokia phones are so powerful in these days, but you only see it, if you do not use any symbian classes and write as much as you can by yourself. I don’t know the teams who wrote symbian, but if you see the code it looks like they were not really enthusiastic or they wrote the whole system under heavy time pressure: No smart ideas, no performance, no good error handling and no love to the system.
At the other side, the article is wrong about apple.
We have no problem with memory and battery?
The memory is slow and the batteries are weak.
And the clever idea is the possibility to run good looking fast developed widgets?
Not, if you are in hurry after 3 hours working with the iphone to search the next power line. Maybe apple use unknown memory chips, unknown displays and brand new high-tech-nano batteries, but I don’t think so. It was the wrong decision, to use this big OS, which is not optimized for this hardware.
Apple bought a good thin layered system for the ipods. Enhance this system with a good compatible graphic engine (shipping a bit later) and nokia must be afraid, but not so.
@XYZ: The funny thing is that I actually get the complete opposite impression of the Symbian API design - to me, the impression is more of a closely-knit team of developers trying to do everything “right”, and putting a lot of thouhgt into the design of their system… maybe too much, so that for an outsider it takes a very long time to actually get into the same overall mindset that the developers of the original system had.
Can’t argume about taste - after having used it for a few years, I for one like it. Not so much because of “having mastered the beast”, but because it starts to make sense after a while.
—
The article itself appears to me as written from a somewhat frustrated perspective, and sounds a bit like the author’s idea of Symbian 9 is largely based on hearsay.
For example, it repeats the widespread myth that *all* Symbian 9 applications need to be Symbian Signed (ok, Symbian and Nokia may not have not been too successful in explaining this properly), and seems to have missed the transition from Leaves to Exceptions (again, something that Symbian hasn’t done too much to popularize :-)).
Unfortunately, in terms of expressing the typical frustration of Symbian developers in their first year, the article isn’t as far off the mark as one would hope…
@Marcus: Yes Marcus, you are right.
EPOC was a good start and the clever ideas are from these former times.
It’s not overall ugly.
But afterwards nothing more happens, only layers over layers.
Do you like how Avkon encapsulate Eikon ?
Never throws away the started Avkon object and implemented it by yourself directly with Eikon ?
It’s not transparent, it’s restrictive and that is not productive.
Or the Error handling: Symbian tries to hide as much errors as possible from the users.
Simple ends the program to not confuse the stupid users.
We have no stupid users, we have only stupid architects.
That is not professional.
Unbelievable: For developer it is also hard to catch errors.
Going a bit deeper:
Therefore I want to say something possitive. A really good thing in symbian:
If you want to develop a good program, you have to write an exception handler.
It shows you where the error happens at runtime. (after shipment, without debug info and so)
At best ask the user to send you the error report (stack trace, register info and so).
I mean here not C++ exception, i talk about access violations and so.
And how to implement it in symbian ? It’s a nightmare.
Yes there is an API to handle it, called “RThread::SetExceptionHandler”.
But what is doing this method ?
It’s changing all registers and stack information before you can reach them.
For system usage to recreate the exception. But this is a user method and not system ones.
I managed it at the end with the debug interface in the 2nd edition.
But in the 3rd edition, also this gate is closed.
Ok. I stop here now, or I feel bad
The floating point emulator. It is really fast and there is a good interface.
Peter,
You’ve inspired me. Thanks!
Tote
For a lively discussion see also slashdot thread ;).
Cheers,
Bradley
I generally agree with the negative comments about symbian’s problems. Let me first say, that nobody cares how new APIs are designed. They are doing new things, I have no better alternative. What developers care about is “C” working like it should. “C++” working like it should. “libc” working like it should.
Whenever Symbian has a choice to make they choose the easy option. Easy for themselves. Hard for 3rd party.
Every design decision you make that restricts the developer is eliminating millions of lines of ALREADY WRITTEN code from consideration. that is why there are so few apps ported to S60.
It’s no good fixing it in the new release. Fix it in the old release already! Update the SDKs to remove some of the problems.
Regarding the SIS signing. Why is there no SIS validator? That is the biggest struggle. The messages you get when failing to install are cryptic and inaccurate.
We live the area of “Rapid Application Development”, however Symbian approaches programming from the early 1990s perspective where you had to master a rather complicated C++ framework (like Borland OWL or Microsoft MFC) to develop a rich Windows application and there is where the problem arise because been a C/C++ DOS and latter on Microsoft Windows programmer I used such solutions then but I do not want to use them again Now!
Surely I can master Symbian C++ framework just like I did with MS-Windows API and latter on with MFC but nowadays I prefer Visual Programming Tools, with forms and components and nice easy to use tools (and libraries) like CodeGear C/C++ Builder, Delphi or Microsoft .NET framework.
Been programming with such solutions the last 10 years, I just can’t convince my self follow the “Symbian way” anymore… even if Symbian discovered the “Holy Grail” of OSes
P.’S
“UI Designer” is a step to the right direction, but you should integrate it also with your Carbide free version to give us a spike to work with your system at no-cost (do you believe that I shall spend a dime to Carbide PRO if I cannot program with Free Carbide?), except if you do not want Symbian (and thus your Smart phones) to flourish with Software
I agree the core user mode API is quite strange and complex (especially the strings) in Symbian, but things are quite the same on other OS es, just look at the WIN32, not to mention MFC. So perhaps the next move to take for Symbian would be, as was also the case for MS, to also provide a light-weight platform for the needs of most of the applications, and leave the hard-core low level tasks of an application to be implemented in the native API. For example Microsoft, besides WIN32, came with Visual Basic, and later the .NET platform, but they never removed the core APIs. And another point, programming in a leight weight platform like Java or C# can become such a BORING task after a while, I know from my experience that after 2-3 months I started missing the good old C/C++ pointers. And if things were that easy good programmers would find it difficult to find new jobs after a while. So I must say, Symbian is not that bad !