As a commuter, I spend hours on (delayed) trains every week. In between napping and finishing off a few pieces of work, I’ll often turn to Facebook on my phone to keep myself amused. Last week one of my friends updated his status to: “John is wondering who on earth came up with the term “widget” and why on earth it is (mis)used for so many things.”
John (whose name has been changed) raises a good point. A barrage of comments later and we’d established that most people in the mobile industry are equally baffled by widgets, the hype around them and the proliferation of widget-related pseudo-standards. We also established that people outside the mobile industry didn’t have a clue what we were talking about.
Broadly, a widget appears to be a light-weight application based on web technologies, typically HTML, CSS and JavaScript. But wait…on Android a widget is a Dalvik-based home-screen application and that’s different to a Google Gadget you get on your PC. A quick look at Wikipedia and the word widget can be applied to almost anything from Economics to Beer.
So why my obsession with Widgets? Taken in the “web” sense, encapsulating the power of advanced web-technologies into an application runtime is a great idea. If you make it fast and powerful enough the majority of mobile applications can be written using web technologies, significantly reducing the barrier to developing great applications. The need for more complex runtimes is reduced, the tools are simplified, and all you need to worry about is compatibility between different browser technologies – something we’re already used to.
Last time I wrote for the Symbian blog I mused about the potential demise of Java. From the comments, I concluded that most people weren’t too worried about Java, and web technologies were much higher on their agenda. After a dismal start with WAP, the mobile web has rapidly converged with the PC. More recently, the proliferation of open-source browser projects have started to bring HTML5 and JIT JavaScript interpreters to the small screen at an incredible pace. The budding mobile web developer’s time has come…
Like all great paradigm shifts, a few people are having the same idea at the same time, so the widget world is slightly confusing at the moment. As this new world evolves, the role of the Symbian platform is both to bring you the best web-runtime technologies and to shield you from the complexity of widget proliferation. To help me with this task, I’d be very interested to know what web technologies you’re getting excited about, and your experiences with widgets (of the web variety). I’ve started a thread on this topic in the Symbian developer forums, so please sign up and join the conversation.
What ever happened to using “widget” as a term for computer UI elements (buttons, menus, tickboxes etc.)?
Anyway, back to the topic – I’m curious, can Symbian WRT widget embed Flash Lite content? The web browser can so I would have thought they could too.
Also, are there any options for exposing functionality of 3rd party native code to widgets? E.g. I write a Symbian C++ DLL, some kind of C++-to-JavaScript wrapper and then I can prod my C++ DLL from the widget.
Hi James,
WRT Widgets can indeed use Flash in this way, however it was never really practical and the WRT softkeys can’t be removed.
So yes you could, but no you probably shouldn’t.
Mark
Adobe http://www.flashmobileblog.com
James – Yes, you can embed Flash Lite content in a WRT widget.
Extending widgets with native functionality is currently a nasty local sockets hack, like with Java ME. It should be possible to add extensions more easily but with the coming of Qt WebKit (which is just amazingly powerful) there isn’t much point.
For devices pre-Qt it might be possible to shadow ROM components with updated versions of the open sourced bits of the platform for the platform services APIs and open something up, but I expect it would be both difficult technically and hard to get past the signing guardians (because WRT apps don’t require any signing, so it’s a big security hole).
Hi,
I think the most important thing that can be done at this point is to put together a BoaF group ASAP to make sure that everyone is pulling in the same direction.
I would see this involving folks like Android, Apple?, Palm and any other group in the mobile space working on WRT. I would suggest at least a wiki site and mailing list for interested parties *not* branded as an OS idea. Perhaps someone should think of a snappy acronym for such a group.
I can provide you with some people who work for Android who I’m sure would be keen to join.
The areas to cover would include the API interface library issue that is mentioned above (perhaps creating an abstraction layer like NSPR (http://www.mozilla.org/projects/nspr/)) as well as persistence (Gears) better UI / input configuration support, etc.
Thoughts?
How about the BONDI initiative from the OMTP?
It seems to meet most of the requirements listed.
Thanks for that David – looks very interesting.
Who in the Foundation would allocate resources to get involved in a project like that? Which team do you think it falls under?
Not everyone creating a widget platform is involved in the OMTP, or the BONDI initiative, but it looks like a large enough group for everyone else to rally around.
There’s already ongoing discussion about a BONDI implementation on Symbian and how it will be developed. A lot of the interested parties were at Boundary Row this week.
> Not everyone creating a widget platform is involved in the OMTP
What about Apple, RIM, Google and Palm? Are these folks in the room for this one?
No, it’s a big who’s who list of the industry but none of those guys feature:
http://www.omtp.org/Membership.aspx
Since when did Apple ever care about open standards though?
New stuff like this will never get complete co-operation at the beginning, there will always be people trying to compete on the development platform – I think Google and Palm are doing just that right now.
This is one of the best features of the Symbian platform.
My favourite development trio and, imo, one of its best selling points is the support for:
- Web Widgets
- Python
- Qt
All three are easy, straightforward, and quite popular programming approaches. Even if everything else blew apart, I would love to see these three being kept.
> New stuff like this will never get complete co-operation at the beginning
That’s a sad thought and implies that groups will have to do extra work to move into a subsequently created standard.
Surely better for groups who claim to be “open” (Symbian and Android for two) to prove their “open” credentials by working on something like this in a public collaborative manner?
Surely better for groups who claim to be “open” (Symbian and Android for two) to prove their “open” credentials by working on something like this in a public collaborative manner?
Symbian is working with the OMTP and I’m sure Google would be very welcome. There’s still a lot of proving of “open” credentials to be done on all sides.
Personally, although I’m a big fan of open collaboration, I don’t believe that should eliminate competition. What if (and this is completely hypothetical) the OMTP produces a really bad widget platform? Or one with an architecture that turns out not to be sufficiently flexible or scalable? Should we be stuck with it, or would it be better to be able to switch to a competing solution?
The existing open source world has a very wide proliferation of programming frameworks and often competing solutions to the same problem. Isn’t it better to only standardise on something when it’s proven? The JCP tries to create the standards first and then have everyone implement them for Java and that hasn’t turned out too well.
IMHO, an open monopoly is better than a closed one, but nowhere near as good as an open market.
> What if (and this is completely hypothetical) the OMTP produces a really
> bad widget platform? Or one with an architecture that turns out not to be
> sufficiently flexible or scalable? Should we be stuck with it, or would it be
> better to be able to switch to a competing solution?
A very good question without an easy answer.
The Foundation needs to publicly declare whether cross-platform compatibility or functionality are more important to them. I for one would be very interested in hearing the answer.
Regardless I hope that Symbian is not setting up such attempts at pre-emptive standards setting to fail. Only time will tell how they work out.
In the mean time it *certainly* would not hurt to create bridges between the Symbian and Android developers and architects working on these areas.
The Foundation needs to publicly declare whether cross-platform compatibility or functionality are more important to them. I for one would be very interested in hearing the answer.
I really don’t think these are mutually exclusive. You simply back the “cross-platform” standard you think has the best chance of succeeding (OMTP appears to be the most obvious choice for Symbian in this case) but recognise the cross-platform doesn’t necessarily mean “across ALL platforms”. There’s no question of setting anything up to fail, you do your best to make sure your chosen option works out.
I’m all for bridge building but Symbian has a pretty good record and stated plan for cross-platform runtimes. Qt is cross-platform, so is Flash, so is Java ME… the Python runtime is even evolving in a more “standard” direction. Android doesn’t support any of these (although Flash is on the way), nor does Palm, or Apple. RIM has Java ME at least (although with proprietary extensions of course).
Regardless, my answer was on a more philosophical level. Web technologies are pretty standard now but there’s still evolution and competition around the edges in a lot of areas. I’d argue that mobile extensions are one of these areas and it wouldn’t be healthy if there were only one solution planned. I hope that the OMTPs efforts end up combining with the W3C’s in some way so that we get an official web standard that includes mobile! Possibly the final standard will incorporate the best ideas from currently competing solutions. I suppose my position is that fragmentation, while bad, is a natural stage in the evolution of new technologies and as such shouldn’t be seen as something to be avoided at all costs. This is all just my opinion though, not necessarily that of “the Symbian Foundation”.
Hi Mark,
Thanks for taking the time to have such an interesting and useful discussion. Can I ask what your role is in Symbian?
Perhaps the best way forward at this point would be to find if there are any Android developers in London working in this area and then perhaps going out for a meal one evening just to have a general chat about how they think things are going in the standards area.
I have a good contact in Google if you think that would be useful. Let me know what you think.
Cheers.
Hi David,
I’m still trying to work out exactly what my role is!
I work in Developer Technical Services, in the developer support team (I say team but there are only 2 of us just now).
I think our technology manager for runtimes, Robert Ackland, would be the ideal person to talk to the Android guys about their plans in this area. I believe he already worked on Android in his last job, but more contacts (particularly local ones) can never hurt.
Lets take this discussion out of the blog comments (I think I’ll see you tomorrow) and we can sort out an introduction.
Cheers,
Mark
May be a stupid question. But I will ask it anyway.
Why Nokia should limit WRT to Symbian? Why not make it platform independent, especially, when you are talking web?
@crux: not a stupid question at all! One great thing about Web Widgets is that they are not necessarily tied to any specific platform, or for that matter any single type of device.
The W3C is working now on standards for Web widgets that are intended to be applicable to both mobile and desktop computers. The Working Group on Web Applications is already quite far along in defining basic widget specs (http://www.w3.org/2008/webapps/), and a new group focusing on platform API’s is in the works (http://lists.w3.org/Archives/Public/public-device-apis/).
Rgds,
-Oren (from Nokia)