Net Dots

.Net and programming in general

Code paste from Visual Studio

Hooray, very nice HTML code formatter is available for Live Writer.

http://plugins.live.com/writer/detail/paste-from-visual-studio

In action:

        public static IObservable<T> Previous<T>(this IObservable<T> source)
        {
            return source
                .Scan(Tuple.Create(default(T), default(T)), (prev, current) => Tuple.Create(prev.Item2, current))
                .Skip(1)
                .Select(x => x.Item1);
        }
Advertisements

July 17, 2012 Posted by | Uncategorized | Leave a comment

Making list navigation responsive using Reactive Extensions-part 3 (CombineVeryLatest)

Let’s take a look at creating a variation of CombineLatest operator which we used as a part of SampleResponsive extension in the previous article in the series. We needed an operator that would combine two most recent elements from source observables on one-to-one basis (in the combined observable, no element from any of the sources would appear twice). CombineLatest almost makes the first part of this requirement, and we just need to filter out extra pairs that contain duplicate elements.

The first trick we will use is a Select overload which allows us to generate id’s attached to our elements. The resulting observable contains pairs of tuples, each containing both the real value and id:

                 return  Observable .CombineLatest(
                     leftSource.Select(Tuple .Create<TLeft, int >),
                     rightSource.Select(Tuple .Create<TRight, int >),
                         (x, y) => new  { x, y })
  

Now, we can introduce a “state” to our extension which would track the latest id’s and also make possible to filter the oncoming elements comparing to that id’s. We update the state by inserting a side-effecting extension .Do right after the filter:

         public  static  IObservable <TResult> CombineVeryLatest<TLeft, TRight, TResult>(this  IObservable <TLeft> leftSource,
           IObservable <TRight> rightSource, Func <TLeft, TRight, TResult> selector)
         {
             int  l = -1, r = -1;
             return  Observable .CombineLatest(
                 leftSource.Select(Tuple .Create<TLeft, int >),
                 rightSource.Select(Tuple .Create<TRight, int >),
                     (x, y) => new  { x, y })
                 .Where(t => t.x.Item2 != l && t.y.Item2 != r)
                 .Do(t => { l = t.x.Item2; r = t.y.Item2; })
                 .Select(t => selector(t.x.Item1, t.y.Item1));
         }
  

This is the same signature as CombinedLatest has. The only thing left is to isolate the state (l and r variables) within the extension from multiple subscribers. This is usually done by using the .Defer() method (which would also make our observable Cold):

         public  static  IObservable <TResult> CombineVeryLatest<TLeft, TRight, TResult>(this  IObservable <TLeft> leftSource,
           IObservable <TRight> rightSource, Func <TLeft, TRight, TResult> selector)
         {
             return  Observable .Defer(() =>
             {
                 int  l = -1, r = -1;
                 return  Observable .CombineLatest(
                     leftSource.Select(Tuple .Create<TLeft, int >),
                     rightSource.Select(Tuple .Create<TRight, int >),
                         (x, y) => new  { x, y })
                     .Where(t => t.x.Item2 != l && t.y.Item2 != r)
                     .Do(t => { l = t.x.Item2; r = t.y.Item2; })
                     .Select(t => selector(t.x.Item1, t.y.Item1));
             });
         }
 

All done! This extension is useful in situations when you need to combine pairs of values that “expire” after being combined.

February 9, 2011 Posted by | Uncategorized | Leave a comment

Making list navigation responsive using Reactive Extensions-part 2 (SampleResponsive)

In the previous article in this series we used standard RX operator Throttle to reduce the frequency of details view updates while navigating between records in a list. We have identified two problems with this  approach:

  • A “single” navigation does not cause the details to start refreshing immediately, creating an illusion that the system is sluggish.
  • While we navigating continuously, details are not refreshed, so we do not have a good idea where in the list we are located currently.

The second point can be addressed by using Sample instead of Throttle. Think of Sample as of a strobe light – it flashes periodically revealing the last event that happened just before. If we replace Throttle with Sample in out example from previous article, we would have responsive solution with some “feedback” but unfortunately our biggest problem of not “reacting immediately” still stands.

We need a new observable extension, that follows these rules:

  • “Front” event or an event that happens after some period of inactivity is passed through immediately.
  • Events that come frequently are filtered out but some are passed through periodically
  • The last event before inactivity is always passed through.

Sounds complex? The good news, there is a “real world” apparatus implementing these rules so it can serve as a reference model for us. Here:

ak47

 

Think of it. Always ready to fire (the way we like our details navigation), firing at fixed intervals when trigger is held. Let’s copy the model and use in our "SampleResponsive” extension. Machine gun works by using the power of a shot (recoil or gas) to load the next round into the chamber. In our case, we need somehow mix the external events (trigger presses) with internal process (reloading) and this combination of events (fire) will be our target observable, to which we would subscribe and which would also feed the internal process. In other words, our system will contain a positive feedback loop. What is interesting, the RX logo itself contains a reference to this concept:

RXLogo

Interesting, isn’t it? Let’s start then. To “stitch” the loop together, we must use a Subject, otherwise we have no way to feed the stream of events back to itself. The Subject, being both IObserver and IObservable, can be subscribed on and subscribed to. Let’s call it fire:

                 
                 var  fire = new  Subject <T>();
  

Now we need to emulate the process of “reloading” which we will create with a simple Delay extension, assuming for simplicity it takes a half of a second to reload the next round:

 
                 var  whenCanFire = fire.Delay(TimeSpan .FromSeconds(0.5));
 

This whenCanFire observable signifies a collection of moments when a fresh round in the chamber becomes available. Now, wait a second… To start firing, we need to have the first round ready, otherwise we will not be able to start this chain of events. Let’s feed the first round manually:

 
                 var  whenCanFire = fire
                     .Delay(TimeSpan .FromSeconds(0.5))
                     .StartWith(default (T));
  

Now we can bring together these two sequences – one when trigger is pressed (source parameter in our SampleResponsive extension) and another is whenCanFire from above. What RX function we can use for this task? Unfortunately, the entire library contains only two “parallel combinators” – Zip and CombineLatest. All other extensions are either “non-parallel”, meaning that combined observables play different roles; or not “combinators”, meaning that they do not bring pairs of events together (Merge is an example). CombineLatest is probably the closest to what we want, but if we use it, our “machine gun” would act like one with a trigger that “stuck” – one press of the trigger and it would fire continuously without additional presses. We need to combine only one press with one round, consuming both in the firing process. Let’s call this new observable extension CombineVeryLatest and we will create it in the next article. For now, let’s just assume it has the same signature as CombineLatest with the difference that each element in the pair can be used only once. We use our new extension to join the external and internal processes and to create the positive feedback loop:

 
                 var  subscription = src
                     .CombineVeryLatest(whenCanFire, (x, flag) => x)
                     .Subscribe(fire);
  

Bringing it all together, here is our extension:

 
         public  static  IObservable <T> SampleResponsive<T>(
                 this  IObservable <T> source, TimeSpan  delay)
         {
             var  fire = new  Subject <T>();
 
             var  whenCanFire = fire
                 .Delay(delay)
                 .StartWith(default (T));
 
             var  subscription = source
                 .CombineVeryLatest(whenCanFire, (x, flag) => x)
                 .Subscribe(fire);
 
             return  fire.Finally(subscription.Dispose);
         }
  

We still have some work to do. Observables come in two “flavors” or rather “temperatures” – cold and hot. “Cold” ones perform all subscription activity separately for each subscriber, “Hot” observables do it once, when first subscription appears. What temperature is ours? It is hard to say, SampleResponsive combines a Subject which is a Hot observable with CombineVeryLatest, which is a Cold observable – maybe we can call ours “lukewarm”. This is not good – f.e. the above implementation would create the subject and internal subscription always, even if nobody subscribes to it. So where should we go temperature-wise – to hot or to cold? Let’s ask ourselves – if we have two subscribers  are we Ok to receive the same set of events for each? I think yes, so the decision is made to make our extension Hot:

 
         public  static  IObservable <T> SampleResponsive<T>(
                 this  IObservable <T> source, TimeSpan  delay)
         {
             return  source.Publish(src =>
             {
 
                 var  fire = new  Subject <T>();
 
                 var  whenCanFire = fire
                     .Delay(delay)
                     .StartWith(default (T));
 
                 var  subscription = src
                     .CombineVeryLatest(whenCanFire, (x, flag) => x)
                     .Subscribe(fire);
 
                 return  fire.Finally(subscription.Dispose);
             });
         }
  

Now all “internals” – Subject, subscription, etc. will be created only once when the first subscriber checks in. Let’s use it, replacing the Throttle in our subscription (see previous article) with SampleResponsive:

 
             _whenItemSelected
 //                .Throttle(TimeSpan.FromSeconds(0.4)) 
                 .SampleResponsive(TimeSpan .FromSeconds(0.4))
                 .Do(_ => ReadDetailData())
                 .Subscribe(_ => InvokePropertyChanged("Details" ));
  

Running the application, we can see that we are back to square one – it acts sluggish again. Looking at the debug output, we can see our “detail reading” process happens on the main UI thread. There are two ways to deal with it and demand “task pool processing”. One, we can use ObserveOn operator:

 
             _whenItemSelected
 //                .Throttle(TimeSpan.FromSeconds(0.4)) 
                 .SampleResponsive(TimeSpan .FromSeconds(0.4))
                 .ObserveOn(Scheduler .TaskPool)
                 .Do(_ => ReadDetailData())
                 .Subscribe(_ => InvokePropertyChanged("Details" ));
  

Another (and this is preferred approach, since it both gives developer a greater flexibility and enables RX TestScheduler unit testing) is to introduce a scheduler parameter to our extension. Doing this is quite easy – you just squeeze in the scheduler to all elements that can take it (in our case, Subject and Delay):

 
         public  static  IObservable <T> SampleResponsive<T>(
                 this  IObservable <T> source, TimeSpan  delay, IScheduler  scheduler = null )
         {
             return  source.Publish(src =>
             {
                 var  fire = new  Subject <T>(scheduler ?? Scheduler .Immediate);
 
                 var  whenCanFire = fire
                     .Delay(delay, scheduler ?? Scheduler .TaskPool)
                     .StartWith(default (T));
 
                 var  subscription = src
                     .CombineVeryLatest(whenCanFire, (x, flag) => x)
                     .Subscribe(fire);
 
                 return  fire.Finally(subscription.Dispose);
             });
         }
  

It is good to have .Net4 default parameter as the scheduler – but it makes you responsible for providing the right defaults when the parameter is missing. You might notice that the default scheduler used above is different for the Subject and for the Delay. Of course you can make separate statements for default and non-default, but your code would look ugly:

 
                 var  whenCanFire = scheduler == null 
                     ? fire.Delay(delay).StartWith(default (T))
                     : fire.Delay(delay, scheduler).StartWith(default (T));
  

Another better way is to use Reflector and look at the Reactive libraries IL code to find out what defaults different functions use. Here is a little “cheat sheet” showing RX functions and objects grouped by their default scheduler:

Scheduler.ThreadPool: (you can use also Scheduler.TaskPool as a default parameter for these)

Delay

BufferWithTime

GenerateWithTime

Interval

Sample

Start

Throttle

TimeInterval

TimeOut

Timer

TimeStamp

ToAsync

Scheduler.CurrentThread:

Generate

Repeat

Replay

Subscribe (to enumerable)

ToObservable

ReplaySubject constructor

Scheduler.Immediate:

Merge

Prune

Publish

Return

StartWith

Throw

Subject constructor

BehaviorSubject constructor

AsyncSubject constructor

 

Now our extension is ready. Here’s the code using it:

 
             _whenItemSelected
                 .SampleResponsive(TimeSpan .FromSeconds(0.4), Scheduler .TaskPool)
                 .Do(_ => ReadDetailData())
                 .Subscribe(_ => InvokePropertyChanged("Details" ));
  

Now it works as planned – you can navigate fast and smooth, and details are displayed after a minimal delay if you’re changing selection once. In the next article in the series, we will look at the code for CombineVeryLatest.

December 13, 2010 Posted by | Uncategorized | 1 Comment

Making list navigation responsive using Reactive Extensions–part 1 (Throttle)

In the following series, I’ll try to show how Reactive Extensions can be used to make list UI navigation fast while also refreshing the detail view. The nice thing about this example is that it covers a lot of different concepts within RX – the end goal of this series is to make you more familiar with these concepts. You need to have some level of familiarity with the RX library to get through – the RX Hands-On Labs is a good introduction to the area. In this series, I’ll try to concentrate on the practical side of using RX.

Let’s start with the simple UI: create a WPF form that consists from a list box on the left and a text box on the right. The text box will be the “detail view” and we will pretend that it takes a half of a second to refresh this view.

     <Grid> 
     	<Grid.ColumnDefinitions> 
     	    <ColumnDefinition/> 
     	    <ColumnDefinition/> 
     	</Grid.ColumnDefinitions> 
     	<ListBox  
             ItemTemplate="{DynamicResource ItemTemplate}"  
             ItemsSource="{Binding List}" 
             SelectedItem="{Binding Current}" 
             /> 
 	<TextBox Grid.Column="1" Text="{Binding Details, Mode=OneWay}"/> 
     </Grid>

We will use Expression Blend to generate a collection of sample data and to simplify the project we will make the main window to be its own ViewModel. What actually matters to us, is that we cannot display the details instantly:

         private  object  _current;
         public  object  Current
         {
             get  { return  _current; }
             set 
             {
                 _current = value ;
                 Details = ((Item )value ).Property1;
             }
         }
 
         private  string  _details;
         public  string  Details
         {
             get  { return  _details; }
             set 
             {
                 _details = value ;
                 ReadDetailData();
                 InvokePropertyChanged("Details" );
             }
         }
 
         private  static  void  ReadDetailData()
         {
             Debug .WriteLine("Reading details on thread "  + Thread .CurrentThread.ManagedThreadId);
             Thread .Sleep(500);
         }

When we run this project and try to use arrow keys to move the selection within the list box, the experience is painful – the system is non-responsive most of the time, and the fast navigation within the list is impossible. This happens because the process of reading happens on the UI thread, blocking it from processing the furthest events.

What if we execute the reading of details on a secondary thread?:

                 Task .Factory.StartNew(() =>
                                           {
                                               ReadDetailData();
                                               InvokePropertyChanged("Details" );
                                           }); 

This works, and the UI becomes responsive, but there are two problems with the approach:

  1. In real life scenario, each read would take different time to execute, and the earlier (non last) detail can end up being displayed when user stopped navigating.
  2. The system will be overtaxed by the unnecessary reads, since each selection change would lead to a detail read.

Let’s use Reactive Extensions to save us from both problems:

         private  readonly  Subject <string > _whenItemSelected = new  Subject <string >();
         private  string  _details;
         public  string  Details
         {
             get  { return  _details; }
             set 
             {
                 _details = value ;
                 _whenItemSelected.OnNext(value );
            }
         } 

We isolated the cause (details selection change) from the effect (reading of the details) using the _whenItemSelected Subject. A Subject is a “relay” of the RX world that ties together event flows. We will use this to “filter out” unnecessary reads using the Throttle extension method:

         public  MainWindow()
         {
             DataContext = this ;
             InitializeComponent();
             _whenItemSelected
                 .Throttle(TimeSpan .FromSeconds(0.4))
                 .Do(_ => ReadDetailData())
                 .Subscribe(_ => InvokePropertyChanged("Details" ));
             Debug .WriteLine("Executing on thread "  + Thread .CurrentThread.ManagedThreadId);
         } 

Throttle works by filtering out input when it comes more frequently that is specified by the delay parameter.  Below is the “marble diagram” for Throttle:

Throttle

My mental model of Throttle is a ball you keep in the air by kicking it with a foot. While you are kicking, the events are suppressed. When you stop kicking, the ball lands (event goes through). This is what we need to do when navigating through list – skip the events while they are coming, and land the last one that came before pause in the navigation process.

Are we happy now? Almost. My biggest complain about using Throttle is that for single navigation event, reading of details is delayed versus being started immediately. Also, it would be nice to pass through some events when user navigates continuously to give some visual feedback.

Let’s try to make a better “Throttle” in the next article in the series.

November 3, 2010 Posted by | Uncategorized | 1 Comment

Silverlight as a “Rule them all” concept–glad to see you go…

The ZDNet article by Mary Jo Foley ignited an extensive discussion on where is the Silverlight place in the future world. Some people are predicting a swift and painful death to Silverlight, some especially ones with invested interests are arguing that Silverlight will always be a superior choice to HTML5. I liked this post by Tim Heuer which does a good summary on this little war.

My position in the referenced discussion is defined by the fact that I am a WPF developer working on the same product for the last 13 years (of course, it was Delphi before WPF). I think that in the ideal world the applications should be fewer but of much higher quality. And the concept of the “least common denominator”, even in the UI area, does not contribute to quality. I’d like to live in the world where native UI framework with all “bells and whistles” is used for each platform – WPF for Windows, Silverlight for Windows Phone, HTML5 for browser, Cocoa for Mac, IPhone and IPad.

So I am kind of glad to hear about this “strategy shift” – let us build “native” applications and leave Silverlight and Flash the role of a “bridge” technology (with the exception of Windows Phone, where Silverlight is the “native”).

November 2, 2010 Posted by | Uncategorized | Leave a comment