Jeff Prosise's Blog

Dynamic Page Loading in Silverlight

jprosise — Sun, 27 Jun 2010 03:04:00 GMT

A while back, I blogged about the INavigationContentLoader interface introduced in Silverlight 4. INavigationContentLoader is an extensibility point in Silverlight’s navigation framework that lets you provide your own plug-in for loading pages. Silverlight 4 comes with one INavigationContentLoader implementation in a class named PageResourceContentLoader, which loads pages from assemblies in an application’s XAP file. I recently put INavigationContentLoader to work by building my own content loader that loads pages from local XAP files as well as remote assemblies. I named my implementation DynamicContentLoader, and you can download a Visual Studio 2010 project that uses it from Wintellect’s Web site.

My goal in building DynamicContentLoader was to create a content loader that supports the partitioning of large navigation apps. Imagine you’re writing a navigation app that contains hundreds, perhaps thousands, of pages. Depending on how the user interacts with the app, you may not need all those pages, and you don’t want every user to have to pay the price for downloading them, which is exactly what happens if you put all those pages in the application’s XAP. DynamicContentLoader supports a special syntax that lets you identify auxiliary assemblies containing “external” pages. The first time you load an external page, DynamicContentLoader downloads the assembly, loads it into the appdomain, and creates the page. It also caches information allowing that page (and other pages in the same assembly) to be loaded again without redownloading the assembly.

My sample begins with the following goo in MainPage.xaml:

<nav:Frame Source="Page1">

<nav:Frame.ContentLoader>

<local:DynamicContentLoader />

</nav:Frame.ContentLoader>

<nav:Frame.UriMapper>

<map:UriMapper>

<map:UriMapping Uri="" MappedUri="/Page1.xaml" />

<map:UriMapping Uri="Page1" MappedUri="/Page1.xaml" />

<map:UriMapping Uri="Page2" MappedUri="/EXT:ExternalPages.dll|Page2.xaml" />

<map:UriMapping Uri="Page3" MappedUri="/EXT:ExternalPages.dll|Page3.xaml" />

</map:UriMapper>

</nav:Frame.UriMapper>

</nav:Frame>

</Grid>

The URI mappings target the app’s three pages: Page1.xaml, Page2.xaml, and Page3.xaml. Page1.xaml lives in the application’s XAP file. Page2.xaml and Page3.xaml do not; they live in an external assembly named ExternalPages.dll. That assembly isn’t embedded in the XAP; it was created from a separate Silverlight project and copied into ClientBin, where it sits beside the application’s XAP file. If the user never navigates to Page2.xaml or Page3.xaml, the assembly never gets loaded. But the moment the user navigates to one of these pages, ExternalPages.dll gets downloaded from ClientBin and loaded into the application. There is no limit to the number of auxiliary assemblies you can deploy. If you wanted to add pages 4 and 5 to the app and house them in an assembly named MorePages.dll, you could modify the URI mappings as follows:

<map:UriMapping Uri="" MappedUri="/Page1.xaml" />

<map:UriMapping Uri="Page1" MappedUri="/Page1.xaml" />

<map:UriMapping Uri="Page2" MappedUri="/EXT:ExternalPages.dll|Page2.xaml" />

<map:UriMapping Uri="Page3" MappedUri="/EXT:ExternalPages.dll|Page3.xaml" />

<map:UriMapping Uri="Page4" MappedUri="/EXT:MorePages.dll|Page4.xaml" />

<map:UriMapping Uri="Page5" MappedUri="/EXT:MorePages.dll|Page5.xaml" />

All you have to do is preface the assembly URI with /EXT:, and separate the assembly URI from the page URI with a vertical bar (|). DynamicContentLoader will do the rest.

My DynamicContentLoader class is implemented as follows:

public class DynamicContentLoader : INavigationContentLoader

{

private const string _extern = "/EXT:";

private const char _separator = '|';

private PageResourceContentLoader _loader = new PageResourceContentLoader();

// Maps URIs to types (e.g., "/EXT:ExternalPages.dll/Page2.xaml" -> typeof(Page2))

// Used to determine whether a page has been requested before and to instantiate it

// quickly if it has

private static Dictionary<string, Type> _pages = new Dictionary<string, Type>();

// Maps downloaded DLLs to assembly info (e.g., "ExternalPages.dll" ->

// "ExternalPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null")

// Used to determine whether an assembly has been downloaded before and to

// store info needed to get information about types in that assembly

private static Dictionary<string, string> _assemblies = new Dictionary<string, string>();

public IAsyncResult BeginLoad(Uri targetUri, Uri currentUri, AsyncCallback userCallback, object asyncState)

{

if (!targetUri.ToString().StartsWith(_extern))

{

// If the URI doesn't start with "EXT:," let the default loader handle it

return _loader.BeginLoad(targetUri, currentUri, userCallback, asyncState);

}

else // Otherwise handle it here

{

NavigationAsyncResult ar = new NavigationAsyncResult(userCallback, asyncState);

string fullUri = targetUri.ToString();

// If this page has been loaded before, instantiate it

// using type information generated the first time and

// cached in the _pages dictionary

Type type;

if (_pages.TryGetValue(fullUri.ToLower(), out type))

{

ar.Result = Activator.CreateInstance(type);

ar.CompleteCall(true);

return ar;

}

// Extract the page URI (e.g., "Page2.xaml")

int index = fullUri.IndexOf(_separator) + 1;

string pageUri = fullUri.Substring(index, fullUri.Length - index);

if ((index = pageUri.IndexOf('?')) > 0)

pageUri = pageUri.Substring(0, index); // Strip off query string

// Extract the assembly URI (e.g., "ExternalPages.dll")

int len = _extern.Length;

string assemblyUri = fullUri.Substring(len, fullUri.Length - len);

assemblyUri = assemblyUri.Substring(0, assemblyUri.IndexOf(_separator));

// If the assembly has been downloaded before, instantiate

// the page without downloading the assembly again

string fullName;

if (_assemblies.TryGetValue(assemblyUri.ToLower(), out fullName))

{

// Instantiate the page

type = GetXamlPageType(pageUri, fullName);

ar.Result = Activator.CreateInstance(type);

_pages.Add(fullUri.ToLower(), type);

ar.CompleteCall(true);

return ar;

}

// Prepare the IAsyncResult

ar.TargetUri = fullUri;

ar.PageUri = pageUri;

ar.AssemblyUri = assemblyUri;

// Begin downloading the assembly

WebClient wc = new WebClient();

wc.OpenReadCompleted += new OpenReadCompletedEventHandler(OnOpenReadCompleted);

wc.OpenReadAsync(new Uri(assemblyUri, UriKind.Relative), ar);

return ar;

}

void OnOpenReadCompleted(object sender, OpenReadCompletedEventArgs e)

{

if (e.Error == null)

{

NavigationAsyncResult ar = e.UserState as NavigationAsyncResult;

// Load the downloaded assembly into the appdomain

AssemblyPart part = new AssemblyPart();

Assembly assembly = part.Load(e.Result);

string fullName = assembly.FullName;

// Instantiate the page

Type type = GetXamlPageType(ar.PageUri, fullName);

ar.Result = Activator.CreateInstance(type);

// Update the dictionaries

_pages.Add(ar.TargetUri.ToLower(), type);

_assemblies.Add(ar.AssemblyUri.ToLower(), fullName);

// Signal that loading is finished

ar.CompleteCall(false);

}

else

throw e.Error;

}

public bool CanLoad(Uri targetUri, Uri currentUri)

{

if (targetUri.ToString().StartsWith(_extern))

return true;

else

return _loader.CanLoad(targetUri, currentUri);

}

public void CancelLoad(IAsyncResult asyncResult)

{

// Do nothing

}

public LoadResult EndLoad(IAsyncResult asyncResult)

{

if (asyncResult is NavigationAsyncResult)

return new LoadResult((asyncResult as NavigationAsyncResult).Result);

else

return _loader.EndLoad(asyncResult);

}

/////////////////////////////////////////////////////////////////

// Given the URI of a XAML page (e.g., Page2.xaml) and the name

// of the assembly that hosts the page, GetXamlPageType extracts

// the page from the assembly, finds the x:Class attribute, and

// returns the corresponding type.

private Type GetXamlPageType(string pageUri, string assemblyFullName)

{

string shortName = assemblyFullName.Substring(0, assemblyFullName.IndexOf(','));

string path = shortName + ";component/" + pageUri;

StreamResourceInfo sri = Application.GetResourceStream(new Uri(path, UriKind.Relative));

using (XmlReader reader = XmlReader.Create(sri.Stream))

{

reader.Read();

string name = reader.GetAttribute("x:Class");

return Type.GetType(name + ", " + assemblyFullName, false, true);

}

There’s a lot going on inside, but the gist of it is that before loading a new page, the navigation framework calls the registered content loader’s CanLoad method to determine whether the page can be loaded. DynamicContentLoader’s CanLoad method checks for a /EXT: prefix at the beginning of the URI. If the prefix is present, CanLoad returns true. If there is no such prefix, CanLoad delegates to an instance of PageResourceContentLoader so that “normal” pages will work as usual.

The real action happens in BeginLoad, which is called to begin an asynchronous page load. The workflow in my implementation can be summed up as follows:

Check to see if the requested URI contains a /EXT: prefix. If not, delegate to PageResourceContentLoader to do the loading.
Check the _pages dictionary to see if the page (and the assembly containing it) has been loaded before. If so, extract a Type object representing the page from the dictionary and pass the Type to Activator.CreateInstance to create an instance of that page.
If the page has not been loaded before, check the _assemblies dictionary to see whether the assembly designated in the URI has been loaded before. If so, inspect the assembly and create a Type object representing the page. Then use Activator.CreateInstance to create an instance of the page and cache the Type object in the _pages dictionary.
If neither the page nor the assembly has been loaded before, use WebClient to asynchronously download the assembly. When the download is complete, load the assembly into the appdomain with AssemblyPart.Load and create a Type object representing the page. Then use Activator.CreateInstance to create an instance of the page, and cache the Type object in the _pages dictionary and information about the downloaded assembly in the _assemblies dictionary.

The helper method named GetXamlPageType plays a key role in content loading. Given the URI of a page resource (for example, Page2.xaml), it uses a little trick with Application.GetResourceInfo to extract the resource from the designated assembly. Then it uses an XmlReader to find the x:Class attribute on the page’s root element. That attribute identifies the class that corresponds to the XAML page.

David Poll has blogged extensively about INavigationContentLoader, but to my knowledge, this is the only example out there of a content loader that loads pages dynamically based on XAML page URIs rather than class names. One idea I have for extending DynamicContentLoader is to give it the ability to download auxiliary XAPs containing external pages. Conceptually, it wouldn’t be hard: just download the XAP file, enumerate the assemblies inside, and load them one by one with AssemblyPart.Load. I’ve done that in other extensibility demos, and it’s not difficult. But because I just landed in Beijing in preparation for spending a week at the Microsoft office here, and because I want to do some sightseeing before work starts tomorrow, for now, I’ll leave that enhancement up to you. :-)

UPDATE: I modified the code to strip query strings from page URIs. The downloadable zip file containing the finished project has been updated accordingly.

Dynamic Localization in Silverlight

jprosise — Mon, 21 Jun 2010 16:33:00 GMT

Localization is (and has always been) a hot topic in Silverlight. There are many ways to do it, but most solutions that I've seen use some variation of the technique described in the Silverlight documentation, which puts localization resources in RESXes and uses data binding to bind XAML elements to localized resources. It works, but it has always left a bad taste in my mouth. For one thing, all the satellite assemblies built from the RESX files are packaged in the application's XAP file, meaning the XAP can grow quite large. That's wasteful, because for a given user, you probably only need one of those satellite assemblies. (A user who prefers to see content in French probably has no need to see it in Manadarin Chinese, too.) For another, you often need the ability to switch between languages at run-time so you can present a list of language choices to the user and immediately switch to the language they selected. Finally, Visual Studio suffers from a long-standing bug that leaves the constructor of the ResourceManager wrapper class it generates marked internal when you change the class's access modifier to public. This means that whenever you modify the primary RESX file, forcing a code regen, you have to manually change internal to public on the constructor in the generated code. It beats me why this hasn't been fixed after all these years, but it hasn't.

I came up with a solution that addresses all of these issues and that so far has proven to be reasonably maintainable and robust. It starts with a class that I call ObservableResources:

public class ObservableResources<T> : INotifyPropertyChanged

{

private static T _resources;

public T LocalizationResources

{

get { return _resources; }

}

public event PropertyChangedEventHandler PropertyChanged;

public ObservableResources(T resources)

{

_resources = resources;

}

public void UpdateBindings()

{

if (PropertyChanged != null)

PropertyChanged(this, new PropertyChangedEventArgs("LocalizationResources"));

}

The inspiration for this class came from a blog post by Tim Heuer. The idea is that instead of binding XAML elements to the ResourceManager wrapper generated by Visual Studio, you bind them to an object that wraps the wrapper (whose class name comes from the names of your RESX files and is passed to ObservableResources as a template parameter) and implements INotifyPropertyChanged. Now you can change the culture at run-time and call ObservableResources.UpdatingBindings to update the binding targets. A side benefit of wrapping the wrapper is that it eliminates the need to change the Visual Studio-generated wrapper class’s constructor from internal to public. (Now if only Silverlight would allow you to declaratively instantiate generic types. Grrr. Because you have to instantiate ObservableResources programmatically, you lose design-time support.)

The second part of the solution is a helper class named LocalizationManager. I won’t post the source code here, but LocalizationManager exposes a simple API for changing cultures. If necessary, it downloads external XAPs containing localization resources and loads them into the appdomain so ResourceManager can find them. My implementation has intimate knowledge of which localization resources are stored in which XAPs, but you could easily build a more generic version that works in any application. LocalizationManager’s API looks like this:

public event EventHandler<CultureChangedEventArgs> CultureChanged;

public event EventHandler<CultureChangedErrorEventArgs> CultureChangeFailed;

public void ChangeCulture(CultureInfo culture);

To demonstrate the ObservableResources/LocalizationManager approach to localization, I built a sample app with this in MainPage.xaml:

<TextBlock Text="{Binding LocalizationResources.Greeting}"

Foreground="LightYellow" FontSize="72" FontWeight="Bold"

HorizontalAlignment="Center" VerticalAlignment="Center">

<TextBlock.Effect>

</TextBlock.Effect>

</TextBlock>

<Button Width="120" Height="60"

Content="{Binding LocalizationResources.EnglishLabel}"

Tag="en" Click="OnChangeCulture" Margin="5" />

<Button Width="120" Height="60"

Content="{Binding LocalizationResources.FrenchLabel}"

Tag="fr" Click="OnChangeCulture" Margin="5" />

<Button Width="120" Height="60"

Content="{Binding LocalizationResources.GermanLabel}"

Tag="de" Click="OnChangeCulture" Margin="5" />

<Button Width="120" Height="60"

Content="{Binding LocalizationResources.SpanishLabel}"

Tag="es" Click="OnChangeCulture" Margin="5" />

</StackPanel>

</Grid>

And this in MainPage.xaml.cs:

public partial class MainPage : UserControl

{

private LocalizationManager _manager = new LocalizationManager();

private ObservableResources<Resources> _resources =

new ObservableResources<Resources>(new Resources());

public MainPage()

{

InitializeComponent();

// Set LayoutRoot's DataContext to specify binding sources for child elements

LayoutRoot.DataContext = _resources;

}

private void OnChangeCulture(object sender, RoutedEventArgs args)

{

// Change the culture, and then rebind

_manager.CultureChanged += (s, e) => _resources.UpdateBindings();

_manager.CultureChangeFailed += (s, e) => MessageBox.Show(e.Error.Message);

_manager.ChangeCulture(new CultureInfo((sender as FrameworkElement).Tag.ToString()));

}

When the app starts up, you see this:

And when you click the Spanish button, you see this:

The application XAP contains a single RESX file (Resources.resx) containing strings for the default language (English). Strings for other languages live in a separate XAP named ExternalResources.xap. Clicking one of the language buttons executes a call to LocalizationManager.ChangeCulture, which does the following:

Downloads ExternalResources.xap if it hasn’t been downloaded before, and sets a flag to prevent it from being downloaded again
Extracts all satellite assemblies from the XAP and loads them into the appdomain
Changes the culture by assigning the specified CultureInfo to the CurrentCulture and CurrentUICulture properties of the current thread
Fires a CultureChanged event to let you know that the culture has changed

My CultureChanged event handler calls UpdateBindings on the ObservableResources object, forcing the bindings that provide data to my TextBlock and Button elements to be reevaluated. Thus, the UI updates automatically.

That’s the crux of the solution, and, of course, there are details that I haven’t covered. I didn’t make my helper classes thread-safe, because I’m assuming that they’ll only be called from the UI thread. If you’d like to see the entire solution, you can download it from Wintellect’s Web site. It’s not the final word on Silverlight localization (not by a long shot), but it’s a big step in the right direction.

Dynamic XAP Discovery with Silverlight MEF

jprosise — Thu, 17 Jun 2010 12:03:00 GMT

I've spent copious amounts of time lately digging into Silverlight 4's new Managed Extensibility Framework (MEF) and seem to find new uses for it every day. I love the fact that you can download a remote XAP file and import all of its exported parts with basically two lines of code:

DeploymentCatalog dc = new DeploymentCatalog("MoreWidgets.xap");

dc.DownloadAsync();

What's missing, it seems, is a mechanism to dynamically discover the XAPs that are available on the server. If I'm using MEF to support a plug-in architecture, for example, I might want to drop a XAP containing a new plug-in into a folder on the server and have the plug-in automatically show up in my browser the next time the application runs.

MEF won't do that on its own, but it will if you lend it a helping hand. After discussing various ways to do dynamic discovery in MEF with Jeremy Likness, I wrote a sample to demonstrate a technique based on passing InitParams to the Silverlight control. The technique is pretty simple.

You begin by modifying the ASPX file that hosts your Silverlight application. First, you add an empty InitParams <params> element to the <object> element that instantiates the Silverlight control, and you include an ID and a runat="server" attribute so you can manipulate the element from server-side code:

Next, you add the following C# code to the ASPX file:

private void Page_Load(object sender, EventArgs e)

{

StringBuilder sb = new StringBuilder();

DirectoryInfo di = new DirectoryInfo(Server.MapPath("ClientBin"));

FileInfo[] files = di.GetFiles("*.xap");

foreach (FileInfo file in files)

{

sb.Append(file.Name);

sb.Append("=,");

}

ip.Attributes.Add("value", sb.ToString());

}

This little piece of code enumerates the XAP files in ClientBin and writes them to the <object> element as InitParams. The resulting <param> element might look like this:

The final step is to add logic to your Silverlight app to process InitParams and turn each XAP file listed there into a DeploymentCatalog that begins downloading when the app starts up. Here's how I did it:

AggregateCatalog catalog = new AggregateCatalog();

foreach (string uri in Application.Current.Host.InitParams.Keys)

{

DeploymentCatalog dc = new DeploymentCatalog(uri);

catalog.Catalogs.Add(dc);

dc.DownloadAsync();

}

CompositionHost.Initialize(catalog);

CompositionInitializer.SatisfyImports(this);

In real life, you'd probably want to process DownloadCompleted events to make sure the XAPs are downloaded successfully. And, of course, you'll need to have recomposition enabled on your imports so the new exports will show up as the downloads complete.

Understanding Input Scope in Silverlight for Windows Phone

jprosise — Tue, 11 May 2010 12:36:00 GMT

If you write applications for Silverlight for Windows Phone, one of the features you quickly become familiar with is the Software Input Panel, or SIP. The SIP is the virtual keyboard that appears when a text-input control such as a TextBox gets the input focus. You don't have to do anything to make the SIP appear; that happens automatically. But you can lend Silverlight a hand by specifying an input scope for each text-input control that you create. This enables the runtime to stylize the SIP to match the type of data you expect the user to enter.

You specify an input scope on a per-control basis by assigning a value to the control's InputScope property. To demonstrate, I created a new Silverlight for Windows Phone project and added the following TextBlock and TextBox declarations to a vertical StackPanel in MainPage.xaml:

When you run the application and the "Name" box has the focus, the UI looks like this:

When the "E-Mail Address" box has the focus, the SIP changes slightly to include "@" and ".com" keys:

And when the "Phone Number" box has the focus, the SIP morphs into a telephone keypad:

SIPs differ not only in appearance but in behavior. For example, the Default SIP does little in the way of helping the user enter text. But setting InputScope to "Text" turns on auto-capitalization, auto-completion, and other helpful features.

The current Silverlight for Windows Phone CTP includes more than 60 InputScopes. Some of them, such as Bopomofo and KatakanaHalfWidth, you'll probably never use. A handful, including Xml and RegularExpression, generate runtime exceptions. (This is, after all, a preview release.) But others, such as Text and TelephoneNumber, are extraordinarily useful and will probably be used by a majority of developers.

You can view a list of InputScopes in IntelliSense if you use the more verbose property-element syntax to specify an InputScope name:

You can use reflection to generate a list of InputScopes in code:

List<string> names = new List<string>();

for (int i = -10; i < 100; i++)

{

if (Enum.IsDefined(typeof(InputScopeNameValue), i))

names.Add(Enum.GetName(typeof(InputScopeNameValue), i));

}

You can even assign an InputScope to a control programmatically:

MyTextBox.InputScope = new InputScope()

{ Names = { new InputScopeName() { NameValue = "Text" } } };

Using InputScope to produce context-aware SIPs improves the user experience. Use them liberally if you build phone applications that support keyboard data entry!

Understanding Page Orientation in Silverlight for Windows Phone

jprosise — Mon, 10 May 2010 11:05:00 GMT

At MIX this year, Silverlight developers were handed a real treat: their first look at Silverlight for Windows Phone. Silverlight is the primary platform that developers will use to write applications for the new Windows phone, which will debut later this year. I can't remember being this excited about a platform since...well, since Silverlight 1.0. If you're an iPhone user like me, and you'd love to write iPhone apps but don't care for Objective-C (soooooo 1990s!), Silverlight for Windows Phone is the hottest thing since color TV. Just think: you can leverage the skills you acquired writing Silverlight apps for the browser to write Silverlight apps for phones. You already know 90% of what you need to know; all you have to do is learn about the relatively few differences between Silverlight for the browser and Silverlight for the phone.

One of those differences is page orientation. When you write browser-based (or out-of-browser) Silverlight apps, you don't have to worry about a user turning his or her monitor on its side. The phone, of course, is different. Silverlight for Windows Phone introduces the concept of page orientation, which tells you whether the phone is upright, upside-down, or on its side. Most apps don't have to do much to rotate the entire display when the phone itself rotates; Silverlight does that for them. But some apps will need to know when the phone has rotated so they can customize the UI programmatically.

To demonstrate, I built a simple app that displays Dooby the Penguin:

When you create a new Silverlight for Windows Phone application, Visual Studio includes the following line of code in MainPage's constructor in MainPage.xaml.cs:

SupportedOrientations = SupportedPageOrientation.Portrait | SupportedPageOrientation.Landscape;

This tells the runtime that the application supports both portrait and landscape orientations, and when the phone is rotated onto a side, Silverlight automatically rotates the display:

When you design a Silverlight for Windows Phone application that supports portrait and landscape modes, you strive to create a XAML UI that produces the look you want in either orientation without code intervention. In this example, because the penguin is positioned inside a Grid cell, it is automatically centered in the display whether the phone is upright or on its side.

If you don't want the display to rotate when the orientation changes, you can remove Landscape from the page's supported orientations:

SupportedOrientations = SupportedPageOrientation.Portrait;

Now turning the phone on its side will produce this:

The more interesting case is when code intervention is required to achieve the look you want when the orientation changes. For example, suppose you want to display one penguin in portrait mode, but two penguins in landscape mode:

If SupportedOrientations is SupportedPageOrientation.Portrait | SupportedPageOrientation.Landscape (or simply SupportedPageOrientation.PortraitOrLandscape), the page fires an OrientationChanging event when a turn begins and an OrientationChanged event once the turn is complete. You can use these events to modify the XAML UI. For example, I structured my XAML this way to display one penguin in portrait mode and two in landscape mode:

<Grid.RowDefinitions>

</Grid.RowDefinitions>

<TextBlock Text="ORIENTATION DEMO" x:Name="textBlockPageTitle"

Style="{StaticResource PhoneTextPageTitle1Style}"

HorizontalAlignment="Center"/>

</Grid>

<Grid>

<Grid.ColumnDefinitions>

</Grid.ColumnDefinitions>

<local:PenguinUserControl Grid.Column="0" />

<local:PenguinUserControl Grid.Column="1"

Visibility="Collapsed" x:Name="SecondPenguin" />

</Grid>

Then I did this in the code-behind:

public partial class MainPage : PhoneApplicationPage

{

public MainPage()

{

InitializeComponent();

SupportedOrientations = SupportedPageOrientation.Portrait |

SupportedPageOrientation.Landscape;

this.OrientationChanged +=

new EventHandler<OrientationChangedEventArgs>(OnOrientationChanged);

}

void OnOrientationChanged(object sender, OrientationChangedEventArgs e)

{

if ((e.Orientation & PageOrientation.Landscape) != 0)

{

SecondPenguin.Visibility = Visibility.Visible;

SecondColumn.Width = GridLength.Auto;

}

else // Portrait

{

SecondPenguin.Visibility = Visibility.Collapsed;

SecondColumn.Width = new GridLength(0);

}

The Orientation property of the OrientationChangedEventArgs passed to the event handler is a PageOrientation object, which is defined this way in the Silverlight for Windows Phone runtime:

public enum PageOrientation

{

Landscape = 2,

LandscapeLeft = 0x12,

LandscapeRight = 0x22,

None = 0,

Portrait = 1,

PortraitDown = 9,

PortraitUp = 5

}

It follows that you can determine exactly what the phone's orientation is (upright, upside-down, on its left side, or on its right side) by comparing e.Orientation to specific values such as PortraitUp and LandscapeRight. But the more common case is that you simply want to know whether the phone is oriented vertically or horizontally. You can check for the latter by ANDing e.Orientation with Landscape and checking for a nonzero value. That's precisely what I'm doing in the OnOrientationChanged method above.

Interestingly enough, you can't determine the phone's orientation by checking the ActualWidth and ActualHeight properties of the Silverlight control or any other control; these properties don't change when the orientation changes. (That's how it works in the Silverlight for Windows Phone CTP, anyway; I can't guarantee that will be the case in the final version.) Nor does there appear to be any way to determine what the phone's orientation is at startup. However, if the application starts up in landscape mode, the page immediately fires its OrientationChanging and OrientationChanged events, so you can design your UI to assume that the application starts up in portrait mode and let your event handlers adjust the display if in fact it starts up in landscape mode.

Silverlight 4 is Here!

jprosise — Sat, 17 Apr 2010 04:51:00 GMT

Silverlight 4 shipped this week, and you can download it along with all the tools you need to develop for it from the Silverlight Web site. Silverlight 4 represents a milestone of sorts in that it adds the features you need to build line-of-business (LOB) apps that run inside or outside the browser. Among the most exciting new features is support for "trusted applications" that run outside the browser and enjoy an expanded sandbox.

I blogged about Silverlight 4 a lot during the beta cycle and will be blogging more in weeks to come. Right now I'm in the middle of several weeks of travel (much of it international) and am so jet-lagged I can barely stay awake when I'm not at work!

In little more than a week, I'll be delivering a session on Silverlight 4 at Devscovery in New York. I would love to have you attend the session. Plus, Charles Petzold will deliver a special session on using Silverlight to develop for the Windows phone. I'll bet that session will be jam-packed, and I plan to be there early to secure a seat!

I have also agreed to deliver a Silverlight 4 precon at Microsoft TechEd in New Orleans in June. Help me make this session SRO by signing up to attend! The buzz around Silverlight is huge, and I have some cool code samples to share that exploit the very best features Silverlight 4 has to offer. I intend to have some cool phone samples ready, too, to make this the most exciting TechEd precon I've delivered in years.

See you in New York and New Orleans!

Asynchronous Controllers in ASP.NET MVC 2

jprosise — Mon, 29 Mar 2010 19:19:00 GMT

I've been working with version 2 of Microsoft's ASP.NET MVC framework and have found a lot to like about it, particularly the new support for client-side validation based on data annotations. But the feature that excites me the most is support for asynchronous controllers and controller methods. Asynchronous pages have always been the secret to writing ASP.NET apps that scale, and now we can apply the same asynchronous magic to I/O-bound methods in our MVC controllers, too.

As an example, suppose you have a simple controller with a synchronous action method that reaches out to Abcnews.com to fetch an RSS feed containing top news stories:

public class HomeController : Controller

{

public ActionResult Index()

{

RssFeed feed = new RssFeed();

IEnumerable<SyndicationItem> items =

feed.GetRssFeed("http://feeds.abcnews.com/abcnews/topstories");

ViewData["SyndicationItems"] = items;

return View();

}

The Index view could then render the SyndicationItems into hyperlinks by doing this:

<% foreach (SyndicationItem item in

(IEnumerable<SyndicationItem>)ViewData["SyndicationItems"]) { %>

<% } %>

The problem with this approach is that once the call to Abcnews.com goes out on the wire, you have no control over how long it will take to return. If the controller is synchronous, the request-processing thread must wait for the call to complete. Meanwhile, it's not available to process other calls, and with a finite-sized CLR thread pool to draw from, you can quickly run out of threads.

Asynchronous controllers offer an elegant and (relatively) simple solution to the problem of I/O-bound threads. In MVC 2, you can rewrite the controller this way:

public class HomeController : AsyncController

{

public void IndexAsync()

{

AsyncManager.OutstandingOperations.Increment();

RssFeed feed = new RssFeed();

feed.GetRssFeedAsyncCompleted += (s, e) =>

{

AsyncManager.Parameters["items"] = e.Items;

AsyncManager.OutstandingOperations.Decrement();

};

feed.GetRssFeedAsync("http://feeds.abcnews.com/abcnews/topstories");

}

public ActionResult IndexCompleted(IEnumerable<SyndicationItem> items)

{

ViewData["SyndicationItems"] = items;

return View();

}

Observe that the controller class now derives from AsyncController rather than Controller. In addition, the Index action method has been split into methods named IndexAsync and IndexCompleted, which are analagous to the Begin and End methods in asynchronous pages. Logically, the controller still exposes a single action method named Index. But physically, the method implementation has been broken up using a variation on the async pattern used throughout the .NET framework.

When the Index action is invoked, the MVC framework calls IndexAsync. That method makes an asynchronous call into the model (note that it now calls GetRssFeedAsync rather than GetRssFeed) to fetch the RSS feed asynchronously. When GetRssFeedAsync completes, the controller first creates the parameter passed to IndexCompleted by adding an item named "items" to AsyncManager's Parameters collection. Then it calls AsyncManager.OutstandingOperations.Decrement to reduce the count of "outstanding operations" (read: asynchronous tasks) from 1 to 0. When the count reaches 0, AsyncManager knows that all asynchronous tasks are complete. It responds by letting the framework know, and the framework responds by calling IndexCompleted. One aspect of this schema is that an asynchronous action method could launch several asynchronous tasks in parallel, but the action itself wouldn't complete until all asynchronous tasks are complete. Moreover, the asynchronous tasks don't have to know about one another. Each tasks simply does its thing, decrements the operation count when it's done, and lets the framework do the rest.

These code samples come from a project that I created to demonstrate the basics of asynchronous MVC controllers. Here's the application running in IE and showing the day's top headlines from a live RSS feed:

But rather than take my word for it, download the sample code and try it yourself!

Silverlight 4's New INavigationContentLoader Interface

jprosise — Mon, 08 Feb 2010 13:37:00 GMT

One of the extensibility points added to the run-time in Silverlight 4 is the new INavigationContentLoader interface, which allows applications that use Silverlight's navigation framework to take control of page loading. In Silverlight 3, navigation URIs had to target XAML files containing Silverlight pages. In Silverlight 4, a navigation URI can target anything—a class name, a Web service that provides page content dynamically, or a XAML file contained in a remote XAP, for example—as long as an INavigationContentLoader implementation is present to support it.

David Poll has blogged extensively about INavigationContentLoader and about the different scenarios in which it can be used. Here, for example, is a great post on using a custom content loader to load pages from XAPs that are downloaded on demand. Here's another that demonstrates how to use a custom content loader to authorize access to a page before navigating to it. It seems there is no end to the purposes that INavigationContentLoader might serve.

To demonstrate the bare-bones basics of INavigationContentLoader, I implemented one that serves a simple purpose: it appends ".xaml" to the file names of the pages targeted by navigation URIs. Rather than declare your Frame control and URI mappings this way:

<nav:Frame x:Name="Main" Source="Home">

<nav:Frame.UriMapper>

<map:UriMapper>

<map:UriMapping Uri="" MappedUri="/Index.xaml" />

<map:UriMapping Uri="Home" MappedUri="/Index.xaml" />

<map:UriMapping Uri="Detail/{id}" MappedUri="/Detail.xaml?id={id}" />

</map:UriMapper>

</nav:Frame.UriMapper>

</nav:Frame>

With my CustomContentLoader class, you do it this way instead:

<nav:Frame x:Name="Main" Source="Home">

<nav:Frame.UriMapper>

<map:UriMapper>

<map:UriMapping Uri="" MappedUri="/Index" />

<map:UriMapping Uri="Home" MappedUri="/Index" />

<map:UriMapping Uri="Detail/{id}" MappedUri="/Detail?id={id}" />

</map:UriMapper>

</nav:Frame.UriMapper>

<nav:Frame.ContentLoader>

<local:CustomContentLoader />

</nav:Frame.ContentLoader>

</nav:Frame>

Note the new ContentLoader property on the Frame control, which allows you to replace Silverlight's default content loader with a custom content loader. The default content loader is an instance of PageResourceContentLoader, which loads pages from local XAML files. My CustomContentLoader wraps an instance of PageResourceContentLoader and appends ".xaml" to target URIs before delegating to PageResourceContentLoader to do the actual loading. Here's the source code:

public class CustomContentLoader : INavigationContentLoader

{

private PageResourceContentLoader _loader = new PageResourceContentLoader();

public IAsyncResult BeginLoad(Uri targetUri, Uri currentUri,

AsyncCallback userCallback, object asyncState)

{

return _loader.BeginLoad(AddFileNameExtension(targetUri),

currentUri, userCallback, asyncState);

}

public bool CanLoad(Uri targetUri, Uri currentUri)

{

return _loader.CanLoad(AddFileNameExtension(targetUri), currentUri);

}

public void CancelLoad(IAsyncResult asyncResult)

{

_loader.CancelLoad(asyncResult);

}

public LoadResult EndLoad(IAsyncResult asyncResult)

{

return _loader.EndLoad(asyncResult);

}

private Uri AddFileNameExtension(Uri uri)

{

int index = uri.OriginalString.IndexOf('?');

if (index == -1) // No query string; append extension

return new Uri(uri.OriginalString + ".xaml", UriKind.Relative);

else // Insert extension before query string

return new Uri(uri.OriginalString.Insert(index, ".xaml"), UriKind.Relative);

}

Note the asynchronous design of INavigationContentLoader. When you implement it, you often have to implement IAsyncResult, too. I didn't have to in CustomContentLoader because I used the IAsyncResult returned by PageResourceContentLoader. While the asynchronous design complicates matters when writing a synchronous loader, it's perfect for content loaders that load pages using Silverlight's asynchronous networking stack.

This is a trivial example, but it still demonstrates the power of INavigationContentLoader. The upshot is that in Silverlight 4, navigation URIs no longer have to target local XAML files, but can be virtualized instead. Look for this to come in handy not only for application developers, but for future versions of Silverlight as well.

Silverlight 4's New Notification Windows

jprosise — Sat, 09 Jan 2010 13:44:00 GMT

Silverlight 4 includes a slew of features designed to make out-of-browser applications richer. One of those features is notification windows, also known as “toast” windows. This feature is available to all OOBs, regardless of whether they are trusted. It is not available to applications that run inside the browser.

A notification window is one that pops up in the lower right corner of the screen, similar to the ones that Outlook uses to notify users about incoming e-mails. (On the Macintosh, notification windows appear at the top of the screen rather than the bottom.) Notification windows are normally used to let the user know something important has happened. A classic use for them is to inform the user that an updated version of an out-of-browser application is available when the OOB is launched from the desktop or Start menu:

This notification window was created by first declaring a user control named UpdateNotification that contained the following content:

<Border.Background>

<LinearGradientBrush StartPoint="0.5,0.0"

EndPoint="0.5,1.0">

</LinearGradientBrush>

</Border.Background>

<Border.Effect>

<DropShadowEffect BlurRadius="4" ShadowDepth="4"

Opacity="0.4" />

</Border.Effect>

<TextBlock Text="Update Available" FontSize="12"

FontWeight="Bold" Foreground="White" Margin="4" />

</Border>

<Image Source="Images/Update.png" Width="32" Height="34"

Stretch="Fill" Margin="4" VerticalAlignment="Top" />

<TextBlock Width="240" Text="An updated version..."

FontSize="11" Foreground="#FF202020" TextWrapping="Wrap"

Margin="4" />

</StackPanel>

</Border>

</Grid>

Then it was displayed by creating an instance of System.Windows.NotificationWindow, instantiating the user control and assigning it to the NotificationWindow’s Content property, and calling NotificationWindow.Show:

NotificationWindow win = new NotificationWindow();

UpdateNotification un = new UpdateNotification();

win.Width = un.Width;

win.Height = un.Height;

win.Content = un;

win.Show(10000);

The parameter passed to NotificationWindow.Show is a time-out parameter that specifies how long the notification window will be displayed—in this case, 10 seconds. If desired, you can call NotificationWindow.Close to close the notification window early—for example, in response to a mouse click.

Another new feature available only to OOBs is the ability to interact with host windows. In Silverlight 3, out-of-browser applications had limited control over their environment. It was not possible, for example, for an OOB to resize the window in which it was hosted.

This changes in Silverlight 4 with the addition of the System.Windows.Window class and the new Application.MainWindow property. An out-of-browser application can get a reference to its window through the MainWindow property, and it can use Window properties and methods to interrogate and even modify the host window. The following code snippet resizes the host window programmatically:

Window win = Application.Current.MainWindow;

win.Width = 1024;

win.Height = 768;

The Window class also features properties named Left and Top for repositioning host windows, WindowState for minimizing, maximizing, and restoring host windows, and TopMost for controlling the host window’s topmost state. And it includes an Activate method for bringing a host window to the foreground and assigning it the focus.

Silverlight 4's New Managed Extensibility Framework

jprosise — Mon, 04 Jan 2010 14:46:00 GMT

One of the less-talked-about features of Silverlight 4 is the new Managed Extensibility Framework, or MEF. MEF has been evolving on CodePlex for a while now. It's slated to be integrated into .NET 4.0 and Silverlight 4, and as such is something with which developers should be familiar.

As its name implies, MEF is a framework for building extensible applications. It provides infrastructure for loose coupling between components and can be used to create composable applications—apps that pull together "parts" from various locations to compose an aggregate to present to the user. One of the key concepts in MEF is that of the catalog, which tells MEF where to look for parts that make up an application. An application can import parts from the catalog with [Import] attributes, and parts themselves can use [Export] attributes to expose themselves to importers. That's the big picture, and of course it ignores hundreds of little details, but understanding these core concepts is a big help in understanding MEF as a whole.

To demonstrate how Silverlight developers might use MEF in a somewhat real-world scenario, I built a sample application named MEFDemo, which you can download from Wintellect's Web site. MEFDemo is an extensible Silverlight 4 image editor. You load photos into it through an OpenFileDialog, and then you click buttons to apply filters of various types to the photos. Here's MEFDemo showing a photo I snapped in the Vatican a few years ago:

And here's how it looked after I clicked the Blur button a few times and then embossed the image:

Out of the box, MEFDemo offers three image filters: a grayscale filter, a blur filter, and an embossing filter. Because the filters are MEF plug-ins, you can easily write filters of your own and plug them into the application.

One of the filters—the grayscale filter—is embedded in the main application. It's found in GrayscaleFilter.cs and it implements an interface named IImageFilter:

public class GrayscaleFilter : IImageFilter

{

public string Label

{

get { return "Grayscale"; }

}

public void Execute(WriteableBitmap bitmap)

{

...

}

IImageFilter is defined a separate project named ImageFilterContract and is decorated with an [InheritedExport] attribute, which means all types that implement the interface should be exported by MEF:

[InheritedExport]

public interface IImageFilter

{

void Execute(WriteableBitmap bitmap);

string Label { get; }

}

The other two filters are exported from a separate project named ConvolutionFilters. Because the project type is Silverlight Application, not Silverlight Class Library, building the solution places two XAP files in the Web site's ClientBin folder: MEFDemo.xap, which contains the main application, and ConvolutionFilters.xap, which contains BlurFilter and EmbossFilter. These filters, too, implement IImageFilter and are automatically exported from the XAP as a result of the [InheritedExport] attribute.

In MEF terminology, the exported image filters are "parts." Which begs the question: how and where do the parts get imported?

Look in MainPage.xaml.cs and you'll find the following property declaration:

[ImportMany(AllowRecomposition = true)]

public ObservableCollection<IImageFilter> Filters { get; set; }

The [ImportMany] attribute tells MEF to look for all exported parts that implement IImageFilter and to populate the ObservableCollection with references to those parts. In MainPage's constructor, a single line of code binds the ObservableCollection to an ItemsControl to produce buttons representing the imported image filters. The ItemsControl uses the following item template to create the buttons:

<ItemsControl.ItemTemplate>

<Button Content="{Binding Label}" Width="96" Height="32"

Margin="0,12,12,12" Tag="{Binding}" Click="OnExecuteFilter" />

</DataTemplate>

</ItemsControl.ItemTemplate>

The text on the face of each button comes from the associated image filter's Label property, and the Tag property holds an IImageFilter reference to the filter itself. When a button is clicked, it's a simple matter to retrieve the IImageFilter reference and use it to invoke the filter:

IImageFilter filter = (sender as Button).Tag as IImageFilter;

filter.Execute(_bitmap);

With MEF, we can export parts and we can import parts. But how does MEF know where to look for parts to satisfy our imports? The answer is found in MainPage's constructor:

// Create a catalog and add this XAP to it

PackageCatalog catalog = new PackageCatalog();

catalog.AddPackage(Package.Current);

// Download additional XAPs and add them to the catalog

Package.DownloadPackageAsync(new Uri("ConvolutionFilters.xap", UriKind.Relative),

(s, p) => catalog.AddPackage(p));

// Pass the catalog to the MEF and compose the parts

var container = new CompositionContainer(catalog);

container.ComposeParts(this);

The first line creates a package catalog. The second line adds the current package (MEFDemo.xap) to the catalog, which allows MEF to find the GrayscaleFilter class exported from MEFDemo.xap. The third line initiates an asynchronous download of ConvolutionFilters.xap and adds it to the catalog when the download completes. This allows MEF to find the BlurFilter and EmbossFilter classes in that XAP. Adding image filters to the application is as simple as placing additional XAP files containing the filters in ClientBin and adding one line of code per XAP to download the package and add it to the catalog. Once filters are exported and added to the catalog, buttons representing them will automatically show up in the UI.

This example demonstrates the basics of MEF, but it could go even further. For example, MEF allows you to attach metadata to parts, and to read that metadata without instantiating the parts. Rather than use a Label property to expose text for buttons, image filters could use metadata instead. Glenn Block of Microsoft discusses metadata and lazy loading of imported types in Building Hello MEF Part II. Glenn's blog is a great source of information on MEF, as is Jeremy Likness's blog, which is currently exploring the integration of MEF and Prism. In addition, Mike Taulty has posted a great series of video tutorials on Silverlight MEF on Channel 9.

MEF makes composability a first-class citizen in Silverlight, and it's going to be interesting to see how much of an impact it has on Silverlight design and development. One thing's for sure: there has never been a more exciting time to be a Silverlight programmer!

Silverlight 4's New HTML Hosting Support

jprosise — Tue, 22 Dec 2009 17:12:00 GMT

Another of the new capabilities that Silverlight 4 brings to the platform is the ability to host HTML content inside a Silverlight control. This support isn't limited to static HTML content; the content can be interactive and can include script. It can even be Flash content or content that includes other Silverlight controls.

To host HTML content in Silverlight, you can use either a WebBrowser control or an HtmlBrush. One way to display HTML content is to fire up a WebBrowser control and point it to a URL:

Another way to do it is to call NavigateToString and pass a string of content to the WebBrowser control:

WebBrowserControl.NavigateToString("<h1>Hello, Silverlight</h1>");

HTML hosting is not available to in-browser apps (it applies to out-of-browser applications only), and if an OOB lacks elevated permissions, it can only display content that comes from the same domain as the Silverlight application. However, you can use a little trick to display cross-domain content in OOBs that run without elevated permissions—simply pass an IFRAME targeting the remote content to NavigateToString:

WebBrowserControl.NavigateToString("<iframe src=\"http://www.bing.com\" style=\"width: 100%; height: 100%\"></iframe>");

You can render HTML content with HtmlBrush, too. The following XAML snippet paints a Rectangle with content retrieved from Bing:

<Rectangle.Fill>

</Rectangle.Fill>

</Rectangle>

One difference between WebBrowser and HtmlBrush is that the former displays "live" content, while the latter does not. Another difference is that HtmlBrush can have transforms applied to it, while WebBrowser cannot. For snazzy visual effects involving HTML content like the HTML puzzle demoed at the PDC, you'll probably find yourself using HtmlBrush. To display live, interactive content, you'll find WebBrowser more useful instead.

One of the really cool things about the WebBrowser control is that you can use its InvokeScript method to call JavaScript functions in content hosted by the control. Conversely, JavaScript hosted inside a WebBrowser control can use window.external.Notify to raise ScriptNotify events that can be handled in C#.

To demonstrate why this might be useful (and how it works), I built a sample application that plays YouTube video using YouTube's API player and that uses the player's JavaScript API to drive the video playback from C#. The application runs as an OOB and requires elevated permissions:

The video that plays in the application is one I uploaded to YouTube; it shows one of my RC jets getting a workout at a recent jet meet near Atlanta, GA. You can download the app and install it on your PC to try it out. Don't forget that it has to run outside the browser.

The application uses a WebBrowser control to host the YouTube player. The content is stored in a text file packaged as a loose file inside the XAP file. It's extracted from the XAP with Application.GetResourceStream and passed to the WebBrowser control via NavigateToString:

// Read the HTML content from the XAP

StreamResourceInfo sri = Application.GetResourceStream

(new Uri("YouTubePlayer.txt", UriKind.Relative));

StreamReader reader = new StreamReader(sri.Stream);

string content = reader.ReadToEnd();

// Feed the content to the WebBrowser control

Player.NavigateToString(content);

The content itself includes a mix of HTML and JavaScript (mostly JavaScript). The script instantiates the YouTube player, forwards certain events from the player to the application so they can be handled in C#, and provides a thin JavaScript API layer that the application calls via InvokeScript to control playback of the video. For example, when the user clicks the Play, Pause, and Stop buttons, the application uses InvokeScript to call script funtions named play, pause, stop, and cue:

private void OnPlay(object sender, RoutedEventArgs e)

{

Player.InvokeScript("play");

}

private void OnPause(object sender, RoutedEventArgs e)

{

Player.InvokeScript("pause");

}

private void OnStop(object sender, RoutedEventArgs e)

{

Player.InvokeScript("stop");

Player.InvokeScript("cue", "df6x4U0u7iQ");

}

Similarly, when the state of the player changes—for example, when video playback begins or ends—script inside the control uses window.external.Notify to fire a ScriptNotify event in C# and activate a handler that updates the visual states of the buttons:

function onYouTubePlayerStateChange(state) {

// Ask the Silverlight control to update the YouTube video player

var state = document.getElementById("apiplayer").getPlayerState();

window.external.Notify('Update:' + state.toString());

}

The end result is an application that demonstrates key features of the WebBrowser control and does something interesting, too. Merry Christmas and Happy Holidays!

Silverlight's Big Image Problem (and What You Can Do About It)

jprosise — Thu, 17 Dec 2009 17:46:00 GMT

Quick: Can you spot the problem with these three lines of code?

BitmapImage bi = new BitmapImage();

bi.SetSource(stream);

TheImage.Source = bi;

These statements create an image from a stream of PNG or JPG image bits and display the image by assigning it to a XAML Image object named TheImage. It's boilerplate code used to display images read from the local file system or obtained from a service. And while there's nothing inherently wrong with the code itself, you'll want to think carefully before including it in any Silverlight application.

I call it "Silverlight's Big Image Problem." Not the kind of image problem a movie star might suffer, but an inherent memory-consumption problem when dealing with large bitmap images in Silverlight.

The problem manifests itself when you handle large images in large numbers. The My Pictures Viewer that I blogged about yesterday is a case in point. When a user running the application selects a folder containing one or more image files, the viewer displays clickable thumbnail versions of the images. The problem is that because Silverlight's BitmapImage class consumes massive amounts of memory (up to 40 or 50 MB per image for a typical 2 to 3 MB digital photo), you simply can't have too many instances extant at once. But to create a thumbnail, you first need a BitmapImage that wraps the entire image. You might create a thumbnail by assigning the BitmapImage to an Image object that measures just 100 by 100 pixels, but if the original image measures 4,000 by 4,000 pixels, it's the latter figure you pay the price for.

To demonstrate, I wrote a simple test harness that you can easily duplicate yourself. I began with an app that pops up an OpenFileDialog and lets the user select an image file from his or her hard disk. Once the image file is selected, the application generates a thumbnail version of the image and adds it to the scene. Then it generates another thumbnail, and then another, and so on and so forth until Silverlight throws an out-of-memory exception. Here is the helper method that I initially used to generate the thumbnails:

private Image CreateThumbnailImage(Stream stream, int width)

{

BitmapImage bi = new BitmapImage();

bi.SetSource(stream);

double cx = width;

double cy = bi.PixelHeight * (cx / bi.PixelWidth);

Image image = new Image();

image.Width = cx;

image.Height = cy;

image.Source = bi;

return image;

}

And here's what happened when I ran the application and selected a 3,648 x 2,736 JPG with a file size of 2.1 MB:

So get this. The application created 26 thumbnails, each measuring a mere 100 x 75 pixels. But attempting to create a 27th thumbnail produced an out-of-memory exception. When the exception occurred, Task Manager showed that the process's working set size had grown from 30 MB to nearly 1.5 GB! It seems crazy on the surface, because a full-color 100 x 75 image should only require about 30K of memory. But it makes a lot more sense when you realize that underlying each thumbnail is a gigantic BitmapImage that retains the full fidelity of the 3,648 x 2,736 original.

The obvious question is what do you do about it? Is there a way to efficiently create thumbnail images from streams of image bits in Silverlight? It's a question that pops up time and again in discussion forums and on message boards. And the short answer is yes, there is a way. But the answer probably isn't the one you expect.

Developers commonly attempt a solution along these lines:

private Image CreateThumbnailImage(Stream stream, int width)

{

BitmapImage bi = new BitmapImage();

bi.SetSource(stream);

double cx = width;

double cy = bi.PixelHeight * (cx / bi.PixelWidth);

Image image = new Image();

image.Source = bi;

WriteableBitmap wb = new WriteableBitmap((int)cx, (int)cy);

ScaleTransform transform = new ScaleTransform();

transform.ScaleX = cx / bi.PixelWidth;

transform.ScaleY = cy / bi.PixelHeight;

wb.Render(image, transform);

wb.Invalidate();

Image thumbnail = new Image();

thumbnail.Width = cx;

thumbnail.Height = cy;

thumbnail.Source = wb;

return thumbnail;

}

The basic idea is that instead of creating a thumbnail by assigning a large BitmapImage to a small Image, you use WriteableBitmap.Render with a ScaleTransform to create a thumbnail, and then assign the WriteableBitmap to an Image. Meanwhile, the BitmapImage and the Image it was temporarily assigned to—the one passed to WriteableBitmap.Render—go out of scope and are eventually picked up by the garbage collector.

It works well in theory, but not so well in practice, thanks to an undocumented behavior of WriteableBitmap. In fact, when I plugged the revised CreateThumbnailImage method into my test harness, the application ran out of memory just as quickly as before.

The problem, it turns out, is that when you call WriteableBitmap.Render, WriteableBitmap apparently retains a reference to the XAML object passed in the first parameter. (I was stumped, too, until Jeffrey Richter and I did a little detective work and discovered what was happening under the hood. Jeffrey's my go-to guy for CLR issues, and I'm not sure I would have ever figured this out without him asking the right questions and suggesting solutions.) When CreateThumbnailImage returns an Image holding a reference to a WriteableBitmap, and the WriteableBitmap holds a reference to an Image, and the Image holds a reference to a BitmapImage, none of these objects gets garbage-collected. It seems that WriteableBitmap does nothing to solve the problem, especially given that there's no public method or property you can use to force the WriteableBitmap to release the reference.

But all is not lost. You can make a copy of the WriteableBitmap and assign it to the Image you return. And since you didn't call Render on the copy, it doesn't hold a reference to an Image that prevents the garbage collector from cleaning up the BitmapImage. Here is the fixed and final version of CreateThumbnailImage—this time, one that accomplishes what we set out to do:

private Image CreateThumbnailImage(Stream stream, int width)

{

BitmapImage bi = new BitmapImage();

bi.SetSource(stream);

double cx = width;

double cy = bi.PixelHeight * (cx / bi.PixelWidth);

Image image = new Image();

image.Source = bi;

WriteableBitmap wb1 = new WriteableBitmap((int)cx, (int)cy);

ScaleTransform transform = new ScaleTransform();

transform.ScaleX = cx / bi.PixelWidth;

transform.ScaleY = cy / bi.PixelHeight;

wb1.Render(image, transform);

wb1.Invalidate();

WriteableBitmap wb2 = new WriteableBitmap((int)cx, (int)cy);

for (int i = 0; i < wb2.Pixels.Length; i++)

wb2.Pixels[i] = wb1.Pixels[i];

wb2.Invalidate();

Image thumbnail = new Image();

thumbnail.Width = cx;

thumbnail.Height = cy;

thumbnail.Source = wb2;

return thumbnail;

}

When I plugged this implementation into my test harness, it successfully created hundreds of thumbnails (and could have created hundreds, perhaps thousands, more) without significantly increasing the working set size—and without throwing out-of-memory exceptions.

The moral is that you should be very careful about how you use BitmapImage in Silverlight. Even one of them can swell the working set size dramatically, but a couple dozen of them wrapping digital photographs is more than most PCs can handle. With a little care, however, you can scale down the impact of BitmapImage so that memory consumption is proportional to the sizes of the images you're displaying rather than the sizes of the original, unreduced images. And that, in the end, is a handy arrow to have in your arsenal.

Silverlight 4's New Local File System Support

jprosise — Wed, 16 Dec 2009 19:56:00 GMT

In my last blog post, I wrote about Silverlight 4 applications that run outside the browser with elevated permissions and their ability to leverage COM automation servers on the host PC. Another privilege that applications with elevated permissions—also known as "trusted apps"—enjoy is the ability to access parts of the local file system without prompting the user with an OpenFileDialog or SaveFileDialog. This feature opens the door to types of applications that simply weren't possible with Silverlight 3.

File access is limited to certain locations on the hard disk: primarily the "My" folders such as My Documents, My Pictures, and My Music. But within those constraints, file system access works pretty much the same in Silverlight as it does in .NET. You generally begin by calling Environment.GetFolderPath to acquire a path to the folder you wish to access. The following code snippet enumerates the files in My Documents and stuffs the file names into a ListBox named FileList:

string path = Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments);

foreach (string file in Directory.EnumerateFiles(path))

{

FileList.Items.Add(file.Substring(file.LastIndexOf('\\') + 1));

}

Of course, you're not limited to enumerating files. You can open files, create files, and delete files, and you can do the same with directories. Plus, there's no limit on the amount of data you can write to the hard disk since the user okayed the elevated permissions when the application was installed.

To demonstrate Silverlight file access in action, I wrote the My Pictures Viewer pictured below. When started, it populates a TreeView control with all the folders and subfolders in your My Pictures directory. You can expand and collapse branches of the tree, and when you select a folder, the right half of the window is populated with thumbnail images of all the PNGs and JPGs in that directory. You can then click a thumbnail to see a close-up of the picture in a child window. Click the picture (or the X in the child window's upper right corner) to close the child window and continue photo browsing.

You can download the source code and try it for yourself. Run the application once in your browser and right-click it to install it as an out-of-browser application. Once the viewer is running outside the browser, you can begin browsing pictures.

The code to populate the TreeView with folder names looks like this:

if (Application.Current.HasElevatedPermissions)

{

string path = Environment.GetFolderPath(Environment.SpecialFolder.MyPictures);

foreach (string dir in Directory.EnumerateDirectories(path))

{

TreeViewItem item = new TreeViewItem();

item.Header = dir.Substring(dir.LastIndexOf('\\') + 1);

DirectoryTree.Items.Add(item);

ProcessFolder(dir, item.Items);

}

ProcessFolder is a recursive method that's implemented this way:

private void ProcessFolder(string path, ItemCollection items)

{

foreach (string dir in Directory.EnumerateDirectories(path))

{

TreeViewItem item = new TreeViewItem();

item.Header = dir.Substring(dir.LastIndexOf('\\') + 1);

items.Add(item);

ProcessFolder(dir, item.Items);

}

Perhaps the most interesting part of the source code is how it generates thumbnail images. It uses a BitmapImage to decode each image file. Then it assigns the BitmapImage to an Image object, uses WriteableBitmap.Render with a ScaleTransform to generate a thumbnail, and then, strangely enough, makes a copy of the WriteableBitmap in another WriteableBitmap. The second WriteableBitmap is the one that's ultimately assigned to an Image object to display the thumbnail on the screen.

At first glance, this may appear gratuitous. Why not just assign the BitmapImage created from the image file directly to the Image that displays the thumbnail on the screen? Furthermore, why go to the trouble of making a copy of the WriteableBitmap? The short answer is that I did it this way to avoid out-of-memory exceptions, which are all too common in Silverlight applications that display digital photos. In fact, I'm planning a follow-up blog post that covers this in detail. Stay tuned.

Silverlight 4's New COM Automation Support

jprosise — Mon, 14 Dec 2009 16:47:00 GMT

One of Silverlight 4's most compelling new features is support for out-of-browser applications with elevated permissions. An app running with elevated permissions can perform actions that a normal sandboxed application can not. For example, it can access the local file system, and on Windows boxes, it can interact with COM automation servers. This latter feature—also new to Silverlight 4—is the subject of this blog post.

Silverlight 4's ComAutomationFactory class provides an API for instantiating COM automation objects and for determining whether COM automation is available. (It's not available if the app is running without elevated permissions, or if it's running on a Macintosh.) And C# 4.0's new dynamic keyword provides a means for interacting with automation objects, which by definition are late-bound (meaning they expose features to clients using an IDispatch interface).

One practical example of what you can do with Silverlight's COM automation support is sending an e-mail message via Outlook. The following sample does just that:

dynamic outlook = ComAutomationFactory.CreateObject("Outlook.Application");

dynamic mail = outlook.CreateItem(0);

mail.Recipients.Add("webmaster@contoso.com");

mail.Subject = "Hello, Silverlight";

mail.Body = "This message was sent from Silverlight 4";

mail.Save();

mail.Send();

The code is exceedingly simple and it works just fine if Outlook is installed on the client and the user OKs the prompt from Outlook warning that an external application is attempting to use it. For added robustness, you should catch the System.Exception thrown from ComAutomationFactory.CreateObject if object creation fails. That's exactly what will happen if Outlook isn't installed on the host PC.

For fun, I wrote a downloadable demo that uses Microsoft's speech automation server to verbalize error messages. (I definitely wouldn't recommend using this in a production application because it is quite annoying, but it's just novel enough to get a few laughs from your friends.) Here's how the application looks when it's running:

If you click a button while the application is running inside the browser or outside the browser but without elevated permissions, the error message encapsulated in the ensuing exception is displayed in a message box. However, if you do the same with the application running with elevated permissions outside the browser, a friendly voice reads the error message out loud. Nothing calls attention to a null reference exception like a female voice informing you "Object reference not set to an instance of an object." For added fun, you could append "I'm sorry, Dave; I'm afraid I can't do that" to every error message.

When the application starts up, it attempts to instantiate the speech server and assign a reference to a local field:

if (ComAutomationFactory.IsAvailable)

{

try

{

_speech = ComAutomationFactory.CreateObject("Sapi.SpVoice");

}

catch (Exception) { }

}

Then, when an exception is thrown, it forwards the exception to a helper method named NotifyException, which verbalizes the error message if possible or displays it in a message box if not:

private void NotifyException(Exception ex)

{

if (_speech != null)

_speech.Speak(ex.Message);

else

MessageBox.Show(ex.Message);

}

If you install the application locally and OK its request for elevated permissions, you should hear (rather than see) the error messages. How's that for an error UI? :-)

Silverlight 4's New Commanding Support

jprosise — Tue, 01 Dec 2009 02:33:00 GMT

One of the exciting new features in the Silverlight 4 beta is a pair of properties added to the ButtonBase and Hyperlink classes named Command and CommandParameter. These properties represent the first real support in Silverlight for commanding, which is primarily beneficial to to Model-View-ViewModel (MVVM) applications. MVVM has long been popular among WPF developers and is rapidly gaining popularity with Silverlight developers. And now, thanks to commanding, Silverlight comes a little closer to supporting pure MVVM implementations without help from auxiliary frameworks such as Prism.

To demonstrate Silverlight 4's new commanding infrastructure, I took a sample that I originally wrote to show how to consume RSS in Silverlight. You type an RSS URL into a TextBox and click the "View" button. The app uses a WebClient to fetch the RSS feed, and then renders the feed items into a ListBox using data binding:

I then rewrote the app as an MVVM app and took advantage of commanding to move all the logic that used to appear in the code-behind to the view-model. You can download the source code to see how it works. Here are some of the highlights.

First, my model is implemented in the RssModel class. RssModel exposes a method named GetRssFeedAsync that the view-model can use to fetch a live RSS feed. It also implements a couple of events: an RssLoadComplete event that's fired following a successful RSS download, and an RssLoadError event that's fired if an RSS download fails. These methods and events are part of an interface named IRssProvider, which you could mock in a unit-testing scenario to provide RSS content from a local source rather than a network source.

Second, my view-model is implemented in a class named RssViewModel. Part of the intent of the view-model is to provide properties that the view can bind to to populate controls with data. To that end, RssViewModel exposes a string property named RssUri which can be bound to the TextBox in the view, and an ObservableCollection property named RssFeed that can be bound to the ListBox. It also implements a read-only ICommand property named GetRssFeed that returns an instance of a class named GetRssFeedCommand. This is where commanding enters the picture in Silverlight 4.

Open the code-behind file for the view (RssView.xaml.cs) and you'll see that it contains no code other than a constructor that calls InitializeComponent. In Silverlight 3, I would have had to include a handler for the button's Click command that calls into the view-model to fetch the RSS feed and stuff the RSS items into the RssFeed property. Thanks to the new commanding infrastructure in Silverlight 4, I was able to accomplish this declaratively. First, the view declares an instance of the view-model:

<UserControl.Resources>

<local:RssViewModel x:Key="RssViewModel" />

</UserControl.Resources>

Then it binds the view-model to the DataContext property of the Grid that contains the TextBox, ListBox, and Button:

The TextBox's Text property and the ListBox's ItemsSource property are bound to the view-model's RssUri and RssFeed properties:

More importantly, the Button is bound to the view-model this way:

Observe that the Button declaration doesn't contain a Click attribute; in other words, the Click event isn't bound to an event handler in the code-behind. Instead, when the button is clicked, it invokes the command exposed through the view-model's GetRssFeed property. That command is implemented this way:

public class GetRssFeedCommand : ICommand

{

private IRssProvider _model;

private ObservableCollection<SyndicationItem> _feed;

public GetRssFeedCommand(ObservableCollection<SyndicationItem> feed, IRssProvider model)

{

_feed = feed;

_model = model;

}

public event EventHandler CanExecuteChanged;

public bool CanExecute(object parameter)

{

return true;

}

public void Execute(object parameter)

{

_model.RssLoadComplete += new EventHandler<RssEventArgs>(OnRssLoadComplete);

_model.GetRssFeedAsync(new Uri((string)parameter, UriKind.Absolute));

}

void OnRssLoadComplete(object sender, RssEventArgs e)

{

if (_feed != null) // Just to be sure

{

_feed.Clear();

using (XmlReader reader = XmlReader.Create(e.Result))

{

SyndicationFeed feed = SyndicationFeed.Load(reader);

foreach (SyndicationItem item in feed.Items)

_feed.Add(item);

}

At run-time, invoking the command causes its Execute method to be called, and the command responds by using the model to fetch the RSS feed and parsing the feed items into the view-model's RssFeed property. Thanks to the data binding between that property and the ListBox, and because RssFeed is an ObservableCollection, the items promptly appear in the ListBox.

The binding between the Button and the view-model's GetRssFeed property is possible because of the Command property added to the Button class (actually, to ButtonBase) in Silverlight 4. In addition, Button now contains a CommandParameter property that can be used to pass a parameter to the command. In this example, CommandParameter is bound to the view-model's RssUri property, which ensures that the URL typed by the user is available to the command when the command is invoked.

The upshot of all this is that Command and CommandParameter enabled me to build a pure MVVM implementation that wasn't possible in Silverlight 3 without outside help. It's not the final word in commanding—after all, Silverlight still lacks commanding support in other controls such as ListBox—but it's a step in the right direction. And it's indicative of the fact that the Silverlight team is listening to developers, because commanding, along with printing and support for webcams and other devices, is one of the features that developers lobbied for the most.