OK, so getting back to the widget reality here. I’d like to take a look at what the platforms are, what your options are and if it’s really even worth it to go there. I know that last time I got a bit distracted with the whole ‘sprite’ thing, but I promise to stay on track here.
The first thing that it’s important to sort out is just where your widgets might be supported. Unfortunately, this is not as easy as one might think it would be. Odds are that neither your (or your end user’s) phones will support the modern widget engines. On the surface, all of the providers put forth public statements extolling the virtues of their solution and how wonderful it is for end users and developers: [url=http://dev.opera.com/articles/view/opera-widgets-sdk/]Opera[/url], [url=http://www.forum.nokia.com/Technology_Topics/Web_Technologies/Web_Runtime/]Nokia[/url], [url=http://widgets.access-company.com/en/top.php]NetFront[/url], and [url=http://mobile.yahoo.com/developers]Yahoo![/url] are all out pimping their platforms. However, digging deeper reveals the following:
Opera Widgets are only supported on the 9.x platform, which is currently available in beta for WindowsMobile [i]TOUCH[/i] (PocketPC) devices only. Also, they’ve just published an SDK for T-Mobile which announced support for the platform back at 3GSM in February, but for the life of me I can’t find a list of supported devices. If someone has the list, please enlighten me (and the rest of us). Based on the devices that the beta is available for, I’m guessing Touch enabled WinMo devices (like the HTC Shadow or MDA) will be supported out the door with other WinMo 6.x and S60 devices to follow on.
Nokia WRT support is supposed to find its way to all S60 3rd Edition FP2 devices as well all S60 5th Ed. (such as the N97 and 5800) along with a handful of FP1 devices (the N95 family and the E71/E66/E90). The ‘exhaustive’ [url=http://www.forum.nokia.com/devices/matrix_webruntime_1.html]list of devices is available[/url] and will continue to grow. It’s also worth noting that even non Nokia S60 devices will support the Nokia WRT (such as the [url=http://uk.samsungmobile.com/mobile-phones/samsung-i8910]Samsung i8910[/url]). Nokia is pumping out widget delivery via Ovi, and has recently released plugins for widget development not only for Aptana Studio but for Adobe CS4, as well as Microsoft .Net
The [url=http://widgets.access-company.com/en/developers/index.php]NetFront widget engine[/url] is available for WindowsMobile devices (both PocketPC and SmartPhone) as well as for S60 3rd Edition (regardless of FP version) . It does require end user download, and has the side effect of the fact that the widgets themselves may not be recognized by the native browser on the device (IE) as a known content type. This provides a pretty major impediment to the usefulness of the platform. If users can only access your widget via side-load or via ActiveSync, well, that’s not terribly helpful.
The [url=http://mobile.yahoo.com]Yahoo! Widget Engine (Yahoo! Go)[/url] is available for BlackBerry, WinMo, S60, as well as comes in some Java flavors for a raft of SonyEricsson and Moto devices as well. It’s a pretty mature platform. Interestingly Yahoo! has made some interesting decisions when it comes to the way they interact with Widgets. By building your apps using their Blueprint 1.1 Language, rather than just provide a platform for the client and then be done with it, they actually provide services via the cloud which means that they’ll also transcode/deliver your widget via the browser on devices which don’t support Yahoo! Go. Pretty slick, but obviously in that context (the browser container) you’re not going to be able to access the more advanced/native features of the platform.
You can also probably categorize [url=http://www.sun.com/software/javafx/mobile/index.jsp]JavaFX Mobile[/url] as a widget platform (if you so desire). Call me a cynic but I’m not holding out hopes for this having long legs on Mobile, not just because of Oracle, but Sun’s not yet been able to build beyond the success of JavaME ([url=http://www.sun.com/software/savaje/index.xml]SavaJe[/url] anyone?)
Development for each of these platforms is actually pretty similar. All of the widget managers expect delivery of content in a zipped package containing some sort of manifest (a config.xml file) along with the appropriate html, css, and scripts that your application can use. The bottom line is that you’re encapsulating your web application into a standalone and as a result may (or may not) get access to additional device features (such as location, address book, media player etc). You also get the added benefit of local data storage in the form of something like SQLite or DOM storage (depending on the platform). As I was thinking about this more, I suddenly realized that what these widgets do is bring back my beloved mime/multipart content (sort of). At the end of the day, you the developer are building a web app to run locally. Leverage the browser container, but break out of its confines and gain access to more advanced local services.
Even as these widget platforms proliferate, there are folks out there looking to drive some sort of convergence on them. The W3C is hot on the trail of [url=http://www.w3.org/2008/webapps/wiki/PubStatus#Widgets_Specifications]widget specs[/url] which may (or may not) apply to the mobile context, and the MWI has put forth a [url=http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20090405]Best Practices doc focused on ‘Web Applications'[/url] on mobile devices: . Add to that the effort that’s going forward with Vodafone, ChinaMobile, SoftBank and Verizon: Joint Innovation Lab (http://www.jil.org).
Side note here: If the folks at JIL are going to see success, they’ve got some work to do on their desktop site. My first visit granted me a plain text response of: “Cookies must be enabled to view this page” (they were). Then, when I registered, the response to my registration was another plain text page that said simply “200” (I was left to assume that was an HTTP status…). I did try logging in with my username/password but got a message “We can’t recognise the details you’ve entered. Please try again.” Attempting to register again showed that my username was already taken. They did send me an email with a link for account validation, but all that link did was reload the home page of JIL for me, and attempting to login spit back the same error about recognising my details… I was doing this via Opera, but Firefox had similar issues. Oh Well.
None of the platform vendors are tools companies, and they’ve all learned how not to reinvent the wheel, so rather they forcing you into an IDE of their design, just go ahead and use your favorite environment (Eclipse, DreamWeaver, Visual Studio, emacs…). The only thing that you really need to do is to modify your webserver to deliver the appropriate content type for a widget package (and they even give you a sample .htaccess file with the sample code).
So lets take a quick peek at what we can actually do with one of the platforms. I’m going to pick on Y! because I happen to have a supported device. (No love from either Nokia or Opera on my E61, and my WinMo device isn’t touch screen so I’m SOL there too. I tried NetFront, but that Sideload thing turned me off completely!). Stroll on over to http://mobile.yahoo.com/devcenter to pull down the SDK and get up and running.
The Blueprint language from Yahoo is based on XForms, but leaves out some of the complexity. At the root level, what you’re provided with is containers and a series of controls for your application. All of the processing logic, scripting, and other fun stuff is managed on your end, on your server, in the language of your choice. This is truly a web application more than a widget per-se. You’re not going to build a fish tank app or a tetris widget using this language, it’s more of a way to provide a controlled, convenient access point and take away some of the pain inherent in trying to deliver an optimized mobile experience.
The benefit here is really that you can build a single instance of your mobile web application, pre-package some of the content so that performance is improved, and let the folks at Y! do the heavy lifting on the layout side of things. As a side effect, if the platform supports it you can also get location access without jumping through the hoops often required. The other clever thing that Y! is doing is passing along a greater level of granularity when it comes to device capabilities. They pass along a series of [url=http://developer.yahoo.com/mobile/blueprint/BP_Client_Carrier_Info.html]x-* http[/url] headers which will provide details on the quality of the browser (if you’re talking to a web client instead of a native platform), and info about the carrier as well.
So what do you do, and should you even bother? Honestly, I think that we’re still early when it comes to widgets for mobile. It’s clear that each player means something slightly different when they talk about a ‘widget.’ Nokia is clearly trying to steer developers towards their WRT platform, and that’s probably a good thing, but the addressable market there is still limited. The good news is that on the newest devices widgets will have pretty much first class citizen status. Opera is poised to do something, but it’s not quite clear exactly what yet. The chaps at JIL seem like they want to do something serious, but it also remains to be seen how well it will play out and how far it will reach. Bottom line is that migrating to widgets is not going to solve your fragmentation issues, yet…
