Archive for July, 2012

How will HTML5 “apps” affect the app store eccosystem ?

I noticed with interest a new story last week that The New York Times Pulls App from the BlackBerry store. On the one hand, The New York Times has a great mobile web site and Blackberry devices have a super  HTML stack, but it got me thinking.

Though HTML5 has not reached a state of API evolution such that apps built with HTML5 can do everything that a native application can do, the gap is rabidly narrowing and, in many cases, the technology is already “good enough” to meet the developer’s needs and reap the benefits of open web development.

Mozilla has been building an HTML5 apps strategy for some time.

Google recently expanded it’s apps strategy with a “packaged” apps initiative.

Microsoft has a new web based model for Windows app building (though a proprietary one).

Missing is an HTML5 installable app strategy for Apple devices but you can use tools like PhoneGap to package an HTML5 app for the Apple store.

New York Times leaving the Blackberry store behind is only a single case, but as HTML5 capabilities evolves, lower volume app store will likely experience an decrease in store specific support. After all, pulling support for a specific store doesn’t meaning leaving customers behind.

It even seems like the pace at which the evolution of the HTML5 APIs might accelerate with the W3C and the WhatWG dividing their concentrations.

I’ve been making a living writing code for 30 years and, as an industry, we have always been looking for ways to “wrote once – run everywhere” – or at least to maximize code reuse.

I personally think HTML5 will be the closest we have ever come as an industry – at least on the front end, and I like the fact that the more we move logic to the client tier, the more simple the server side can become, thereby eliminating the need for overly complex infrastructure and applications on the back end.

So I’m curious, how do YOU think HTML5 is progressing? Are yo using, or planning to use HTML5 specific features? What parts are most interesting and important to you?

Testing HTML5 Web Workers (A Demo)

Yesterday I started a series of blog posts on HTML5 apps oriented architectures. You can read the first post HERE.

The demo lets the user select a video that they want to watch and then, when the click on the link, the code dynamically download’s that video and plays it for the user. The next logical step for the evolution of the demo is to move the video download logic out of the main thread using HTML5 Web Workers.

On it’s own, moving the download to another thread doesn’t buy us much. There is nothing for the user to do while they are waiting for the first video to download and subsequent download requests don’t interrupt the video player until they are finished.

But, I’m looking forward to how I want the down feature to ultimately work. Ultimately, I want to store any downloaded videos in a data base and let the user watch saved videos while downloading new videos. That means I’ll need a mechanism by which the user can add videos to a download queue in a Web Worker.

So I spent time today looking into how web workers function. I found lots of demos but I didn’t find one that I thought was a really straight forward test. So I wrote one.

The test model is simple and you’ve probably seen this oversize when learning web services.

We’ll create a Web Worker with a method that receives an argument. The Web Worker will add some text to the inbound argument and return the combined string.

Lets first look at what the running app and then we’ll review the code.

Web Worker Sample

When I click on the “Send to Worker” button, the button click event handler sends the string “MisfitGeek” to a method in the worker process. The worker process appends some text and returns the newly combined string.

Web Worker Demo - Return

Note the number in square brackets at the end of the string in the alert box. It’s value is “1″.

If I click on “OK” and then click on the “Send to Worker” button again, that numeric value changes,

Web Worker Demo - Return

Now let’s look at the code.

The code for the Web Worker lives in a JavaScript code file named “worker.js”.

Here is the code: (It’s just 6 lines long.)

var callCount = 0;

self.onmessage = function(event) {
  // Below is a single line of code seperated for display purposes.
  self.postMessage( +
                   ' : Hello from your worker ! [' + callCount + ']');

The code doesn’t do all that much. It increments the local variable “callCount” and then creates and returns a string by combining the string parameter that was passed in with local values.

The calling page looks like this.

<script type="text/javascript">// <![CDATA[
        var worker = new Worker('js/worker.js');
        worker.addEventListener('message', function(event) {
        }, false);

        function callWorker(msg) {
           worker.postMessage(msg); // start the worker.

// ]]></script>
    HTML5 Example - Worker
<div id="mainDiv" style="text-align: center;">
  <button onclick="callWorker('MisfitGeek')">
    Send to Worker.
 These aren't the droids you're looking for.
 - Move along... move along.</div>

Lines #5 and #6 above are where the magic happens.

Line #5 says take the code in worker.js and run it in a Web Worker.

Line #6 says to hook up the following anonymous function for when that worker posts a message. In our case all we are going to do in that funtion ios to use the message send to the main thread from the Web Worker to display in an alert dialogue.

Line #10 declares a local function that will be called when the user clicks on the “Send to Worker” button which will be called with a text argument (in our case this is hard coded to the text “MisfitGeek”. That function call sthe Web Worker postMessage() method, sending as an argument the text (“MisfitGeek”).

Not that the variable callCount defined in worker.js is not accessible outside the Web Worker.

Simple but powerful. We will use this method in a future post to download video files as selected without blocking the user interface !

Shifting HTML code design to App Architectures – a demo.

For the last nine months I’ve been focused on the potential of HTML5 as an application development platform. When I first started talking about HTML5 for building apps, it seemed like very few people really “got” what it meant. Rather that HTML simply being something that gets spewed out by your server. HTML5 and it’s companion technologies, themselves became a platform.

In fairness, there were lots of developers that were starting to add “richness” to their HTML / client side work, predicated in no small part on the change in web development perspective that was catalyzed by the whole “Ajax” phenomenon.

More and more people seem to be embracing what the HTML5 wave of technologies could mean to development of all sorts. I say “could” mean because I believe HTML5 is in its “usable” infancy.

I recently asked my readers how important they think “off-line” support for HTML5 apps is.

The answers were great and showed how far developers as a group have advanced their perspective on where HTML development is going.

During my years at Microsoft I spent much time helping developers change the way that they looked at ASP.NET based web development by authoring patterns and practices that were focused on developing web applications that used real client / server interactions. With the advances Mozilla is making with it’s HTML5 Apps platform and the Firefox OS, it seems like a good time to apply that same kind of guidance to apps focused patterns and architectures.

So here is the beginning of a demo project for apps.

Understand that this app is a learning project and it’s focused on MozApps and Firefox OS apps. That means I’m writing the sample specificity for Gecko based run-times. If you were writing a cross browser app supporting Gecko, Webkit and Microsoft browsers you would have to do some feature detection and code against the features that are available in your browser. Perhaps I’ll write some samples to demonstrate that in the near future but for now I’ll focus on apps for one of the Gecko run-times.

Here is what the user interface of the demo looks like. I’ve only implemented the first feature for demonstrating “sometimes connected” architecture, but we’ll build on this app over the coming weeks.

Dynamic Media Demo

You can run the page here – just remember that this demo targets the Gecko run-time so if you’re not using a current version of Firefox you’re sort of on your own.

This page will play video files but what is a bit different about this page than you would have found in “old school” HTML page design is that the page contains a single media element and that HTML video tag has no video source specified.

This might be a common scenario in an HTML5 app (Think YouTube or Netflix). One would not, really could not, embed all the videos that the end user “might” want to watch.

In this case, we will not download any videos by default when the page is loaded, we’ll wait until the user selects a video to watch and then DYNAMICALLY fetch that video. When it was been retrieved we’ll play it. In our sample the user can choose from three videos but that number could be 100s of videos since none of the choices are actually downloaded until the user selects a video to watch.

At the top of the UI the user has three videos that they can choose from to watch.

<h3>Videos Available For Viewing</h3>
<div class="gallery">
<div class="photo"><a href="javascript:loadMedia('demo-vid.webm');">
 <img src="img/foto.jpg" alt="" width="155" height="110" />

 <a href="javascript:loadMedia('demo-vid.webm');">Fetch Video 1</a></div>
<div class="photo"><a href="javascript:loadMedia('demo-vid-2.webm');">
 <img src="img/foto.jpg" alt="" width="155" height="110" />

 <a href="javascript:loadMedia('demo-vid-2.webm');">Fetch Video 2</a></div>
<div class="photo"><a href="javascript:loadMedia('demo-vid.webm');">
 <img src="img/foto.jpg" alt="" width="155" height="110" />

 <a href="javascript:loadMedia('demo-vid.webm');">Fetch Video 3</a></div>
<div class="cleaner"></div>

Notice that clicking on each image causes a bit of JavaScript to execute. (Yes I know there are other, and perhaps better ways to do this, especially if you are a jQuery aficionado but this is a straight forward method for learning simplicity.)

Here is what the loadMedia() method looks like.

function loadMedia(mediaFile) {
   var xhr = new XMLHttpRequest();
   var mediaFileLocation = "media/" + mediaFile;"GET", mediaFileLocation, true);
   xhr.responseType = "blob";      // Set the responseType to blob
   xhr.addEventListener("load", function () {
      if (xhr.status === 200) {
         blob = xhr.response;         
         var mediaFile = blob;
         var URL = window.URL || window.webkitURL;
         var mediaURL = URL.createObjectURL(mediaFile);
         var mediaElement = document.getElementById("media-element");
         mediaElement.setAttribute("src", mediaURL);
      else {
		  // Download failed. Stop Download Status.
		  // ToDo: Add Error Handeling.
   }, false);

The function catches a file name to be retrieved and then does an XmlHttpRequest call to fetch the file from the media directory on the server. Not that this method runs on the same thread as the user interface. In a later version we will use “HTML5 Web Workers” to cue the video downloads without blocking the user interface.

The first thing that loadMedia() does is show a hidden div named dlstatus-container. This div contains an animated gif file that indicates the file is being downloaded.

   <div id="dlstatus-container" style="display:none">
      <h2>Downloading Video .......</h2>
      <img src="img/dl-status.gif" alt=""  />
       </br /><br /><hr /><br />

I use a free on line tool at to generate the “working” image.

Line 7 in the listing above defines an event listener and line 8 tests to make sure the download was a success.

After that we turn off the status indicator div and the display the div that contains the HTML5 video element.

   <div id="player-container" style="display:none">
      <h2>Media Fetch</h2>
      <video id="media-element" controls="controls" 
             width="520" height="340" autoplay="autoplay">
      </br /><br /><br /><hr /><br />

Note that autoplay on the video element is on, so that when the video element’s source attribute is populated with the downloaded video on line 16 of the loadMedia() method, the video begins to play.

You can test the feature here –

Note the behaviors.

  • If you start playing one video and then select another video, the first video will continue to play until your second choice is ready.
  • If you play one video, then play a second video, then go back to the fist video you watched – it will begin playing immediately when you select it, since it has been automatically cached by the run-time when it was downloaded.

A simple but meaningful feature.

Stay tuned. We’ll start adding features in the next post in this series.

Weekly HTML5 Links Post On Mozilla Hacks

Hi Folks – this weeks Mozilla Hacks post of links for HTML5 Apps Developers is available HERE !

How important is HTML5 Off Line ?

There are a collection of facilities that are available to developers using HTML5 that enable an HTML5 app to run when no connection to the internet is available.

Of course, the first access to the app requires an internet connection but during that first experience the browser can use AppCache to save the required resources locally so that they are present later when a network connection is not available. Clever use of the NETWORK and FALLBACK sections help you tailor the app’s experience based on the network connection state.

Local Storage and IndexedDB provide facilities to store needed data for use both online and off. window.navigator.onLine and associated event listeners can even help you switch state at runtime.

So technology is in place for building offline HTML5 apps. At Mozilla we’re busy building an HTML5 apps run-time for running HTML5 apps on Windows, Mac,Linux and Android, a marketplace for distribution of such apps, and a cool HTML5 based phone operating system (Firefox OS).

So for the last 10 months or so I’ve been really focused on HTML5 “apps” and I’m especially excited about the B2G Phone OS but it does leave me with the question, how much do folks really need off line functionality in an HTML5 app ?

Fault Tolerant Cloud Based Hosting has become a norm in recent years and the service levels have been very reliable so the question become the utility of the proverbial “last mile”.

For mobile users there are two questions.

1.) Is there service everywhere I need there to be.

2.) How much will use effect my service plan.

Here in rural New England, where I live, there are many spots without cell service coverage. However I tend to only experience them when I’m driving in between places that DO have coverage so the inconvenience is minimal.

As to the data usage, my monthly service contract comes with a monthly data allowance. If my internet usage surpasses that allocation AT&T just automatically adds another “block” of usage to my bill for that month. (I think the increment is $20USD) – So at least it’s not like the old days when you exceeded your plan, silently went into a high-price-by-the-minute plan and got surprised by a $1,000 cell phone bill at the end of the month.

But, the way that it works in the USA and Europe is not necessarily the way it works in the resat of the world.

For example, Mozilla’s phone OS initiative is expected to launch in Brazil first (read more here) but consumer usage profiles in Brazil are very different. Something like 85% of cell phones are acquired on prepaid / pay-as-you-go contracts. This means when you run out of prepaid data access, you’re done until you buy more. Local experts also inform us that “public” use of smart phones is significantly curtailed due to theft concerns, etc.

So share your thoughts on the following two questions.

1.) How much does OFF LINE functionality matter for a desktop app?

2.) How much does OFF LINE functionality matter for a MOBILE phone or tablet app?