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:

11/04/2011

5 Tips and Techniques for Avoiding Automatic GC Collections

by

Automatic memory management is isn't new, but it’s a wonderful thing for programmers. We bring you some tips and techniques to .help you understand a bit more about how .NET’s memory management works, can help you to ensure that you write high-performance .NET code
The .NET garbage collector is, in general, a wonderful thing. It has freed countless programmers from the drudgery both of writing allocation and de-allocation code, and also of tracking down heap corruption and memory leaks (due to bad pointers or de-allocation errors). It allows programmers to simply write code and focus on function without normally needing to care about how memory is actually managed. This tends to make it much easier for junior programmers to write correct (or at least functional) code, thereby reducing training costs and the time necessary to do things like code reviews.
However, for all that the garbage collector is a brilliant piece of software engineering, sometimes collections still occur at inconvenient times. If you need to write high performance, real-time code, in addition to measuring performance using tools like ANTS Performance Profiler, you generally want to try to avoid GC collections during times where execution speed is critical. For example: in an XNA game, you want to avoid collections during gameplay to prevent visual glitches in your animations; in a real time financial analysis and trading application, you want to avoid collections between when you begin analyzing incoming data and when you finish executing an algorithmically-controlled trading decision based on that data. Of course, sometimes GC collections at inconvenient times are unavoidable, and in those situations it is best to instead try to minimize the duration of individual collections (See: http://blogs.msdn.com/b/shawnhar/archive/2007/07/02/twin-paths-to-garbage-collector-nirvana.aspx). This article focuses mainly on avoiding collections, and while there is some overlap between optimizing to minimize GC frequency and optimizing to minimize GC latency, the two goals can also collide. This is certainly the case with object pooling, which can be very helpful with reducing frequency, but is almost guaranteed to increase latency (especially with non-generational GCs).
As you’re no doubt already aware, the GC runs automatically when certain defined conditions are met, and the specific conditions vary depending on the common language runtime in which the program is running. The .NET 4.0 Framework CLR has different conditions than the .NET 3.5 Compact Framework CLR, for instance. Nonetheless, the GCs of every CLR that I am familiar with all run a collection when a certain number of bytes have been allocated since the previous collection, and it’s this triggered collection that we will consider.
Note: Generational GCs are more complicated, as we saw in Clive Tong’s article, The Top 5 .NET Memory Management Misconceptions. The essence of a generational GC is that objects which survive a collection of their current generation are promoted to the next generation (if any). The higher generations are collected less frequently, such that the GC typically runs more quickly (it only needs to examine all the objects which are at or below the generation for which it is running a collection). For more, see: http://msdn.microsoft.com/en-us/library/ee787088.aspx and http://blogs.msdn.com/b/abhinaba/archive/2011/06/08/wp7-mango-mark-sweep-collection-and-how-does-a-generational-gc-help.aspx. Non-generational GCs maintain all objects at the same level such that every collection entails an examination of all live objects.
The .NET Framework 4.0 CLRs that run on Windows OSs have generational GCs, with algorithms that will vary the number of bytes that trigger an automatic collection in order to increase performance. On the other hand, the CLR that runs on the Xbox 360 and on Windows Phone 7.0 both run automatic collections whenever 1 MB has been allocated since the last collection. To be more specific, the Windows Phone Mango CLR has a generational GC that collects Gen0 whenever 1 MB has been allocated to Gen0, and collects Gen1 whenever 5 MB has been promoted to that generation (see: http://blogs.msdn.com/b/abhinaba/archive/2011/06/14/wp7-mango-the-new-generational-gc.aspx).
Understanding a bit more about how .NET’s memory management works can help you with both paths. These tips and techniques should help to both increase your understanding of what your code is doing, and to design your code to run faster with a minimum of extra work.

1. Know the difference between value types and reference types

There are two kinds of data types in .NET: value types and reference types. (See http://msdn.microsoft.com/en-us/library/ms173104.aspx, specifically the material beginning at the “The Common Type System” subheading) The difference between these two types ultimately comes down to how they store their data. An instance of a value type holds its data within itself, whereas an instance of a reference type holds a reference to the memory location of its data. Both value types and reference types have a default value, which is assigned to the instance when it is created in various situations.
Typical situations where the default value is automatically assigned are static variables, member variables of structs when instantiated with the default constructor, member variables of classes when a value is neither assigned in the constructor nor explicitly specified in a field’s declaration.
For value types, the default value is the result of a zeroing of the type’s member variables (e.g. for integers it’s zero, for booleans it’s false, for enumerations it’s zero (normally the first member of the enum), and for structs it’s the default value of each member of struct). For reference types, the default value is null. For those who are curious, the value of null in .NET is a zeroed out reference (the size of a reference depends on the runtime platform’s native memory address size and is thus only known at runtime).
So why does this matter? In truth, the difference is normally not too important, although sometimes you might trip over some peculiarities of value types (e.g. if you have a struct as a property, you cannot directly set any of its public fields or properties since the property’s get method returns a copy of the struct, instead of a reference to the struct). However, when writing to avoid or minimize GC collections, the difference becomes very important.
A value type either exists or does not exist. It cannot be null (Nullable<T> struct simulates nullity by maintaining a bool that specifies whether or not the struct has a value and by overriding the Equals method inherited from System.Object to handle checking for null. So it is never null, it just tests as equal to null in the appropriate circumstances) and exists for as long as the object that contains it does. As such, a value type has, at worst, a negligible effect on garbage collection. In fact, value types often do not exist within the GC’s heap. For example, a value type instance that is created within a method is not managed by the GC and, as such, the GC’s internal allocation amount tracking variable does not increase. On the other hand, if the value type is a struct, and that struct has a reference type as a member, then that reference type (should it be instantiated) is still managed by the GC. However the struct itself, when locally scoped in an ordinary method, is not subject to the GC’s purview (see http://blogs.msdn.com/b/ericlippert/archive/2010/09/30/the-truth-about-value-types.aspx).
Further, even when a value type is stored on the GC’s heap, e.g. when you create an array of value types, the GC does not need to check to see if those value type instances still exist when it does a collection since a value type cannot be null; the mere fact that the array still exists guarantees that they exist (and when the array is no longer reachable, they are also thereby not reachable, as their value nature precludes a reference to them existing in such circumstances ).
References to value types are possible, but never ones that could survive the object that contained the value type itself. An example would be a method like: public void AddHalf(ref double value) { value += 0.5; } . The ref double parameter is legal (and saves 4 bytes in the method call in a 32-bit program since references are 4 bytes and doubles are 8) but it’s impossible to have an object that contains the referenced double (such as an array) be subject to collection so long as the reference to the double exists.
So when the GC, in the course of doing a collection, comes across an array of one million floats, just needs to check to see if the array itself is still reachable. By contrast, for an array of one million class instances, it needs to check to see if the array itself is reachable, and then it needs to check each and every one of those one million elements to see if they are valid references or are null. The same holds true for generic collections. By using value types where appropriate, you can both help prevent GC allocations and can also make the GC’s collections speed along more quickly.

2. Consider a Struct Instead of a Class.

When creating a type, especially one that you are going to use in an array or a generic collection, consider making it a struct. Since structs are value types, they cannot be null such that the GC does not manage them (though it does manage any reference types that are members of the struct). When a GC collection does run, it only checks reference types to see if they are still reachable. This is only a small benefit for individual struct instances, but the benefit grows quickly with arrays, and can help to significantly reduce collection times when an array is composed of struct instances rather than class instances.
In my tests, I’ve come across one possible exception. Where you have a struct that contains a reference type as a member and a class with the same members, if most class instances in an array are null then the .NET Framework 4.0 x86 CLR’s GC will be faster on the array of classes. If there are no reference types within the definition or if even a small number (less than one-tenth) of the class instances are non-null, then the struct array retains its advantage.
With an array of class instances, the GC has to check each item in that array to see if it is a live object or not (the same is true for generic collections, which use an internal array). With an array of structs, the GC just looks to see if the array itself is still a live object, since structs cannot be null (this is true even for Nullable<T> structs, which just use an internal tracking mechanism to determine nullity). So that is potentially thousands or even millions of items that the GC does not need to examine when a collection runs!
There are several downsides to structs, though, so don’t get too carried away. They cannot inherit from classes or even from other structs, so while they can implement interfaces, the lack of inheritance can lead to a fair bit of code duplication and can increase your development time as a result. They also, as the term ‘value type’ implies, are copied by value rather than passed by reference when used as method parameters or assigned to / retrieved from arrays, collections, and properties. As such, when they have a large number of members, the cost of copying begins to add up. Lastly, they cannot have destructors (also known as finalizers) such that they are a poor choice for items that need to implement IDisposable. Nonetheless, when you have a data structure which will have many thousands of instances created of it, or of which it would be impractical to create an object pool, a struct can often be a big benefit in terms of GC performance and minimizing automatic GC collections.
The XNA Framework serves as a great example of appropriately using structs in preference to classes. To the extent that it was possible, the types which are commonly created and used in gameplay code, such as Vector2, GamepadState, and Color, have been implemented as structs made up of other value types. Types that aren’t commonly created during performance critical code or which need to be classes to implement IDisposable properly, such as BoundingFrustum and Texture2D, are implemented as classes.

3. Design classes so that instances are reusable and then use object pools where appropriate.

Regardless of the platform, most managed objects, excluding arrays and generic collections, tend to be small. Because of this, keeping instances of objects around when you are done with them and reusing them rather than creating new instances every time can be a useful trick. Doing so prevents the GC’s internal allocation counter from increasing, which helps prevent an automatic GC collection from running. Write objects you are likely to use many times so that each overload of its constructor has an equivalent public method that you can call to reinitialize that object. Then use a generic collection type such as a List<T> to pool object instances.
My own coding tends to be on platforms that use the .NET Compact Framework. The Xbox 360 and Windows Phone 7 both use versions of the .NET CF, and both automatically run a collection every time that 1 MB of GC-managed memory has been allocated since the previous collection. On the .NET Framework, the GC is more flexible on when it runs a collection, and also has separate heaps for large objects (the “LOH”) and for small objects, along with a generational GC which introduces efficiencies that make GC collections less intrusive. Object pools can also be very expensive if you are unable to eliminate GC collections during time critical code, since you are keeping around more objects that the GC will need to examine (this expense is especially a factor on platforms without a generational GC).
The following is an example of an object pool.
    /// <summary>
    /// A basic generic object pool. Objects are removed from the pool when request
    /// and re-added when returned.
    /// </summary>
    /// <typeparam name="T">
    /// The type of object to pool. This must be a class and have a parameterless
    /// constructor.
    /// </typeparam>
    public class ObjectPool<T> where T : class, new()
    {
        /// <summary>
        /// The pool itself.
        /// </summary>
        private System.Collections.Generic.List<T> pool;

        /// <summary>
        /// A lock for synchronizing access to the pool.
        /// </summary>
        private readonly System.Object _poolLock;

        /// <summary>
        /// Returns the count of items currently in the pool.
        /// </summary>
        public int Count
        {
            get
            {
                lock (_poolLock)
                {
                    return pool.Count;
                }
            }
        }

        /// <summary>
        /// Creates the object pool with <paramref name="initialCount"/> number
        /// of instances created and added to the pool. The pool will have an
        /// initial capacity of <paramref name="initialCapacity"/>.
        /// </summary>
        /// <param name="initialCapacity">
        /// How large the initial capacity of the pool should be. Set this high
        /// enough that you won't exceed it, but not so high as to needlessly
        /// waste memory.
        /// </param>
        /// <param name="initialCount">
        /// How many object instances to create initially.
        /// </param>
        public ObjectPool(int initialCapacity, int initialCount)
        {
            _poolLock = new System.Object();

            pool = new System.Collections.Generic.List<T>(initialCapacity);

            for (int i = 0; i < initialCount; i++)
            {
                pool.Add(new T());
            }
        }

        /// <summary>
        /// Gets an instance of <typeparamref name="T"/> from the pool. If the pool is
        /// empty, a new instance of <typeparamref name="T"/> is created and returned
        /// to you instead.
        /// </summary>
        /// <returns>An unused instance of <typeparamref name="T"/>.</returns>
        public T GetObject()
        {
            lock (_poolLock)
            {
                if (pool.Count == 0)
                {
                    System.Diagnostics.Debug.WriteLine("Had to create a new item.");
                    return new T();
                }

                // Remove from the end of the pool to prevent an internal rearrangement.
                var item = pool[pool.Count - 1];
                pool.RemoveAt(pool.Count - 1);
                return item;
            }
        }

        /// <summary>
        /// Return (or add) an existing instance of <typeparamref name="T"/> to the pool.
        /// </summary>
        /// <param name="item">
        /// The instance of <typeparamref name="T"/> to return to the pool.
        /// </param>
        /// <exception cref="System.ArgumentNullException">
        /// Thrown when <paramref name="item"/> is null.
        /// </exception>
        /// <exception cref="System.InvalidOperationException">
        /// Thrown when <paramref name="item"/> is already in the object pool.
        /// </exception>
        /// <remarks>
        /// Do not return an object that you are still using. This will likely lead
        /// to the same object being "checked out" twice which will cause bugs. Also if
        /// <typeparamref name="T"/> implements <see cref="System.IDisposable"/>, do not
        /// return an object that has been disposed.
        /// </remarks>
        public void ReturnObject(T item)
        {
            if (item == null)
            {
                throw new System.ArgumentNullException("button");
            }

            lock (_poolLock)
            {
                if (!pool.Contains(item))
                {
                    pool.Add(item);
                }
                else
                {
                    throw new System.InvalidOperationException("The pool already contains this item.");
                }
            }
        }

        /// <summary>
        /// If <typeparamref name="T"/> implements <see cref="System.IDisposable"/>, this
        /// will call Dispose on all objects in the pool.
        /// </summary>
        /// <remarks>
        /// If <typeparamref name="T"/> does not implement
        /// <see cref="System.IDisposable"/>, this will do nothing. You should
        /// only call this method when you are completely finished with the pool as
        /// as you will otherwise get disposed objects back when calling
        /// <see cref="GetObject"/>.
        /// </remarks>
        public void DisposeAllObjects()
        {
            if (typeof(System.IDisposable).IsAssignableFrom(typeof(T)))
            {
                foreach (var item in pool)
                {
                    (item as System.IDisposable).Dispose();
                }
            }
        }
    }

4. Use collection constructor overloads that take an initial capacity for collection types that have them.

Most of the generic collections have constructor overloads that take an ‘int initialCapacity’ parameter. Internally, List<T>, Dictionary<TKey, TValue>, and the other generic collections use one or more arrays along with a tracking variable to identify how many items of internal array hold valid data. Whenever adding an item to the collection would exceed the capacity of the internal array, a new array that is double the previous capacity is created. The existing array’s elements are then copied to the new array, and the new array then replaces the old internal array. All of this generates allocations that increase the GC’s internal allocation counter.
When you first create a collection using its parameter-less constructor with the .NET Framework 4.0 CLR, the internal array’s length is 0. The first addition causes it to resize to hold 4 elements. These are all implementation details, including the fact that there is an internal array at all. These internal details could change in the future so you should not rely on these internal implementation details. The advice itself (use initial capacity constructors) is part of the public interface, though, so using it is safe.
If you know approximately how many elements will ever be in that collection at one time, you can use one of the constructor overloads that tells the collection to create its internal array(s) with a specific initial size, rather than its default size. If you know the exact number of elements your collection will hold, use that. If not, use an estimation with a small bit of extra capacity, just in case. If you don’t have any idea, consider using System.Diagnostic.Debug.WriteLine to write out the name, current Count, and current Capacity of the collection whenever you have just added an item to it. Then run your program as normal and make note of the debugging output. This will give you a good estimation of each collection’s capacity needs, which you can then use to decide on an initial capacity.
Assuming you set your initial capacity high enough, that internal array will never need to be resized, meaning you can avoid generating new allocations. However, setting the initial capacity to be far in excess of your needs will just cause wasted memory (especially with collections of value types), and will cause GC collections to take longer when they do occur.

5. Be aware of common operations that generate allocations.

There are a few common operations in .NET that generate GC allocations in a way that might not be obvious. The two prime targets are the boxing of value types and most string operations. We’ll look at each in turn.
Boxing of value types refers to the act of casting a value type (such as an integer or a float) to a reference type (such as System.Object or an interface). One place this is commonly found is in string operation methods that take a ‘params object[]’ argument such as String.Format and Console.WriteLine. Since every System.Object has a ToString method, you can cast anything (including value types) to Object, and then pass them to a method that uses ToString to get that object’s string representation. Boxing also occurs when explicitly casting a value type to an interface. While interfaces cannot be instantiated, the CLR treats them as being reference types whenever you create an instance of an interface (through casting an existing data item that implements that interface).
There is also a corresponding ‘unbox’ CIL instruction for casting a boxed value type from Object back to its value type. This is commonly found when a method takes in a parameter as an Object instance and then casts it to its appropriate value type. Unbox does not generate GC allocations.
For value types, a reference type container (a ‘box’) needs to be created to hold the underlying value type when it is cast to Object or to an interface . If you use a disassembler tool such as ildasm.exe or .NET Reflector® , you can look for the Common Intermediate Language (“CIL”) ‘box’ instruction to find instances where you are boxing value types. It’s not always possible to eliminate boxing, and it may not be worthwhile to do so even when it is possible, but simply by knowing what it is and how to spot it, you are more aware of the memory implications of your code.
Strings are a strange thing in .NET. They are reference types and thus are managed by the GC. However they are immutable and are not subject to re-use due to the way they are stored (see http://blogs.msdn.com/b/ericlippert/archive/2011/07/19/strings-immutability-and-persistence.aspx). As such, virtually all operations that involve transforming a string will in some way result in GC allocations. String concatenation creates a new string, for instance, as does trimming whitespace with Trim and its cousins. Most other string operations (e.g. almost any one that returns a string) will generate allocations. Transforming objects into their string equivalents by using the ToString method also normally generates GC allocations. They’re hard to avoid.
One way to minimize allocations caused by string operations is to use System.Text.StringBuilder. StringBuilder is to the String class as List<T> is to an array. By this I mean that it uses an internal array that it automatically resizes itself when needed (using the same “create an array that is twice as big, copy over the data, and replace the existing array with the new array” mechanism). Unfortunately, not many classes in .NET that take a string will also take a StringBuilder. Nevertheless, you can use StringBuilder to compose strings from many different parts, and can reuse StringBuilder instances to cut down on allocations. It’s not often a large gain, but it can help save some allocations in code that performs a lot of string operations.

Wrap Up

Automatic memory management is by no means a new invention (John McCarthy, the inventor of LISP, first came up with the concept in 1959 ). Nonetheless, it’s a wonderful thing for programmers, and is something that will likely find its way into many more venues as computing power continues to grow. Knowing a bit about how it works is something I think every .NET programmer could benefit from. I hope this has helped shed a bit of light on it for you.

Bonus Tip - 6. Force a GC collection at convenient times.

Using the GC class, you can force a collection by calling its static Collect method. In ordinary programming, it’s usually best to let the GC handle such matters itself. However, if you have a situation where a GC collection would be bad, e.g. during the middle of a level in a game, it usually makes sense to force a collection right after you have finished loading that level’s content (right before going into gameplay). Doing so will reset the GC’s internal allocation counter, and delay the next collection. If you have managed to limit, but not eliminate, garbage generation during gameplay, then you might find that your time-sensitive operation will complete before you pass the magic allocation mark at which an automatic collection occurs. So, if you can identify good places within your code to force a GC collection, consider doing it and measuring the performance results. A forced collection might be just the thing you need to stave off an unwanted automatic collection.