I’m increasingly looking forward to the unveiling of lots of secrets about Symbian software. The more I hear about specific ideas third party developers have for add-on and plug-in software for Symbian devices, the more I realise that their needs will be better served once the Symbian secrecy kimono is swept away.
Take one example, from my browsing of the Forum Nokia Developer Community Discussion Board. User “jas76” asks a question:
Hi, I need to mute downlink audio (i.e. from remote end) during call; and play music on music player. Remote voice is currently mixed with music and couldn’t find a way around it with any public API/SDK plugin. All discussion thread finaly result in to microphone mute. (mute mic is possible though via SDK plugin)
Is this possible from any private API that we could request? or there is no API that could achieve it? Any experince from Nokia partners in this area?
Less than 90 minutes later, there’s an answer on the Forum, from one of the Forum Nokia Experts, “symbianyucca”:
I’m rather sure there are not such an API available.
Needless to say, jas76 had been hoping for a different kind of answer. He followed up:
Hi Symbianyucca, Thanks for your inputs. So disappointing that such a simple functionality/requirement and Nokia made it not difficult but impossible. If this is because of security reason they could lock it under some capability. But making it impossible is really really disappointing.
Thanks anyways for your response. Anyone else tried to get API from Nokia for this purpose?
And the thread goes cold.
Is the answer on the Forum correct? Is the particular aspiration of the third party developer one that is reasonable, from a technical point of view? The point is, it’s really hard to tell, without gaining access to information that is currently not available to the majority of participants of this kind of forum.
By the way, before going further, I must say that I am impressed by the helpfulness, knowledge, friendliness, diligence, and upbeat humour shown on these forums by the Forum Nokia champions – who are generally providing answers on a voluntary (unpaid) basis. These individuals do a fine job, oiling the wheels of discussion, and making lots of useful suggestions, to nurture and expand a spirit of community self-help. However, there are often limits on the help that can be provided in this way. That’s because of current restrictions on distributing the source code of Symbian OS and S60. Without access to this source code, many discussions become stalled.
Take another example. Significant numbers of developers (including researchers at universities) are keen to explore the interesting possibilities of the information known to the phone about its location. The phone itself is usually in contact with several different cell towers. If applications could access this full set of information, it would allow them to determine the position of the phone more accurately than is possible by just using information from a single cell tower. However, I’m told that no APIs are available that provide this richer set of information. On the other hand, internal Nokia applications do seem to be able to benefit from this information. (Note: I understand that this information will be available to third parties in Symbian OS v9.5 – but that’s of little comfort to developers who are trying to develop location-aware applications on existing Symbian phones.)
That’s two examples. There are many more. I probably not have picked the best examples. I’m not sure about the details of each example, and I may got some of the details wrong. However, the general points seem clear:
- Developers will in principle benefit considerably from being able to delve into currently restricted information on Symbian and S60 APIs, once the code is placed into open source;
- This will avoid the situation where, at present, too many interesting discussion threads become stalled, and enthusiasm withers away before it has the chance to create an important innovation.
On the other hand, there are of course drawbacks to this kind of openness. There are often good reasons why internal APIs have not been publicised.
For example, as soon as they are published in official SDKs, APIs become subject to tight compatibility change control. This change control is vital, for the stability of add-on and plug-in applications that depend on these APIs. But it also restricts the freedom of internal Symbian and S60 developers to evolve and improve these APIs. Especially while APIs are at an early stage in their life, there can be compelling reasons for developers to completely change their design. So there will need to be a careful education campaign, that explains that internal APIs (and many other pieces of information which developers obtain by browsing the source code) can change without warning – and may even change between two apparently similar versions of the same phone (distinguished, perhaps, only by a minor build number)!
- For this reason, I expect that discussion forums will collect and publicise information about the ways these internal APIs change between different phones.
Secondly, some part of the code of a phone will not be made public. Like it or not, the owners of some parts of the code may decide that the code would allow leakage of knowledge of commercially sensitive algorithms, data structures, or whatever. However, the good news is that, in the world of the Symbian Foundation, the extent of this kind of withheld code will be very much less than at present. Whereas the current bias often seems to be, “in case of any doubt, withhold”, the new bias will be, “release the code, unless there’s a very strong specific reason not to do so”.
So we can look forward to moving from a situation where developers are often constrained by lack of information, towards one in which the primary constraint will be their own ability. That’s a much better situation.
That leaves the question: how long will we need to wait? Given that it may take up to two years (from the initial SyFo announcement on 24th June) for the completion of the exercise to move Symbian platform code into open source, it may seem this is a far-off future vision. But many things will be happening before the end of that two year period. Parts of the source code will be released, in a staged manner, at various phases during 2009. We’ll be moving as fast as we can, subject to due care and attention – and subject to continuing to meet our very important “business as usual” commitments of interim deliveries of technologies and customer support.
dw2 
The singular biggest thing that would rebuild my faith in the foundation would be if Nokia had a clean distinction between Applications and Operating Systems divisions.
At the moment it appears when the the applications teams need an API or an OS change they can get it made and locked to their project so 3rd parties are locked out of building competing applications.
Microsoft was sued in the EU for exactly this kind of anti competative and discriminatory behaviour and I hope that the Foundation will curb this kind of abuse so that all of us 3rd party developers can develop under the same constraints as Nokia internal application developers (ie not OS developers).
For example I would like to be able to work with the headset buttons but at the moment this is locked to the Nokia music player and cannot be overridden. What I would like to see is the music player team operate under the same banner as a third party so the API they use to access the headset hardware can be licenced by us to provide the same functionality.
(I speak for myself and this is not the view of company I work or may have worked with before)
Comment by pault — 25 September 2008 @ 11:28 am
The singular biggest thing that would rebuild my faith in the foundation would be if Nokia had a clean distinction between Applications and Operating Systems divisions.
At the moment it appears when the the applications teams need an API or an OS change they can get it made and locked to their project so 3rd parties are locked out of building competing applications.
Microsoft was sued in the EU for exactly this kind of anti competative and discriminatory behaviour and I hope that the Foundation will curb this kind of abuse so that all of us 3rd party developers can develop under the same constraints as Nokia internal application developers (ie not OS developers).
For example I would like to be able to work with the headset buttons but at the moment this is locked to the Nokia music player and cannot be overridden. What I would like to see is the music player team operate under the same banner as a third party so the API they use to access the headset hardware can be licenced by us to provide the same functionality.
(I speak for myself and this is not the view of company I work or may have worked with before)
Comment by pault — 25 September 2008 @ 11:28 am
I look forward to the interesting discussions at the smartphone show on this….
Comment by pault — 25 September 2008 @ 11:29 am
I look forward to the interesting discussions at the smartphone show on this….
Comment by pault — 25 September 2008 @ 11:29 am
>I look forward to the interesting discussions at the smartphone show on this….
Yes, so do I đ
// dw2-0
Comment by David Wood — 25 September 2008 @ 6:34 pm
>I look forward to the interesting discussions at the smartphone show on this….
Yes, so do I đ
// dw2-0
Comment by David Wood — 25 September 2008 @ 6:34 pm
Whereas the current bias often seems to be, “in case of any doubt, withhold”, the new bias will be, “release the code, unless there’s a very strong specific reason not to do so”.
Heh. I made a similar decision-making innovation last year with Nokia Beta Labs. Whereas before the mode was “In case of doubt, withhold”, now it is “Publish it unless there is a clear reason not to do so”.
Nowadays, I make decision proposals to management in this way: “I propose xyz. Please comment by xx/yy if you you object, or if you want further discussion. Otherwise, we’ll proceed with this”
Works perfectly. Never underestimate the power of default.
Comment by Tommi Vilkamo — 25 September 2008 @ 6:35 pm
Whereas the current bias often seems to be, “in case of any doubt, withhold”, the new bias will be, “release the code, unless there’s a very strong specific reason not to do so”.
Heh. I made a similar decision-making innovation last year with Nokia Beta Labs. Whereas before the mode was “In case of doubt, withhold”, now it is “Publish it unless there is a clear reason not to do so”.
Nowadays, I make decision proposals to management in this way: “I propose xyz. Please comment by xx/yy if you you object, or if you want further discussion. Otherwise, we’ll proceed with this”
Works perfectly. Never underestimate the power of default.
Comment by Tommi Vilkamo — 25 September 2008 @ 6:35 pm
>The singular biggest thing that would rebuild my faith in the foundation would be if Nokia had a clean distinction between Applications and Operating Systems divisions.
I have to start by saying I agree that Nokia have to play fair or it isn’t going to work. People will take their toys and play elsewhere.
But that’s the solution in cases like this: take your innovation and implement it on another platform – if you can. Microsoft gets sued because they have an established monopoly and they abuse it. I think regulators will let market forces work out who’s allowed to do what in the mobile space for a few years yet.
The chances are (and I don’t know for sure in this case) that the headset buttons are hard-coded to the built-in music player and there is no way to register to recieve them in another application (I do know for sure of other cases that work like this). That’s why you can’t get an API, rather than any deliberately anti-competitive behaviour.
Once the foundation platform is open it should be possible to change anything you need to access (as long as it’s done in a way that doesn’t negatively impact anyone else) but there will still be an advantage of time for Nokia and other device manufacturers. They can implement their innovations on the next device they release. Other third party software vendors will have to wait for the next platform release to be taken into devices, after they’ve got their changes to the platform approved/included. Also, the device manufacturers can bundle firmware patches for old devices with their applications if needed.
I think the only way around this is full patching of device firmware (either MS style “you need to download an update to use this…” or some kind of officially sanctioned patches to bundle with third party applications). Will consumers go for it? It’s certainly technically possible already. Will device manufacturers implement it (they’d have to manage the firmware updates)? Is it at all practical?
To some extent we have to accept that smartphones aren’t quite PCs yet and live with the limitations. With the foundation you should at least be able to get them fixed in the next version and even contribute the code to do it (or pay someone else to) if you need to speed up the process.
Mark
Comment by m_p_wilcox — 26 September 2008 @ 8:38 am
>The singular biggest thing that would rebuild my faith in the foundation would be if Nokia had a clean distinction between Applications and Operating Systems divisions.
I have to start by saying I agree that Nokia have to play fair or it isn’t going to work. People will take their toys and play elsewhere.
But that’s the solution in cases like this: take your innovation and implement it on another platform – if you can. Microsoft gets sued because they have an established monopoly and they abuse it. I think regulators will let market forces work out who’s allowed to do what in the mobile space for a few years yet.
The chances are (and I don’t know for sure in this case) that the headset buttons are hard-coded to the built-in music player and there is no way to register to recieve them in another application (I do know for sure of other cases that work like this). That’s why you can’t get an API, rather than any deliberately anti-competitive behaviour.
Once the foundation platform is open it should be possible to change anything you need to access (as long as it’s done in a way that doesn’t negatively impact anyone else) but there will still be an advantage of time for Nokia and other device manufacturers. They can implement their innovations on the next device they release. Other third party software vendors will have to wait for the next platform release to be taken into devices, after they’ve got their changes to the platform approved/included. Also, the device manufacturers can bundle firmware patches for old devices with their applications if needed.
I think the only way around this is full patching of device firmware (either MS style “you need to download an update to use this…” or some kind of officially sanctioned patches to bundle with third party applications). Will consumers go for it? It’s certainly technically possible already. Will device manufacturers implement it (they’d have to manage the firmware updates)? Is it at all practical?
To some extent we have to accept that smartphones aren’t quite PCs yet and live with the limitations. With the foundation you should at least be able to get them fixed in the next version and even contribute the code to do it (or pay someone else to) if you need to speed up the process.
Mark
Comment by m_p_wilcox — 26 September 2008 @ 8:38 am
Hi Mark,
The point being is that the applications team would need to go to the OS team who would then have to provide an open API as this is going into public facing code, otherwise the fallout from having hard coded hacks in public source code would be very negative for all concerned. The OS team would also be incentivized to produce both timely and good quality code so the apps team could roll out their application.
It could have been IMHO easy to setup PS keys to handle the headset features and expose these keys out of the remote control API, still no use crying over spilt milk as the saying goes…
Comment by pault — 26 September 2008 @ 9:17 am
Hi Mark,
The point being is that the applications team would need to go to the OS team who would then have to provide an open API as this is going into public facing code, otherwise the fallout from having hard coded hacks in public source code would be very negative for all concerned. The OS team would also be incentivized to produce both timely and good quality code so the apps team could roll out their application.
It could have been IMHO easy to setup PS keys to handle the headset features and expose these keys out of the remote control API, still no use crying over spilt milk as the saying goes…
Comment by pault — 26 September 2008 @ 9:17 am
Hi David,
I thoughts comments on your other blog post are frozen similar to discussion threads on nokia forum. But I am delighted that you took your precious time and tried to understand developers' needs.
Strength of open platforms is that The sky is the limit for implementing your ideas and community can also benefit from developer's work if they develop new APIs. Ofcourse Symbian has limit somewhere in developing new APIs, but developers can help in that and make platform much stronger much faster.
@Pault@Wilcox
Pault really hit the right issue and there need to be some concrete steps to rebuild the faith. There are other examples in the list I am touching one more to illustrate Pault's comment in more detail. OS provides CMDAudioPlayerUtility to play audio but Nokia has inserted its own VendorID in the server (which is part of OS) and restricted it for 3rd party developers.
>>Parts of the source code will be released, in a staged manner, at various phases during 2009<< && >> the new bias will be, "release the code, unless there's a very strong specific reason not to do so"<<
Best promise from Symbian so far, I must admit.
Thanks Again. Looking forward to a better tomorrow with Symbian.
Comment by Rick — 26 September 2008 @ 9:59 am
Hi David,
I thoughts comments on your other blog post are frozen similar to discussion threads on nokia forum. But I am delighted that you took your precious time and tried to understand developers' needs.
Strength of open platforms is that The sky is the limit for implementing your ideas and community can also benefit from developer's work if they develop new APIs. Ofcourse Symbian has limit somewhere in developing new APIs, but developers can help in that and make platform much stronger much faster.
@Pault@Wilcox
Pault really hit the right issue and there need to be some concrete steps to rebuild the faith. There are other examples in the list I am touching one more to illustrate Pault's comment in more detail. OS provides CMDAudioPlayerUtility to play audio but Nokia has inserted its own VendorID in the server (which is part of OS) and restricted it for 3rd party developers.
>>Parts of the source code will be released, in a staged manner, at various phases during 2009<< && >> the new bias will be, "release the code, unless there's a very strong specific reason not to do so"<<
Best promise from Symbian so far, I must admit.
Thanks Again. Looking forward to a better tomorrow with Symbian.
Comment by Rick — 26 September 2008 @ 9:59 am
@Paul,
You are absolutely correct of course. The development teams in Nokia will have to adjust to a much more open mode of working.
Hopefully the shame factor will prevent too many quick hacks getting into the foundation code. This sort of area we’re discussing never would have got anywhere near Symbian (the OS team as you put it) though. A quick change to the sysapp is all that’s required for permanent key routing to a specific application.
The really important thing will be how much is guaranteed compatible for a Symbian Foundation phone, which is one of the issues David is describing above. A sysapp is likely to be part of the platform but there’s nothing to stop device manufacturers shipping a modified version of it in the firmware. It is a quick and easy way to make device specific modifications for things like slide or fold detection and extra hardware keys like a camera or music button.
I have high hopes for the Symbian Foundation but I don’t think we’re likely to see quite the level playing field that you’re asking for – it would be too much of a burden for the Nokia development teams.
Whatever happens it will be much better than iPhone, where your application would just get barred from the store for competing with an Apple application. Now that’s anti-competitive!
@Rick
There is no server behind CMdaAudioPlayerUtility, the architecture is plug-in based. There is/was a vendor ID check in the low-level audio server (beneath DevSound) which was, as I see it, security goof and Nokia released the Audio Proxy Server as a workaround until an appropriate API could be delivered.
I honestly believe that at least 90% of the things that people get wound up about result from the fact that Nokia are focused on delivering products with the required functionality on time. The “platform” aspects have been a bit of an afterthought, at least until recently. It’s not that they don’t care or didn’t want to build a developer platform, it’s just a case of limited resource and other business priorities.
They test devices for BC on all the published APIs but developers always want to do more. Hence open source! This isn’t going to fix the problem overnight but it will make everything more transparent.
Personally I’d much rather Nokia build great products that ship hundreds of millions of units which I can target with applications than be completely open and let developers change everything (the IMHO empty promise from Android) but not ship many devices. If I wanted the latter I’d write apps for Openmoko.
Mark
Comment by m_p_wilcox — 26 September 2008 @ 2:31 pm
@Paul,
You are absolutely correct of course. The development teams in Nokia will have to adjust to a much more open mode of working.
Hopefully the shame factor will prevent too many quick hacks getting into the foundation code. This sort of area we’re discussing never would have got anywhere near Symbian (the OS team as you put it) though. A quick change to the sysapp is all that’s required for permanent key routing to a specific application.
The really important thing will be how much is guaranteed compatible for a Symbian Foundation phone, which is one of the issues David is describing above. A sysapp is likely to be part of the platform but there’s nothing to stop device manufacturers shipping a modified version of it in the firmware. It is a quick and easy way to make device specific modifications for things like slide or fold detection and extra hardware keys like a camera or music button.
I have high hopes for the Symbian Foundation but I don’t think we’re likely to see quite the level playing field that you’re asking for – it would be too much of a burden for the Nokia development teams.
Whatever happens it will be much better than iPhone, where your application would just get barred from the store for competing with an Apple application. Now that’s anti-competitive!
@Rick
There is no server behind CMdaAudioPlayerUtility, the architecture is plug-in based. There is/was a vendor ID check in the low-level audio server (beneath DevSound) which was, as I see it, security goof and Nokia released the Audio Proxy Server as a workaround until an appropriate API could be delivered.
I honestly believe that at least 90% of the things that people get wound up about result from the fact that Nokia are focused on delivering products with the required functionality on time. The “platform” aspects have been a bit of an afterthought, at least until recently. It’s not that they don’t care or didn’t want to build a developer platform, it’s just a case of limited resource and other business priorities.
They test devices for BC on all the published APIs but developers always want to do more. Hence open source! This isn’t going to fix the problem overnight but it will make everything more transparent.
Personally I’d much rather Nokia build great products that ship hundreds of millions of units which I can target with applications than be completely open and let developers change everything (the IMHO empty promise from Android) but not ship many devices. If I wanted the latter I’d write apps for Openmoko.
Mark
Comment by m_p_wilcox — 26 September 2008 @ 2:31 pm
Hi Rick,
>I thoughts comments on your other blog post are frozen similar to discussion threads on nokia forum. But I am delighted that you took your time and tried to understand developers' needs.
Although I am not able to reply to all the points that are raised in comments to my blog postings, please be assured that I do read all comments carefully, and I have a long list of matters arising which I am engaged in progressing.
I want to keep the good threads of discussion alive, but equally important, I want to use my time and effort to deepen my understanding of what look like key issues, and then to identify and implement solutions. That often takes a lot of time – so please forgive periods of radio silence on my part.
Hi Mark,
>Once the foundation platform is open it should be possible to change anything you need to access (as long as it's done in a way that doesn't negatively impact anyone else) but there will still be an advantage of time for Nokia and other device manufacturers. They can implement their innovations on the next device they release. Other third party software vendors will have to wait for the next platform release to be taken into devices, after they've got their changes to the platform approved/included. Also, the device manufacturers can bundle firmware patches for old devices with their applications if needed.
>I think the only way around this is full patching of device firmware (either MS style "you need to download an update to use this…" or some kind of officially sanctioned patches to bundle with third party applications). Will consumers go for it? It's certainly technically possible already. Will device manufacturers implement it (they'd have to manage the firmware updates)? Is it at all practical?
My own view is that seamless downloading of validated updates to system software, in support of new application features, is going to become more and more prevalent. As you say, the technical issues have largely already been solved. It will come down to smoothing the distribution channel and the user experience. This kind of remote device management will fit nicely alongside Symbian Apps Store functionality.
// dw2-0
Comment by David Wood — 29 September 2008 @ 3:51 pm
Hi Rick,
>I thoughts comments on your other blog post are frozen similar to discussion threads on nokia forum. But I am delighted that you took your time and tried to understand developers' needs.
Although I am not able to reply to all the points that are raised in comments to my blog postings, please be assured that I do read all comments carefully, and I have a long list of matters arising which I am engaged in progressing.
I want to keep the good threads of discussion alive, but equally important, I want to use my time and effort to deepen my understanding of what look like key issues, and then to identify and implement solutions. That often takes a lot of time – so please forgive periods of radio silence on my part.
Hi Mark,
>Once the foundation platform is open it should be possible to change anything you need to access (as long as it's done in a way that doesn't negatively impact anyone else) but there will still be an advantage of time for Nokia and other device manufacturers. They can implement their innovations on the next device they release. Other third party software vendors will have to wait for the next platform release to be taken into devices, after they've got their changes to the platform approved/included. Also, the device manufacturers can bundle firmware patches for old devices with their applications if needed.
>I think the only way around this is full patching of device firmware (either MS style "you need to download an update to use this…" or some kind of officially sanctioned patches to bundle with third party applications). Will consumers go for it? It's certainly technically possible already. Will device manufacturers implement it (they'd have to manage the firmware updates)? Is it at all practical?
My own view is that seamless downloading of validated updates to system software, in support of new application features, is going to become more and more prevalent. As you say, the technical issues have largely already been solved. It will come down to smoothing the distribution channel and the user experience. This kind of remote device management will fit nicely alongside Symbian Apps Store functionality.
// dw2-0
Comment by David Wood — 29 September 2008 @ 3:51 pm