HTML5 Geolocation

Recently I’ve been playing with HTML5 features just to see what it can do in the area of Rich Internet Applications (RIA).

Especially geolocation, local storage and application caching got my attention.
As I don’t think privacy is a concept of the past, I thought it would be a nice use case to track a persons location and store it locally.
So I created a little Location Tracker App to show those features in action.

The required browser features are not supported on all desktop browsers. But due to the fact that most mobile webbrowsers are based on Webkit, it runs on almost any mobile device. (Using a location tracker on a fixed PC seems to be of limited use anyway ;-))

It is amazing to see what you can do with HTML5, Modernizr, KnockoutJS, jQuery and a few lines of JavaScript. For me HTML5 is an interesting option especially for mobile devices.

RIA goes to Hollywood

Most RIA technologies today use an asynchronous model to communicate with the server, primarily to keep the UI responsive no matter what the server is doing. This principle is also known as the Hollywood principle. Don’t call us, we call you means that instead of continuously polling, the server calls back when the operation finished. In order to be notified when the server finished its job, callbacks are used.

For instance in Silverlight this leads to code like this

void ClickLoad()
{
    LoadCustomer(1,
    (result) =>
    {
        // Process result
    },
    (error) =>
    {
        // Process error
    });
}

void LoadCustomer(int id, Action<Customer> success, Action<Exception> error)
{
    LoadFromServer("select * from customers where id = " + id,
    (result) =>
    {
        success(result[0] as Customer);
    },
    (exp) =>
    {
         error(exp);
    });
}

void LoadFromServer(string query, Action<List<object>> success, Action<Exception> error)
{
    server.LoadCompleted += (s, e) =>
    {
        if (e.Error != null)
            error(e.Error);
        else
            success(e.Data);
    };

    server.LoadAsync(query);
}

Not very nice, is it? In jquery we find a similar pattern.

$.ajax({
  url: 'ajax/load.html',
  data: "query=1"
  success: function(result) {
    // Process result
  }
  error: function(XMLHttpRequest, textStatus, errorThrown) {
    // Process error
  }
});

Usually an application consists of several layers. In that case the callbacks have to be routed back to the original caller, leading to code that is neither easy to read nor easy to maintain.

From what is already visible, it is very likely that Silverlight and WinRT are going to have great overlap. The combination of XAML, C# and WinRT plus the tooling will be very familiar to all Silverlight users.
That means, it is likely that the asynchronous programming model will be the predominant model for client/server communication for Windows Metro style apps. In order to simplify this, C#5.0 is going to include the await/async keywords, that will make callback chaining obsolete.

Example:


void ClickLoad()
{
    try
    {
        Customer result = await LoadCustomer(1);
        // Process result
    }
    catch(Exception e)
    {
        // Process error
    }
}

async Task<Customer> LoadCustomer(int id)
{
    List<object> result = await LoadFromServer("select * from customers where id = " + id);
    return result[0] as Customer;
}

async Task<List<object>> LoadFromServer(string query)
{
    return await server.LoadAsync(query);
}

This is much cleaner than the examples above. Actually it is a synchronous programming model supporting an asynchronous runtime model. As asynchronous calls are very common in RIA applications the async/await keywords are going to change the way we program async calls in the near future, leading to code that is easier to develop and maintain.

I can’t await async in C# 5.0 😉

Wide or Deep? – That is the Question

There has been some discussion over the last months about the future of Silverlight and it’s role especially compared to HTML 5. This question is regularly asked in my Silverlight workshops as well, so it is time to shed some light on it.
To me it seems that essentially the question is whether you would like to go wide or deep.

Joey deVilla coined the terms in his blog post Silverlight, HTML5, The Web, The Phone and All That

Wide means reaching potentially every user on the planet.
Currently the only technology capable of doing that is HTML 4.1 (+ CSS + JavaScript of course). Not HTML 5 because it is not yet there. Neither finally specified nor fully implemented in all major browsers. (check HTMLTest for your browser compliance). Not mobile Apps cause there is no dominant platform yet. (Will there ever be one?) Even if a mobile platform, such as Android, had a market share of 50% a mobile App would only reach 50% of the mobile devices.

Deep means creating compelling user experiences in terms of performance, interactivity and usability. This is usually expected for line of business applications (LOB). Those applications run in corporate environments and target at power users who work with the applications on a daily basis. Here Silverlight is a great option. It reaches far beyond .NET as it can be combined with almost every backend technology via standard protocols.

Here are some quotes from related blogs to underpin this view:

With the blossoming of Silverlight, I think we finally get the best of both worlds when it comes to LOB – the ubiquity of the browser, the rich experience, the online and offline scenarios, and the great languages and tooling.
Jonathan Allen on InfoQ

Web devs never picked up Silverlight as their platform of choice. They always stayed close to what they felt most comfortable with – JS, HTML, CSS, AJAX. Sure, they suffered from cross-browser issues due to the fact that every browser has its take on how “standard” features should be implemented, but they stayed true to pure web development and never embraced Flash or Silverlight.
Vassil Terziev on Telerik blog

Silverlight will become dead if and only the hundreds of thousands or millions of devs who are doing desktop apps today decide that writing JavaScript is cool and that they can achieve more with HTML5-capable browsers, tooling and platforms than with Silverlight or some other similar technology. I honestly don’t see that happening, though, and believe in the merits of SL when it comes to development of heavy-duty LOB apps for the Enterprise.
Vassil Terziev on Telerik blog

In short, if you want to go wide use HTML, if you want to go deep use Silverlight.

I know that this is a bit of a simplification as other factors affect technology decisions as well. Actually is not the technology that comes first. Technology decisions should follow business requirements. And sometimes it is even a combination of technologies that produces a great solution.
But maybe the wide or deep question might help to find the best technology for your requirements.