email: ceberhardt@scottlogic.co.uk
on Google+
Last week I submitted Property Finder, a simple application that searches for properties based in the UK, to the Windows Phone 7 Marketplace. I was happy to receive confirmation that this application had been certified and published just two days later.
You can download the application from the marketplace now.
You can also watch a video of Property Finder on YouTube.
Property Finder isn’t your regular Silverlight-based application, it is written with HTML5 / JavaScript. It was made possible by the following technologies and APIs:
- PhoneGap – a framework that hosts JavaScript / HTML code within a native wrapper. This wrapper allows you to write cross-platform mobile applications which can be distributed within the Windows, Apple and Android marketplaces.
- KnockoutJS – An MVVM framework. The structuring that this framework imposes makes it much easier to handle tombstoning and persistence.
- Nestoria APIs – A property search API which provides a JSON interface.
- jQuery – everyone’s favourite JavaScript UI framework.
- jQuery-JSONP – A very small library that provides a much better JSONP implementation than the one provided by jQuery.
I have already written a couple of blog posts about PhoneGap / Windows Phone 7, including one which introduces the basic concepts, and a second one which tackles the problem of tombstoning. I plan to write a few more blog posts about how Property Finder was implemented, covering topics such as back-stack handling and how to disable the WebBrowser control’s pinch / scroll behaviours.
Why HTML5?
So why did I go to all this bother of implementing this application using HTML5? Why not write it in Silverlight instead?
There is one simple answer to that question – HTML5 is cross-platform. The code I have written for this application will work eqally well on a desktop browser, or within a browser-control on other mobile phoen devices (Android, iPhone, …). If you look at the current smartphone market-share, Android has suddenly leaped into the lead with WP7 a long way behind. Fortunately for WP7 developers, Gartner predicts a promising future, with a significant market-share by 2015. Also, recent analysis predicts WP7 will make a lot of impact in the enterprise.
However, whether these predictions are right or wrong, the one thing you can be sure of is that the future smartphone market will not be dominated by a single OS. Now and in the future, if you want to make your applications available to smartphone users in general, rather than the users of a specific smartphone model, you have to either write your application multiple times, once for each OS, or use a cross-platform technology.
Will the user-experience suffer?
This is a big question. Developing WP7 applications with Silverlight makes it easy to create the authentic Metro theme, however, most of the libraries for creating HTML5-mobile UIs focus on immitating the iPhone look and feel.
The easy option when creating a cross-platform HTML5 mobile application is to use the same UI across each platform. Whilst I can imagine Android users being happy with the iPhone look that jQuery Mobile presents, I have a feeling that WP7 users would reject it. I wanted to see how close I could get to something which looks authentic. Opinions so far seem to indicate that I have come close …
But perhaps not close enough …
The phrase “the user’s dog is barking” was new to me, but I think describes Property Finder quite well!
With the use of KnockoutJS the presentation (View) is separate from the logic (ViewModel), which means that it should be possible to change the view for Property Finder to make it look like an iOS application, with minimal effort. This is something I plan to do in the near future, releasing it on iTunes for Apple devices shortly.
Regarding productivity, once I got into the swing of JavaScipt / Knockout development, I found that I was quite productive. Most of the development work takes place within the browser, in my case, using FireFox and Firebug. Whilst the developer tooling is not great, the process itself is quite rapid; you can edit your code and have it up and running within your browser in less than a seconds!
Loose ends
Property Finder shows a lot of promise, however, it is not quite ready for putting in front of end users yet. There are a couple of technical issues that still need to be resolved before this application, and HTML5-based WP7 applications in general, are ready for prime-time:
The IE9 gray-boxes
If you download the application, or watch the video closely, you will notice that every time you click on a button, and image or the app-bar, a small gray rectangular overlay is render. This totally spoils the illusion I am trying to create! I have asked on the Microsoft Windows Phone Blog, asked on StackOverflow and raised an issue against PhoneGap, but to no avail.
If someone from Microsoft is reading this, please address this issue! It will seriously hamper the use of HTML5 for web-applications on Windows Phone 7. (And after you have fixed that, please add CSS 3D transforms, and transitions – thanks!)
Device capabilities
Before submitting my application to the marketplace I was careful to detail its capabilities, listing it as requiring:
Network access, Web browser, geolocation
However, one of the first people to download the application informed me that the ‘my location’ button was not working. On checking my listing on the marketplace I discovered the following list of application capabilities:
data services, movement and directional sensor, microphone, music and video library, owner identity, camera, contacts, camera, compass
All kinds of phone features that I was not using, minus geolocation, which I was! So what is going on here?
When your application is submitted to the marketplace, static code analysis is used to determine the phone capabilities used. Because my application includes the PhoneGap assembly, which provides JavaScript APIs for camera, compass, contacts etc … my application was listed as using these phone features, even though my application doesn’t actually use them!
So why is geolocation not listed? This is because PhoneGap does not supply a geolocation API, instead I am using the HTML5 geolocation APIs which are supported by the WebBrowser control directly. It appears that the tools the marketplace team use to detect application capabilities does not ‘understand’ that a WebBrowser control can use the phones geolocation capabilities.
I am sure these issues can be resolved … I’ll keep you posted!
Conclusions
I am happy to see that my first attempt at a HTML5-based WP7 application was accepted by the Windows Marketplace. I am sure that HTML5 will play a significant part in the future of mobile application development and it is re-assuring that Windows Phone 7 can be a part of it.
More blog posts and technical details to follow …
Regards, Colin E.
Tags: HTML5, JavaScript, PhoneGap
Quick question: If you’re going to make an app out of HTML5 that really doesn’t look like WP7 Metro and does little more than list some properties, why not just make a mobile webpage that does the same thing? It makes it easier on users as well as development. It is essentially what you’re doing anyways it seems except that you’re packaging your website into an installer.
However, I have to say that I tried most of the PhoneGap WP applications and yours is by far the best one. I think the biggest limitations you have is not necessarily the HTML or javascript, but PhoneGap itself… which is why I’ve decided never to use PhoneGap for mobile app development. I think you did a great job overcoming the limitations of the platform you were using with this app you’ve created.
Hi John,
if you do not want to distribute your app via an app-store or marketplace, then yes, hosting it on a website is by far the easiest option. The only issue with this is if you need to use some capabilities of the phone that are not available via regular JavaScript APIs, the camera for example, where PhoneGap would provide you with a suitable API.
Have fun, Colin E.
I think that this is a great start, but I agree on the dog barking…
The main thing that unsettles me is the responsiveness of the appbar buttons, there is noticable lag and I’m just not used to lag on a WP7 device! This is on my Lumia 800, I haven’t looked at it on the Omnia.
Any ideas about where the delay comes from here?
C
Hi Carl, personally I think the biggest problem is the ‘gray box’ effect. I have been bugging Microsoft about this one!
Where exactly are you experiencing a lag? Is it, for example, when you click on the about button, the time taken to show the About page? The app is quite responsive on my phone (HTC Trophy).
Slight envious of your Lumia!
Colin E.
Hi Colin,
I think that you are right about the grey box being the biggest problem.
The lag itself is not huge but is just before the grey box appears when clicking on any of the elements. It’s most noticable on the appbar ellipsis, I guess this may be due to the animation that’s in there?
Whenever the missus resurfaces from Christmas shopping I’ll give it a try on the Omnia…
I know next to nothing about PhoneGap, just started looking at it yesterday, but I wonder if any of this has been improved in v1.3?
C
HI Carl,
Thanks for clarifying, I haven’t really noticed this myself – but I am pretty sure I know what the problem is. I recall reading that the developers of the HTML5 iPad application were finding the application was a little unresponsive. This is because the browser waits ~300ms before firing click events in order to support gestures and double-tap. To fix this problem they created FastClick, which is native code that handles clicks, immediately passing this on to the DOM elements. You can read about it here.
It should be possible to use a similar approach for WP7.
I’m afraid the responsiveness and gray-box highlight have not been fixed in PG 1.3, they are ‘features’ of the WP7 platform – i.e. Microsoft needs to provide a fix.
Colin E.
[...] Read original post by Colin Eberhardt at ScottLogic [...]
Great job on this app, Colin. I also noticed all the capabilities listed with the app and was scratching my head on e.g. why Camera was needed… but of course it’s because of the Marketplace’s static code analysis. This is definitely an issue with PhoneGap – even if not a very large one, but some users are quite sensitive and sometimes stay away from simple apps asking for lots of capabilities.
On the location end, a workaround idea: insert some “dead code” using something from the System.Device.Location namespace?
All in all I think if you can overcome the theming issue and some small niggles this kind of development method could be even more viable, now that several apps want to target iPhone, Android as well as Windows Phone – a pretty large development effort for three apps!
Agree, some geolocation dead-code would probably fix the issue where the ‘My Location’ button fails. I will give that a try in my next update.
I have submitted an issue with PhoneGap, long-term I think the only viable solution is for them to split up their library into separate assemblies based on capability usage.
Anyhow, thanks for the feedback