One of the most important threads of activity running through the inaugural meetings last week of all four Symbian Foundation Councils was a multi-angle review of the content of the release plan of forthcoming Symbian platform releases.
Here are some of the highlights of what was discussed:
Symbian^2
Symbian^2 is the first release for which the source code is available on the Mercurial repositories on the Symbian developer website.
Symbian^2 will reach Functionality Completed in week 19 2009, and is expected to be Hardened by week 51 this year.
Key features of this release include:
- Support for multiple form factors, resolutions and input methods;
- Customisable home screen supporting embedded widgets and other personal content.
Symbian^2 is particularly suitable for device manufacturers who have already been working with previous versions of Symbian OS technology. Device manufacturers who are relatively new to the Symbian world are expected to use Symbian^3 in their first commercial shipments.
Symbian^3
Symbian^3 will be part of a complete ecosystem offering of all the software needed to quickly create a wide range of winning mobile devices – including state-of-the-app mobile phones, and lots more.
Symbian^3 is expected to reach Functionality Completed in week 04 2010, and to be Hardened by week 26 that year.
Key features of this release include:
- Integrated support for seamless composition of hardware-accelerated content into UI elements (this incorporates “Screenplay” technology);
- An integrated high performance communications architecture enabling a performance level typical of wired internet (this incorporates “Freeway” technology).
Symbian^4
Planning for Symbian^4 is at an earlier stage. It follows Symbian^3 by around six months.
The following technology contributions are expected to be fully integrated for Symbian^4:
- Qt optimised for the Symbian platform – Qt is a well-liked application and UI framework;
- A new “Orbit” extension library for Qt, which contains more than 50 widgets tailored for mobile user experience, and which will provide a replacement for the existing “Avkon” widget set;
- A new “Direct UI” interaction and navigation logic, combined with finger-optimised layouts offering excellent touch and hybrid-device user experience;
- The application suite re-factored and re-written to take advantage of Qt APIs, Orbit widgets, and Direct UI.
Elements of this combined offering will of course be available for experimentation ahead of their full integration in Symbian^4.
For more information
More details of the Symbian release plans are increasingly available on the beta Symbian developer website.
It’s an exciting future. Developers will have a great deal to get their teeth into!
Will the old Avkon APIs still be available in Symbian^4 for backwards app-compatibility or will they be removed completely in favour of QT?
Good question, James. Inquiring minds here also want to know.
Hi James, Tyson,
How important do you think it will be for devices built on Symbian^4 and beyond to provide compatibility for applications written using Avkon APIs?
Perhaps if the new APIs are published sufficiently in advance, developers can target them well in advance of the new devices reaching the market.
What are your views?
// David W.
I reckon that it’d be important to have ABI compatibility, and maybe a “glue”/”bridge” API (at least for a transitional period) so that users with proprietary, closed-source applications can continue to use them on the new platform release, without worrying about whether or not they’ll work. It’d probably make it a little easier on developers who have the old APIs ingrained on their minds, too.
Of course, if things go to plan, and Avkon is open-sourced, developers could make (and share) their own bridge if they wished, so the impact is reduced a little.
David,
It’s VERY important that Avkon continue alongside Orbit, and that the two work properly together, probably for at least four years into the future (so 8 releases of Symbian).
The constant breaking of UI API’s has been a major contributor to preventing any real growth in the Symbian ecosystem, and if you continue to do this going forward, it will continue to limit growth. Why invest in developing a product which has a potential life of only two or three years before it needs recoding?
This is an area where Microsoft has always excelled, and when they’ve messed up (as in Vista and Win 2000) have always corrected with their next release (Win 7 and XP). It is no coincidence that MS’s developer community is the envy of any other platform. (That and their developer tools are very solid.)
Symbian need to take this issue seriously! (I’m speaking as a developer completely recoding UI layers for the fourth time in ten years. I can understand a couple of these, but four times is excessive.)
It’s a tough one. Personally, I think it depends on the UI changes themselves. If DirectUI is used as an opportunity to completely overhaul the UI (i.e. starting with a blank canvas and trying to figure out the best possible UI for a phone) then I think it’s conceivable that the foundation will face some tough decisions along the lines of: “We could change the way a user interacts with X for the better but it completely goes against the S60 UI guidelines and/or Avkon functionality”. Do you a) not change the UI as radically to preserve backwards compatibility or do you b) radically change the UI but in doing so break backwards compatibility?
It’s not an easy choice.
However, I could see a compromise along the lines of: Totally redo the UI and in doing so break BC but provide some kind of legacy environment which lets people run old apps within an old-style UI. I’m thinking of something a bit like Apple’s “Classic Environment” that let people run old Mac OS 9 apps within Mac OS X.
No doubt that would add to the ROM size and thus BOM cost but I suppose it could be optional so cheap phones may choose to omit it (and even then it could be made available as a user-installable extra which the app stores could even download and install silently for you in the background when required so users don’t get confused with “to run app X you need to first install library Y”.)
Considering how much effort we spend working around issues in the outright mess that is Avkon, I for one would not be missing it in future Symbian implementations.
Re-writing the UIs we make today in Qt would probably be less work than adapting Avkon for new widgets and device configurations.
It’s not an easy choice, but the compromise is probably the most expensive and worst option. It constrains the new world to provide support for the legacy environment, and continues to constrain it forever more. Eventually the cost of all the compatibility boxes becomes so high that you need the resources of a Microsoft to pay to maintain them. GIven a long view, it’s cheaper to have engineers help rework application code than it is to support the original binaries for many years.
In an Open Source world, you pay to fix the problems you care about – if Nokia is contributing the Qt and DirectUI changes, then they will make a judgement about how painful a compatibility break would be for their markets, and look for a cost-effective solution. The role of Symbian will be to help others understand that break and how to contribute to the solution so that it becomes bearable for their markets too.
David has said that his job is to be a catalyst – what catalysts do is to make chemical reactions work by reducing the energy needed to get from the old state to the new state. Something similar will be needed here: something to reduce the cost of migration.
Stay tuned – this is sure to be interesting…!
Hmm, you raise some interesting points. By the time you strip out Avkon, and everything that comes with it, you’re left with something that can’t be called “S60″, since it’s so different, although that’s just my 0.2p.
For what it’s worth, are the “legacy” UI layers still going to be released under the EPL soon? (As for UIQ, that’s a special case, and I’m uncertain about it’s future after an e-mail exchange with Thibaut Rouffineau a while ago).
On the flipside, software for mobile phones tends to have a shorter lifespan than software for general-purpose computers, and there’s a tendency for developers to release an “all-new” version of a program for S60/UIQ whenever a new version of the said platform arrives anyway.
I was under the impression the S60 name was on its way out anyway. The whole OS+UI is now just called “Symbian^N” isn’t it?
Good point, although just because the name is going, it doesn’t mean that the software should go wholesale, too…
avkon needs to stay for backward compatibility of existing applications for 2-3 years after a new UI toolkit is standard at least.
Ideally, all the built in apps will be updated, so the only time you ever see avkon is if you install an old app.
Yes it is a tough call to make but like one of the previous posts mentioned it is better to phase out avkon and move on….
The challenge is primarily on providing the end user an out of the world user experience with the new UIs. Basically, the end user would “FORGET”, in a sense, about older apps/user interfaces. They are “compelled” (not forcefully that is ) to choose the newer versions with a much richer set of features.
Off topic, I have some queries regarding the evolution of the symbian framework itself. This might not be the right place to put forth my questions (may be a separate forum would be better)but anyways here goes…
1. Would Symbian continue to use the Symbian C++ constructs (NewL NewLC, CleanupStack, TDes) in future,maybe after Symbian^4 ?
If yes, would it be limited to back end components and UI would be QT/ Direct UI (plain C++)?
2. Would things like the Windowing framework be re-written for faster response (maybe adding support for multi-touch and things like that)?
Paraphrasing WTR1, backwards compatibility is easily talked about but not easy to execute. It’s always a very expensive endeavour.
You should place the argument in the context of the current users. How would they be affected by such a change?
Firstly I doubt many users take an application from one phone to another. Perhaps the only interesting cases might be enterprise customers but that sounds like something for a handset manufacturer to look at to help the customer to migrate.
I don’t think many Symbian users would worry whether their favourite game would continue to work on the next phone. (http://www.joelonsoftware.com/articles/APIWar.html, see the Simcity ‘compatibility’ workaround)
Would the change affect the availability of applications?
In the short term, probably, but how many people are buying Symbian phones for the applications? I’ve had a Symbian phone (of various kinds) for years, and I can’t think of an application I must have. There probably is no killer (third party) app.
Have previous API breaks have seriously effected the growth of the Symbian ecosystem? I suspect it’s more to do with the fact that Symbian has just failed to achieve a critical mass because of the incoherrent ways it’s applications are advertised and delivered by manufacturers or other parties.
I agree with Tyson Key’s point that the lifespan of software on mobile platforms appears to be pretty short. Perhaps if Symbian branches out into Netbooks and corporate areans where the application lifespan tends to be very long API compatibility is a more serious issue.
Granted that 3rd party app vendors will proabably bitch about a big API break but then again most of them are very well adjusted for structuring their software to make it easily portable to different OS’s.
I suggest concentrating on getting PIPS to deliver a reasonably familiar OS environment rather than worrying about the UI.
I’ll be interested to see how this’ll play out. After all, we did have a big ABI break during the transition from Symbian OS 8.x to 9.x which left developers kicking and screaming, until they finally let it pass over them…
Any plans on building system updates directly into the Symbian OS so that if a component is updated, users can upgrade their devices?
Not to mention it would allow companies to do their own custom deployments a lot easier if you let them use their infrastructure to host custom code and what not.
Well, I assume that Qt will be available as a SIS file for current (and maybe older) devices (you can do this now with the ‘garden’ release from Qt). So one would hope that developers could start writing Qt apps pretty soon without having to wait for a Symbian^ release.
If some thought is given to the roll out and app developers can ship a Qt runtime with their SIS files, then it would be s good way to encourage migration.
The migration task is made easier by the fact that Avkon is so god awful that most developers would rather lick sweat off an infected pig than wrestle with avkon some more.
Nokia are going to be reliant on avkon for many years. Migrating all the internal applications and retesting each is a huge task( Bear in mind that one of the applications has a 1876 line C++ constructor).
Also think of the task of re-localisation using Qt’s localisation method.
The more interesting question is who’s designing the Orbit widgets? Given that the core applications will be using these widgets – they will have a profound impact on the usability and feel of ^ devices.
Or to put it Lee’s language – who is the Michelangelo behind the UI renaissance?
[...] Many things where cleared up; especially that inviting yet wondrous pictures – and new video – that represent Symbian Foundation. Many of you may not even know this but there is a book called “Oh The Place You’ll Go!” by Dr. Zeuss. I bought this book 11 yrs ago and read it to my son countless of times. With Symbian Foundation … and to developers it has an equal importance beyond the obvious. You have brains in your head. You have feet in your shoes. You can steer yourself any direction you choose. You’re on your own, and you know what you know. And you are the one who’ll decide where you’ll go. Oh the places you’ll go. Symbian Foundation is on a SERIOUS roll lately. Just a look over at their blogs shows that work is like a bullet train with no derailments in sight. Symbian^2 will reach Functionality Completed in week 19 2009, and is expected to be Hardened by week 51 this year. Reviewing the Release Plan. [...]
There seem to be quite a number of people commenting about the lack of need for backward compatibility based on the premise that Symbian is just a phone OS, and how many people transfer applications from phone to phone?
Surely this is the point! People don’t regard smart phones as an application platform in the same way they regard, say MS Windows or Mac OS/X precisely because smart phones are not promoted (or even thought of) in that way by the very sellers and makers of these devices.
What is the point of talking about the Symbian Ecosystem, as we have been for a decade now, if we don’t take one of the core requirements of an ecosystem (a relatively stable environment) seriously?
I have absolutely no love for Avkon, so I’m not speaking out of a desire to keep it around for its own sake. However, it is a major part of the current platform, and abandoning it in a hurry is akin to attempting to move a chunk of tropical rainforest into the middle of Greenland — some plants will survive the change it their environment, but the rich diversity will vanish. (Using the ecosystem metaphor.)
PC hardware and interfaces haven’t really evolved for more than a decade. The PCs just get faster and have more memory. If you wrote a DOS application you almost certainly had to re-write it for Windows 3.1 and again for Win95. There may have been compatibility of APIs, but the UI changed and using the old APIs gave you an old looking app that no-one wanted.
With Symbian the hardware and interfaces are changing more significantly, so the value of keeping the old UI is much less clear. When the new UI appears, apps with old UIs will be extremely undesirable in comparison. All the core OS APIs underneath should still be there, so the application engine should still work, but it needs a new UI. This either requires extension of Avkon, or replacement, or both. I think that Avkon is hard enough to work with compared to Qt that updating the UI for the new look and feel would be more work than recoding it using Qt. Once you have Qt, they’ve been pretty good at maintaining compatibility long term (porting module provided for big break in Qt 3 -> Qt 4) and need to remain so since they also target desktops.
Mobile really is different from the desktop because we can’t just keep backward compatibility by endlessly bloating the firmware and resource use like Microsoft. Personally I think a break from the past would be a really good thing!
A few other points from comments in this thread:
The proposal really is to remove Avkon currently, and re-write the apps in the stated timeframe. The best thing you can do with a “1876 line C++ constructor” is throw it away and start again.
As I understand it, Nokia do plan to stop using and marketing the S60 brand, it’ll all just be Symbian (and just Qt for most app developers, but not with the current UI paradigm, look out for more of the declarative UI stuff built on Kinetic that the trolls were talking about in Monaco at the Nokia Developer Summit).
I’m really not sure how practical/useful a compatibility bridge of some kind is. The UI paradigms are really very different. Possibly the existing Avkon widgets could be kept for a transition period, but I very much doubt complete BC could be maintained with such a radical overhaul.
Qt for S60 (as it’s currently called) should be mature in September this year and become part of Qt 4.6. I’d expect Nokia to ship it in the firmware of Symbian^3 devices and it’ll be available to download to Symbian^1 and Symbian^2 devices (although that’s not very practical for commercial app distribution since I assume it will be pretty big).
A final point – this is currently a proposal to the Symbian Foundation’s feature and roadmap council. If you want to provide input to the discussion, sign up to the website beta (or wait for it to go public) and post a thread on the council’s discussion board in the forums.
>> The best thing you can do with a “1876 line C++ constructor” is throw it away and start again.
Ok I know that’s tongue in cheek. But a lot of that code is due to listening to many 100s of different events from Etel, centrep, P&S etc.
There is a huge amount of investment in active objects which litter the Apps – certainly the idea that you can strip out the symbian-esque avkon and stick Qt on top of the ‘engine’ is a bit foolhardy.
In some ways it’s quite ironic that Symbian has always been lambasted for using an out of date, proprietor interpretation of C++ and now they are moving to Qt which has a similar heritage.
- You write in a strange dialect of C++ )need to pre-processes sources with moc_
- The framework doesn’t support exceptions (you have to isolate them to your code)
- The OOM behaviour is dubious at best
Qt is better than Avkon, but it’s not linage of ‘embedded’ systems and has its own issues when it comes to creating robust applications.
>>although that’s not very practical for commercial app distribution since I assume it will be pretty big
If Symbian/Nokia want to re-stimulate app development on the platform, this would be a a valid tradeoff. As soon as I have to tell users to download another SIS…..i’m out of here.
If you look at Nokia’s published strategy and public actions (for example the presentation given by Mika Rytkonen at the recent Nokia Developer Summit) you’ll see that Qt is seen as far more important for its cross-platform nature than its embedded heritage (or lack of – Qtopia wasn’t so bad though). Providing a nicer environment for third party app developers was clearly a consideration, but I’d suggest not the main reason for the switch to Qt.
Some of the S60 app “engines” are being re-written with Qt and others not as I understand it. I’ve tried a bit of hybrid Qt/Symbian C++ programming already myself and it seems to work pretty well. The Qt event loop has been ported in a way that includes active object processing.
Symbian’s non-standard version of C++ was working around issues with the compilers and standards at the time it was written. At least Qt is only non-standard in areas where they add genuine enhancements. Also, you can build Qt with exception support, although it admittedly doesn’t do much for you. Besides, it’s not like there’s a decent application framework out there that uses standard C or C++. It must be admitted that there is work to be done on OOM in Qt for embedded systems. I’m interested to see what they can come up with there.
You never HAVE to tell users to download another SIS file, you can embed it and even silently install it – the issue is how large a download can you reasonably expect people to put up with (and possibly pay for)?
Actually my larger concern would be how dependent the shiny new GUI will be on hardware accelerated graphics. Will the older devices not have the performance to run the apps anyway?
From what I can see, Nokia have jumped so far into the Qt experiment that it’s do or die now. I expect the technical challenges are not impossible and they have the resources to pull it off.
Are there any plan to include Digital Signal Processor API and Image Processor API (if present) into Symbian ? That would help develop image-processing applications a lot.
[...] Nokia’s plan is to try and make Qt the main S60 development environment. There are clues in Symbian Foundation’s plan to make Qt’s Orbit UI a replacement for the current Symbian Avkon windows controls. Once this [...]
[...] phase out S60 all together”. I suspect this probably derives from a misunderstanding of the declared intent to replace the Avkon UI libraries (which have characterised S60 over the years) with new Qt-based [...]
[...] concrete terms – as has already been communicated when we announced our Release Plan: Symbian^2 is the first release for which the source code is available on the Mercurial [...]