Awhile back I did an interview with XAMLCast about the philosophy behind ReactiveXaml and basically what the library is about. If you’ve got the time between checking out all the great PDC10 videos, check this out as well:

Some folks from the nRoute Framework were looking for an elegant way to handle displaying an intermediate value during async updates – something like changing the text to say “Working…” until the task is complete, then displaying the results. I realized this was pretty easy to do with ReactiveXaml, so I wrote up some code – here it is:

One of the scenarios that our summer intern Roberto Sonnino pointed out over the summer that was somewhat annoying in ReactiveXaml (my MVVM library that integrates the Reactive Extensions for .NET), was making RxXaml more friendly to asynchronous web service calls in Silverlight. Since this is a pretty important scenario, I decided to hack on it some (it’s always been possible, just not as easy).

Getting our function prototype correct

Remember from an earlier post that an IObservable can be used as a Future, a “box” that will eventually contain the result of a web service call or other asynchronous function, or the error information. So to this end, we’d really like our web service calls to all be vaguely of the form:

However, we know that neither HttpWebRequest nor the web service generated code looks anything like that. Normal Silverlight objects use an OnCompleted event to fire a callback once the call completes. The Rx framework designers saw this coming however, and gave us a pretty handy function to deal with it: Observable.FromAsyncPattern(). This function will take a BeginXXXX/EndXXXX pair that follows the .NET Asynchronous Pattern and in return, will give us a Func that follows the form above, without us having to write some boilerplate code to connect the async method to an IObservable.

An example: looking at the Bing Translation API

One of the most simple public web services is the Bing Translation API, so its Translate() method is a good candidate for our example. The synchronous signature is:

Here’s how we could take this and turn it into an Rx-friendly Async function – don’t be scared off by the five template parameters, they’re just the types of the parameters and return value, in the same order as a Func<T>:

An important note for Silverlight!

Silverlight’s web service generated client code does something a bit annoying – it hides away the BeginXXXX/EndXXXX calls, presumably to make the Intellisense cleaner. However, they’re not gone, the way you can get them back is by casting the MyCoolServiceClient object to its underlying interface (i.e. the LanguageServiceClient object has a generated ILanguageServiceClient interface that it implements)

Turning this into a Command

Once we’ve got the function, turning it into a command is easy via a new method introduced to ReactiveAsyncCommand – RegisterObservableAsyncFunction. This method is almost identical to RegisterAsyncFunction, but instead of expecting a synchronous Func which will be run on the TPL Task pool, it expects a Func that returns an IObservable as described above. Here’s a simple example of a good ViewModel object that demonstrates this:

What does that get us?

Let’s review what this fairly short, readable code gets us – using a few simple bindings, we’ll have a fully non-blocking, responsive UI that correctly handles a lot of the edge cases associated with background operations: greying out the Button attached to the Command while the web call is running, saving off the results, then notifying the UI that there is something new to display so that it updates instantly, without any tricky callbacks or mutable state variables that have to be guarded by Lock statements to ensure multithreaded safety. That’s pretty cool.

Some folks on the mailing list for ReactiveXaml rightly pointed out some code in ReactiveXaml that could really use some work – my implementation of INotifyPropertyChanged’s “RaiseAndSetIfChanged”. For the impatient, here’s how I did it

Trying to make RaisePropertyChanged less verbose

This method is a helper method designed to encapsulate the following common code pattern when implementing a property:

1. Make sure that the property is different than the original value
2. Set the property to the new value
3. Call RaisePropertyChanged with the name of the property that has changed

Doing this via a helper is a little bit tricky – the naive approach often forgets #1 entirely, or will try to do #2 and #3 in the opposite order, resulting in WPF/Silverlight not correctly updating. Another problem is that we usually have to pass in a string literal to RaisePropertyChanged (as well as RaiseAndSetIfChanged). While I’m a Rubyist and string literals don’t bother me, most .NET developers are annoyed by it, and it also can lead to really evil-to-debug issues after refactoring.

Using Expression Trees to implement a better version

Here’s what the new syntax for defining properties looks like:

Much improved, and fairly clean (we could do way better if C# had Macros, but I digress). Compare this with the old, dumb looking syntax:

Or doing this by-hand:

How can we do this? Expression Trees! When we write Expression<Func<T>> as a type instead of Func<T>, instead of getting a compiled method pointer, we get an object representing the AST of the lambda function. We’ll use this to grep out the property name.

Astute readers will notice an issue – how can we correctly decide T so that Intellisense works correctly? If we naïvely choose ‘ReactiveObject’ as T, none of our properties will be defined, since they’re all really defined on the derived class, not on ReactiveObject itself. To solve this, we’ll use a Mixin plus a cleverly typed generic function – since the first parameter of an extension method is the type itself, the compiler will automatically bolt this on to any ReactiveObject while still treating it as the correct derived type:

Some tricky caveats

It’s not all biscuits and gravy though, there are a few subtle implementation details that might catch you when using this – remember though, that you can always fall back to writing it by-hand via RaisePropertyChanged, this method is solely a helper:

1. You must name the field that backs your property as _TheFieldName – we use Reflection to set the backing field
2. Writing the ‘this’ in ‘this.RaiseAndSetIfChanged’ isn’t optional – otherwise the extension method won’t be invoked, the old busted version will

A thread-safe, asynchronous MemoizingMRUCache

As we saw in a previous entry, MemoizingMRUCache is great for certain scenarios where we want to cache results of expensive calculations, but one disadvantage is that it is fundamentally a single-threaded data structure: accessing it from multiple threads, or trying to cache the results of several in-flight web requests at the same time would result in corruption. QueuedAsyncMRUCache solves all of these issues, as well as gives us a new method called AsyncGet, which returns an IObservable. This IObservable will fire exactly once, when the async command returns.

What places would I actually want to use this class? Here’s a motivating example: you’re writing a Twitter client, and you need to fetch the profile icon for each message – a naive foreach loop would be really slow, and even if you happened to write it in an asynchronous fashion, you would still end up fetching the same image potentially many times!

Using IObservable as a Future

One of the things that an IObservable encapsulates is the idea of a Future, described simply as the future result of an asynchronous operation. The pattern is implemented via an IObservable that only produces one element then completes. Using IObservable as a Future provides a few handy things:

• IObservables let us block on the result if we want, via Observable.First().
• IObservables have built-in error handling via OnError, so we can also handle the case where something goes pear-shaped.
• We can easily group several IObservables together via Observable.Merge and wait for any (or all) of them.

A difficult problem – preventing concurrent identical requests

Furthermore, QueuedAsyncMRUCache solves a tricky problem as well: let’s revisit the previous example. As we walk the list of messages, we will asynchronously issue WebRequests. Imagine a message list where every message is from the same user:

For the first item, we’ll issue the WebRequest since the cache is empty. Then, we’ll go to the 2nd item – since the first request probably hasn’t completed, we’ll issue the same request again. If you had 50 messages and the main thread was fast enough, you could end up with 50 WebRequests for the same file!

What should happen? When the 2nd call to AsyncGet occurs, we need to check the cache, but we also need to check the list of outstanding requests. Really, for every possible input, you can think of it being in one of three states: either in-cache, in-flight, or brand new. QueuedAsyncMRUCache ensures (through a lot of code!) that all three cases are handled correctly, in a thread-safe manner.

One of the folks using RxXaml is our intrepid intern, Roberto Sonnino (he’s the one who came up with the short name RxXaml!) – he’s created some handy snippets that will expand out to the standard forms of a read-write ReactiveObject property, as well as a property backed by ObservableAsPropertyHelper. I’m personally against snippets since I want typing extra code to cost me personally as much as possible, encouraging me to be more general and brief! However, I think in this case it’s a good idea – here are the snippets:

• ObservableToPropertyHelper.snippet
• ReadWriteViewModelProperty.snippet

Memoization and Caching

One thing that is useful in any kind of programming is having a look-up table so that you don’t have to spend expensive calls to fetch the same data that you just had recently, since fetching the data and passing it around via parameters often gets ugly. A better way is to use a cache – store values we’ve fetched recently and reuse them. So, a naïve approach would be to store the data off in a simple Dictionary. This might work for awhile, but you soon realize as Raymond Chen says, “Every cache has a cache policy, whether you know it or not.” In the case of a Dictionary, the policy is unbounded – an unbounded cache is a synonym for ‘memory leak’.

To this end, one of the things that comes with ReactiveXaml is a class called MemoizingMRUCache. As its name implies, it is a most recently used cache – we’ll throw away items whose keys haven’t been requested in awhile; we’ll keep a fixed limit of items in the cache, unlike other approaches involving WeakReference that keep references to items only if they’re used on some other thread at the time. Since most desktop / Silverlight applications aren’t so massively multithreaded as a web application, using a WeakReference approach means we’ll just get constant cache misses.

Using MemoizingMRUCache

Really when it comes down to it, you can just think of MemoizingMRUCache as just a proxy for a function – when you call Get, it’s going to invoke the function you provided in the constructor. One thing that’s important to understand with this class, is that your function must be a function in the mathematical sense – i.e. the return value for a given parameter must always be identical. Another thing to remember is that this class is not implicitly thread-safe – unlike QueuedAsyncMRUCache, if you use it from multiple threads, you have to protect it via a lock just like a Dictionary or a List.

Here’s a motivating sample:

Maintaining an on-disk cache

MemoizingMRUCache also has a feature that comes in handy in certain scenarios: when a memoized value is evicted from the cache because it hasn’t been used in awhile, you can have a function be executed with that value. This means that MemoizingMRUCache can be used to maintain on-disk caches – your Key could be a website URL, and the Value will be a path to the temporary file. Your OnRelease function will delete the file on the disk since it’s no longer in-use.

Some other useful functions

• TryGet – Attempt to fetch a value from the cache only
• Invalidate – Forget a cached key if we’ve remembered it and call its release function
• InvalidateAll – Forget all the cached keys and start from scratch

Implementing an auto-search TextBox using Rx and ReactiveXaml

One of the most important classes in ReactiveXaml called ObservableAsPropertyHelper is a class that allows you to take an IObservable and convert it into a read-only, change notifying property. This class is really useful for exposing the results of your code (i.e. the “output”). This class makes it easy to complete the scenario that was described in the previous blog post about ReactiveAsyncCommand. One of the cool things about ObservableAsPropertyHelper, is that it guarantees that it will run notifications on the UI thread via the Dispatcher so that you don’t have to think about what thread the observable notification came in on.

The sample app

Click on the image to download the sample project.

Going through the code

First, let’s look at our main data item – a Flickr search result item. Since we will never change these objects, we don’t need any INotifyPropertyChanged goo, just regular old auto-properties:

Now, the app data model – there’s two real bits; the current search text, and the List of FlickrPhoto results. In ReactiveXaml, all of this code below is boilerplate – these code chunks are just some stuff to memorize or put into a snippet and never look at it again. Note: once again because of a syntax highlighting glitch, generics are using [] instead of < >

Now here’s the interesting part

Our goal is to write a search box which automatically issues searches in the background as the user types, similar to what most browsers do with the address bar. However, there are a number of tricky aspects to this:

• We don’t want to issue too many requests, especially when the user is still typing, so wiring something directly to KeyUp would be lousy.
• Don’t issue queries for empty strings, and don’t issue the same query 2x (for example, if the user types “foo”, then quickly hits Backspace, then retypes ‘o’, we should realize that we already have the right results)
• The delay should be consistent, so having a global timer won’t work because sometimes the user will hit the key right before the timer fires, so the delay will vary wildly between the max time and instantaneous.

Implementing this properly using traditional methods would be absolutely awful. Here’s the code on how we do it, and it’s 5 lines in the constructor:

Here’s the code that actually does the work as an aside, it’s not nearly as pretty:

ViewModels via ReactiveObject

Like any other MVVM framework, ReactiveXaml has an object designed as a ViewModel class. This object is based on Josh Smith’s ObservableObject implementation in MVVM Foundation (actually, many of the classes’ inspiration come from MVVM Foundation, Josh does awesome work!). The Reactive version as you can imagine, implements INotifyPropertyChanged as well as IObservable so that you can subscribe to object property changes.

Other things that are nice to have

ReactiveObject also does a few nice things for you: first, when you compile ReactiveXaml in Debug mode, it will print debug messages using its logging framework whenever a property changes. Another example is, implementing the standard pattern of a property that raises the changed event is a few lines shorter:

Compared to the traditional implementation which is a few lines longer:

Some philosophy

A lot of examples of the Reactive Extensions make its domain appear really constrained, like the only thing it’s ever useful for is either handing web service requests and implementing drag-and-drop. However, here’s the key thing to realize – a property change notification is an event. Once you realize that Reactive Programming applies to any time an object changes state, Rx suddenly becomes far more applicable to any programming domain – really, Rx is a library to model state machines that are context-free with respect to threading.

Abstracting away context is critical for a multicore + cloud world

What do I mean by “context-free”? Well, just as LINQ abstracts away the idea of a for loop into these operations like “Select” and “Where”, where the implementation is separate from the semantics, Rx does the same thing. When you call Where() on an IEnumerable, the default implementation is a simple loop – but add an .AsParallel(), and suddenly the same code is now running on multiple cores. Use Dryad, and the same code is running on multiple machines in an HPC cluster.

In traditional imperative programming, we are always explicit about the thread context in which we were running in – to put work on another thread, we had to call new Thread(). The really interesting thing about Rx, and the reason that Rx is made by the “Cloud Programmability Group” inside MS, is that Rx is also an abstraction above context – in Rx, you usually don’t care what thread you’re running on, and you only have to specify it when you explicitly do care via ObserveOn (like to deal with WPF’s thread affinity). Observables are essentially a way to declaratively write dependencies between incoming data sources without explicitly specifying the mechanism of their synchronization, only their semantics.

Do you see where I’m going with this? If the concept of “Lock” and “Thread” are no longer concretely tied to a kernel thread and a Critical Section, this means that you can write the same Rx code, and go from a single thread, event-based model with no locks, to a multicore model that synchronizes via locking, to a cluster of computers in a lab which synchronize via a message-passing model, to a giant cloud computing array that synchronizes via a service bus. I think that’s awesome.

A Sample App makes understanding ReactiveXaml way easier

I used this application to help guide the API design around ReactiveXaml, and I think it’s a good illustration on how to use this library to write WPF applications. The original goal of it was to teach WPF to folks, so it has a ton of documentation in the comments – it almost is “blogging via code”, and I think it’s a really interesting way to express ideas, calling back somewhat to Knuth’s ideas of Literate Programming

Our sample app helps us make a list of Awesome People

Make sure to read the code!

A lot of people who originally saw this sample ran it, saw that it didn’t really do anything interesting, then forgot about it. The app itself is boring, the code is what’s important! Read through it, there are lots of “essays” scattered throughout the source code, they all start with the tag “COOLSTUFF” – searching for it will help you find guidance on Rx, MVVM, as well as things like layout and bindings.

This dialog shows validation, async web requests, and a clever use of Flickr

Where’s the code again?

It’s at the ReactiveXaml repository on Github – if any of you want to check this out but have trouble getting Git to work, let me know via Email at paul@paulbetts.org or Email the mailing list and I’ll help you out.