Sander van der Wal wrote:
> What do you thing Symbian/Nokia/SonyEricsson/Motorola etc
> must do to improve the Symbian development environment?
> Better docs, better development environment, better
> software components?
Well, yes, everything. The phones need to be more stable, and they have
to make it possible to know _why_ something crashes or doesn't work.
KErrNotfound or CTextLayout-6 PANIC aren't really helpful: the first
doesn't tell you _what_ wasn't found and the second isn't documented.
My 6600 reboots itself every now and then. I need to know _why_, so
if it's a problem with some of our code I can fix it.
There should be real examples for the classes in the SDK. E.g., Nokia
_has_ those examples: they are the software on the phone. They should
stop guarding the stuff so vehemently. Things like the fact that
with a Btree your Key() function must produce a certain kind of TAny*
pointer for the tree to actually work, even though you are supplying
the Compare function as well (hint: the tree doesn't actually use
the Compare when looking for equality). Or all these TMdaPackage*
arguments to the media stuff. If the API gives you an error when you
give it something, how do you know what it is it wants. I think a lot
of the newer Symbian APIs are getting worse: there are more and more
opaque ints, arrays and buffers flying around: you can't figure out
how to use them from the headers anymore. There's a reason why
http://db.cs.helsinki.fi/~mraento/lxr/source is so popular.
There should be something like Ant, or even the ability to use real
makefiles out-of-the-box, which can do builds, stop on errors, recreate
BC while in development, run tests. Something that will support
development for multiple platforms from the same codebase. For gods
sake, it's not even possible to know which version of Symbian you
are building for from headers: there's no version macro in any header.
You have to build all of this yourself. Things are getting slightly
better with the 8 SDKs, but it doesn't help us who want to build for
6.1 still as well.
The emulator's behaviour should resemble the devices more, or the
installation process should a lot quicker. Most of the things we
are doing either don't work on the emulator or are so different
as to make testing worthless (calls, video, audio, bluetooth,
network connection establishment).
Or these so-called non-public APIs. ER5 had lot of debug source code.
Nokia 9200 SDK RBasicGsmPhone, Sendo's first version had everything
Nokia had given to them, Motorola A925 has RMobilePhone (for 7.0,
most things work on Series 60 (based on 7.0s and 8.1), but some
crash the device), the UIQ3 beta includes e.g., etelmm and etelqos
LIBs, Series 60 3rd ed beta headers. None of this is actually
non-public: you just have to hunt around a lot for it, and you
don't know whether anything works before you test it, so there's
a lot of risk. Etel3rdparty.dll would fix some of this, but it's
on no devices. I find it really ridiculous that still Symbian/Nokia
employees will tell you on the forums 'No, those APIs are not available'
when everybody has been using them for years.
I talked with some developers at Nokia, who say that it's really
difficult to work Avkon even when you have the full source and can
debug through the libraries. Without that source it's almost
impossible. The skin-stuff is all Uids and interface casting.
Even Microsoft provides debug symbols for the whole operating system.
Does Symbian/Nokia really think that somebody will be able to
steal all of their ideas if they don't strip debug symbols?
The platform is difficult enough with the beginning-of-90's design,
all these things just make it even worse. What we really don't need
is the platform security (although I do see the point,
I know the problem it tries to solve is real, and no, I don't have
a better answer).
>> Maybe it doesn't matter to Nokia and Symbian. What they (and the
>> operators) want are consumer devices that they can control. The apps
>> will be the designed-by-a-committee and written by 'professional'
>> developers kind.
> Don't forget the operators.
Yep, that's the 'and the operators' bit above.
>> Having a networked general purpose computer that people actually _want_
>> to carry around and use is the biggest thing since sliced bread.
> I don't think that these people want to carry a computer around.
That's the whole point. If they've got a smartphone, they do. It's
the whole pervasive/ubiquitous computing thing in real-life. We
can do things that are qualitatively different from anything that has
been possible before since the people do carry around a computer
> They want a phone, and some of them might want to play a
> game, take a picture and don't MMS that picture. Those few
> people that want a computer/phone buy a communicator, p910,
> winmobile or treo thingie.
But there's so much more that could be done. Ubiquitous information
services (Google maps), rich presence (ContextContacts), automatically annotated-published-shared media
vertical apps, _things we have not figured out yet_. And if
the development is too difficult, we _won't_ figure them out.
We have run a prototype presence service on Series 60 phones with
three user groups (see http://www.cs.helsinki.fi/group/context/).
I don't claim that it's ready yet for general consumption or that
it's something everybody wants. But the thing is, some of the users
(a group of teenager friends) were really, really happy with it. They
thought it really made them closer to their friends, triggered
conversations and helped them organize collaborations. Basically
all of that service and app has been done with the so called
'non-public' APIs. It has to run 24/7 like all phone stuff, so it's
really crucial to know why things are crashing and not working but
all we can do is guess. Like why does the phone lose all GSM
connectivity if you look at it funny, how can we detect that,
and how can we safely reboot in that case. Nokia's presence stuff
is much, much poorer, and they never managed to sell it to any
of the operators anyway.
Again, it's hard to say that Nokia is wrong in it's market strategy
(since it's one of the most successful companies ever), but it's
very easy to say that they really making it difficult for small
developers to do cool things on their devices. And surprisingly
much cool stuff has come from individuals: the Web from Berners-Lee,
Google from two Stanford postgrads, Usenet/UUCP from a few hackers
at CMU and Duke, Linux kernel from Torvalds etc. Small players can
take much larger risks. Nokia can't risk alienating the operators,
(I'm pretty much lumping Nokia and Symbian together here, since
that's how the device market looks like as well as the Symbian