11/06/2011

HTML5 Offline Applications: ‘Donut Hole’ Caching

Craig Shoemaker

HTML Offline Applications allow you to create applications that work without an Internet connection using technologies native to the Web browser. Pages included in an offline application are listed in the application manifest and thus are served from the application cache whether a connection to the Internet is present or not. Sometimes, however, if an Internet connection is available, you may want to display some data from the server without requiring the user to change pages.
Scott Guthrie introduced the concept of “donut hole” caching in ASP.NET, where a cached page may include small windows of content that are updated independently of the cached page. This tutorial demonstrates how to implement an offline page that makes an AJAX call when connected to the Web in order to display live data to the user. When offline, the page simply renders default data in the page.
There are a number of practical reasons to implement an offline application. While most developers first think of the mobile context when considering who might use an offline application, almost any Web site can benefit from having some availability regardless of connection status. A site’s Home and Contact Us pages are excellent candidates for offline availability so users can get some basic information about the organization, even when disconnected.

Building the Application

The example in this tutorial demonstrates how to cache a “Contact Us” page that displays notifications of upcoming events to users. When a user is connected to the Web, live event listings are displayed; otherwise, a telephone number prompts the user to call for event information. This approach keeps the user informed and connected with or without access to the public Web.
Figure 1 depicts how the page is rendered for offline viewing, while Figure 2 shows how the page looks when served from the application cache but the computer is connected to the Web.
When the User Is Working Offline, the Application Prompts Him to Call for Event Information
Figure 1 When the User Is Working Offline, the Application Prompts Him to Call for Event Information

When the User Is Connected to the Internet, the Application Shows Event Information from the Server
Figure 2 When the User Is Connected to the Internet, the Application Shows Event Information from the Server

The Manifest

The application manifest acts as the master list of resources included in the offline application. Figure 3 shows the full manifest file for this example.
Figure 3 Manifest File (manifest.aspx)
CACHE MANIFEST
# version 1
CACHE:
contact.htm
style.css
jquery-1.6.3.min.js
map.png
NETWORK:
events.htm
<%@Page
    ContentType="text/cache-manifest"
    ResponseEncoding = "utf-8"
    Language="C#" AutoEventWireup="true"
    CodeBehind="manifest.aspx.cs"
    Inherits="ConditionalCaching.manifest" %>
<script language="CS" runat="server">
  void Page_Load(object sender, System.EventArgs e)
    {
      Response.Cache.SetCacheability(HttpCacheability.NoCache);
    }
</script>
The file begins with the requisite CACHE MANIFEST header and includes a versioning comment to allow changes in listed files to propagate to the client.
Next, the CACHE section references the contact page intended to be available to users regardless of connection status. The contact page references a style sheet, jQuery and a map image indicating the physical office location.
Finally, the NETWORK section is needed in this instance to ensure access to the events.htm page (shown in Figure 4). The reason this page isn’t included in the CACHE section is because in the real world the events page would be built dynamically as a server-generated page. Caching a page like this would defeat the purpose of making live event data available to the user when connected to the Web. With the events page listed in the NETWORK section rather than the CACHE section, the Application Cache API won’t attempt to cancel the request to the page. Ultimately, the page’s inclusion in the NETWORK section tells the browser to always attempt to fetch the page from the Web regardless of connection state.
Figure 4 Events Page (events.htm)
<table border="1" cellpadding="2" cellspacing="0">
  <tr>
    <td>Aug 15</td>
    <td><a href="/events/anaheim">Anahiem Convention Center</a></td>
  </tr>
  <tr>
    <td>Sept 5</td>
    <td><a href="/events/los-angeles">Los Angeles Convention Center</a></td>
  </tr>
  <tr>
    <td>Oct 3</td>
    <td><a href="/events/las-vegas">Las Vegas Convention Center</a></td>
  </tr>
  <tr>
    <td>Nov 14</td>
    <td><a href="/events/denver">Colorado Convention Center</a></td>
  </tr>
</table>
Note that the manifest is implemented as an ASPX file in order to disable browser caching of the file. You may prefer to disable caching on the Web server via configuration settings, but this approach is used here to make the sample code more portable for demonstration purposes.

The Contact Us Page

The contact page HTML, shown in Figure 5, is implemented as you might expect regardless of whether the page is being optimized for offline access. The most important detail to note in the HTML for the page is the contents of the paragraph with the ID of localMessage. This container holds the content that’s displayed when the user is working offline; that content is replaced on-the-fly when a connection to the Internet is available.
Figure 5 Contact Page (contact.htm)
<!DOCTYPE html>
<html manifest="manifest.aspx">
<head>
  <title></title>
  <link rel="Stylesheet" href="style.css" type="text/css" />
  <script src="jquery-1.6.3.min.js" type="text/javascript"></script>
  <script>
    $(function () {
      window.applicationCache.onupdateready = function (e) {
        applicationCache.swapCache();
        window.location.reload();
      }
      function isOnLine() {
        //return false;
        return navigator.onLine;
      }
      function showEventInfo() {
        if (isOnLine()) {
            $("#localMessage").hide();
            $.get("/events.htm", function (data) {
                $("#eventList").html(data);
                $("#eventList table tr:odd").addClass("alt");
            });
        }
        else {
          $("#localMessage").show();
        }
      }
      showEventInfo();
    });
  </script>
</head>
<body>
  <div id="container">
    <h1>Awesome Company</h1>
    <h2>Contact Us</h2>
    <p>
      Awesome Company<br />
      1800 Main Street<br />
      Anytown, CA 90210<br />
      (800) 555-5555<br />
      <a href="mailto:awesome@company.com">awesome@company.com</a>
    </p>
    <img src="map.png" />
    <div id="events">
      <h2>Events</h2>
      <p>We are coming to a city near you!</p>
      <p id="localMessage">Give us a call at (800) 555-5555
        to hear about our upcoming conference dates.</p>
      <div id="eventList"></div>
    </div>
    <div id="version">Version 1</div>
  </div>
</body>
</html>
Note that in the script section of the page, all functions are defined and run nested in the jQuery document-ready handler:
$(function () {
    ...
});
The first order of business is to process any updates to the page loaded in the application cache by handling the updateready events. If the application manifest changes, all the files listed in its CACHE section are copied to the client. When new versions of the files are available, the updateready event fires and the page can load the latest version of the contact page from the cache by calling applicationCache.swapCache. Finally, once the latest version is loaded into memory, the page is reloaded in order to display the changes to the user:
window.applicationCache.onupdateready = function (e) {
  applicationCache.swapCache();
  window.location.reload();
}
Next, the page needs a mechanism to detect whether the computer is working in a connected or disconnected state. The isOnLine function simply wraps up a call to the read-only navigator.onLine Boolean property. This encapsulation is handy because, should you want to override the value for testing purposes, you can un-comment the return false line and test the page’s offline behavior without having to actually disconnect from the Web:
function isOnLine() {
  //return false;
  return navigator.onLine;
}
By the way, using navigator.onLine as the sole mechanism for detecting online status is a bit rudimentary. For a more robust way to detect online status, please read the tutorial, “Working Off the Grid with HTML5 Offline,” by Paul Kinlan.
The showEvent function is responsible for implementing the “donut hole caching” functionality for the HTML offline application. The function first detects the connection status of the computer and then either fetches and renders live event data or just shows the event information that already exists in the page.
If the isOnLine function returns true, the local message is hidden from the user and an AJAX call to the events page is initiated. When a response from the asynchronous call is recognized, the resulting HTML is fed to the eventList container and the table is styled with zebra striping.
If, on the other hand, the computer is working offline, the local message is displayed to the user like so:
function showEventInfo() {
  if (isOnLine()) {
      $("#localMessage").hide();
      $.get("/events.htm", function (data) {
        $("#eventList").html(data);
        $("#eventList table tr:odd").addClass("alt");
      });
  }
  else {
    $("#localMessage").show();
  }
}
Finally, the manifest file is referenced at the top of the HTML page by populating the manifest attribute of the html element pointing to the manifest file:
<html manifest="manifest.aspx">
Figure 6 shows the style.css file that’s listed in the manifest and referenced by the contact page.
Figure 6 Style Sheet (style.css)
body
{
  font-family:Segoe UI, Arial, Helvetica, Sans-Serif;
  background-color:#eee;
}
h1
{
  text-transform:uppercase;
  letter-spacing:-2px;
  width:400px;
  margin-top:0px;
}
#container
{
  position:relative;
  margin-left:auto;
  margin-right:auto;
  padding:20px;
  width:700px;
  -webkit-box-shadow: 3px 3px 7px #999;
  box-shadow: 6px 6px 24px #999;
  -moz-border-radius: 10px; 
  -webkit-border-radius: 10px;
  border-radius: 10px;
  margin-top:20px;
  background-color:#fff;
}
#events
{
  position:absolute;
  width:210px;
  right:20px;
  top:255px;
  border:1px solid #ccc;
  padding:10px;
  font-size:.7em;
  background-color:#eee;
}
#events h2
{
  margin:0px;
}
#version
{
  font-size:.7em;
  color:#ccc;
}
table
{
  border-collapse:collapse;
}
table, tr, td
{
  border:1px solid #999;
}
.alt
{
  background-color:#ccc;
}

Wrapping Up

Even though pages loaded into the application cache are served from the cache whether the computer is connected to the Internet or not, you can construct your pages to take advantage of online resources when they’re available. “Donut hole caching” works by making an AJAX call to the server when a connection is available and then rendering the results to the user. If the page is in a disconnected state, the application quietly renders data already available on the page—it’s the best of both worlds!

 

Better Web Forms with HTML5 Forms

Brandon Satrom

Download the Code Sample
If you’re a Web developer, you’ve probably created an HTML Form before. In fact, you may have created more of them than you care to remember. You’re no doubt familiar with classic input types like text, password, file, hidden, checkbox, radio, submit and button, and you’ve probably used most or all of these at various times.
If I were to ask you what type of input—from the previous list—you use more than any other, you’d probably say “text,” as would most of us. The text input type is the multitool of classic HTML Forms development. On the one hand, it’s able to adapt to nearly any job you give it, but on the other, it’s semantically neutral, so the browser offers no help in turning this element into something practical. To compensate, developers and designers have added their own semantics to these elements (via IDs and class names) and have relied on server frameworks and JavaScript to handle validation and add rich interactions.
A classic example is collecting dates in text fields. Most of the time, you want to enhance a date field with a date picker of some kind. This is often done with hand-rolled JavaScript or a framework like jQuery UI, which adds an interaction behavior that allows the user to select a date from a widget and have that date populated into the original field.
As useful as that pattern is—and we’ve become quite adept as developers with patterns like this—it’s repeated so often that you can’t help but ask, “Why can’t the browser just do it?”
The good news is that, with HTML5 Forms, the browser can—and will. In addition to text and the handful of existing types we’ve had for years, HTML5 adds 13 new values for the input type attribute, as well as a host of other attributes that will speed up your forms development. This month, I’ll share some of the new input types and attributes coming with HTML5 Forms, as well as their implementation status in various browsers. Next, I’ll present a quick overview of new client validation features for HTML5 Forms. 
Finally, I’ll take a look at how recent updates to Visual Studio 2010 and the Microsoft .NET Framework 4 enable HTML5 Forms and ASP.NET Web Forms to play well together. Throughout, I’ll discuss how you can embrace HTML5 Forms in your applications today, while providing fallback solutions for older browsers. All of the demos for this article—which are available online—were built using WebMatrix, a free, lightweight Web development tool from Microsoft. You can try WebMatrix out for yourself at aka.ms/webm.

New Input Types in HTML5

What we know today as HTML5 Forms or HTML5 Web Forms started as Web Forms 2.0, a pre-HTML5 specification authored by a group known as the Web Hypertext Applications Technology Working Group, or WHATWG. Much of the initial work by WHATWG became the starting point for what we now call HTML5, and the Web Forms 2.0 effort is now part of the official HTML5 specification, which you can read at bit.ly/njrWvZ. A significant portion of the specification is dedicated to new types and content attributes for the input element, which you’ll find at bit.ly/pEdWFs.
As I mentioned, the specification introduces 13 new input types for use in forms: search, tel, url, email, datetime, date, month, week, time, datetime-local, number, range, color.
Using these new types is simple. Say I want to put a new e-mail field on an order form. As you can see in Figure 1, I’ve modified the WebMatrix Bakery Template Web site’s Order page with some additional fields, including e-mail.
A Sample Order Form
Figure 1 A Sample Order Form
For this form, the e-mail field is marked up like so:
<input type="email" id="orderEmail" />
Notice that the type attribute is equal to “email” instead of “text.” The best part about the new HTML input types is that you can use them today and they work, at some level, in every single browser. When a browser encounters one of these new types, one of two things will happen.
If the browser doesn’t support the new input types, the type declaration won’t be recognized. In this case, the browser will gracefully degrade and treat the element as type=“text.” You can try this by putting this element on a form and typing “document.getElementById(‘orderEmail’).type” in the Internet Explorer 9 F12 Tools Console. So, you can use these new types today, and if the browser doesn’t support a given field, it will continue to work just like a regular text field.
If the browser does recognize a type, however, you’ll gain some immediate benefits by using it. For recognized types, the browser adds some type-specific built-in behavior. In the case of the email type, Internet Explorer 10 Platform Preview 2 (PP2) and later will automatically validate any input, and present the user with an error message if the provided value isn’t a valid e-mail address, as shown in Figure 2.
Automatic Browser Validation of the Email Input Type
Figure 2 Automatic Browser Validation of the Email Input Type
It’s easy to infer the purpose and behavior of each element by its type, so we readily gain another level of semantic richness in our forms. Moreover, some of these new input types let the browser provide richer interactions to users out of the box. For example, if I place the following element on a form and then open that form in a browser that fully supports the date input type, the default interaction is much richer than a plain old text box:
<input type="date" id="deliveryDate" />
Figure 3 shows what the date type can provide in Opera 11.5. The best part is that all I had to do to get this interaction was specify type=“date” and the browser took care of all the manual work I previously had to do in JavaScript to offer this level of functionality.
The Date Input Type in Opera 11.5
Figure 3 The Date Input Type in Opera 11.5
It’s important to note that the HTML5 specification doesn’t dictate how browsers should present these new input types, or how they should present validation errors, so you can expect to see subtle to major differences among browsers. For example, Chrome 13 presents a spinner control for the date rather than a date picker, as shown in Figure 4 (which, of course, may have changed by the time you read this). You should also know that there’s ongoing discussion in the World Wide Web Consortium, or W3C, around browser styling and localization of elements like datetime, date and color. The browsers don’t all agree, at present, on how to implement these types, and there’s no current customization mechanism within 
existing implementations that’s similar to what you’d find with jQuery UI. Should you choose to implement or experiment with these new types, always be sure to provide a thorough fallback solution. In addition, if consistency of presentation and behavior is important to your users, you may need to apply custom styles, override default behaviors on these controls or use a script-based solution.
The Date Input Type in Chrome 13
Figure 4 The Date Input Type in Chrome 13
Earlier I stated that these fields will still behave as regular text fields, which is a nice piece of graceful degradation the browsers provide for us. But a date field implemented as a plain text box is clunky, and widely considered a poor user experience. With a little help from Modernizr and jQuery UI, however, you can provide a solution that mixes the best of HTML5 Forms with a nice fallback solution.
You’ll recall from my last article (msdn.microsoft.com/magazine/hh394148) that Modernizr (modernizr.com) is a JavaScript library that can help you detect support for HTML5 features in the browser. For this example, I want to use Modernizr to help detect support for the HTML5 date input type and, if it’s not supported, use the jQuery UI (jqueryui.com) datepicker widget to provide a similar user experience. Once I’ve downloaded and added references for Modernizr, jQuery and jQuery UI, I can add fallback support for my date elements with just a few lines of code:
if (!Modernizr.inputtypes.date) {
  $("input[type=date]").datepicker();
}
The result, as seen in Internet Explorer 10 PP2, is depicted in Figure 5.
Date Field Support with jQuery UI
Figure 5 Date Field Support with jQuery UI

New Input Content Attributes in HTML5

In addition to the new input types, HTML5 provides some handy new content attributes that can be used on input fields to supply validation support and enhanced functionality. One of those new attributes is “placeholder,” which, according to the specification, “…represents a short hint (a word or short phrase) intended to aid the user with data entry” (emphasis theirs). For example, I can take a couple of the fields from our order form and add placeholder=“some text” to each field, with the result shown in Figure 6:
<input type="email" id="orderEmail" placeholder="ex. name@domain.com" />
<input type="url" id="orderWebsite" placeholder="ex. http://www.domain.com" />
Using the Placeholder Attribute with Input Fields
Figure 6 Using the Placeholder Attribute with Input Fields
The placeholder text is lighter in color than normal text, and if I place focus on each field, the text disappears, enabling me to 
enter my own value.
As with the new input types, the placeholder attribute isn’t supported in older browsers. Nothing bad will happen if a user visits a page with them, though, so consider using them today, even if you don’t plan to add support for older browsers. If you do want to “polyfill” placeholder support, Modernizr can help. As I mentioned in my last article, the good folks at Modernizr try to keep a running list of every polyfill and fallback you could possibly want for a given HTML5 feature. You can check that list out at bit.ly/nZW85d.
For this example, let’s use the jQuery HTML5 Placeholder created by Mike Taylor, which you can download from bit.ly/pp9V4s. Once you have it, add the following to a script block referenced by your page:
Modernizr.load({
    test: Modernizr.input.placeholder,
    nope: "../js/html5placeholder.jquery.min.js",
    callback: function() {
      $('input[placeholder]').placeholder();
    }
  });
Here, Modernizr tests whether the placeholder attribute is supported and if it’s not, loads html5placeholder.jquery.min.js. jQuery then selects every element with a placeholder attribute and adds plug-in support to each. If you try this out in Internet Explorer 9, you’ll notice that the end result looks very similar to the native browser support provided in Internet Explorer 10 PP2.
Another interesting new attribute is “autofocus,” which, as it sounds, lets you specify a single form field to automatically receive focus when a page loads. Only one field per page should hold this attribute; if multiple elements are marked up with autofocus, the first one with that declaration receives focus on page load. For my order form, I want the Name field to receive focus, so I add the attribute like so:
<input type="text" class="field" id="orderName" autofocus />
The autofocus attribute can be used on any form control, and is an excellent alternative to the script-based, form-focused strategies many Web developers have fought with in the past.

HTML5 Form Validation

I don’t have the space to cover all the interesting new form-related attributes here, but I’ll spend a few moments talking about “required,” “pattern,” “novalidate” and “formnovalidate,” all of which make client-side form validation a snap.
For browsers that support it, the “required” attribute tells the browser that this form can’t be submitted without a value. For example, I add “required” to the Name field of my order form:
<input type="text" class="field" id="orderName" required />
When I visit this page in the Internet Explorer 10 PP2 and attempt to submit the form, I see something like what’s shown in Figure 7. With a single attribute, the browser knows enough to style the element with a red border and display a message to the user indicating that the field is required.
Using the Required Attribute on a Form Field
Figure 7 Using the Required Attribute on a Form Field
Earlier, Figure 2 showed how the browser can automatically validate certain types, such as “email” and “url,” without additional input from the user. With the “pattern” attribute, you can provide your own validation test for input types. According to the HTML5 specification, “pattern” expects a regular expression, which the browser uses to validate the owning field.
My order form contains a telephone (type=“tel”) field and I can specify a validation pattern like this:
<input type="tel" id="orderTelephone" pattern="\(\d\d\d\) \d\d\d\-\d\d\d\d" title="(xxx) xxx-xxxx" />
This (not very complex) regular expression tells the browser to expect a seven-digit number with parentheses around the area code and a dash in the local number. Entering anything else results in the message shown in Figure 8. Notice that the message contains instructions to the user on how to format input: “(xxx) xxx-xxxx.” This part of the message is taken from the title attribute of the same element, so it’s possible to control at least part of the validation message via your markup. There’s one thing to note when using title to aid in validation, though. According to the spec, the browser may choose to show the title in other, non-error cases, so don’t count on this attribute as a place for error-sounding text.
Using the Pattern Attribute to Specify a Validation Expression
Figure 8 Using the Pattern Attribute to Specify a Validation Expression
Automating validation by the browser is nice, but two immediate questions come to mind. First, what about server validation or client validation scripts generated by my server framework (ASP.NET MVC, for example)? And second, what about cases where I want the user to be able to save the form as a work in progress, without validation? The first is, unfortunately, outside the scope of this article, but I’ve written a blog post about this very subject in ASP.NET MVC, which you can find at bit.ly/HTML5FormsAndMVC.
The second question, on the other hand, is easy. Let’s assume you have a form that users will spend quite a bit of time on before submitting, perhaps even saving multiple times before finally posting it to your server. For such cases, where you’ll want to allow a user to submit a form without validation, there are two attributes you can use: “formnovalidate,” which is placed on input fields of type “submit,” and “novalidate,” which is placed on an opening form tag. Here I’ll place two submit fields on my form, like so:
<input type="submit" value="Place Order" />
<input type="submit" formnovalidate value="Save for Later" id="saveForLater" />
The “formnovalidate” attribute on the second button will turn off validation and submit the form, allowing the user’s work in progress to be saved in my database, or even on the client side using a new HTML5 storage technology like localStorage or IndexedDB.

HTML5 Forms and ASP.NET Web Forms

Before I wrap up this article, I want to share a few additional bits of information related to HTML5 Forms for ASP.NET Web Forms developers. If you’re planning to do HTML5 Forms development with ASP.NET Web Forms, there’s good news: Many HTML5-related updates to .NET and Visual Studio are being released out-of-band, so you don’t have to wait for the next framework version to use these features today.
To get started with HTML5 Forms and ASP.NET Web Forms, you’ll need to grab a couple of updates. First, make sure you have Visual Studio 2010 SP1 (bit.ly/nQzsld). In addition to adding support for new HTML5 input types and attributes, the service pack also provides some updates that enable you to use the new HTML5 input types on the TextBox server control. Without this update, you’d see compile-time errors when using the new types.
You’ll also want to grab the Microsoft .NET Framework 4 Reliability Update 1 (bit.ly/qOG7Ni). This update is designed to fix a handful of problems related to using the new HTML5 input types with ASP.NET Web Forms. Scott Hunter covers a few of those—UpdatePanel, Validation Controls and Callbacks—in a blog post from early August that you can check out at bit.ly/qE7jLz.
The addition of Web Forms support to browsers with HTML5 is good news for Web developers everywhere. Not only do we have a set of semantic input types to leverage in our applications, but we can also use these input types today with no ill effects in older browsers, while getting enhanced functionality—including automatic client validation—in newer ones. Using these new fields right away has immediate benefits in the mobile application space as well, where using types like “url” and “email” will prompt mobile devices to present the user with soft keyboard options tuned for that input type. When you combine these new features with Modernizr and one of the great polyfilling options, you have all the tools you need to adopt HTML5 Forms in your applications right now.
For more information on HTML5 Forms support in Internet Explorer 10 PP2, go to ietestdrive.com, and be sure to check out the developer’s guide at the Internet Explorer Developer Center (bit.ly/r5xKhN). For a deeper dive into HTML5 Forms in general, I recommend “A Form of Madness,” from Mark Pilgrim’s book “HTML5: Up and Running” (O’Reilly Media, 2010), as well as the Forms section of the W3C HTML5 specification (bit.ly/nIKxfE).    

 

Deploying LightSwitch Applications to Windows Azure

Mike Wade

The new Microsoft Visual Studio LightSwitch aims to simplify the creation of classic line-of-business (LOB) forms-over-data applications. LightSwitch reduces the overhead of building these applications by performing much of the heavy lifting of creating connections to databases (the data-storage tier), displaying a professional UI (the presentation tier) and implementing business logic code (the logic tier).
To further simplify your life, you can host such applications on Windows Azure, an Internet-scale cloud services platform hosted on Microsoft datacenters. The platform includes Windows Azure, a cloud services OS, and SQL Azure, a database service hosted in the cloud. Hosting a LightSwitch application on the Windows Azure platform eliminates the need to dedicate resources to infrastructure management, such as Web servers and data servers: Windows Azure can take care of all of that for you.
In this article I’ll take a look at how to deploy a LightSwitch application to Windows Azure using the Vision Clinic sample application, which is available for download at bit.ly/LightSwitchSamples. Vision Clinic is a simple LOB application designed for an optometrist’s office. The application can be used to manage patients and appointments, as well as products the clinic’s patients may require. It uses two databases: the intrinsic application database, which manages patients and their appointments, and an attached database called PrescriptionContoso that manages products available for sale at the clinic. The original walk-through shows how to deploy the application as a two-tier desktop application: the application runs completely on the client user’s machine, but the data for the application is hosted elsewhere. After completing the steps in this article you’ll be able to publish your application on Windows Azure.

Attaching to a SQL Azure Data Source

The walk-through makes use of a sample external database—the PrescriptionContoso database, which you can download from MSDN and install to your local development machine. Because the PrescriptionContoso database is an attached data source, you’ll have to create and populate the database yourself. When the finished application is deployed to Windows Azure, it will use both an attached data source and the intrinsic data source hosted in the cloud. Let’s get the hard part out of the way first: creating that attached data source in SQL Azure.
Start by logging in to your Windows Azure account at windows.azure.com. If you don’t already have an account, you can sign up for one at the same site. Once you’ve signed in to the Windows Azure Platform Management Portal, select the Database node in the navigation pane on the left and view the database information for your subscription in the central items list. (See bit.ly/pcwCLX for a description of the layout of the portal.) If your account doesn’t yet have a database subscription, select your subscription in the navigation panel, and choose Create from the ribbon across the top (see Figure 1). This will launch a server-creation wizard, allowing you to choose your SQL Server hosting region and your administrator login name and password, and to create firewall rules (see Figure 2). You’ll need to add at least two firewall rules for your server:
  1. Select the checkbox to allow other Windows Azure services to access this server. This enables the Vision Clinic application, which will eventually be hosted on Windows Azure, to access this database.
  2. Add a range of IP addresses that will also be able to access the server. These are IP addresses of computers that can manage the database through the Windows Azure Platform Management Portal. For example, the IP address of my PC is 131.107.xxx.yyy, so I added a range of addresses starting at 131.107.0.0 and ending at 131.107.0.255. Don’t forget: You’ll still need your Windows Azure subscription login information to manage the database through the portal, but setting this firewall rule allows Visual Studio to access to the database during development. Once you’ve created and deployed the application, you can remove this firewall rule to prevent any external machines from accessing the database.
Windows Azure Platform Management Portal: Creating a Database Server
Figure 1 Windows Azure Platform Management Portal: Creating a Database Server
Using the Wizard to Create a Database Server
Figure 2 Using the Wizard to Create a Database Server
With the database server created, you can now view its properties. Select the database server in the navigation pane (mine was called “pq96r63lrm”). The items list includes all of the firewall rules you created, as well as a default “master” database.
You’ll want to create a new database for the PrescriptionContoso information. Make sure your database server has been selected in the navigation pane, and then click the Create button from the ribbon in the Windows Azure Platform Management Portal. For your database name, type “PrescriptionContoso” and leave the default settings for Edition and Maximum size (see Figure 3).
Creating the PrescriptionContoso Database
Figure 3 Creating the PrescriptionContoso Database
Now it’s time to add the tables to the PrescriptionContoso database. Select the new database in the left-hand navigation panel and click the Manage button. This will open a new Web page that allows you to manage the PrescriptionContoso database. On the new page, select New Table. This will open a table editor page (see Figure 4). Name the table “Product” and enter the information shown in Figure 5 for the schema.
Adding the Product Table to the PrescriptionContoso Database
Figure 4 Adding the Product Table to the PrescriptionContoso Database
Figure 5 Schema for the Product Table
ColumnTypeDefault ValueIs Identity?Is Required?In Primary Key?
ProductIDInt YesYesYes
ProductNamenvarchar (50)  Yes 
MSRPMoney  Yes 
Descriptionnvarchar(max)    
ProductImagevarbinary(max)    
Categorynvarchar(max)    
Create another new table, name this one “ProductRebate,” and enter the information in Figure 6 for the schema. As with all attached data sources, the connection string LightSwitch uses to interact with the PrescriptionContoso database will be stored in the web.config file generated as project output. Three-tier applications store the web.config file on the IIS server where it can’t be seen by application users.
Figure 6 Schema for the ProductRebate Table
ColumnTypeDefault ValueIs Identity?Is Required?In Primary Key?
ProductRebateIDInt YesYesYes
ProductIDInt  Yes 
RebateStartSmalldatetime    
RebateEndSmalldatetime    
RebateMoney    
However, with two-tier applications, all users who install the application can see the web.config file. Thus, it’s important to create a non-admin login and user for the PrescriptionContoso database for use at run time. This user will not be a full database server administrator and will be able to perform only Create, Read, Update, Delete (CRUD) operations on the PrescriptionContoso database. You create a new login for the database by opening a connection to your master database and executing the following commands in SQL Server Management Studio Express or using sqlcmd (see bit.ly/ok2Mdh for more information):
CREATE LOGIN <user> WITH password='<password>';
Be sure to substitute a new <user> and <password>. The password you provide must be strong (see bit.ly/p4BEwU).
Now connect to the PrescriptionContoso database with your SQL Azure administrator account and create a user:
CREATE USER <user> FROM LOGIN <user>;
The database schema has been created, but the table contains no data. You can add data to the table using the data designer on the Windows Azure Platform Management Portal or by migrating the data from the PrescriptionContoso.mdf file included in the sample to the Windows Azure database. You can also use the bcp utility that comes with Microsoft SQL Server 2008 and Microsoft SQL Server 2008 Express (bit.ly/bhH7Ub). Yet another option is to add the data through a running application. It’s possible to have a two-tier application attach to a data source hosted on SQL Azure, so let’s populate the database by publishing and running the Vision Clinic example as a two-tier application.
With the schema in place on Windows Azure for the attached data source, it’s time to publish the application. You should be able to follow the deployment steps in the Vision Clinic walk-through (bit.ly/py9yna) until step 8. On the Other Connection Information page, enter the connection string to the database that was just created. You’ll find the connection string in the Windows Azure Platform Management Portal by selecting the database in the navigation pane and hitting the Connection Strings button in the properties pane. Copy the ADO.Net connection string (see Figure 7) and paste it into the PrescriptionContoso textbox in the LightSwitch publish wizard. Open the Connection Properties dialog and make sure you type the user name and password for the new user you created. Use the Test Connection button to make sure you’re able to connect to the SQL Azure database.
Getting the Connection String for the PrescriptionContoso Database
Figure 7 Getting the Connection String for the PrescriptionContoso Database
After you enter the connection string for the attached data source, you can finish the publish wizard and wait for your application to be published. Once it’s published, you can view the generated web.config file among the publish output and see that the connection string to your Windows Azure database is now in place. Because the application is still two-tiered, end users will need the Microsoft .NET Framework 4 installed on their computers, but the application can now read and write data to the PrescriptionContoso database on SQL Azure.

Hosting the Application on Windows Azure

Next, let’s take a look at hosting the application completely on Windows Azure. Because Windows Azure is running IIS, it’s possible to have the same types of applications on Windows Azure as on an IIS server residing in your enterprise. Application users will only need to have Microsoft Silverlight 4 or higher to run the application, rather than the full .NET Framework 4, greatly simplifying client deployments. You’ll modify the Vision Clinic sample to publish the application to Windows Azure. The service tier will still require the .NET Framework 4, but Windows Azure will automatically provision that for you.
Before you can publish Vision Clinic to Windows Azure, there’s some additional preparation that needs to be done to your subscription. You’ll need to pre-create a hosted service in the Windows Azure Platform Management Portal. This service is what will run the server-side code of the deployed application. You’ll also need to create a storage account, which will be used to store the application binaries while the application is deploying. The application data will be stored in a SQL Azure database.
Navigate back to the portal and select the Home button in the navigation pane (see Figure 8). In the ribbon, you should see a button marked New Hosted Service. Clicking this button shows a new window in which to create your Hosted Service. Enter a service name, URL prefix and region for your application. For Deployment Options, choose “Do not deploy”; the LightSwitch publish wizard will be deploying the application. The Storage Account is created in a similar fashion: Click the New Storage Account button on the ribbon and fill out the fields in the pop-up that comes up. You should now be able to navigate to the Hosted Services and Storage in the Windows Azure Platform Management Portal. The rest of the Windows Azure configuration can be done through the LightSwitch publish wizard.
Creating a Hosted Service in the Windows Azure Platform Management Portal
Figure 8 Creating a Hosted Service in the Windows Azure Platform Management Portal
Let’s make some updates to the Vision Clinic sample in the LightSwitch IDE. Because the application is being hosted in the cloud, it’s a good idea to secure your LightSwitch application using Forms authentication. (For more information, see the article, “Securing Access to LightSwitch Applications,” in this issue.) This is configured in the application properties access control tab of the VisionClinic application (see Figure 9). Now navigate to the Application Type tab. The application will remain a desktop application, because you want the application to be able to interact with other applications installed on an end user’s computer (for example, exporting data to Microsoft Excel). For the Application Server Configuration, select Windows Azure (see Figure 10). Click on the Publish… button in the designer to begin the publishing process.
Using Forms Authentication
Figure 9 Using Forms Authentication
Choosing to Host Application Services on Windows Azure
Figure 10 Choosing to Host Application Services on Windows Azure
Hit Next twice in the wizard to get to the Connect to Windows Azure page. This page requires two pieces of information (see Figure 11):
  1. The ID of your account subscription
  2. A management certificate thumbprint
Connecting to Windows Azure in the LightSwitch Publish Wizard
Figure 11 Connecting to Windows Azure in the LightSwitch Publish Wizard
The subscription ID is obtained from the Properties pane of the hosted service in the Windows Azure Platform Management Portal. If this is the first time you’re publishing to Windows Azure, you’ll also have to create a new certificate that will be used to confirm your identity to the Windows Azure service during the publish process because there’s no login during the publish process. In the drop-down, select the option to <Create new self-signed certificate…>. Doing this adds a new certificate to your computer’s certificate store. Now you need to upload certificate information to your Windows Azure account. Choose Copy Path in the publish wizard and then go back to the portal and select the Management Certificates 
node in the navigation pane. Select Add Certificate from the ribbon and then choose the Browse… button from the ensuing dialog (see Figure 12). Paste in the path that you copied from the publish wizard—and your certificate should now be added.
Adding a Management Certificate to Windows Azure
Figure 12 Adding a Management Certificate to Windows Azure
The Azure Service Configuration page (see Figure 13) in the wizard allows you to specify the names of the hosted service and storage accounts that were created through the Windows Azure Platform Management Portal. These drop-downs should be automatically populated by the wizard once a valid subscription ID and management certificate have been entered on the previous page. You also can choose which Environment the application will be deployed to: Production or Staging. For this example, select Production.
Setting Windows Azure Service and Storage Information While Publishing
Figure 13 Setting Windows Azure Service and Storage Information While Publishing
Next, you’ll need to specify the Security Settings for the application: a certificate that will be used to establish an SSL connection for the deployed application. Communicating with Windows Azure over HTTPS protects business data exchanged between client and server, as well as the user name and password when using Forms authentication information. The wizard allows you to select from existing certificates that have already been uploaded to Windows Azure, or to upload a new certificate, as shown in Figure 14. The drop-down lets you create a new self-signed certificate that can be uploaded to Windows Azure. The Silverlight out-of-browser launcher tool that LightSwitch desktop applications use requires a trusted certificate on the server when run over HTTPS. If the certificate isn’t trusted, the application won’t run correctly. The best approach is to use a certificate signed by a trusted Certificate Authority. A less-secure alternative is to pre-install the new self-signed certificate in the client’s certificate store (see bit.ly/ra3CKG for more information). A LightSwitch client that runs in the browser can work with a self-signed certificate, but the browser will show a warning before loading the Silverlight application.
Setting the Certificate to Use for an HTTPS Connection
Figure 14 Setting the Certificate to Use for an HTTPS Connection
The next piece of information to enter into the publish wizard is the database connection settings for the intrinsic data source. This time, LightSwitch will automatically create the database and publish the schema to SQL Azure. You can start by getting the connection string of the master database that’s created automatically for you on SQL Azure. Paste this value into the administrator connection string in the publish wizard. Bring up the connection properties in the publish wizard by clicking on the builder button and enter a new database name to replace “master” (for example, “VisionClinic”)—see Figure 15. Update the user password (the connection string that was copied contains only a dummy password). Also consider setting the Encrypt connection property to True and the TrustServerCertificate connection property to False in the Advanced Properties for the connection string. This ensures the connection is encrypted and man-in-the-middle attacks aren’t possible. You don’t want the application to use the administrative connection string for its CRUD operations, so create a new login for the database server by clicking the Create Database Login button on the publish wizard.
Setting the Connection String for the Application Data
Figure 15 Setting the Connection String for the Application Data
Next, you should enter a user name and password for the application’s initial security administrator. A security administrator provides access to the security administration screens in the running LightSwitch client application. These screens allow the security administrators to provide initial access to other users to run the application.
You can continue to use the PrescriptionContoso connection string that was previously added on the Other Connections wizard page. On the Specify a Certificate wizard page, you can choose to sign the client application (see Figure 16). Signing the application allows the Silverlight out-of-browser launcher to automatically update the application on a user’s machine when you publish a newer version of the application to Windows Azure (bit.ly/iY6lFP).
Specifying a Certificate to Sign the Client Application
Figure 16 Specifying a Certificate to Sign the Client Application
When the wizard is done, the application is packaged up and sent off to Windows Azure for installation. When publishing is complete, LightSwitch will launch the Windows Azure Platform Management Portal. LightSwitch tells Windows Azure to start the hosted service, but it may take a few minutes for the process to complete. You can track the progress of the deployment in the Hosted Service tab of the navigation pane on the portal.
When the deployment has been completed, select Hosted Services in the navigation pane of the portal, and then open child nodes in the items list to reach the completed “Vision_Clinic” deployment (see Figure 17). The Properties window should contain a DNS name for your deployed application; clicking on this link will open the Web page to your application, after first automatically redirecting the application to use HTTPS. This is the URL clients should use to run the application. It’s possible—but highly discouraged—to turn HTTPS redirection off by setting the Microsoft.LightSwitch.RequireEncryption property to “false” in the service configuration file (described in the following section).
Viewing the Published Application in the Windows Azure Platform Management Portal
Figure 17 Viewing the Published Application in the Windows Azure Platform Management Portal

Publish Output

Let’s take a look behind the scenes. There are three output files unique to publishing to Windows Azure. They are:
  • Vision Clinic.cspkg
  • ServiceDefinition.csdef
  • ServiceConfiguration.cscfg
In the build output directory, you’ll see a .cspkg file. This file is a bundle of all of the files relevant for the Windows Azure application: the application binaries as well as the service definition and configuration files. During the publish process this file is transferred to Windows Azure to configure the hosted service.
ServiceDefinition.csdef (see Figure 18) is the Cloud Services definition file for the application. This XML file dictates how the Web site for your application can be configured. The file declares that the one WebRole, LightSwitchWebRole (under the WebRole node), should enable both HTTP and HTTPS (the Sites and EndPoints nodes). It specifies that HTTPS will require a certificate stored on the Windows Azure machine (Certificates node), and declares customizable configuration settings specific to this application (ConfigurationSettings node). These settings include diagnostics logging information as well as whether to redirect HTTP calls to HTTPS.
Figure 18 The ServiceDefinition.csdef File
<ServiceDefinition name="Vision_Clinic"
  xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="LightSwitchWebRole"
           vmsize="Small"
           enableNativeCodeExecution="true">
    <ConfigurationSettings>
      <Setting name="Microsoft.LightSwitch.Trace.Enabled" />
      <Setting name="Microsoft.LightSwitch.Trace.LocalOnly" />
      <Setting name="Microsoft.LightSwitch.Trace.Level" />
      <Setting name="Microsoft.LightSwitch.Trace.Sensitive" />
      <Setting name="Microsoft.LightSwitch.Trace.Categories" />
      <Setting name="Microsoft.LightSwitch.RequireEncryption" />
    </ConfigurationSettings>
    <Sites>
      <Site name="Web">
        <Bindings>
          <Binding name="HttpIn" endpointName="HttpIn" />
          <Binding name="HttpsIn" endpointName="HttpsIn" />
        </Bindings>
      </Site>
    </Sites>  
    <Endpoints>
      <InputEndpoint name="HttpIn" protocol="http" port="80" />
      <InputEndpoint name="HttpsIn" protocol="https" port="443"
        certificate="SSLCertificate" />
    </Endpoints>
    <Certificates>
      <Certificate name="SSLCertificate" storeLocation="LocalMachine"
        storeName="My" />
    </Certificates>
  </WebRole>
</ServiceDefinition>
Figure 19 shows the Cloud Services configuration file (ServiceConfiguration.cscfg) contains the actual configuration settings for the Web Role. If you look at the ServiceConfiguration.cscfg file in the build output directory, you’ll see a setting that contains the SSL certificate thumbprint that was specified in the “Security Settings” page of the publish wizard.
Figure 19 The ServiceConfiguration.cscfg File
<ServiceConfiguration serviceName="Vision_Clinic"
  xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">
  <Role name="LightSwitchWebRole">
    <Instances count="1" />
    <ConfigurationSettings>
      <!-- A value of true will enable diagnostic logging on the server -->
      <Setting name="Microsoft.LightSwitch.Trace.Enabled" value="false" />
      <!-- A value of true only lets local access to Trace.axd -->
      <Setting name="Microsoft.LightSwitch.Trace.LocalOnly" value="true" />
      <!-- The valid values for the trace level are: None, Error,
        Warning, Information, Verbose -->
      <Setting name="Microsoft.LightSwitch.Trace.Level"
        value="Information" />
      <!-- A value of true will indicate that logging sensitive
        information is okay -->
      <Setting name="Microsoft.LightSwitch.Trace.Sensitive" value="false" />
      <!-- The semi-colon separated list of categories that will be
        enabled at the specifed trace level -->
      <Setting name="Microsoft.LightSwitch.Trace.Categories"
        value="Microsoft.LightSwitch" />
      <!-- A value of true will indicate http requests should be
        re-directed to https -->
      <Setting name="Microsoft.LightSwitch.RequireEncryption"
        value="true" />
    </ConfigurationSettings>
    <Certificates>
      <Certificate name="SSLCertificate"
        thumbprint="CD27FF4C85A2AD495A054D606E354BCAAD01B3D8"
        thumbprintAlgorithm="sha1" />
    </Certificates>
  </Role>
</ServiceConfiguration>
There are two ways to change the additional configuration settings for the Web Role. One option is to edit the ServiceConfiguration.cscfg file contained in the LightSwitch project directory. For example, to enable diagnostic logging on the server, you’ll need to modify the Microsoft.LightSwitch.Trace.Enabled property, like this:
<Setting name="Microsoft.LightSwitch.Trace.Enabled" value="true" />
The values set in the project’s cloud service configuration file in the project will end up in the built cloud service configuration file.
It’s also possible to change the values in ServiceConfiguration.cscfg post-deployment. In the Windows Azure Platform Management Portal, click Hosted Services, Storage Accounts & CDN, then click Hosted Services in the lower part of the navigation pane. Drill down to the Vision_Clinic deployment item in the items list. Once there, you should see the Configure button on the ribbon. Clicking this button allows you to either upload a new service configuration file or edit the existing file.

Using Additional Windows Azure Features

Although there’s no built-in support for many additional Windows Azure features, with some simple modifications to your project’s Service Definition.csdef and ServiceConfiguration.cscfg files, it’s possible to take advantage of additional Windows Azure features. Here are a couple of examples.
Virtual Machine (VM) Size Windows Azure provides several sizes of compute instances, which dictate the amount of resources dedicated to each service instance: the greater the VM size, the more expensive the application is to run. LightSwitch applications default to a Small compute size, but you can change the level by updating the “vmsize” attribute of the default WebRole in the ServiceDefinition.csdef file:
<WebRole name="LightSwitchWebRole"
         vmsize="ExtraSmall"
         enableNativeCodeExecution="true">
ExtraSmall (which is currently available in beta release) is the least resource-intensive service available on Windows Azure. A summary of all VM sizes is available at bit.ly/qdTFZp.
Microsoft Windows AzureConnect Windows Azure Connect (bit.ly/nvTg6Z) allows for IP-based network connections between Windows Azure and on-premises resources. Windows Azure Connect, currently in CTP, provides a way for an application deployed to Windows Azure to connect to an on-premises SQL Server database or SharePoint site. You could also have a Windows Azure VM join your local domain, enabling your application to use Windows Authentication. It’s possible to configure your LightSwitch application to take advantage of the Windows Azure Connect features. While performing this configuration is beyond the scope of this article, keep an eye on the “Deployment” page of the LightSwitch Developer Center (bit.ly/pxmV5d).

 

Working with Media in HTML5

Jason Beres

 

Unless you have been living on a remote island for the past year or so, you have probably heard the buzz and hype around HTML5. No, HTML5 will not cure most illnesses, nor will it end world hunger, but it is poised to reshape the rich Internet application landscape. With all the hype over the new HTML standard, it's important to bring the discussion back down to earth. Here are the important facts you need to know about this new HTML specification:
  • HTML5 is the first new version of the specification since 1999—the Web has changed a lot since then.
  • HTML5 will be the new standard for HTML, XHTML and the HTML DOM.
  • HTML5 provides a standard way of playing media—a key benefit  because there was no standard for playing media in a Web page without a browser plug-in, and no guarantee that every browser would support the plug-in.
  • HTML5 is still a work in progress, but most modern browsers have some HTML5 tag support.
When Silverlight 1.0 shipped in 2007, Microsoft touted its video and audio playback as primary features, and a prime reason to see Silverlight as an alternative to Flash—which is supported in one version or another on 95 percent of browsers worldwide. As of this writing, Silverlight is supported on around 75 percent of browsers worldwide, or about three of every four computers. But if you’re looking to play media and you don’t want to the hassle or the dependency of a plug-in, HTML5 is the answer.
To see the difference between using the HTML5 video tag and the traditional object tag to play media, consider the example in Figure 1.
Figure 1  The HTML Video Tag vs. the Object Tag to Play Media
<section>
    <h1>Using the HTML5 Video tag to play video</h1>
    <video src="video1.mp4" >
    </video>
</section>
<section>
    <h1>Using the Object tag to play media using the Flash plug-in</h1> 
    <object type="application/x-shockwave-flash"
               data="player.swf" width="290" height="24">
        <param name="movie" value="player.swf">
    </object>
</section>
So what’s the big deal? Both examples are simple and easy to implement. But the important point here is that because the <video> tag is a standard, there will be no question that it should be used to play media. You don’t have to guess if a browser has a certain version of a particular plug-in installed to play your media. The standard part is what’s been missing from HTML.

Supported Media Formats in HTML5

To use media in your next HTML5 application, you need to know what formats are supported. HTML5 supports AAC, MP3 and Ogg Vorbis for audio and Ogg Theora, WebM and MPEG-4 for video.
Even though HTML5 supports these media formats, however, not every browser supports every format. Figure 2 shows current browsers and the media formats they support.
Figure 2 Media Support in Current Browsers
BrowserVideo FormatsAudio Formats
Ogg TheoraH.264VP8 (WebM)Ogg VorbisMP3Wav
Internet ExplorerManual install9.0Manual installNoYesNo
Mozilla Firefox3.5No4.0YesNoYes
Google Chrome3.0No6.0YesYesYes
SafariManual install3Manual installNoYesYes
Opera10.50No10.60YesNoYes

Using the Video Tag

To play a video in an HTML5 page, just use the <video> tag, as shown here:
<video src="video.mp4" controls />
The src attribute (http://www.w3.org/TR/html5/video.html#the-source-element) sets the name or names of the video to play, and the control’s Boolean switch dictates whether the default playback controls displays. You can also use two other Boolean properties—autoplay and loop—when setting up the video tag. Figure 3 lists each property attribute and its value.
Figure 3 Video Tag Properties
AttributeValueDescription
 AudioMutedDefines the default state of the audio. Currently, only muted is allowed.
 AutoplayAutoplayIf present, the video starts playing as soon as it’s ready.
 ControlsControlsAdds Play, Pause and Volume controls.
 HeightPixelsSets the height of the video player.
 LoopLoopIf present, the video will start over again every time it finishes.
 PosterurlSpecifies the URL of an image representing the video.
 PreloadPreloadIf present, the video is loaded at page load and is ready to run. It is ignored if Autoplay is present.
 SrcurlThe URL of the video to play.
 WidthPixelsSets the width of the video player.
The following code shows a few of the key properties on the video player in a common scenario that includes setting the height and width, autoplay, loop and controls properties, which will display the play, pause and volume controls as well as a fallback error message.
<video src="video.mp4" width="320" height="240" autoplay controls loop>
    Your browser does not support the video tag.
</video>
You can also set the specific MIME typeusing the type attribute and codec in the source element. These examples use the type attribute to set the MIME type and the encoding of the media:
<!-- H.264 Constrained baseline profile video (main and extended video compatible)
  level 3 and Low-Complexity AAC audio in MP4 container -->
<source src='video.mp4' type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>
<!-- H.264 Extended profile video (baseline-compatible) level 3 and Low-Complexity
  AAC audio in MP4 container -->
<source src='video.mp4' type='video/mp4; codecs="avc1.58A01E, mp4a.40.2"'>
You can set properties in either HTML or JavaScript. The following code shows how to set the Boolean controls property in HTML and JavaScript.
<!-- 3 ways to show the controls -->
<video controls>
<video controls="">
<video controls="controls">
// 2 ways to show controls in JavaScript
video.controls = true;
video.setAttribute
       ('controls',
        'controls');
When you don’t know whether a browser will render the page, you need a fallback mechanism to play your media. All you do is list the video formats you have rendered your video in, and the browser plays the first one it supports. You can also add text as a last resort to let the user know that the browser being used doesn’t support native HTML5 playback of video. The following code includes multiple video sources as well as a fallback message indicating no HTML5 support.
<video controls>
    <source src="video1.mp4" />
    <source src="video1.ogv" />
    <source src="video1.webm" />
    <p>This browser does not support HTML5 video</p>
</video>
If you want to make sure your video plays, you can include the object tag to play a Flash version as well, like so:
<video controls>
    <source src="video1.mp4" />
    <source src="video1.ogv" />
    <source src="video1.webm" />
    <object data="videoplayer.swf">
        <param name="flashvars" value="video1.mp4">
        HTML5 Video and Flash are not supported
    </object>
</video>
You can also use JavaScript to check if a video format is supported by checking the canPlayType property, as follows:
var video = document.getElementsByTagName('video')[0];
if (video.canPlayType)
   { // video tag supported
if (video.canPlayType('video/ogg; codecs="theora, vorbis"'))
      { // it may be able to play}
        else
      {// the codecs or container are not supported
        fallback(video);
  }
}
If you want to do something more expressive than the simple fallback text, you can use the onerror event listener to pass the error to:
<video src="video.mp4"
       onerror="fallback(this)">
       video not supported
</video>
Using the poster property, you can specify the URL of an image to show in place of the video on the form. Usually you’re showing either a list of videos or a single video on a form, so having an easy way to show a preview of the video in the form of an image delivers a better user experience. Here is the poster property in action:
<video src="video1.mp4" poster="preview.jpg" </video>
Finally, by using a bit of JavaScript and basic HTML, you can create a more interactive video player. Figure 4 shows how to add a video player to a form with JavaScript and how to respond to user input to the control.
Figure 4  Interacting with Video in JavaScript
var video = document.createElement('video');
video.src = 'video1.mp4';
video.controls = true;
document.body.appendChild(video);
var video = new Video();
video.src = 'video1.mp4';
var video = new Video('video1.mp4')
<script>
    var video = document.getElementsByTagName('video')[0];
</script>
<input type="button" value="Play" onclick="video.play()">
<input type="button" value="Pause" onclick="video.pause()">
For a complete list of events and capabilities for playing video, check out this section of the spec at http://www.w3.org/TR/html5/video.html#playing-the-media-resource.

Using the Audio Tag

Using the audio tag is much like using the video tag: you pass one or more audio files to the control, and the first one the browser supports is played.
<audio src="audio.ogg" controls>
 Your browser does not support the audio element.
</audio>
Figure 5 lists the properties available in the audio tag. The control doesn’t need to display like a video player, so properties like height, width and poster are not included.
Figure 5 Audio Tag Properties
AttributeValueDescription
 AutoplayautoplayIf present, the audio starts playing as soon as it’s ready.
 ControlscontrolsControls, such as a play button, are displayed.
 LooploopIf present, the audio starts playing again (looping) when it reaches the end.
 PreloadpreloadIf present, the audio is loaded at page load, and is ready to run. It’s ignored if autoplay is present.
 SrcurlThe URL of the audio to play.
As with the video tag, you can pass multiple files to the audio tag and the first one that is supported will play. You can also use a fallback message when the browser doesn’t support the audio tag, like this:
<audio controls autoplay>
   <source src="audio1.ogg" type="audio/ogg" />
   <source src="audio1.mp3" type="audio/mpeg" />
    Your browser does not support the audio element.
</audio>

Summary

HTML5 is the next standard for the Web, and depending on the browsers you’re targeting, you can start using some of the new tags, such as audio and video, right now. Be cautious when using HTML5, however, because not every browser supports the new tags, and even if one does, it might not support every media format. If you’re using a modern browser that does support HTML5, you still need to do the extra work to process your media in all formats to ensure user success. Here are some great Web resources that provide browser support information as well as all the other information you need to ensure HTML5 media success: