Colin Eberhardt's Technology Adventures

Property Finder – the first HTML5-based Windows Phone 7 Application

November 7th, 2011

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: , ,
Posted in Uncategorized | 9 Comments »

Dart – will Google make HTML5 applications viable?

September 11th, 2011

Just a few weeks ago I wrote a blogpost “Can Microsoft ‘fix’ JavaScript and make HTML5 applications viable?”, where I described some of the issues with JavaScript and how these could be solved by Microsoft if they wrote a C# to JavaScript compiler. Just a couple of days ago it was announced that Google have been working on a new language that they hope will replace JavaScript and its deficiencies. This new language is called ‘Dart’.

To briefly recap my earlier blogpost; HTML5 is causing a lot of buzz at the moment, proving itself to be a serious threat to Silverlight and Flash / Flex. When meeting with out current and potential customers, who work within the financial domain, almost all of them have aspirations to migrate their desktop and web applications to HTML5. There is no doubt that HTML5 and CSS3 bring some fantastic new features to the web, making it possible to develop the kind of complex application that previously required a plugin. However, the fundamental problem with HTML5 is JavaScript, which is not an ideal language for enterprise application development.

Google recognises this issue. An internal email from Nov 2010 that outlines their strategy for ‘Dart’, says:

“Complex web apps–the kind that Google specializes in–are struggling against the platform and working with a language that cannot be tooled and has inherent performance problems”

In the past Google has used Java to JavaScript compilation (GWT) and annotated-JavaScript to JavaScript compilation (Closure) to overcome these problems. In my previous blogpost I speculated that Microsoft could use a similar approach, offering a C# / VB.NET to JavaScript compiler, allowing HTML5 developers to use the full power of Visual Studio. However, with Dart Google are looking to go one step further:

“The goal of the Dash effort is ultimately to replace JavaScript as the lingua franca of web development on the open web platform.”

That’s quite an ambituous goal!

In terms of strategy, Google have adopted a two-pronged approach. They are still participating in the standards-based evolution of JavaScript, as part of the ECMA committee. In parallel that have been developing Dart, which looks like it will be unveiled in one month’s time at the GOTO conference.

The goals for Dart are; Performance, Developer Usability and Tooling. The language will maintain the dynamic nature of JavaScript, which has made it such a popular scripting language for the web. However, it will be more easily tooled, with optional types, allowing refactoring and IDE code-comprehension (which gives Intellisense etc…) – vital features for enterprise application development.

Dart is designed to run on a VM within the browser, just as JavaScript does. It can also be run within a browser that does not have a Dart VM by compiling it to JavaScript. I think this is essential to the success of the language, allowing it to be used across any browser, regardless of whether the manufacturer chooses to support the Dart VM.

For enterprise application development, where quality tooling is very important, I am very keen on the idea of writing code using a more enterprise-centric langauges like Java or C# then compiling it to JavaScript. What I like about Google’s Dart initiative is that they are proposing to fix the issue directly at source, by replacing JavaScript.

Why not evolve JavaScript? Brandon Eich, the inventor of JavaScript, is clearly not happy about Dart, favouring evolution of the language via standards and committee. Personally I don’t think this is working at the moment for a couple of reasons. Firstly, HTML5 is upon us and gaining popularity fast, JavaScript desperately needs some attention, fast! Secondly, non-backward-compatible or breaking changes are not possible via evolution, there are features of JavaScript that really need to be broken in order to fix them.

What about jQuery and other popular libraries? If Dart is really going to fix JavaScript, I would imagine that existing JavaScript libraries will not work with it. The web developer community will probably find it hard to accept Dart without jQuery.

Will everyone adopt it? This is probably the most important question of all. It is clearly Google’s aim that everyone does adopt Dart, then they will pass it over to committee, just as JavaScript was passed over to ECMA. The problem is, what’s in it for the other browser manufacturers? How will they benefit by adopting Dart? To be honest, I can’t see any benefict for Mozilla, Microsoft or anyone else. Lars (Google Tech Lead) has promised to Lars to “sweet talk” the other browser vendors, which in acknowledges the issue they face, but since when has sweet talking been part of the browser wars?

Personally, looking at the team behind Dart and their aim for the language, I have every faith that it will be a great language. I would love to see JavaScript replaced with something better, whilst maintaining some of its more elegant features.

With so many people looking to use HTML5 as part of their future web strategy and as more complex applications are built on the web, Dart could be a good thing for all of us.

Regards, Colin E.

Tags: , ,
Posted in Uncategorized | 12 Comments »

Can Microsoft ‘fix’ JavaScript and make HTML5 applications viable?

August 16th, 2011

Microsoft’s recent change in stance over Silverlight, promoting HTML5 as “the only true cross-platform solution for everything”, seems to have sidelined Silverlight as a niche framework. This has understandably caused a great deal of upset and confusion in the .NET development community. Despite this, Microsoft are remaining steadfast and tight-lipped about their vision for tighter integration of HTML5 into Windows 8 (and as a result just how side-lined Silverlight will be), until the BUILD conference next month. Recently I have read numerous blog posts about the difference between HTML5 and Silverlight, and how to select the right technology for your development, however almost all of them seem to ignore the great-big thorn in HTML5s side … JavaScript. In this blog post I will explain why JavaScript is such a big issue for Microsoft and what it could do to solve this.

That HTML5 will be a huge success is a given. The specification is not finished yet; the parts that are finished are not fully-rolled out, however it is making technology headlines on a daily basis. The HTML5 buzz has also been felt by both technical and non-technical managers, who you will often find asking, “why aren’t we creating HTML5 applications?”. Pointing at the unfinished specification is a little unfair on HTML5, you can reliably use a number of the APIs right now, and they will certainly provide a ‘boost’ to your current web-offerings.

HTML5 is a real mixed-bag of features, from the complex, such as canvas and video, to simple semantic markup improvements and a powerful set of CSS features. Because HTML5 provides a spectrum of features from the simple to the complex, I don’t doubt that every new site will be using HTML5 in a few years time, you simply have to add rounded borders or a <header> tag to earn yourself the coveted HTML5 badge!

One concept that underpins the HTML5 specification(s) is that of client-side web-applications. The server-side web-application, where business logic and presentation logic reside on the server, spitting out markup (sprinkled with a bit of JavaScript) are becoming an architecture of the past. The model where the server exposes business logic as a service makes it much easier to provide a front-end on a range of devices (mobile, tablet, desktop), a range of operating systems (Windows, iOS, Android), allows the effective use of client CPU, and provides a more accessible service that customers can integrate into their own application. From my perspective the most significant undertone of the HTML5 specification is that it supports this model.

The problem is that the name ‘HTML5’ can be a little misleading. Whilst the specification has much to do with HTML, it has much more to do with JavaScript. In fact, many of the HTML5 APIs have nothing to do with presentation or layout. Any article which compares HTML5 and Silverlight, without focussing on JavaScript is really missing the point.

So, what is my big issue with JavaScript?


Image used under Creative Commons Licence from Flickr

JavaScript was hastily developed as a language for scripting the web. Unfortunately it has not evolved much since its inception. Certainly the APIs that surround it have evolved, including the DOM APIs, HTML5 and popular libraries such as jQuery, however the language itself remains largely unchanged.

The big issue with JavaScript is that it is not well suited for the development of large applications, and if we shift to a model where the server provides a service which is consumed by the client web-application, this necessitates a lot of JavaScript code. I don’t want to go into all the gory details of the problems with JavaScript, but here are a few:

  • Many language quirks and gotchas (see this article on codeproject)
  • A lack of ‘familiar’ object-oriented concepts (I am not going to make the mistake of saying it is not an OO language!)
  • A lack of dependency management
  • A lack of organisational structure (namespaces)
  • A very small ‘base’ library (for example no event support, string formatting, etc…)
  • It is not strongly-typed
  • A confusing array of patterns for solving some of the above!

This list is certainly not exhaustive; rather it is just a brief illustration of some of the obstacles that JavaScript presents to the developer of complex applications. Many of the items listed above are features of the language that are advantageous in a simple, scripting context, but when used to develop complex applications they are quite troublesome.

Another issue with JavaScript is not so much the language itself, more the attitude of developers towards the language. Because of its quirks and its predominant usage as a language for scripting web-pages (with the usual “google → cut → paste” approach) many developers simply don’t bother learning how it works. I have interviewed many job candidates who list ‘JavaScript’ as one of their skills, yet they cannot describe the difference between the binding of the ‘this’ variable between JavaScript and C#/Java.

There are numerous JavaScript frameworks that go some way towards solving the above issues … filling in the gaps. This is an area that Microsoft has dabbled in before, with the Microsoft Ajax Library adding inheritance patterns and .NET style libraries (albeit with a very clumsy, verbose and convention-heavy syntax!).

Whilst the list of issues above presents a challenge to the JavaScript developer, they provide just as great a challenge to the tool providers. Many features of existing IDEs, Intellisense (auto-completion) and structured views of the code rely on language features that are absent from JavaScript. Again, Microsoft has provided some innovations in this area, with pseudo-execution of JavaScript code providing some Intellisense support. Unfortunately this neat feature, which works well if you have all your code in a single JavaScript file, is less easy to manage on a large, more complex application. From personal experience I find Visual Studio adds little value to my JavaScript development experience, I am equally happy with Notepad++ and JSLint!

So when Microsoft announces their tighter integration of HTML5 / JavaScript into Windows 8, what innovations are they going to announce?

Personally, I think if Microsoft is serious about HTML5 and its potential for client-side application development they need to do much more than just add CSS3, canvas and video support to ASP.NET. They need to support the client-side application model, where ASP.NET no longer has a stake. To fully support this they need to ‘fix’ the problems with JavaScript.

One of Microsoft’s most prized assets is Visual Studio, their investment in tool-support allows you to use the same quality tooling for developing in a wide range of languages (C#, VB.NET, C++, F#, …) and frameworks (WinForms, MFC, WPF, Silverlight, ASP.NET, …). To fully embrace HTML5 / JavaScript it has to be fully embraced by Visual Studio. But therein lies the problem, the lack of namespacing, familiar object oriented concepts, strong-typing and base ‘class’ framework makes this a challenge.
I think the worst thing Microsoft could do is add their own JavaScript framework to the mix, further fragmenting the JavaScript development experience. Thankfully they recently adopted jQuery within their ASP.NET framework, showing signs that they are willing to work with existing open-source frameworks. So if they do not announce a new JavaScript framework, what could they provide instead?


Image used under Creative Commons Licence from Flickr

Microsoft’s Scott Henselmann has published a couple of interesting blog posts about the concept of JavaScript being the assembly language of the web (or the JVM of the web depending on your perspective). His second blog post included comments from a number of JavaScript thought leaders including its creator Brendan Eich who said “Believe it or not, classical OOP languages — especially ones with not-very-expressive static type systems — are not the only way to build large apps. It can be done in JS, but it’s harder than it ought to be”.

Google have already made some innovations in this area, the first is Google Web Toolkit (GWT), which allows developers to write Java code (using the powerful Eclipse IDE), which is compiled into JavaScript. The second is Google Closure Compiler, a JavaScript to JavaScript compiler / optimiser that provides type checking via annotated comments. It is this area that I think Microsoft should be investing in.

Microsoft could create a C# (or VB.NET etc…) to JavaScript compiler with an accompanying set of .NET base-class libraries. This would significantly boost Microsoft’s JavaScript offering in that it would be fully supported by Visual Studio, providing the developer with the quality tooling that they are used to when developing using other .NET frameworks. Furthermore, the C# to JavaScript compiler could be used to compile the existing .NET base-class library giving developers a large suite of familiar libraries for use within their code. You could event support C# to jQuery using a fluent Linq-style API!

So how would this work a runtime? When used on the internet to write applications for the browser or mobile browser, a set of C# DOM APIs could be created that compile to the ‘native’ JavaScript equivalent. HTML and CSS3 could of course be included directly within the project as resources.

On the desktop there are a few options, HTML could certainly be used as the presentation technology, but there is of course another option … XAML. Microsoft has clearly indicated that XAML will be part of Windows 8, considering that Silverlight 1.0 was XAML + JavaScript, it is clearly possible to have a XAML UI backed by JavaScript code. Although, it would seem a bit convoluted to compile C# to JavaScript to interact with the UI generated from XAML when C# APIs exist already!

In summary, I feel the current focus on HTML5 whilst ignoring the very real JavaScript issue is going to cause adopters of this technology a lot of pain. Whilst this technology set gives a fantastic boost to interactive websites, using JavaScript for the development of large client-side applications is an expensive option. My hope is that if Microsoft really embrace HTML5 they look beyond simply adding tag support and tooltips and address the real problem … JavaScript.

Regards, Colin E.

Tags: , ,
Posted in Uncategorized | 21 Comments »