Todd Anglin's Code Campground

A casual look at the world .NET coding

May 2008 - Posts

Silverlight Mobile Road Map Refresher

In keeping with my apparent "theme" this week of providing you with some Silverlight detail refreshers, I want to bring-up the topic of Silverlight for mobile platforms. While it has been widely known since the earliest days of Silverlight that mobile platforms would be supported, little attention (or scrutiny) has really been applied to the portable plug-in. In fact, if I were to ask you to tell me about Silverlight's mobile plans right now, you'd probably list these details:

  • The plug-in will not require you to change your Silverlight code (build once, deploy everywhere- ideally)
  • The mobile plug-in will be available for Microsoft Windows Mobile and Nokia S40/S60 and Internet Tablet platforms.
  • Microsoft is actively trying to develop partnerships to deploy the plug-in on other mobile devices. And no, the iPhone is not on the known short list.

But quick! Tell me which version of Silverlight is coming to the mobile platform first? And when is that version going to be available? If those answers don't come to you as quickly, I don't blame you. The information is not really circulating as prominently as it should be.

In my preparation for a recent trip to India- the place where all Silverlight Mobile development is done, by the way- I collected the latest known public details on Silverlight's mobile road map and will share them with you here. In short, Silverlight's road map looks something like this:

silverlightMobileRoadMap 

What's this diagram saying? Exactly this:

  • The first version of Silverlight for Mobile is going to be Silverlight 1.0 (JavaScript only - no .NET) and a CTP should be available any day now.
  • We'll get the first "official" Silverlight for Mobile (1.0) towards the end of this year, sometime after Silverlight 2.0 officially ships for the desktop. Around the same time we should get a CTP of Silverlight 2.0 for Mobile.
  • Finally, around this time next year we'll get the .NET-loving version of Silverlight for Mobile.

It appears that the Silverlight for Mobile development is lagging about a year behind it's desktop counterpart, which may come as a surprise to some. The real take-away here, though, is this: if you're planning on doing any Silverlight development for mobile platforms, don't expect to begin rolling-out production applications until early 2009. If you want to roll-out applications that re-use that fancy Silverlight 2.0 .NET you're writing now, expect to wait 'til next summer for production.

This post isn't intended to be "doom and gloom" on the Silverlight for Mobile road map, but rather a reality check for any developers that are getting increasingly excited about Silverlight 2.0 and are starting to make plans for real application development. Silverlight for Mobile is definitely coming- and it will be cool when it arrives- just don't expect to launch new Silverlight 2.0 apps completely cross platform (as in, including mobile devices) until sometime next year.

Isolated Storage changes in Silverlight 2

This isn't exactly what you call "breaking" news, but it is news that I don't see getting enough coverage. I also just noticed that I've been doling out bad info in my recent Silverlight 2 beta 1 presentations, so I wanted to take a minute to correct the record and set things straight.

The News

In short, Silverlight 2 beta 1 introduced some changes to the Isolated Storage API and its defaults. In Silverlight 1.1 alpha, the default Isolated Storage quota size was 1 MB. In Silverlight 2 beta 1, the default has been reduced to 100 KB. The issue is not that significant, and I expect many Silverlight apps will not have a problem staying well inside of this quota. But if you're planning on making any "significant" use of the Isolated Storage, be prepared to hit your quota limit fast in Silverlight 2.

The other tidbit that was news to me is how API for requesting a larger quota works. While the API for requesting a larger quota makes it appear like you can request any quota size you'd like (it accepts a size in bytes that you want to set the quota to, after all), in reality there are only a few discrete quota sizes you can use: 100KB, 1MB, 5MB, 10MB, and Unlimited.

That means requests for sizes larger than one if the discrete values will automatically round-up to the next valid quota size. And if your request is for a quota larger than 10MB, Silverlight will automatically ask the user to give you an "unlimited" quota. What's not clear at this point is what "unlimited" means, but it is likely that space will be limited by some user-configurable value (in the soon to arrive Isolated Storage configuration menu). I expect it will be very similar to the way users configure the allowed size for IE temporary files.

I also think that this setup, however well conceived, means the Isolated Storage API should be altered. Why use an API that accepts a freely defined integer value when only 5 distinct options are available? Perhaps an enumeration would make things more clear. In the absence of a clear API, though, just make a mental note and don't be surprised when your request for 2MB is automatically translated in to a request for 5.

Quick Review

For those of you that have yet to try increasing the Isolated Storage quota, the process is very simple. All you must do is tell Silverlight how large you'd like to make your application's storage quota (in bytes) and it will prompt the user asking for their permission to grant the increase. If they approve it, you're in business. If they don't, you must design your application to handle rejection. See the code snippet below for a quick look at how the API works.

// Obtain an isolated store for an application and ask user
// to allow quota increase
try
{
    using (var store = IsolatedStorageFile.GetUserStoreForApplication())
    {
        // Request to increase the quota size
        Int64 newQuotaSize = 1 * 1024 * 1024; //1MB
        Int64 curAvail = store.AvailableFreeSpace;

        // If available space is less than
        // what is requested, try to increase.
        if (curAvail < newQuotaSize)
        {

            // Request more quota space
            if (!store.TryIncreaseQuotaTo(newQuotaSize))
                lblAlert.Text = "Increase rejected.";           
            else
                lblAlert.Text = "Increase approved.";
        }
        else
            lblAlert.Text = "1 MB is still available.";
    }
}
catch (IsolatedStorageException ex)
{
    lblAlert.Text = ex.Message;
}

Beyond that, there are only a few additional facts important to remember about Isolated Storage quotas:

  • While Silverlight Isolated Storage files are isolated at the application level (per XAP), the quota is set per domain. This design is for security, and MS's Wilco Bauer has a good explanation on his blog.
  • Isolated Storage is a non-volatile cache. That means it won't be cleared by browser cache resets. The files are stored separately and can only be cleared by the Isolated Storage API (in other words, programmatically by your app) OR by the user with the forth coming configuration menu.
  • Isolated Storage is shared across browsers. Changes made to files in Isolated Storage in Firefox are accessible in IE and vice versa. That also means they share the same quota, so you don't get separate space allocations for each browser.
  • You can only access the GetUserStoreForApplication() method within a Silverlight initiated event (such as a Silverlight button click). You cannot fire requests to increase the quota arbitrarily- you must respond to some user action.

Hopefully this post helps highlights some important changes in the Isolated Storage quota system in Silverlight 2 beta 1 and sets you up for successful development on the soon to arrive Silverlight 2 beta 2. Assuming it doesn't make any more significant changes...

More Posts