Sergio Loscialo's Blog

Working with PivotViewer and the CxmlCollectionSource

sloscialo — Mon, 17 Oct 2011 22:39:14 GMT

Microsoft’s PivotViewer control is an amazing tool for visualizing data and creating a unique UI for your application. The one issue everyone seems to have with it, however, is its lack of styling capability. In fact, working with PivotViewer in Expression Blend yields little in the way of styling or templating. There are only a few color settings one can make, and some generic overall changes. Replacing the filter panel or info panel is not currently supported.

What to do?

Since we cannot style the filter panel, we need to hide it and put our own in. Hiding the panel is relatively simple and straight-forward. Simply put, you need to subclass the PivotViewer and override the OnApplyTemplates() method, then walk the tree until you find the filter panel. Fortunately, tools like Snoop or Mole can help you determine where the filter panel resides. Below is a snippet of code showing where the filter panel resides in the Silverlight 5 version of the PivotViewer.

   1: public override void OnApplyTemplate()

   2: {

   3:     base.OnApplyTemplate();

4:

   5:     Grid partContainer = (Grid)this.GetTemplateChild("PART_Container");

   6:     CollectionViewerView cvv = ((CollectionViewerView)(partContainer).Children[2]);

   7:     Grid container = cvv.Content as Grid;

   8:     Border viewerBorder = container.Children[1] as Border;

   9:     Grid viewerGrid = viewerBorder.Child as Grid;

10:

  11:     // Filter Panel

  12:     viewerGrid.Children[2].Visibility = System.Windows.Visibility.Collapsed;

  13: }

NOTE: This is very brittle code and will most likely fail when Microsoft releases a new version of the PivotViewer.

Now that the filter panel is gone, we need to create our own. If you’re manually creating the facets and data in code, then you should have no trouble binding a new Filter control to your data structures. But what if you’re using the CxmlCollectionSource and loading your data from a cxml external file?

As anyone who’s worked with the CxmlCollectionSource can tell you, the facets and their filter values aren’t readily available for consumption. In order to build up a collection of facets and filters, you to perform a little preprocessing. The Items collection off the CxmlCollectionSource is the dataset you’re working with, however, getting values and properties for the items isn’t immediately apparent.

My solution was to create a small class to hold the facet information I required:

   1: public class Facet

   2: {

   3:     public string Category { get; set; }

   4:     public string Value { get; set; }

   5:     public bool IsChecked { get; set; }

   6: }

In order to iterate through the Items collection, you need to wait until the CxmlCollectionSource finishes processing the .cxml document. Since it occurs asynchronously, you can start your processing in the event handler for the StateChanged event. That can look something like this (I’m not implementing an MVVM pattern for simplicity’s sake. This is just part of the code-behind for the MainPage.xaml).

   1: void OnLoaded(object sender, RoutedEventArgs e)

   2: {

   3:     if (_cxml == null)

   4:     {

   5:         _cxml = new CxmlCollectionSource(new Uri(HtmlPage.Document.DocumentUri, "/Data/PivotViewerData.cxml"));

   6:         _cxml.StateChanged += CxmlStateChanged;

   7:     }

8:

   9:     return;

  10: }

11:

  12: void CxmlStateChanged(object sender, CxmlCollectionStateChangedEventArgs e)

  13: {

  14:     if (e != null && e.NewState == CxmlCollectionState.Loaded)

  15:     {

  16:         MyPivot.PivotProperties = _cxml.ItemProperties.ToList();

  17:         MyPivot.ItemTemplates = _cxml.ItemTemplates;

  18:         MyPivot.ItemsSource = _cxml.Items;

19:

  20:         ProcessFacets();

21:

  22:         this.DataContext = _facetData;

  23:     }

24:

  25:     _cxml.StateChanged -= CxmlStateChanged;

  26: }

The next step is to iterate over the Items of the CxmlCollectionSource and build a dictionary of Facets and their properties. The Items collection is a collection of PivotViewerItems that do not contain the actual values of the data elements. Instead, you need to call a method, GetPropertyValue(id) in order to get the list of properties that particular data elements contains.

The ProcessFacets() method below simply iterates over each item in the data set and determines which properties it contains that are filterable and what the acceptable values are for each. For example if your data has two filterable properties, such as “Ingredients” and “Serving Size”, these two facets could have a wide range of acceptable values for each data element. The call to GetPropertyValue for “Ingredients” for an particular item may return “Oil” and “Vinegar”, while another item may return “Milk”, “Oil” and “Peanuts.” The dictionary built by ProcessFacets will create a Key for “Ingredients” and add a List of four strings representing the four unique values.

I think it may be clearer just to read the code below:

   1: private void ProcessFacets()

   2: {

   3:     // Iterate through all the PivotViewerItems.

   4:     foreach (var item in _cxml.Items)

   5:     {

   6:         // Determine what Propeties it has that are filterable.

   7:         var facets = from f in item.Properties

   8:                      where

   9:                          (PivotViewerPropertyOptions.CanFilter ==

  10:                           (f.Options & PivotViewerPropertyOptions.CanFilter))

  11:                      select f;

12:

  13:         // For each facet, get its values.

  14:         foreach (var f in facets)

  15:         {

  16:             // create a new facet if it doesn't exist.

  17:             if (!_facetData.Facets.ContainsKey(f.Id))

  18:                 _facetData.Facets.Add(f.Id, new List<Facet>());

19:

  20:             // get the facet values.

  21:             var props = item.GetPropertyValue(f.Id);

22:

  23:             // there can be more than one value per facet.

  24:             foreach (var p in props)

  25:             {

  26:                 // don't add the same one more than once.

  27:                 if (!_facetData.Facets[f.Id].Any(o => o.Value.Equals(p)))

  28:                     _facetData.Facets[f.Id].Add(new Facet()

  29:                                                     {

  30:                                                         Category = f.Id,

  31:                                                         Value = p.ToString(),

  32:                                                         IsChecked = false

  33:                                                     });

  34:             }

  35:         }

  36:     }

  37: }

So, there you have it.

Armed with this data, you can now create your own filter panel and programmatically control the PivotViewer independently of the built-in panel. All you would need to do from this point on is write the Xaml for your Filter view and bind the Facet data to it. Finally, call SetViewerState on the PivotViewer and pass in the filter string built by your new view. Note, however, that the filter string is a mini-language of a sorts and will require some processing in code to generate the appropriate parameter. To get you started, I iterate over the dictionary like so:

   1: string[] filters = _facetData.Values

   2:   .SelectMany(facet => facet.Where(prop => prop.IsChecked))

   3:   .Select(prop => string.Format("{0}=EQ.{1}", prop.Category, prop.Value))

   4:   .ToArray();

5:

   6: string filterString = string.Join("&", filters.ToArray());

7:

   8: MyPivotViewer.SetViewerState(filters.Length > 0 ? filterString : "");

The PivotViewer is an extremely powerful tool to have in your arsenal, but it is not very customizable. With a small hack and some understanding of the data set, some of its limitations can be overcome. I hope this post gets you on the road to creating your own custom PivotViewer applications.

The Cascade Game: From Silverlight to HTML5 (part 2)

sloscialo — Thu, 15 Sep 2011 22:02:36 GMT

Game Loops and Timer-Based Animations

Previous Entries in Series

Part 1 – Introduction and Game Layout

My next short term goal was to get some of spheres to show and animate. And that was going to entail using HTML5’s new <canvas> tag. I saw two ways of going about animating the spheres. The first way would be to manually draw the spheres on a single canvas and animate them by clearing the canvas and redrawing at every game cycle. The second way would be to create a separate canvas for each sphere and use CSS3 to animate them. The latter method would allow the GPU to help accelerate the graphics processing and seems to be the best choice for animations of this type in HTML5 (see this blog entry from Jeff Prosise).

In the Silverlight version of this game, I created several classes that managed the spheres, levels, scores, and whatnot. I wanted to mimic that structure as closely as possible in Javascript to make the conversion less painful. Since Javascript doesn’t really have any type-safety without writing a lot of support code, I knew this task was going to be a bit frustrating until I became re-acclimated to Javascript again (I confess, it’s been some time).

As in the Silverlight version of the game, I’m going to rely on a game timer to run my main game loop. In Silverlight I used a simple DispatcherTimer to control the animation. In HTML/Javascript, there aren’t too many choices: setInterval and setTimeout. The setInterval method will execute a callback at a specified interval, while setTimeout will execute a callback in a specified time span. In essence, setInterval will continue running the callback while setTimeout will run it once. In the setTimeout methodology, the callback will usually call setTimeout again in order to keep the animation timer going. Both these animation techniques have been in use for a long time…and they both suffer from performance issues. Namely, they continually run whether or not the tab containing the HTML page is visible or not.

The solution in HTML5 is to use the new requestAnimationFrame method. However, this API is still in the development stages and is not supported by all modern browsers (once again Internet Explorer 9.0 falls behind, but the API is supported in IE 10). Paul Irish has a very good explanation and a workable fallback routine that I will be using for Cascade Html5.

The animation heart of Cascade looks essentially like most traditional game loops, like this:

   1: window.requestAnimFrame = (function () {

   2:     return window.requestAnimimationFrame ||

   3:            window.webkitRequestAnimationFrame ||

   4:            window.mozRequestAnimationFrame ||

   5:            window.oRequestAnimationFrame ||

   6:            window.msRequestAnimationFrame ||

   7:            function (callback, element) {

   8:                 window.setTimeout(callback, 1000 / 60);

   9:            };

  10:      })();

11:

  12: function startLevel(level) {

  13:     instantiateSpheres(level.maximumSpheres);

14:

  15:     startTimer();

  16: }

17:

  18: function startTimer() {

  19:     requestAnimFrame(startTimer);

  20:     gameLoop();

  21: }

The startLevel() function is called by the main application and dynamically creates the game resources (i.e. the spheres) for a particular game level before starting the game timer.

The gameLoop() function is the routine that animates each sphere in relation to the others. This method is responsible for two things during each animation cycle: 1) move each sphere, and 2) check for collisions with an explosion. I’m using a rather basic loop to iterate through all the spheres and avoiding double-checking collisions. Here’s the code:

   1: function gameLoop() {

   2:     // move and check for collisions.

   3:     for (var i = 0; i < _spheres.length; i++) {

   4:         _spheres[i].move();

5:

   6:         for (var j = i + 1; j < _spheres.length; j++) {

   7:             if (_spheres[i].isColliding(_spheres[j])) {

   8:                 if (_spheres[i].isExploding) { _spheres[j].explode(_spheres[i]); }

   9:                 if (_spheres[j].isExploding) { _spheres[i].explode(_spheres[j]); }

10:

  11:                 if (USE_COLLISIONS)

  12:                     _spheres[i].collide(_spheres[j]);

  13:             }

  14:         }

  15:     }

  16: }

The USE_COLLISIONS variable is a simple boolean that I can use to globally turn off the rudimentary physics in the game. The sphere class encapsulates the logic for all movement and collision detection. The gameLoop() routine simply tells to each sphere to move itself and then determine if they collide with each other. Remember the gameLoop() routine should be running approximately 60 times every second.

So far, the animations are proceeding exactly as they did in the Silverlight version since both rely on a clock tick to perform their calculations. At this point, I was quite happy with the migration from Silverlight since I was able to take the C# code and only slightly modify it to Javascript. For example, here the same game loop in C#:

   1: void OnTimerTick(object sender, EventArgs e)

   2: {

   3:     // Move and check for collisions.

   4:     for (int i = 0; i < spheres.Count; i++)

   5:     {

   6:         spheres[i].Move();

7:

   8:         for (int j = i + 1; j < spheres.Count; j++)

   9:         {

  10:             if (spheres[i].IsColliding(spheres[j]))

  11:             {

  12:                 if (spheres[i].IsExploding) { spheres[j].Explode(spheres[i]); }

  13:                 if (spheres[j].IsExploding) { spheres[i].Explode(spheres[j]); }

14:

  15:                 if (!this.IsCollisionOff)

  16:                     spheres[i].Collide(spheres[j]);

  17:             }

  18:         }

  19:     }

  20: }

Some of the smaller problems I incurred during this portion of the conversion was color manipulation, points, and vectors. Obviously, Silverlight and .Net in general has strong color manipulation capabilities; Javascript, not so much. I ended up passing colors around as arrays of 4 bytes (R, G, B, and A) for easier manipulation. The other issues stemmed from core libraries available in C# that deal with points and vectors but simply don’t exist at all in Javascript. While I may have been able to find some external libraries for these pieces, they weren’t too difficult to reproduce.

However, I’m a bit concerned with next piece of the conversion: the explosions. I used Silverlight’s key-frame animations in storyboards along with data-binding to easily create animations that explode the sphere to a multiple of its initial radius, pause for moment, and then contract to nothingness. I’m anticipating issues attempting to use CSS3 and HTML5 to provide the same ease of animation development. However, that’s a topic for the next part of this blog series.

The Cascade Game: From Silverlight to HTML5 (part 1)

sloscialo — Thu, 08 Sep 2011 21:39:51 GMT

A few years ago I played a game on Facebook that had a simple premise, but became quite addictive for a while. It consisted of progressing levels of spheres in which the player was tasked with exploding by initiating a chain-reaction. You had one shot. Placement, timing, and luck determined how well you scored. At the time, I was learning Silverlight and thought it would be a good sample project to duplicate the fundamentals of this game in Silverlight, and thus Cascade was born.

Now, with the advent of Html5 and Javascript poised to reclaim the virtual landscape, I decided that it may be a beneficial learning experience to rewrite Cascade as an HTML5 application. The next series of posts will outline my progression in converting the Silverlight version of Cascade into a workable Html5 game.

The first thing I started with in the conversion was the shell for the game, a simple HTML5 page. At this point, it’s still in the rough sketch phase (I’ll add more finalized artwork later). Below is a picture of the game board with very little in the graphics department. The HTML5 markup is pretty basic, but I wanted to put a gradient in the header. With HTML5 and CSS3, gradients are very simple to implement without having to use a repeating graphic image. So, while still possible to achieve this affect with either a large image or a small, repeated one, the new gradient effects in HTML5 /CSS3 are better for two reasons: they look good at all resolutions and are smaller in download size.

Unfortunately, Internet Explorer 9 does not support gradients. However, it does support Scalable Vector Graphics (SVG), as do all the other mainstream browsers. So, while it’s not quite pure HTML5, the SVG background scales just as nicely and is minimal in size: see Robert Biggs’ blog at http://css3wizardry.com/2010/10/29/css-gradients-for-ie9/ for more information. I borrowed and slightly tweaked the Robert’s SVG gradient for my project. And while he mentions customizing the code to only show the SVG for IE9, I’m inclined to let the other browsers use the SVG as well.

There is a good case to be made to support SVG only in Internet Explorer and use the HTML5/CSS3 gradients for all other browsers. However, for the purposes of this project, I’m going to stick with the one method; in a production application, I’d follow Robert’s advice and create the customization since IE will eventually support the feature.

The HTML is rather straight-forward and simplistic: it consists of a few CSS3 styles, a handful of HTML tags, and some Javascript.

   1: <body style="margin: 0">

   2:     <header id="scoreBoard" class="boxSizing">

   3:         <article class="box">

   4:             <div>CASCADE</div>

   5:             <div>powered by Wintellect</div>

   6:             <div id="headerControls" style="display: box">

   7:                 <input type="checkbox">Turn off collisions.</input>

   8:                 <a href="#" style="align: right">Help</a>

   9:             </div>

  10:         </article>

  11:         <article style="margin-top: 15px; vertical-align: bottom">

  12:             <div class="fixedWidthColumn">Score: <span id="score" /></div>

  13:             <div class="fixedWidthColumn">Level: <span id="level" /></div>

  14:             <div class="fixedWidthColumn">Goal: <span id="goalObtained"/> / <span id="goalTarget" /></div>

  15:             <div class="fixedWidthColumn">Total: <span id="total" /></div>

  16:         </article>

  17:     </header>

18:

  19:     <div id="playingBoard" class="boxSizing">></div>

  20: </body>

As you can see, there’s not too much to it. In fact, there isn’t much that’s HTML5 specific (the article and header tags could easily be replaced by standard divs). Also, I’m using a div to represent the playing board, and not a canvas (the reason is that the I’ll be dynamically creating canvases to hold the spheres and animating them individually instead of painting and clearing a single canvas…more on that in the next post).

The elements are styled through CSS3 to provide the image you see in the snapshot above.

   1: <style>

   2:     .boxSizing {

   3:         -moz-box-sizing: border-box;

   4:         -webkit-box-sizing: border-box;

   5:         -o-box-sizing: border-box;

   6:         box-sizing: border-box;

   7:     }

8:

   9:     #scoreBoard {

  10:         background-image: url('background.svg');

  11:         border: 1px solid gray;

  12:         width: 800px;

  13:         height: 120px;

  14:     }

15:

  16:     article {

  17:         font-family: verdana;

  18:         font-size: 14pt;

  19:     }

20:

  21:     .fixedWidthColumn {

  22:         border: 1px dotted white;

  23:         float: left;

  24:         width: 24%;

  25:         margin-left: 0.5%;

  26:         margin-right: 0.5%;

  27:         padding: 2px;

  28:         -moz-box-sizing: border-box;

  29:         -webkit-box-sizing: border-box;

  30:         -o-box-sizing: border-box;

  31:         box-sizing: border-box;

  32:     }

33:

  34:     #playingBoard

  35:     {

  36:         border: 4px solid gray;

  37:         background: black;

  38:         width: 800px;

  39:         height: 480px;

  40:         position:fixed;

  41:     }

  42: </style>

For both the Silverlight game and this one, I fixed the size of the game to be 800x600. My reasoning was that game’s difficulty is dependent upon the number, size, and speed of spheres flying around. Perhaps I’ll adjust the size of the spheres in this version to be proportional to the size of the game board and see how that affects the playability of the game.

One other note is the use of the box-sizing attributes set to border-box. HTML5 allows the developer to change the way boxes are measured. The simplistic answer is that the default method, called content-box (HTML4 and earlier) don’t include the margins and border when you define the width and height. Meaning if you create a 100px wide and 50px tall element and put a 2px border around it, the element would actually appear to take up 104px by 54px on the screen. By setting the box-sizing to border-box, I’m telling the browser to render the border, padding, and margins inside the element. I prefer box sizing since I know that the total space taken by the visual element is what I set it to.

After getting the basic UI of the game in place, I set up the game’s programming framework: basically initialization, start logic, game timing loop, and cleanup. Part 2 of the this blog series will dive into the level initialization and the animation of the spheres.

Where’s my DataContext?

sloscialo — Tue, 26 Jul 2011 15:51:30 GMT

Every now and then a question comes up concerning a missing DataContext. The questions usually center around a ViewModel being set to a View properly, but then developer can not bind some command or property to a FrameworkElement. And typically the FrameworkElement in question is nested within an ItemsControl’s ItemTemplate or other similar structure.

First things first, once a DataContext is set, it is available for every child and all nested children until another DataContext is set. That’s why the following Xaml snippet works, and we don’t need to set the DataContext on both TextBlocks.

        1: <Grid DataContext="{StaticResource MyViewModel}">

       2:     <StackPanel>

       3:         <TextBlock Text="{Binding SomeText}" />

       4:         <TextBlock Text="{Binding SomeMoreText}" />

       5:     </StackPanel>

       6: </Grid>

This is basic data-binding and is at the heart of WPF, Silverlight and Windows Phone 7 development. So, no matter how many elements we nest within the Grid, they all will have access to the DataContext until an element is assigned its own DataContext.

The question of the lost DataContext usually arises when the Xaml is slightly more complex. For example,

   1: <Grid DataContext="{StaticResource MyViewModel}">

   2:     <ItemsControl ItemsSource="{Binding MyItems}">

   3:         <ItemsControl.ItemTemplate>

   4:             <DataTemplate>

   5:                 <Grid>

   6:                     <StackPanel Orientation="Horizontal">

   7:                         <TextBlock Text="{Binding MyItemText}" />

   8:                         <Button Content="Delete" Command="{Binding DeleteItemCommand}" />

   9:                     </StackPanel>

  10:                 </Grid>

  11:             </DataTemplate>

  12:         </ItemsControl.ItemTemplate>

  13:     </ItemsControl>

  14: </Grid>

This can tend to trip up developers new to WPF and Silverlight. Why?

The first reason is that Grid on line 5 has had its DataContext changed transparently; the DataContext of the ItemsControl is still MyViewModel, but the internal grid has its DataContext set to an object in the bound collection (seen in line 2 as the ItemsSource). In other words, the DataContext of the grid inside the ItemTemplate is an instance of an object in the collection MyItems. For the above binding to work, the objects in MyItems would need have a property named MyItemText and a property called DeleteItemCommand.

The second reason is even if a developer realizes that the DataContext of the ItemTemplate is an instance of an object in the list, they still want to bind to a property on the original ViewModel. Most likely, the main ViewModel contains the consolidated business logic necessary for the requested task. Or perhaps the list of items contains basic objects pulled from a RESTful service, so adding additional properties (especially ICommands) is too prohibitive.

So, what can we do?

As with most development, there are multiple ways to accomplish this task. I’m going to show several of the more common solutions for obtaining a reference to what I call the main ViewModel. In the two snippets I showed above, I’m assuming a StaticResource contains an instance of the ViewModel I’m concerned with. However, that’s typically not the best practice for setting a ViewModel on a view. More than likely, the main ViewModel will be set in code or through dependency injection.

For the sake of completeness, if you did have a StaticResource pointing to your ViewModel, then you would change line 8 to read:

   1: <Button Content="Delete" Command="{Binding Source={StaticResource MyViewModel}, Path=DeleteItemCommand}" />

If, however, your ViewModel is set in code, what can you do? Well, the ItemsControl’s DataContext would still be set to the main ViewModel in this instance and there are several ways you can get to it.

The first way uses element-to-element binding. In order to use this, you’ll have to explicitly name your ItemsControl, then use a slightly different binding syntax to reference it:

   1: <ItemsControl x:Name="MyItemsControl">

   2:   ...

3:

   4:     <Button Content="Delete" Command="{Binding ElementName=MyItemsControl, Path=DataContext.DeleteItemCommand}" />

5:

   6:   ...

   7: </ItemsControl>

Another method would to use the RelativeSource option for the binding.

   1: <ItemsControl>

   2:     ...

3:

   4:     <Button Content="delete"

   5:             Command="{Binding RelativeSource={RelativeSource AncestorType=ItemsControl}, Path=DataContext.DeleteItemCommand}" />

6:

   7:     ...

   8: </ItemsControl>

My personal preference is to use the RelativeSource option so that I don’t need to sync the element names. The only caveat with RelativeSource would be multiple nesting of ItemsControls (or your container of choice) and then requiring access all the way back to the original ViewModel.

One last thing. While my example is contrived, the DeleteItemCommand will need to know what item to delete. Since we are not changing the DataContext on the button, we still have access to the forced DataContext the ItemsControl imposed on us, namely an instance of an item in the bound collection. Therefore, we could also include a CommandParameter so that the delete command knows what to delete. In all three cases presented above, you would add the following property to the delete button:

   1: CommandParameter="{Binding}"

So there you have it. In certain surprisingly common scenarios, mainly involving the ItemTemplate of ItemsControl and its derived classes such as ListBox, the DataContext you get may not be the one you’re expecting. However, with element-to-element and RelativeSource bindings you can easily obtain the references you need.

Yet another way to attach ViewModels to Views

sloscialo — Thu, 19 May 2011 17:45:57 GMT

Throughout the short history of the MVVM design pattern, several methods have originated for populating Views with their ViewModels. One of the most common methods is to use one of the frameworks (PRISM, MVVM Light, Jounce, among others). Typically, the ViewModel is registered with an IOC container and retrieved when needed. One of the more outstanding issues is when to take the ViewModel and assign it to a View’s DataContext. In many cases, the connection occurs in the constructor of the View with the View requesting the ViewModel from the IOC container. In other cases, a locator is used as a static resource in the View’s Xaml, and using DataBinding a property of the locator is bound to the DataContext. In the latter case, the locator requests the ViewModel from the IOC container.

In a recent project, I discovered (or rediscovered) another method for binding a ViewModel to a View. Using Unity’s IOC Container, I registered both the View and the ViewModel together. Granted this method will not work for every scenario, but in the cases where you create Views programmatically, I believe this method works perfectly.

Unity will allow you to register a type with a key which becomes important when registering different configurations of the same type. But more importantly, Unity supports configuration via InjectionProperties (and other methods as well). InjectionProperties will enable Unity to resolve your Type and inject additional values into the generated class. InjectionProperties work like this:

        1: int expectedInt = 8;

       2: container.RegisterType<MyClass>(

       3:     new InjectionProperty("IntProperty", expectedInt));

Basically, Unity will create an instance of MyClass and set the property “IntProperty” to 8, when the container resolves the type.

For a View to be registered with its ViewModel, several steps must be taken . The steps are simple, first register the ViewModel with Unity, then register the View with an InjectionProperty, optionally adding a key if you need to register the view multiple times with different configurations.

       1: public void RegisterDialog<TView, TViewModel>(string dialogName)

       2:     where TView : IDialogView

       3:     where TViewModel : IDialogViewModel

       4: {

       5:     if (string.IsNullOrEmpty(dialogName)) throw new ArgumentNullException("dialogName");

       6:  

       7:     if (!_container.IsRegistered<TViewModel>())

       8:         _container.RegisterType<TViewModel>();

       9:  

      10:     _container.RegisterType<IDialogView, TView>(dialogName, 

      11:         new InjectionProperty("DataContext", new ResolvedParameter<TViewModel>()));

      12: }

In the code above, I geared the method to support some dialogs, but it’s easily modified to support any type of view you’d like. I use Unity’s ability to name the registrations so I can register multiple views of the same type but with different ViewModels. One item to note is the use of the ResolvedParameter class. The ResolvedParameter instructs Unity to only create the type when it is requested. If I “newed” up a ViewModel instead, Unity would keep around an instance of the ViewModel to inject into all resolved views.

In my Bootstrapper.cs file, where you’d normally register your classes in an IOC container,, I simply make calls to this method for any dialogs I want to create in the application.

       1: RegisterDialog<DialogView DialogViewModel>(DialogNames.OkCancelDialog);

       2: RegisterDialog<DialogView, LoginDialogViewModel>(DialogNames.LoginDialog);

Here I am registering two dialogs of type DialogView with two different ViewModels and assigning them a key. Now, it’s trivial to gain a reference to them in the application:

       1: if (!this.User.IsLoggedIn) {

       2:     IDialogView dialog = _dialogContainer.Resolve<IDialogView>(DialogNames.LoginDialog);

       3:     dialog.Show();

       4: }

That’s all there is to it. Of course, I’ll leave the whole Dialog framework implementation up to you.

Unity is a complex framework with many features. InjectionProperties are only one tool to enhance the configuration of your registrations. Unity will even allow you to call a method on your object when it’s instantiated with or without parameters.

Silverlight Memory Leaks and AutomationPeers

sloscialo — Wed, 13 Apr 2011 18:09:48 GMT

Using a memory profiling tool such as ANTS Memory Profiler from Red-Gate or MemProfiler from SciTech Software (I’m sure there others, but those were the only two I found that can profile a Silverlight Out-Of-Browser application) is a good idea. By using such a tool, developers can discover a myriad of memory leaks and fix them before releasing their code. These leaks usually stem from classes that attach event handlers to other classes. In fact, in my opinion, I’ve seen more memory leaks in Silverlight (and WPF) stemming from poor event handler management than anything else.

However, every once in a while, you’ll see something that appears to be unexplainable.

After profiling an application for a client, I discovered the usual gambit of event-handlers and strong-references between objects. In fact, an initial object retention graph (in this case, produced by the ANTS Memory Profiler) was almost indecipherable.

This is intentionally unreadable for two reasons: 1) to protect the innocent, and 2) because that graph is so big, there’s no way to actually show it in it’s entirety without massive scrolling (I could probably whip up a Deep Zoom for it, but that’s over kill for the purposes of this discussion).

The faint black box above the unreadable red “Start Here” box is the class I was researching, and the other boxes are classes in the hierarchy all the back to a GC root. So, you can see that there were a lot. After days of tracking down each strong reference and removing them, I ended up with a single chain.

This picture showed a ListBoxAutomationPeer as the last entity before being stuffed into the ManagedPeerTable.

My original object (the dark gray box) was never released and since this was one child view inside a parent container, multiple copies stayed in memory never to be garbage collected.

As far as memory consumption goes, it wasn’t too bad. And since all the event handlers were removed, and all messages unsubscribed to, the object just floated in the ether being unobtrusive. But, after spending days trying to clean up memory leaks, this was still unacceptable, especially since there were literally hundreds of these objects floating around.

The Automation framework was created as a method for adding accessibility or automated testing to your applications. The AutomationPeers are the way your application can communicate with Automation clients, or the way the Automation clients can communicate with your application.

If an Automation Client is running, it can and will ask your application if it supports automation. For both Silverlight and WPF this happens automatically (no pun intended). Sometimes the client is nice about it and requires that you attach it to your application (like most automated testing frameworks).

In my case, I wasn’t running an automated testing framework. I wasn’t creating an Automation Client at all and attaching it to my application. But AutomationPeers were being created, nonetheless.

So, I tested this application on a co-workers machine to see if there was something environmental causing the problem. As fate would have it, there was. His computer was not showing this memory leak.

After a day or two of digging around I realized that my computer was running Tablet PC Input Services (I have a Wacom tablet and the Tablet PC Input Services was installed when Windows figured out I had pen-enabled computer).

Turning off the Tablet PC Input Services removed the AutomationPeers from the object retention graph and the memory leak was plugged.

Unfortunately, nothing in the ANTS Memory Profiler or MemProfiler indicated that Tablet PC Input Services was the culprit causing the AutomationPeers to be created. Additionally, while it seems like I’m pointing a finger at TIPS, any AutomationClient would probably cause the same issues within the application.

In conclusion, when looking for memory leaks, be aware that the automation API can keep your objects alive for longer than you expect. You can mitigate bugs this may cause by properly detaching objects from external events and removing strong references to existing objects when you dispose or unload them. Finally, profile your application frequently as lots of things can show up that may help you fix issues before they escalate into week-long bug hunts.

Resumable downloads in Silverlight Out-Of-Browser applications

sloscialo — Mon, 21 Mar 2011 23:52:29 GMT

The task facing us is simple. In fact, it has been done before. Many download management tools already have the ability to resume downloading a file if, for some reason, the process was interrupted. There is no built-in facility for resuming an interrupted download within a Silverlight applications. Silverlight does provide some tools for working around this limitation, but only while running under elevated privileges in an out-of-browser application.

A little background

The HTTP/1.1 specification defines an Accept-Ranges response header. This header is not required by servers and therefore is not guaranteed to be there whenever a file needs to be downloaded. Servers that do support it will typically send back a header that includes the following header fields:

Accept-Ranges: bytes | none
Content-Length: xxxx

The Accept-Ranges field will equal “bytes” if the server supports byte range on GET commands. Additionally, the Content-Length field will equal the total size of the file being downloaded.

Once a server has been determined to support byte ranges, HTTP GET requests can include an additional header field to retrieve a block of data. The size of the block is defined by the application by sending start and end indices. The following header field request the first 1024 bytes from the server.

Ranges: bytes=0-1023

Silverlight Implementation

With that background, the process for creating a resumable downloader in Silverlight OOB is rather straight-forward.

Check to see if the file has not finished downloading
Assuming it’s not finished, request next chunk of data and append to the existing partial file.
Continue requesting chunks and appending until finished.

Several implementations are possible: for example, a temporary file can be used to hold the partial file and its existence lets the implementation know that the download is not finished. An alternative method could be to compare the length of the file on disk with the length returned from the HEAD Http request.

The purpose of the following code snippets are to convey the concepts behind creating a resumable downloader rather than provide a complete implementation. A full-featured resumable downloader may be posted at future data, time permitting. But there should be enough here to get you going.

Creating an Http/1.1 HEAD request

In order to get started we need to know two things: whether the server supports the Range header and the size of the file we want to download. The HEAD request will enable us, in essence, to query the capabilities of the server and determine the size of the file in one round-trip. Using the HttpWebRequest class is necessary to make the HEAD request. We use the asynchronous BeginGetResponse() method to initiate the communication with the server.

WebRequest.RegisterPrefix("http://", WebRequestCreator.ClientHttp);
WebRequest.RegisterPrefix("https://", WebRequestCreator.ClientHttp);

HttpWebRequest webRequest = (HttpWebRequest)WebRequest.Create(downloadUri);
webRequest.Method = "HEAD";

webRequest.BeginGetResponse(OnHttpCheckHeadersResponse, webRequest);

By setting the request method to “HEAD”, only the relevant header information will be returned and the actual download will not start. In the callback, the header can be processed and the download can be started based on the results. Below is a sample of what the callback may look like.

private void OnHttpCheckHeadersResponse(IAsyncResult result)
{
    HttpWebRequest request = result.AsyncState as HttpWebRequest;
    if (request == null) throw new Exception("There was a problem with the web request.");

    try
    {
        var response = (HttpWebResponse)request.EndGetResponse(result);
        var acceptsRange = response.Headers["Accept-Ranges"];

        if (acceptsRange.Equals("bytes", StringComparison.CurrentCultureIgnoreCase))
        {
            // Accepts partial downloads.
            string sizeString = response.Headers["Content-Length"];
            if (long.TryParse(sizeString, out _length))
            {
                ResumableDownload();
            }
        }
        else
        {
            // Download the whole thing at once and hope for the best.
            NonResumableDownload();
        }
    }
    catch (Exception e)
    {
        // Possibly a 404 error.
        throw e;
    }
}

Of course, the actual implementation may differ. For example, header information could be stored in a separate structure, firing events or using messages to signal completion of the header parsing are all viable options.

The remainder of the implementation requires downloading the actual file one piece at a time. Assuming that the downloader may be in a state where a portion of the file was downloaded earlier, a check is needed to determine where to begin. If we’re using a temporary file, the downloader can first determine if the file exists, and if it does, determine its current size. That code may look something like the following, where DownloadBlockSize is a constant used to define the size of the block to download:

string destinationFile = CreateDestinationFileFromUri(downloadUri);
FileInfo tempFile = new FileInfo(destinationFile + ".tmp");

if (!tempFile.Exists)
{
    StartBytesIndex = 0;
    EndBytesIndex = DownloadBlockSize;
}
else
{
    StartBytesIndex = tempFile.Length;
    EndBytesIndex = StartBytesIndex + DownloadBlockSize;
}

At this point, the downloader now has a starting and ending index to request a portion of the file from the server. The final piece of the puzzle simply sets up a loop to continually download chunks of data from the server until there is no more data. Once again, an HttpWebRequest is used to create a GET request with the Range header property set to the appropriate block of data by simply using the StartByteIndex and EndByteIndex discovered when resuming the download.

public void ResumableDownload()
{
    WebRequest.RegisterPrefix("http://", WebRequestCreator.ClientHttp);
    WebRequest.RegisterPrefix("https://", WebRequestCreator.ClientHttp);

    HttpWebRequest webRequest = (HttpWebRequest)WebRequest.Create(downloadUri);
    webRequest.Method = "HEAD";

    webRequest.Headers["Range"] = string.Format("bytes={0}-{1}", 
        StartBytesIndex, 
        (EndBytesIndex <= Length) ? EndBytesIndex.ToString() : "");

    webRequest.BeginGetResponse(OnHttpGetRangeResponse, webRequest);
}

Like the HEAD request implementation, the majority of the GET request resides in the asynchronous callback. In the code snippet below, the object, partialFileStream is a previously opened writeable stream to the temporary file. Since the downloader will attempt to download as much as possible, it should not close and reopen the file with each range received from the server. The Flush() method will insure that the block of data is written to the temporary file.

private void OnHttpGetRangeResponse(IAsyncResult result)
{
    HttpWebRequest request = result.AsyncState as HttpWebRequest;
    if (request == null) throw new Exception("There was a problem with the web request.");

    var response = request.EndGetResponse(result);

    using (Stream responseStream = response.GetResponseStream())
    {
        CopyStream(responseStream, partialFileStream);
        responseStream.Close();
    }

    partialFileStream.Flush();
    OnDownloadRangeComplete();

    StartBytesIndex += DownloadBlockSize + 1;
    EndBytesIndex = StartBytesIndex + DownloadBlockSize;

    if (RemainingBytes > 0)
        ResumableDownload();
    else
        FinishDownload();
}

To finish the implementation, all that needs to be done is close the open file handle and possibly rename any temporary files.

private void FinishDownload()
{
    partialFileStream.Close();

    RenameTemporaryFile();
    OnDownloadComplete();
}

Conclusion

The capability for writing a resumable downloader resides within the Http/1.1 specification. Implementing the specification in Silverlight requires that Silverlight runs out-of-browser and has elevated privileges. Silverlight applications not running with these caveats will not be able to query the file system for the existing of the partially downloaded file or arbitrarily write to files. Silverlight requires explicit permission from the user to begin writing to the file system (this would eliminate using temporary files). Theoretically, there may be an implementation that will allow for resumable downloads in vanilla Silverlight, but the usability will probably be questionable. Of course, this may change in a future version of Silverlight.

As always, constructive feedback is welcome.

WPF – Animating multiple elements simultaneously

sloscialo — Thu, 06 Aug 2009 15:57:00 GMT

A question appeared on StackOverflow asking how to animate a property on multiple elements from one or more trigger mechanisms (i.e. a button click or list box selection). The traditional approach (for brevity’s sake, I omitted the Xaml comprising the actual UI elements) is rather straight-forward:

<Window.Resources>
    <Storyboard x:Key="OnClick1">
        <DoubleAnimationUsingKeyFrames BeginTime="00:00:00" 
                                       Storyboard.TargetName="textBlock1" 
                                       Storyboard.TargetProperty="(UIElement.Opacity)">
            <SplineDoubleKeyFrame KeyTime="00:00:00" Value="0"/>
            <SplineDoubleKeyFrame KeyTime="00:00:00.5000000" Value="1"/>
        </DoubleAnimationUsingKeyFrames>
        <DoubleAnimationUsingKeyFrames BeginTime="00:00:00" 
                                       Storyboard.TargetName="textBlock2" 
                                       Storyboard.TargetProperty="(UIElement.Opacity)">
            <SplineDoubleKeyFrame KeyTime="00:00:00" Value="0"/>
            <SplineDoubleKeyFrame KeyTime="00:00:00.5000000" Value="1"/>
        </DoubleAnimationUsingKeyFrames>
        <DoubleAnimationUsingKeyFrames BeginTime="00:00:00" 
                                       Storyboard.TargetName="textBlock3" 
                                       Storyboard.TargetProperty="(UIElement.Opacity)">
            <SplineDoubleKeyFrame KeyTime="00:00:00" Value="0"/>
            <SplineDoubleKeyFrame KeyTime="00:00:00.5000000" Value="1"/>
        </DoubleAnimationUsingKeyFrames>
        <DoubleAnimationUsingKeyFrames BeginTime="00:00:00" 
                                       Storyboard.TargetName="textBlock4" 
                                       Storyboard.TargetProperty="(UIElement.Opacity)">
            <SplineDoubleKeyFrame KeyTime="00:00:00" Value="0"/>
            <SplineDoubleKeyFrame KeyTime="00:00:00.5000000" Value="1"/>
        </DoubleAnimationUsingKeyFrames>
    </Storyboard>
    <Window.Triggers>
        <EventTrigger RoutedEvent="ButtonBase.Click" SourceName="button">
            <BeginStoryboard Storyboard="{StaticResource OnClick1}"/>
        </EventTrigger>
    </Window.Triggers>
</Window.Resources>

The major complaint about the above solution is the repetition of the Animations. Since each TextBlock implements the same animation, an easier to maintain solution would be ideal. Initially, I believed a Xaml-only solution would not be possible, but StackOverflow user, kek444, put me onto a simple trick of animating a single value and DataBinding the TextBlocks to it. While his solution involved setting the DataContext on an element, I believe using a placeholder element is a cleaner approach (however, I’m sure this is open to debate).

The updated version of the above Xaml would look as follows:

<Window.Resources>
    <UIElement x:Key="AnimationPlaceholder" Opacity="0"/>
    <Style TargetType="TextBlock">
        <Setter Property="Opacity" 
                Value="{Binding Source={StaticResource AnimationPlaceholder}, Path=Opacity}" />
    </Style>
    
    <Storyboard x:Key="OnClick1">
        <DoubleAnimationUsingKeyFrames BeginTime="00:00:00" 
                                       Storyboard.Target="{StaticResource AnimationPlaceholder}" 
                                       Storyboard.TargetProperty="(UIElement.Opacity)">
            <SplineDoubleKeyFrame KeyTime="00:00:00" Value="0"/>
            <SplineDoubleKeyFrame KeyTime="00:00:00.5000000" Value="1"/>
        </DoubleAnimationUsingKeyFrames>
    </Storyboard>
    
    <Window.Triggers>
        <EventTrigger RoutedEvent="ButtonBase.Click" SourceName="button">
            <BeginStoryboard Storyboard="{StaticResource OnClick1}"/>
        </EventTrigger>
    </Window.Triggers>
</Window.Resources>

In this snippet, I’m using a UIElement to hold the animation value since it supports the Opacity property (but in fact, any property of type double, would suffice). Also, if you’re not adverse to a little coding, a custom class could be created to contain the values you wish to change for a particular animation. A style is created to affect all TextBoxes, but this can easily be modified to use explicit styling. Finally, the Storyboard targets the placeholder object and changes its value from 0 to 1 over 0.5 seconds. The style uses DataBinding to bind its Opacity property to the placeholder’s.

Though Blend creates a lot of the Xaml for you when creating trigger-based animations, sometimes the result can be less than ideal. Additionally, as I’ve had reinforced through this little exercise, there is more than one way to skin a cat when it comes to Xaml, so please feel free to comment with refinements or alternative solutions.