Widget development in Windows Mobile 6.5
I had two sessions to present at Over The Air 09. The first was all about the new Widget runtime included in Windows Mobile 6.5.
The runtime brings a Microsoft implementation of W3C Widget support to Windows Mobile for the first time. Our implementation is coupled with the launch of our very own mobile application Marketplace – this goes live with the launch of Windows Mobile 6.5 devices on the 6th Oct – allowing Widgets and native code applications (<10mb in size) to be sold directly to Windows Mobile 6 and upward devices.
If you are new to Widgets then here is a summary: The widget ideal is to be able to build mobile applications using web development skills – HTML, Script and AJAX. They are installed on the device and look like a native application with just enough device integration to use soft keys and device state.
So what is in our Widget implementation.
Firstly, we are using the Internet Explorer 6 HTML presentation engine (HTML Control). This is coupled with most of the IE8 script engine. These are brought together in the Widget runtime application called RIAHOST.EXE.
RIAHost adds other stuff, including shell support for devices with touch, soft keys and importantly the Widget object.
The Widget object allows the Widget programmer to reach beyond the Widget into the state of the device. Being able to determine things like signal and battery strength. If the widget is in focus or hidden. As well as many other things.
Widgets are brilliant but I immediately want to do more with my Widgets.
I think, for Widgets to be successful the developer must make them Smart Widgets. Rather than just using them as installed ‘web pages’ Widgets need to know when to start and when to stop doing stuff. The widget that continually calls a web service data update even when it is no longer ‘visible’ to the end user is going to drain the device battery and drive up the users data plan bill!
With the Widget object, we can get hold of when the device is in focus and when it is hidden – allowing us to start or stop doing stuff. We can also tell if the user is roaming or on their home network – a smart widget might do less data traffic when roaming, or at least remind the user of the potential cost while roaming.
Widgets can use a local data persistence. Each field stored can be up to 4000bytes. This allows Widgets to have another trick – the perceived performance trick. Performance exists into states – perceived performance is the performance the user sees on their device. Real performance is how practical it is to make a device really do something. They are two different things, with perceived performance being more important than real performance. A smart Widget developer will ensure the perceived performance of their widget is fast. They can do this by making only asynchronous web service calls and by using only stored state on startup – thus removing any ‘web update’ delay.
What I like even more about the Widget object is that it can be extended. This means over time as more W3C standard interfaces for device service (like geolocation for example) are delivered, then this functionality can be added to WM 6.5 devices. It also means that WM 6.5 devices are open for developers to innovate and deliver some leading edge solutions!
Let me give you a quick run down of how this works.
Are you a COM programmer? Probably not – so let me just tell you something. Windows has all manner of different levels of interoperability, applicable to many different technologies and skill sets. At the fundamental core of Windows is COM. If you can’t extend or subvert Windows functions by any other means you are 99% likely to be able to do it at the COM level.
The Widget object is implemented with support for the IDispatchEX COM interface. IDispatch is the typical COM automation interface. IDispatchEX – or EXpanded – allows a COM object’s IDispatch interface – which normally reports a static list of method calls – to be extended at runtime with more method calls.
In a nut shell, Widget has a base level of functionality, which by using the IDispatchEX functionality we can add more functionality too. Quite literally, your new object’s methods appear on the Widget object. For example, Widget.MyMethod().
How do you do this? Well because Widget has the IDispatchEX, all we have to do is implement a normal IDispatch on our component. This presents method and properties that can be called from our component and that will appear on Widget.
We have to create a CAB installation file for our component – Widgets aren’t allowed to have ActiveX components in their installation package. This does present an initial installation issue, but basically your Widget needs to test for the existence of the dependant component/s and if they aren’t there redirect the user to the CAB URL so that this can be installed on first use. There after, the component/s will be available to the Widget and any other Widgets that want them.
There is one more ‘special bit’. To tell Widget that our component is designed to extend it we have to set a registry key. This can be easily done by including the key definition in the CAB installation file for the component.
[HKEY_LOCAL_MACHINE\Software\Microsoft\Shell\Widgets\ObjectModels\<ObjectName>] "CLSID"="{GUID}“
Where GUID is the GUID of your component control implementation.
A small aside here. My device was running a near final but not final build of Windows Mobile 6.5. When I looked in the device registry to set this key I discovered my ObjectModels was actually BuiltinObjectModels. All the documentation I have seen says it is ObjectModels, but adding the above key to BuiltinObjectModels worked for me :-) Once it worked I didn’t go back to try doing it with a ObjectModels key – sorry pressures of work.
With that done, and the component installed, our Widget can take advantage of our new functionality using script like this:
Var myObj = widget.createObject(“ObjectName”);
myObj.MyMethod();
What might that new functionality be? Well it could be new W3C bits as they are defined. But what about that intellectual property of yours that you’d prefer not to implement in script for the world to easily see. Or many you just need some additional native code features to help exploit device capability.
Using this feature means you can achieve all sorts of exciting stuff with your Widgets – or in fact, your exciting stuff can become the basis for other peoples widgets too.
I’m currently exploring an Augmented Reality framework that could be implemented for Widgets to exploit. This needs some camera integration not available to the Widget script engine. A widget extension object might just be the way to go.
I’m posting my extended widget source code on the downloads section of this site. Please also see the session slides PDF for more detail and do take a look a the WindowsMobile team’s blog – Jorge is doing an awesome job filling in the detail on Widget development.
There are also some helpful projects on Codeplex which provide Widget packaging, emulation and project templates for VS2008 and Expression Web.