This is fifth and final part of my Widget Anatomy series that described the ins and outs of the Widget Framework that shipped with windows mobile 6.5. In this installment we will discuss the different ways a Widget can receive inputs from the user and how best respond to them.
First the easy one: Touch
Touch is the primary input for all our professional devices and it looks like they will be a significant percentage of our device offering. Handling this is fairly easy since the browser engine translate the touch event into a mouse click which can be handled by using the onclick event handler as shown in the following example:
1: <html>
2: <head>
3: <script type="text/javascript" src="js/ImageSearch.js"></script>
4: </head>
5: <body>
6: <div id="SearchBox">
7: <input id="SearchQuery"/>
8: <img src="images/search.png" class="searchIcon"
onclick="doSearch();" />
9: </div>
10: </body>
11: </html>
It is important to note that, since there is no “mouse” for widgets most of the other mouse related events like onmouseover, onmousemove, etc will not be triggered in a reliable enough way to use them.
Now the hard one: The Directional-Pad
I been making special emphasis to the fact that Widgets work seamless across all Windows Phones so, we need to ensure that the can be used correctly when the user interacts with it using the directional path.
It is important to note that, unlike IE6, a The widget framework will respond to a D-Pad input event by moving the focus to the closed actionable element in the direction of the user click. This behavior is similar to the old pocketIE and among friends we call it “Link to Link navigation”.
An actionable element is defined as any DOM element that can receive focus (Like a form field) or an element that implements its onclick event handler. When an actionable element gain focus the onfocus even is triggered, the same way, the focus is moved away from the element the onblur event is triggered. Now we can easily use those events to show the user where the focus is since the Widget Framework does not automatically highlights the focused element. We do this because we don’t want to inhibit the creativity of the widget creator to design his/her own focused highlight strategy.
The only “little” extra detail is that all elements that can gain focus need to have the tabindex property defined (the value is not important). This is easily forgotten but if not set, the focus and blur events will not trigger,
<html>
<head>
<script type="text/javascript"> 1:
2: function OnFocus(element) { 3: element.style.backgroundColor = "red";
4: }
5:
6: function OnBlur(element) { 7: element.style.backgroundColor = "white";
8: }
</script>
</head>
<body>
<div onfocus="OnFocus(document.getElementById('one'))"
onblur="OnBlur(document.getElementById('one'))"
onclick="alert(1)"
tabindex=1>
<p id="one" style="font-size:medium:">1</p>
</div>
<div onfocus="OnFocus(document.getElementById('two'))"
onblur="OnBlur(document.getElementById('two'))"
onclick="alert(2)"
tabindex=2>
<p id="two" style="font-size:medium;">2</p>
</div>
</body>
</html>
In this example, we created two divs that can receive the input focus, you can move from one to the other using the D-Pad, the element that receives focus changes the color of its background to red.
Conclusion
Writing Windows Mobile applications is now as easy as writing a web page, and, by following some best practices your widget can be as functional and attractive as any other native application on the platform.
This is the end of this blog series and since Windows Phones are now available on many countries, you should go get one and write many cool widgets for it. Don’t forget to share the results with the world by uploading them to the marketplace!
Until next time
Jorge Peraza
Widget anatomy series at glance
#1 The manifest
#2 The keys for a great user experience
#3 Performance and battery life
#4 Security insights
#5 Touch and D-Pad inputs, oh joy!