If you’re using Parallels Desktop and you’re trying to use the awesome new MVC stack (IIS Express, SQL Compact, Razor views), you’ll find something quite frustrating: you’ll get error messages to the effect of “redirection.config: File cannot be found”.

Disable Parallels Shared Folders

The cause is that files that are normally local are being redirected to network shares. Disable this in Parallels and all will be right with the world again!

ReactiveUI: Is it All or None?

No! RxUI provides all of the core components that you need to use the M-V-VM pattern, but many people already have applications written using some of the other great .NET MVVM frameworks, such as MVVM Light or Caliburn.Micro – rewriting an entire codebase just to use Rx is a total bummer.

Fortunately, in ReactiveUI 2.2, there have been several features introduced in order to make using RxUI with existing frameworks easier – you can try out RxUI on a per-page basis, instead of rewriting your whole app.

There are really three core bits that are central to MVVM: a ViewModel object, an ICommand implementation, and a change-notifying Collection. Let’s take a look at how we can Rx’ify these three items.

Using MVVM Light alongside ReactiveUI

First, File->New Project and create a new “MVVM Light” projects via the template. Then via NuGet (you are using NuGet, right?), add a reference to the “ReactiveUI” project. Now, crack open MainViewModel.cs. The critical thing to know is, all of RxUI’s awesomeness are extensions onto an interface called IReactiveNotifyPropertyChanged. Ergo, we need to make MainViewModel implement this. But don’t panic, it’s easy!

Step 1: Change the class definition to implement IReactiveNotifyPropertyChanged.

Step 2: Add a field of type “MakeObjectReactiveHelper”, and initialize it in the constructor:

Step 3: Paste in the following code at the end of your class, which just uses _reactiveHelper to implement the entire interface:

An important caveat about MakeObjectReactiveHelper

One thing that probably won’t affect you, but it might: MakeObjectReactiveHelper doesn’t properly completely implement IReactiveNotifyPropertyChanged unless you are also implementing INotifyPropertyChanging – most ViewModel implementations don’t (in fact, the interface doesn’t even exist in Silverlight or WP7). This means that in certain circumstances when you use the WhenAny or ObservableForProperty with a deep path (i.e. x.Foo.Bar.Baz), you may get duplicate notifications. In practice, this usually isn’t a big deal.

Watching ObservableCollections to create ViewModel collections

With RxUI 2.2, you can easily create a collection which tracks an existing collection, even if the source is an ObservableCollection. Here’s the syntax:

Creating ReactiveCommands like RelayCommands

Unfortunately, the story for ICommand isn’t as easy, you have to wrap commands one-at-a-time in order to subscribe to them. Here’s how to do it:

What does ReactiveUI do?

ReactiveUI is a M-V-VM framework like MVVM Light or Caliburn.Micro, that is deeply integrated with the Reactive Extensions for .NET. This allows you to write code in your ViewModel that is far more elegant and terse when expressing complex stateful interactions, as well as much simpler handling of async operations.

ReactiveUI on Hanselminutes

Check out the recent Hanselminutes episode about the Reactive Extensions as well if you’ve got more time. Scott and I chat about some of the ideas in RxUI and how we can take the ideas in the Reactive Extensions and use RxUI to apply them to Silverlight and WPF apps.

What’s New in ReactiveUI 2.2.1 – Now with 100% less Windows Phone crashes

This release is just a maintenance release – if you don’t currently have any issues with RxUI, there is no reason to upgrade. However, there are two major fixes that were worth creating a new release for:

• .NET 4.0 Client Profile – by including System.Reactive.Testing into ReactiveUI.dll, we broke everyone using the Client profile with WPF. This is now fixed and future versions of RxUI will be built against the Client profile.
• WP7 Crashes – if you tried to use RxUI with WP7, you would receive a TypeLoadException whenever a type was instantiated, or possibly a XamlParseException telling you something to the effect of “MainWindow class does not exist”. This issue is now fixed!

Breaking Change: Introducing ReactiveUI.Testing

To facilitate fixing the first bug above, a new Assembly / NuGet package has been introduced, “ReactiveUI.Testing.dll / ReactiveUI-Testing” – this was originally in ReactiveUI Core, and the libraries here help you write better unit tests for your applications (similar to Rx’s System.Reactive.Testing). As a result of this, you may need to add an extra package / library reference to your project when you upgrade to 2.2.1.

Where can I find the library?

On NuGet! The best way to install ReactiveUI for a project is by installing the ReactiveUI package for WPF/Silverlight projects, or ReactiveUI-WP7 for Windows Phone 7 projects.

If NuGet isn’t your thing, you can also find the binaries on the Github page: ReactiveUI 2.2.1.0.zip.

What does ReactiveUI do?

ReactiveUI is a M-V-VM framework like MVVM Light or Caliburn.Micro, that is deeply integrated with the Reactive Extensions for .NET. This allows you to write code in your ViewModel that is far more elegant and terse when expressing complex stateful interactions, as well as much simpler handling of async operations.

ReactiveUI on Hanselminutes

Check out the recent Hanselminutes episode about the Reactive Extensions as well if you’ve got more time. Scott and I chat about some of the ideas in RxUI and how we can take the ideas in the Reactive Extensions and use RxUI to apply them to Silverlight and WPF apps.

What’s New in ReactiveUI 2.2 – Interop with Existing Code

This release has a focus on enabling folks to use RxUI without having to completely rewrite existing codebases to use ReactiveUI. In future entries, I’ll show how to take existing ViewModels and “Reactiveify” them.

Major Changes

• The ObservableForProperty and WhenAny operators now work with normal INotifyPropertyChanged-based ViewModels, instead of requiring them to be ReactiveObjects. This means it’s now easy to try RxUI in your existing project without changes.
• A new class called MakeObjectReactiveHelper can be included in your existing ViewModel classes to easily make them equivalent to ReactiveObject objects without changing the base class.
• A new overload of RaiseAndSetIfChanged is added that uses a Ref parameter to solve the Silverlight “backing fields must be public” problem.
• New testing features that work along with TestScheduler.CreateHotObservable that allow you to create mock timelines and test your code against it.

Minor Changes

• The legacy QueuedAsyncMRUCache has been removed – this is a breaking change, but you really shouldn’t be using this class, ObservableAsyncMRUCache is much better and doesn’t have correctness issues.
• Performance fixes in MemoizedMRUCache, which is used throughout the framework.
• Many bugfixes directly based on user feedback – specifically, the ReactiveAsyncCommand issue where async items weren’t being run on the Taskpool is now fixed.

A new Sample Application

A Reactive Pomodoro Timer

I’ve written a new sample application based on a Pomodoro Timer – while this application isn’t multithreaded, it’s still asynchronous, and illustrates a lot of how to use Rx in a complex user interface (while a Pomodoro Timer seems quite simple, it actually is quite tricky to write since all of the UI controls are interrelated and very prone to ordering issues). With Rx.NET and RxUI, we can write the entire interaction logic in about a page or two.

But the more interesting thing in this sample, is that all of the interaction logic is also unit-tested. Using Time Travel Testing, we make sure the application does what it says it does, without actually ever waiting on the timers to finish. Here’s an example test: despite it appearing to take time, it runs instantly (Open in Browser if you don’t see a code sample):

Get the sample on the Github page: ReactiveUI 2.2 Sample.zip.

Where can I find the library?

On NuGet! The best way to install ReactiveUI for a project is by installing the ReactiveUI package for WPF/Silverlight projects, or ReactiveUI-WP7 for Windows Phone 7 projects.

If NuGet isn’t your thing, you can also find the binaries on the Github page: ReactiveUI 2.2.0.0.zip.

Message buses allow us to decouple code

If you’ve used the MVVM pattern enough, you’ll sometimes find that you get “stuck” – you need to access a certain ViewModel (usually the “main” ViewModel), but at the point you need it, it’s too far removed from the context that you’re using it in. Sometimes if the object is a Singleton it’s appropriate to think of something like the Managed Extensibility Framework to get a reference.

Other times, a Messaging framework is more appropriate – ReactiveUI provides an “Rx”-take on the Messenger (Publish/Subscribe) pattern. With the Messenger pattern, we don’t have to make all our ViewModels related to each other, which is important for writing testable code, since I can easily replace related objects with mock objects.

ReactiveUI’s MessageBus

ReactiveUI’s MessageBus is based on the Type of the message object. If the Message type isn’t unique enough, an extra Contract string can be provided to make the source unique.

There are three main methods that we’re interested in:

• RegisterMessageSource(IObservable source) – Register an IObservable as a message source – anything that is published on the IObservable gets published to the bus.
• SendMessage(message) – Publish a single item on the bus instead of having to use an Observable.
• IObservable Listen() – Get an Observable for the specified source – you can either Subscribe to it directly, or use any of the Rx operators to filter what you want.

Special support for singleton ViewModels

For ViewModels that only have a single instance, there are a number of helper methods that make using the MessageBus easier – use these methods instead of the above ones:

• RegisterViewModel(ViewModel) – Registers a ViewModel object; call this in your ViewModel constructor.
• IObservable ListenToViewModel – Listen for change notifications on a ViewModel object
• IObservable ViewModelForType – Return the ViewModel for the specified type

Sometimes packages need references to system assemblies

When NuGet packages need to reference other NuGet packages, it’s fairly straightforward to do: add a References section in your NuSpec file pointing to the right package. However, what if your package requires one of the built-in assemblies, like System.ComponentModel.Composition (MEF)? As far as I can tell, NuGet doesn’t have a way to do this in the spec file. ReactiveUI’s WP7 version needs a reference to System.Observable – trying to install the package then building it results in build errors, and that’s no way to live.

Using a post-install script to rig it up

Add a tools folder, and in that add an “install.ps1″ – this is a PowerShell script that gets run whenever your package gets installed. Here’s the magic sauce to add the reference:

You can do all kinds of other cool things with that $project variable, use the NuGet console to explore what’s available.

Office is on the Web now

Does everyone know about office.live.com? As part of Office 2010, Microsoft launched web versions of all their products. Check it out:

It’s OneNote, but works everywhere

This editor is on the web, so it’s accessible from any machine (regardless of browser, works great on Chrome in OS X for me), it’s free, and OneNote will sync with the web notebooks as if they were on your local machine or on a network share.

OneNote on the web means you can make your project notes public

A blog is a great place for documenting your project more formally, or for announcing things you want folks to know, but it’s also important to have a place to store ideas that aren’t yet fully formed, or you’re not committed to finishing. OneNote is good for this, but now we have a way to publish out notes; I’ve done this with ReactiveUI (though right now my notebook is pretty empty, I’m going to try to use it more).

My hope is, that if people can see the direction of the project and what the thinking is behind the code, it might spark good ideas for them as well: “..cool but what about this?“. Either they can fire off a mail to the mailing list, or maybe it will inspire them to write something completely different. If I’m going to write the notebook anyways, I’d rather share it!

What does ReactiveUI do?

ReactiveUI is a M-V-VM framework like MVVM Light or Caliburn.Micro, that is deeply integrated with the Reactive Extensions for .NET. This allows you to write code in your ViewModel that is far more elegant and terse when expressing complex stateful interactions, as well as much simpler handling of async operations. Check out this video for an overview:

Why the name change? I liked ReactiveXaml

The main reason I decided to change the name, is that many of the classes in ReactiveUI are useful outside of WPF and Silverlight, especially with a new library that I’m working on called ReactiveUI.Serialization (not quite ready yet!) Observable objects and collections are quite useful in non-XAML domains as well, so I want to broaden the scope a bit. For example, I think a lot of these classes could be pretty useful for building ASP.NET MVC ViewModels as well! I think ReactiveUI’s shortened name of RxUI looks better too

Where can I find the library?

On NuGet! The best way to install ReactiveUI for a project is by installing the ReactiveUI package for WPF/Silverlight projects, or ReactiveUI-WP7 for Windows Phone 7 projects.

If NuGet isn’t your thing, you can also find the binaries on the Github page: ReactiveUI 2.0.0.2.zip.

Where can I see a sample?

A sample project for WPF 4.0 that includes everything you need to see how it works is on the Github page: ReactiveUI 2.0 Sample.zip. It includes a small sample app, the RxUI binaries, and some sample test cases.

Version 2.0 means breaking changes

ReactiveUI uses semantic versioning (mostly), which means that version 2.0 contains breaking changes from the 1.x series. The biggest one is the namespace change and split – several classes that have dependencies on WPF/Silverlight are now moved into the “ReactiveUI.Xaml” assembly/namespace. Fixing this is usually pretty straightforward. Most of the other breaking changes are name changes and shuffling some parameter names around, especially in ReactiveCommand and ReactiveAsyncCommand.

Here’s one big change that is more subtle – in previous versions of ReactiveUI, the “Changed” Observable would give you “Sender”, “PropertyName”, and “Value”, but Value would be null on certain Observables and non-null on others, in a completely arbitrary way. In ReactiveUI 2.0, the rule is, if you explicitly ask for the property by-name (i.e. via ObservableForProperty), the Value will be set. However, there is also a GetValue() method on ObservedChange and a Value() method on IObservable that will get the value given any ObservedChange.

New features in 2.0

• ReactiveUI now has a simple, Rx-enabled Message Bus, inspired by MVVM Light’s Message Bus
• A new set of extension methods to help writing unit tests (ReactiveUI.Testing) – write unit tests that simulate concurrency without using Thread.Sleep, and get the same results every run
• Unit test detection now correctly works with Silverlight
• A new async cache class that supports Silverlight, and an extension method to easily integrate it to existing code (MemoizedSelectMany). Easily turn concurrent web calls into memoized, rate-throttled web calls
• Object validation is vastly improved in this release – many bugs fixed and is more performant.
• The same async cache class is also used in ReactiveAsyncCommand to properly support memoization
• CreateDerivedCollection() now works with ObservableCollection, making it easier to create ViewModels from existing non-RxUI code
• Easily get an Observable from a DependencyProperty (ObservableFromDP), even in Silverlight and WP7
• Cleaner syntax for creating properties based on Observables
• Intellisense documentation for all classes
• ReactiveCollection is vastly improved – it now supports tracking object property changes (i.e. it’s now easy to track “Tell me when items are added/removed, or when a property changes on any of the objects in this list”)
• RxUI now uses the latest Rx.NET release (the “Christmas Release”)
• The RxUI core DLL is no longer dependent on any WPF binaries, so it is more palatable to integrate into non-WPF projects.

Hey, why is this version 2.0.0.2

Here’s some advice to other developers – if you’re ever considering, “Oh, I’ll just change this one thing right before I release, it’ll be fine!”, don’t. Here’s the last-minute bug that I introduced that completely borks v2.0.0.0. :: sigh ::

https://github.com/xpaulbettsx/ReactiveUI/commit/b00354decf7c97e5af1148a6693136935fb82d22#L3L50

Building the project:

Building the project requires having quite a few products installed – to build a full release, you need:

• Visual Studio 2010
• Pex / Moles
• Code Contracts for .NET
• Expression Blend 4.0
• Silverlight 4.0 Development Tools
• Windows Phone 7 Development Tools

That being said, if you’re only interested in ReactiveUI core, you only need VS2010 Professional – the other projects can simply be unloaded. Clone the source from GitHub, or download the 2.0.0.2 source code release as a Zip file (though I highly recommend the former).

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.

Here’s a great Email post about how to write a proper Email client. Certain classes of software are just fundamentally difficult to do a complete job on, things you wouldn’t necessarily expect like a Textbox control or a build system. An Email client is one of these categories – even today if you discard legacy protocols and standards, you’ve still got a Mount Everest to climb. Here’s the epic mail, written by John C. Welch. Which is a shame, because at least on Windows and Mac, most of the desktop mail clients are sorely lacking in my opinion, with little hope of truly improving.

Some Quotes:

Stop thinking about IMAP as if it were some cohesive standard with a consistent implementation. It is not. It’s a bloody mess that manages to work in spite of its implementations, and Google’s IMAP implementation is one of the worst I’ve seen in the last 12 years I’ve been working with IMAP servers.

Regardless of who this project is aimed at, people using it are going to get email from “icky” sources, like Outlook users who have no control over their email format. (You think I’m kidding about this. I’m not. You should see how bizarre an overly locked-down windows shop can be.) They won’t have the option to get the sender to change format, so in addition to “normal” HTML, you should start thinking about building in TNEF decoding. In fact, if you do this well, it would be a monster point in the application’s favor, since that’s a major problem for people in the real world.

Power User != Programmer, Power User != Programmer, Power User !=
Programmer, Power User != Programmer, Power User != Programmer, Power User
!= Programmer, Power User != Programmer. There, point made.

HTML editor. Yes, I know text, blah, blah. Again, as the non-programmer power user, HTML is a reality, and it needs to be properly managed. There’s no reason to have the entire spec, but things like fonts, bold/italic/underline, alignment, real lists, and ‘real’ indents/tabs are not the work of satan. And that includes images. Welcome to the modern world, pretending it’s not there helps no one.