Is there an answer to the fractured app store?
Published by Ewan Spence at 23:15 GMT, November 29th 2009
There is a lottery whenever you download an application for your Symbian Samrtphone. I don't mean the lottery of whether you'll be able to re-download the app (although that can still be a concern); I don't mean the lottery of getting the right platform variation in terms of 3rd or 5th Edition or something even older (although that can be a concern as well); nor am I thinking about the “will the security certificate still be in date” when I install the app (seriously – who thought that expiring apps would be a good idea?)
No I'm thinking about the mix of C++ and Java applications that any Symbian software store has to contend with. While it's well-established in many computer platforms that you can use multiple languages and it should be indistinguishable to the user (i.e. it should just work), that's not really the case with the majority of Symbian Java applications.
First up, I'm not saying this is always the case. There are apps out there written in Java that really do make good use of the Symbian platform. The Gmail client has always been in java, and a number of developers could make java applications fly.
But I'm not looking at the exception – I'm looking at the majority of apps that you find in these stores. And this majority appear to be generic Java applications, churned out to fit into the Java platform with no consideration of what S60 and Symbian can do.
From the programmer's practical point of view, this is understandable – Java and J2ME is meant to be a 'write once run on everything' approach. They can address countless more machines than a single platform. But it does this by going for a lowest common denominator approach. You get a basic menu, a full screen input box whenever you need to enter information, and a number of other standard screen elements. You also have a graphical window you can use, but then menu handling and button control is up to the end user, and the UI can look like anything they want it to.
Is Qt the answer?
And here's the problem... you have a class of application that fills the app store with a tool that sometimes does the job, but fails to look good, fails to interact well with the UI of the phone, and becomes an unrewarding experience. In my recent review of Smart Trivia, there's a glaring fault in the Java code that does not display the picture of a flag, while asking “which country's flag is this?” To my mind this is an app that has never been tested by the developer on an S60 device – it's an elementary error. Yet it's still there in the Ovi Store, it's still counted by Nokia in the “pieces of content available” and it's still being used, in a tiny part, to sell the Finnish hardware.
Is there any indication of what you as the customer are getting? Beyond the 'carefully chosen by the developer screenshot' and text? Nope.
It's hard to spot a solution. Apple and Android have a playing field with only one strictly controlled environment (although Android 1.0, 1.5 and 2.0 are showing worrying signs of compatibility issues already) which keeps it under control. But Nokia, right now, have a mix of everything for their product lines and in the Ovi Store.
The future may well be sorted in terms of what tools are available for developers but is it going to help this disparate nature of apps? Probably not. Future C++ and Java will be replaced by... C++ and Qt. And of course there's more fragmentation in the store as S40 and S60 will be joined by the Maemo platform. How will developers address this mix? The fear is that they're going to do exactly what they're doing now with the multiple smartphone platforms – and standardise on the lowest common denominator for their coding efforts.
Or will web rule and Nokia's bet on Widgets benefit?
Will that be Qt? Nokia must certainly hope so, but the fractured platform strategy that leads to Java being the “second class” app on an app store is already evident in Nokia's line up and muddled signals to developers and the market aren't helping the issue. For the bedroom coder will it be a choice of Qt S60 or Qt Maemo for their application? Will there be some sort of 'compromise' that forces the respective UI on top of a basic app design? And will that somehow degrade the app in the eyes of the buyer?
Yes, there are Nokia widgets, but that requires a specific focus and packaging for a device. They will be promoted but will it be enough? On the horizon there is “cloud computing”, which would allow development effort to be focussed on server-stored code for people to access via their web browsers. The winner might not be native code on a device, but just an HTML5-compliant web browser that will ship on our smartphone...
-- Ewan Spence, Nov 2009.
Categories: Developer, Editorial Thoughts
Platforms: General, S60 3rd Edition, S60 5th Edition
News Discussion
I agree I'm not sure QT is going to solve a lot of problems - yes it should result in better and nicer looking programs but I still can't believe that as you say coding down to a lowest common denominator isn't going to be the result as they try to support SFx and Maemo. Maybe only user review is the solution to differentiating well and specifically written software from generic clones? Although user review tends to be a very poor system widely open to abuse/spamming.
Maybe Nokia need a more benign dictatorship approach a la Apple, mind you Apple do back that up with very accessible SDK and low entry threshold and slightly goes against the new Nokia open source group think.
I agree with you that a lot of App fuss will die down as we revert back to the browser but still seems a bit of a quandary.
Probably the same person who figured out that they could fleece developers out of hundreds of dollars/euros for certificates and signing programmes.
Qt will be the future SDK for client apps on Symbian.
Web runtime and widgets will be supported as well as on other platforms, with highly hoped convergence to a sort of W3C+BONDI inspired widget engine.
JM2C
http://meedabyte.wordpress.com
When downloading and trying different applications none of them are really separated in the OVI Store.
While the performance is a less eminent problem on 5th edition handsets (which basically can chunk down all of them), this can be more eminent on 3rd edition handsets with poorer experience than a counter application made specifically for Symbian.
On 5th edition handsets the emulated navigation keys are the only indicator that the application is a java application and for widgets that it requires an internet application. (Exceptions are widgets that don't require this.)
It's probably a matter of personal taste, but I find that being able to differ what type of an application is, plays a big part for my user experience.
(Java applications like to fail on 3rd edition, less likely on 5th. Widgets don't work well in 3rd edition and so on.)
Moving away from the user experience the points you made are very valid, about the lowest common denominator. This is unfortunately the case when you look at "mass productions".
Just look at the quality of the gadgets that are out there today. Build quality gets worse (Nokia creaking battery covers)
and same goes for applications.
The assumption is mainly based on that the user won't mind what application type of application is on the store as long as it "works", and as you pointed out it doesn't.