Jim Jackson

Character Counts.
Do the right thing.

Sponsors

May 2010 - Posts

Entity Framework ObservableCollection Add Method - Unexpected Behavior

The documentation for Collection<T>.Add specifically states that when calling the Add method, the new item is appended to the end of the collection. This is not necessarily true. I haven't tested it in all it's incarnations yet but it appears to be adding to the beginning (index 0) of my collection.

http://msdn.microsoft.com/en-us/library/ms132404(v=VS.100).aspx 

My Entity Framework Self-Tracking object contains a collection of items. In my tests I created a couple of dummy objects and inserted them into the database. I was surprised to find that they were in reverse order! The collection type, by the way, is System.Collections.ObjectModel.ObservableCollection<T> in a Silverlight 4 application.

When I looked at the values in the immediate window, sure enough the first item in the collection was the last item I added and so on up the chain. Now you should never count on sorting your database items based on an identity key (obviously) but for spot check purposes, when I'm looking directly at the raw data, I prefer to have my items put in the database in the order expected.

So now rather than calling the Add() method, I'm switching over to using the Insert() method. As a perfomance point though, wouldn't adding an item to the beginning of an array be inherently more processor intensive than adding it to the end?

 

Using the BackgroundWorker in a Silverlight MVVM Application

With Silverlight 4 and the Entity Framework you get a lot of work done on your behalf in terms of standard UI CRUD-style operations. Validations and I/O are pretty easy to accommodate out of the box. But sometimes you need to perform some long running tasks either on the client or on the server via service calls. To prevent your UI from hanging and annoying your users, you should consider placing these operations on a background thread. The BackgroundWorker object is the perfect solution for this. It is easy to use and easy to debug. There are, however, a few things you should understand about where and when the BackgroundWorker can provide feedback and/or manipulate the UI. Spending a few minutes building out the sample listed here should give you the foundation you need to implement very complex, very responsive scenarios.

Note that I used MVVM Light’s RelayCommand not because it’s required but because it’s simple and provides the functionality I required in other applications when binding commands to UI events other than Click. The ViewModelBase also automatically implements INotifyPropertyChanged which is nice.

Here is how the system should operate:

The user types a message into the text box and presses the button. The message is passed into the processor object on a background thread. The processor occasionally notifies the UI that status has changed and the UI refreshes accordingly. While the processor is executing, there should be no lag in the UI functionality. This could also be enhanced to allow the processor to handle in-transit updates to the processor’s payload from the UI but this is beyond the scope of this post.

Getting Started

Start by opening Visual Studio 2010 and creating a new Silverlight Application. No need to do anything special here, no Navigation app, no MVM Light app. Inside the Silverlight application (I named mine BackgroundTest) create three new folders:

·         Models

·         ViewModels

·         Views

Drag the MainPage.xaml from the root folder into the Views folder. This is not really required but it keeps things organized.

Right click on ViewModels and select Add Item => MvvmViewModel. Name it MainViewModel. If you don’t have MvvmViewModel as an item template, check out Laurent Bugnion’s site for details about the MVVM Light Toolkit. http://www.galasoft.ch/

Add two new classes to the Models folder:

·         LongRunningObject: This is our faux object that will take an arbitrary amount of time to process the ProcessItem it receives.

·         ProcessItem: This is a simple business object that implements INotifyPropertyChanged.

In the App.xaml file, add a reference to the ViewModels namespace of the current project and give it a prefix of “vm”:

xmlns:vm="clr-namespace:BackgroundTest.ViewModels"
 

In the Application Resources element (also in App.xaml) add a static reference to the MainViewModel:

<vm:MainViewModel x:Key="MainViewModel" />

 

By adding the MVVM Light ViewModel you should have automatically added references to the following DLL’s. If they are not there, add them now:

·         GalaSoft.MvvmLight.Etras.SL4

·         GalaSoft.MvvmLight.SL4

Here is the Xaml of the MainPage:

<UserControl x:Class="BackgroundTest.MainPage"
      xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity"
      xmlns:cmd="clr-namespace:GalaSoft.MvvmLight.Command;assembly=GalaSoft.MvvmLight.Extras.SL4"
      xmlns:vm="clr-namespace:BackgroundTest.ViewModels"
      mc:Ignorable="d"
       DataContext="{Binding Source={StaticResource MainViewModel}}"
       Height="250" Width="500">
       
     <UserControl.Resources>
             <DataTemplate x:Key="ProcItemsTemplate">
                   <Grid>
                         <Grid.ColumnDefinitions>
                                <ColumnDefinition Width="65" />
                                <ColumnDefinition />
                                <ColumnDefinition Width="30" />
                         </Grid.ColumnDefinitions>
                         <TextBlock Grid.Column="0"
                                      Text="{Binding Path=Progress, StringFormat=\{0:P\}}" />
                         <TextBlock Grid.Column="1"
                                      Text="{Binding Path=CommandData}" />
                         <TextBlock Grid.Column="2"
                                      Text="{Binding Path=IsComplete}" />
                   </Grid>
             </DataTemplate>
      </UserControl.Resources>
 
       <Grid x:Name="LayoutRoot" Background="Beige">
             <Grid.RowDefinitions>
                   <RowDefinition Height="25" />
                   <RowDefinition Height="25" />
                   <RowDefinition />
             </Grid.RowDefinitions>
             <Grid.ColumnDefinitions>
                   <ColumnDefinition Width="140" />
                   <ColumnDefinition />
             </Grid.ColumnDefinitions>
              <TextBox Text="{Binding Path=DataText, Mode=TwoWay}"
                       Width="200" TextWrapping="Wrap" Grid.ColumnSpan="2" />
             <Button Content="Load this and wait..."
                      Grid.Row="1" Width="150" Grid.ColumnSpan="2"
                      Margin="0,2,2,0" >
                   <i:Interaction.Triggers>
                         <i:EventTrigger EventName="Click">
                                <cmd:EventToCommand
                                      Command="{Binding StartLongRunningExecCommand}"
                                       CommandParameter="{Binding Path=DataText}" />
                         </i:EventTrigger>
                   </i:Interaction.Triggers>
             </Button>
             <Rectangle Grid.Row="2" Fill="{Binding Path=CurrentColor}" />
             <StackPanel Orientation="Vertical"
                          HorizontalAlignment="Center"
                          VerticalAlignment="Top" Grid.Row="2">
                   <TextBlock Text="Red=Not Running" />
                   <TextBlock Text="Green=Running" />
                   <TextBlock Text="{Binding Path=ProcessorCount}"  />
             </StackPanel>
             <ScrollViewer Grid.Row="2" Grid.Column="2">
                   <ItemsControl
                          ItemsSource="{Binding Path=TokenList, Mode=TwoWay}"
                          ItemTemplate="{StaticResource ProcItemsTemplate}" />
             </ScrollViewer>
      </Grid>
</UserControl> 
 

This is pretty straight forward. The DataContext of the control is set to the key that you added previously in the App.xml. The binding statements will be more apparent after you dig into the ViewModel. Also, the Click event of the button is bound using Triggers to show that this command could be fired from any event, not just a button. The parameter of the command is set to the text property of the text box.

There is absolutely no code behind other than Initialize in the view which is exactly where we want to be.

Let’s now provide some meat to the business object.

If you fail to implement the INotifyPropertyChanged interface in this business object, updating items in the list will not refresh in the UI regardless of how many times and in how many places you throw the RaisePropertyChanged event.
 

We have three properties: A progress percentage value (double), a string body and a boolean complete flag. In addition there is a private implementation of that calls the PropertyChanged event for each property.

Here is the code:

using System.ComponentModel; namespace BackgroundTest.Models
{
     public class ProcessItem : INotifyPropertyChanged
     {
          
          private double _progress = 0;
          public double Progress
           {
              get
              {
                   return _progress;
              }
              set
               {
                   if (_progress != value)
                   {
                        _progress = value;
                        RaisePropertyChanged("Progress");
                   }
              }
           }
     
          private string _commandData = string.Empty;
          public string CommandData
           {
              get
              {
                   return _commandData;
              }
              set
              {
                   if (_commandData != value)
                   {
                        _commandData = value;
                        RaisePropertyChanged("CommandData");
                   }
              }
          }
   
          private bool _isComplete = false;
          public bool IsComplete
          {
              get
              {
                   return _isComplete;
              }
              set
              {
                   if (_isComplete != value)
                   {
                        _isComplete = value;
                        RaisePropertyChanged("IsComplete");
                   }
              }
          }
  
          public event PropertyChangedEventHandler PropertyChanged;
          private void RaisePropertyChanged(string prop)
          {
              if (PropertyChanged != null)
              {
                   PropertyChanged(this, new PropertyChangedEventArgs(prop));
              }
          }
      }
} 

 

The Long Running Processor

Now lets take a look at LongRunningObject. Remember that this is a pseudo object that simulates a long running call to a web service or some heavy client-side processing that must take place.

We have two public events that fire during processing to notify clients of progress and to state that processing is complete.

When the single public method fires, the events are thrown and a for loop with a sleep timer is used to simulate a long process. Once the loop is complete, the completion event is thrown with the appropriate payload.

Note that I’m throwing a new ProcessItem with each event. This is not completely necessary but the goal is to indicate that anything can come back, not just the input parameter. Remember, this is occuring on a different thread and care should be taken when passing references around in this manner.

Here is the code:

using System;
using System.Threading;
 
namespace BackgroundTest.Models
{
     public class LongRunningObject
     {
          public event Action<ProcessItem> WorkCompleted;
          public event Action<ProcessItem> WorkProgress;
          
          public void RunWorkAsync(ProcessItem inputData)
          {
              double iMax = 25;
              // Throw starting progress event
              WorkProgress(new ProcessItem()
                    {
                         Progress = 0,
                         CommandData = inputData.CommandData
                    });
 
              for (double i = 0; i < iMax; i++)
              {
                   Thread.Sleep(1200);
                   double dProg = (i + 1) / iMax;
                   // Throw the current progress event
                   WorkProgress(new ProcessItem()
                         {
                              Progress = dProg,
                              CommandData = inputData.CommandData,
                             IsComplete = false
                        });
              }
              // Throw the completed event
              WorkCompleted(new ProcessItem()
                    {
                         Progress = 1,
                         CommandData = inputData.CommandData,
                        IsComplete = true
                   });
          }
     }
}
 

That’s it for plumbing and faux code. Now let’s open the MainViewModel and get the real work done.

The ViewModel

First, we’ll add the properties required by the UI. We’ll need a property to bind the RelayCommand (StartLongRunningExecCommand), a string property to bind to the UI TextBlock (DataText), a simple counter to track how many BackgroundWorker objects we have in process (ProcessorCount) and an ObservableCollection to store all the items being processed by the BackgroundWorker (TokenList). Each of these properties will execute the RaisePropertyChanged event in the setter if the source value changes. This means that you should always update the value by setting the property, not hitting the storage field directly if you want the UI to update it’s binding sources.

We also need a local private variable to store the UI thread’s Dispatcher. This will be our means of updating the UI when progress is received from the BackgroundWorker object.

private Dispatcher currentDispatcher;
 

We’ll wire this up in the constructor:

currentDispatcher = App.Current.RootVisual.Dispatcher;
 

The actual work that takes place happens because in the constructor we also wire up the RelayCommand to a method.

StartLongRunningExecCommand = new RelayCommand<string>(p =>
     {
          StartProcess(p);
     });
 

The StartProcess method first instances the events that will be handled during processing:

DoWorkEventHandler workHandler = null;
RunWorkerCompletedEventHandler doneHandler = null;
Action<ProcessItem> longRunProgress = null;
Action<ProcessItem> longRunCompleted = null;
 

Then we set up the BackgroundWorker, assign it’s events and begin the work. Note that inside each delegate event that should fire only once, we immediately unwire the event from the source object to prevent memory leaks from orphaned objects. This makes it very plain that an object can be garbage collected. For events that fire multiple times, care should be taken to unwire those events upon final cleanup. Here we do it when the WorkCompleted event fires from the business object. Additionally, note that we call the currentDispatcher.BeginInvoke method in various places. This allows the method passed to be called on the original UI thread.

Here is the entire StartProcess method:

 
public void StartProcess(string commandData)
{
     // Events used during background processing
     DoWorkEventHandler workHandler = null;
     RunWorkerCompletedEventHandler doneHandler = null;
     Action<ProcessItem> longRunProgress = null;
     Action<ProcessItem> longRunCompleted = null;
  
     // Implementation of the BackgroundWorker
     var wrkr = new BackgroundWorker();
     wrkr.DoWork += workHandler =
 
          delegate(object oDoWrk, DoWorkEventArgs eWrk)
          {
              // Unwire the workHandler to prevent memory leaks
              wrkr.DoWork -= workHandler;
              LongRunningObject LongRun = new Models.LongRunningObject();
              LongRun.WorkProgress += longRunProgress =
                   delegate(ProcessItem result)
                   {
                        // Call the method on the UI thread so that we can get
                        // updates and avoid cross-threading exceptions.
                        currentDispatcher.BeginInvoke(
                             new Action<ProcessItem>(AddToken), result);
                   };
              LongRun.WorkCompleted += longRunCompleted =
                   delegate(ProcessItem result)
                   {
                        // Unwire all events for this instance
                        // of the LongRunningObject
                        LongRun.WorkProgress -= longRunProgress;
                        LongRun.WorkCompleted -= longRunCompleted;
                        currentDispatcher.BeginInvoke(
                             new Action<ProcessItem>(AddToken), result);
                   };
 
               // Events are wired for the business object,
               // this where we start the actual work.
              LongRun.RunWorkAsync(
                   new ProcessItem() { Progress = 0, CommandData = dataText });
          };
     wrkr.RunWorkerCompleted += doneHandler =
          delegate(object oDone, RunWorkerCompletedEventArgs eDone)
          {
              // Work is complete, decrement the counter
              // and kill references to teh donHandler.
              wrkr.RunWorkerCompleted -= doneHandler;
              procCount--;
              RaisePropertyChanged("ProcessorCount");
          };
      // This is where the actual asynchronous process will
      // start performing the work that is wired up in the
      // previous statements.
     wrkr.RunWorkerAsync();
     procCount++;
     RaisePropertyChanged("ProcessorCount");
}
 

The AddToken method is a simple synchronizer that eitehr adds the text value to the UI-bound list or updates the progress value. Once again, if you did not implement INotifyPropertyChanged in your business object, setting the itm.Progress and itm.IsComplete values would not update values on the UI thread.

That’s pretty much it. I’ve included the complete code listing for the Silverlight side here.

http://weblogs.asp.net/blogs/jimjackson/Files/BackgroundTest.zip

 
Silverlight Adventures - The Process So Far

I’m currently in the process of rebuilding my Silverlight application. The initial beta of this app was somewhat underwhelming in that the problems it solved were those I found most interesting, not necessarily those the beta testers were looking for resolutions to. So we head back to the drawing board, this time to build out something that benefits my users as well as provides me with exposure to real world problems that I may not encounter in my day job.

My employer has a number of MVP’s, authors and early adopters in various technologies, mostly Microsoft focused. They get their experience through lots and lots of study, helping out on projects they are not officially a part of, writing and public speaking. I’m fortunate to be a part of such a talented team but I have found that for various reasons, writing, public speaking and dissecting toolkit bits are not really my bag. It’s just too hard to focus on the abstract without a real business problem to apply it to. Building out MuddyGPS.com has provided that focus. I hope that at some point it will make a few dollars and pay for the hosting but in the mean time, it’s a valuable tool for thinking through the architectural solutions for various problem spaces. I have at least 3 or 4 other ideas for ‘amazing’ Silverlight applications in areas where I have some extra-development experience. If only there were another 8 or 10 hours in the day, I’d be good to go!

So here are a few items I’m currently monkeying around with:

Securing Data from Authenticated and Anonymous Users

·         My trails are available only from my site. I want to keep everyone, including my users, from seeing that raw data. They should only be able to view the trails within a map extent via my viewer. They should not be able to ping my service directly and scrape my data.

·         Once authenticated, a user can hit my web services all they want. I haven’t looked too deeply into javascript injection for a while but I know it’s possible because I’ve watched my logs and found that at least one caller is ‘tiling’ my maps looking for everything in my system. Of course it didn’t work but it didn’t stop him from trying.

·         Anonymous users are easy but there are some steps you need to consider in setting up your site when it’s in a hosted environment to be sure it’s secure.

Asynchronously Loading Data To and From a Web Service

·         Once security was taken care of I found that loading 2,500 lines onto a map would cause the UI thread to hang long enough that I’d break into the code to see if something was busted.

·         Taking large data calls, breaking them up and recomposing the messages both on the client and server can take longer but providing the UI with a chance to redraw a small part of the screen at a time gives an animation effect that can be informative to the user, more interesting than a percent bar and give your user a more patient outlook on things.

·         Background threads are also fun but getting back to the UI update in a pattern-based operation can introduce some spaghetti-like coding habits that nobody wants to read or debug.

File Uploads and Downloads

·         The most important questions for file uploads are:

o   Do you upload the file as-is and process on the server?

o   How long will the entire upload operation take?

·         Processing a file on the server has advantages in that you have the file and can always go back and reprocess it. The down side is that if you are not using all the data from the file, you are consuming more bandwidth than necessary. You are also probably storing both the file and the data from that file so you are dramatically increasing your server storage requirements. I’ve currently got about 370 Gb of GPS data on my server and it’s growing all the time. If I put all of this in my hosted environment I’d be out of money pretty quickly.

·         For images being uploaded to a site, you also need to consider whether or not you want to shrink the image before upload. I’m not there yet so I don’t know what SL 4 has in store for me in that venue.

·         In considering the upload time for a file, you need to decide what kind of proxy your WCF service will use. A custom binding with BinaryEncoding will allow for very large downloads but I’ve been personally unable to increase the upload size past 8,192 bytes. Also, since upload speeds are almost always slower than downloads for residential broad band, you need to think about whether or not you should break out the code into multiple uploads and whether or not a Polling Duplex service that gives some feedback about progress is appropriate.

SQL Server Geography Types

·         It’s interesting to me that there is so much discussion of geo-this and geo-that at Microsoft but very few people are discussing how to effectively use the geography and geometry types in SQL Server. Perhaps it’s because they are not supported outside of SQL Server in EF, ADO.Net or pretty much anything else.

·         My experience so far is that you should store both the geographic raw data AND the compiled geography field when using these types. Each has their own place and together you can get a lot of information very quickly.

·         The biggest problem with geography types is their speed. When I’m looking for all points in a map extent, I cannot define a geographic index and then get everything in it. My users may only be viewing that extent for 10 seconds. It’s much easier to store my center points or individual lat/longs in decimal columns and then index those. Crazy fast and I still get the geography features once I have my base rowset to work with.

·         The general rule I follow is to use geography types to calculate but not to select.

Patterns and Practices

·         I’m pretty happy at this stage with MVVM Light from Laurent Bugnion of GalaSoft. It’s a very easy to use, free helper tool kit for both WPF and Silverlight. What it took a few days for me to get through my thick skull was that MVVM is a pattern for the client. That’s all. As a developer, you need to implement other patterns on the server (service) side. Probably a no-brainer for most but I’m old and set in my ways so it took a bit to sink in.

·         The challenge for me is still the Inversion of Control (IOC) stuff, TDD for Silverlight and mocking. Again, all in good time. It’s difficult to hold off forging ahead solving the cool problems and take a breath to build out some unit tests. The results are almost always a stronger platform though and I AM learning.

Styling

·         The greatest thing for me about Silverlight is the ability to provide an immersive environment to a user where subtle queues guide a user through the process of doing whatever you want him to do. This is a blessing and a curse because all of these styling operations can take a lot (!!!) of time if you hand-code them or much less time if you learn to use Expression Blend right the first time! Blend is a true designers tool and I’m no designer. I have a couple of friends who do a lot of graphic design and I’ve been trying to convince them to start working with Xaml. No luck yet but I really believe there will be a thriving employment market for top-shelf Xaml designers very soon.

·         The other problem with styling is deciding how much is too much. For instance, CompletIT has an amazing Silverlight presentation on their site but it’s literally so much that it’s distracting! There is no doubt that they know their stuff and as a design firm, perhaps that site shows the coolness. To me though I would rather see fewer effects and more usability. See a previous post about a good hammer…

So I’ve started blogging again. I think that I’m going to tinker around with an MVVM-friendly background worker for uploading large contents and see how it goes.

Probably the best thing about Silverlight for me is the fact that it's not BI, it's not Sharepoint, it's not CRM and it's not BPM. I had considered the shrink-wrap-framework-package-as-a-foundation-for-everything-under-the-sun to be the wave of the future. It still may be, but I have found that development job to be tedious and uninspiring. I have some experience in all those packages and am looking forward to seeing how an immersive RIA technology like Silverlight can make them even better. An effective UI provides the user with guidance to get their job done better and faster. Now THAT sounds like a project that would wake me up in the morning.

 

More Posts