Thursday Night

Paul Betts’s personal website / blog / what-have-you

Threading bugs in ReactiveUI in Silverlight

View Comments

The symptoms of this bug

If you use the Silverlight version of ReactiveUI, you will currently encounter a lot of issues that appear to be the classic InvalidOperationException, where a Silverlight object is being accessed by a background thread – it might look something like this:


at System.Windows.Threading.Dispatcher.VerifyAccess()
at System.Windows.DependencyObject.GetValue(DependencyProperty dp)
at System.Windows.Controls.Primitives.ButtonBase.get_Command()
at System.Windows.Controls.Primitives.ButtonBase.UpdateCanExecute()
at
System.Windows.Controls.Primitives.ButtonBase.OnCanExecuteChanged(Object
sender, EventArgs e)
at ReactiveUI.Xaml.ReactiveCommand.b__0(Boolean b)
at
ReactiveUI.ObservableAsPropertyHelper`1.<>c__DisplayClass4.< .ctor>b__0(T
x)
at System.Reactive.AnonymousObserver`1.Next(T value)
at System.Reactive.AbstractObserver`1.OnNext(T value)
at System.Reactive.AnonymousObservable`1.AutoDetachObserver.Next(T
value)
at System.Reactive.AbstractObserver`1.OnNext(T value)
at
System.Reactive.ScheduledObserver`1.<>c__DisplayClass639.b__637()
at System.Reactive.ScheduledObserver`1.b__634(Action
self)

You’ll also see the message in the Console output, "WPF Rx.NET DLL reference not added - using Event Loop"

How to fix it

The easiest way to fix this is by adding this block to your App.xaml.cs:

protected override void OnStartup(StartupEventArgs e)
{
    RxApp.DeferredScheduler = DispatcherScheduler.Instance;
    base.OnStartup(e);
}

What’s the Deal??

One of the goals of RxUI was that the core library didn’t have a dependency on WPF/Silverlight: since an Observable Model object or an Observable collection is useful regardless of the domain! However, to do this, we need to do some trickery to ensure the experience is correct.

In a Console app, we don’t have a message loop, so we use EventLoopScheduler; this has the result of creating a single thread where all of our “UI actions” happen – it’s a Dispatcher without the Dispatcher. In WPF/Silverlight, we do have a real message loop, so we want to use DispatcherScheduler as our “put it on the UI thread” scheduler – but, we can’t link to System.Reactive.Threading.dll without pulling in WPF, even if we don’t use it!

What I do is, in the RxApp startup routine, I use Reflection to attempt to find the DispatcherScheduler Type and instantiate it at runtime. In WPF, the code that is currently there works like gangbusters – in Silverlight though, you have to be way more specificLukas Cenovsky does a great job tracking down the bug in this mail thread: you have to specify not just the fully namespaced Type name, but the fully qualified assembly name! (i.e. not just “System.Reactive.Windows.Threading”, but all of the version details and the public key token.

How come this doesn’t happen in unit tests?

Because in Unit Tests, there is no working Dispatcher (you can queue items to it, but they will never run) – ReactiveUI knows this and switches the Scheduler automatically in a unit test runner to Immediate, which makes writing simple unit tests far easier. That has the side-effect for me though, that some of my code is never covered by a unit test. Oops!

tl;dr; - Reflection works a lot differently on Silverlight, and is generally way more of a pain.

Written by Paul Betts

June 23rd, 2011 at 3:41 pm

New Release: ReactiveUI 2.3.1

View Comments

What’s New

ReactiveUI 2.3.1 is a maintenance release. The big difference is to fix the NuGet packages because they were targeted at the wrong branch of Rx.NET – I had built against the 1.0 branch, but only the 1.1 branch is published.

Wrong Branch?

With the latest release of the Reactive Extensions, the team has split the product into two branches – the stable release (having a version number of 1.0.10425), and the experimental release (which begins with 1.1). While the term “Experimental” sounds scary, it’s currently a bit of a misnomer – Experimental is just the Stable release with some extra methods added. Conveniently, they tagged all of the differences with an Attribute called “Experimental”, so you can use a disassembler such as ILSpy or JetBrains’ dotPeek to find all of the new cool stuff if you find the “ExperimentalAttribute” class, then “Find Usages”.

Keep in mind, that the reason that the release is Experimental, is that these new APIs are subject to change – they might work differently in future releases, or be gone altogether.

One more thing

It’s not all boring changes – I added one small feature that folks were asking for: in your class definitions, if you have a custom property getter/setter and can’t use RaiseAndSetIfChanged, you can now use the Expression syntax with RaisePropertyChanging/RaisePropertyChanged. So, “RaisePropertyChanged(x => x.SomeProperty)”.

What is Rx-Xaml?

For the current Rx release, the DLL that contains “ObserveOnDispatcher” (and everything Dispatcher-related) is in a separate “System.Windows.Reactive.Threading.dll” assembly. This DLL is needed for any project that uses WPF/Silverlight/WP7. The Rx team decided to publish two separate packages for this DLL, “Rx-WPF” and “Rx-Silverlight”. While this is easier to grok, it also makes it difficult for projects like ReactiveUI that support both WPF and Silverlight, since I can’t write the dependency in my NuSpec file correctly. So, I created a new package, “Rx-Xaml”, that is a simple merge of “Rx-WPF” and “Rx-Silverlight” – based on the platform, it will do the right thing. I’ll keep this package up-to-date, so feel free to depend on it.

Written by Paul Betts

May 29th, 2011 at 4:27 pm

New Release: ReactiveUI 2.3

View Comments

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:

YouTube Preview Image

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.3 – update to work with Rx 1.1.10425

As you may have noticed, the latest version of Rx has changed quite a bit, in both the functionality and the namespace structure. The latest build is just a release to make RxUI compatible. Another fix is, that since NuGet 1.2+ fixes the support for WP7, so I’ve updated the normal packages. If you’re already using the WP7-specific packages, I’ve updated those 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/new WP7 projects, or ReactiveUI-WP7 for existing Windows Phone 7 projects.

If NuGet isn’t your thing, you can also find the binaries on the Github page: ReactiveUI 2.3.0.0.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.1 Sample.zip. It includes a small sample app, the RxUI binaries, and some sample test cases.

Written by Paul Betts

May 8th, 2011 at 1:36 pm

Using ReactiveUI with MVVM Light (or any other framework!)

View Comments

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.

public class MainViewModel : ViewModelBase, IReactiveNotifyPropertyChanged

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

MakeObjectReactiveHelper _reactiveHelper;

public MainViewModel()
{
    _reactiveHelper = new MakeObjectReactiveHelper(this);
    /* More stuff */
}

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:

public static ReactiveCommand WrapCommand(ICommand cmd)
{
    return ReactiveCommand.Create(cmd.CanExecute, cmd.Execute);
}

Written by Paul Betts

April 4th, 2011 at 5:54 pm

New Release: ReactiveUI 2.2.1

View Comments

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.

Written by Paul Betts

March 22nd, 2011 at 11:38 pm

New Release: ReactiveUI 2.2

View Comments

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.

Written by Paul Betts

February 27th, 2011 at 8:40 pm

ReactiveUI Message Bus – decoupling objects using the publish/subscribe pattern

View Comments

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

Written by Paul Betts

February 25th, 2011 at 12:17 am

WCF.AsParallel() using ReactiveUI and Rx.NET

View Comments

Select.AsParallel() for the Web

I’ve mentioned it before, but SelectMany is the secret to using web services. Check out this previous article on Web Services if you’re new to using SelectMany with web services. Here’s the easy way to understand it in two lines, in terms of PowerShell / *nix pipes:

The cool thing about Rx.NET is that it makes it easy to write completely non-blocking calls a-la node.js. If you’ve ever used the BeginXXXX/EndXXXX calls, you know that it’s not particularly easy to use once you get into more complex examples, but that’s one of the advantages of Rx.NET – being able to take a bunch of asynchronous operations and sews them together in a sane way. It’s easy to write, but what actually happens when we run it? Let’s see what code runs where:

It’s easy to be way too parallel

Non-blocking web service calls take almost no time to execute – this is one of its big advantages, but it also means we can go through the input array really quickly. In effect, this means that if we have an array with 100 elements, we will end up issuing 100 WCF requests at the same time!

Not only is this not friendly to the web server on the other end, it isn’t possible – WCF will throttle your requests to 5 concurrent requests by default, and fail the rest. We need a way to keep a “pending queue”, run a few at a time, and when each one completes, pull a few more from the pending queue.

CachedSelectMany throttles concurrency

Let’s see how the diagram looks like when we use CachedSelectMany instead of SelectMany – from a code standpoint, CachedSelectMany can simply be substituted in places where you use SelectMany with a web service. CachedSelectMany internally uses a class called ObservableAsyncMRUCache to manage concurrency. Despite the fact that calls can be queued, your code doesn’t actually wait – you just won’t be called back until the call completes.


Bar has to wait in line before it can run

Written by Paul Betts

February 8th, 2011 at 2:14 am

Watching DependencyProperties using ReactiveUI

View Comments

Watching DependencyProperties in WPF is easy…

One of the things that is pretty useful in XAML-based frameworks like WPF and Silverlight when working in the codebehind is being able to be notified when a DependencyProperty changes. In the ViewModel, we have a different mechanism called INotifyPropertyChanged to accomplish this, but DependencyProperties are still an important part of WPF/Silverlight.

Let’s see how we would do this in WPF – it’s fairly straightforward:

…but really ugly in Silverlight

Unfortunately, this isn’t possible in Silverlight – it’s only possible to wire up a single callback, and it can only be done by the class that actually creates the DependencyProperty. This might work fine in some scenarios, but something less tightly coupled is often needed.

The solution is to use Attached Properties, as described Anoop Madhusudanan’s blog post – register an attached property, then hook that change notification.

ReactiveUI now does this for you

In ReactiveUI as of v2.0, there is a new method called ObservableFromDP – this method works similarly to the ViewModel’s ObservableFromProperty, but with less syntactic noise:

Of course, since it’s an Observable and not an event handler, all of the power of Rx.NET applies to this as well. Nothing revolutionary, but definitely makes things easier!

Written by Paul Betts

February 4th, 2011 at 8:10 pm

Testing your ViewModels using Time Travel and ReactiveUI

View Comments

Testing asynchronous ViewModel interactions is tough

When running under a unit test runner, ReactiveUI makes it fairly straightforward to test interactions between commands and changing properties. Fiddle with properties, execute the commands, Assert what happens – done!

However, most non-trivial programs need to run something in the background – talk to a web service, calculate something in the background, etc. Testing this can be way more challenging, since it is easy to deadlock yourself with the Immediate scheduler (the one used by-default in a unit test) – when it comes down to it, there is exactly one thread, and it can’t be doing two+ things at a time. This will typically come into play when you use a blocking call like First(), then find out your test runner never finishes. In a non-Rx context, we typically try to test this via Thread.Sleep() calls or Waits, which are really slow and often give you really unpredictable results.

Using EventScheduler in a pinch

What we need, is a replacement for RxApp.DeferredScheduler that is actually deferred, to take the place of WPF/Silverlight’s Dispatcher. Enter EventLoopScheduler! We can use this to create a “pretend” Dispatcher on-the-fly that we control:

This is alright, but it still will slow down our test suite by quite a bit, waiting for network access. What’s worse, if we were testing something more complicated, we could get tests that pass sometimes but not others, depending on the timing – this is a huge time sink for QA folks who have to then debug the test failures.

Testing software via Time Travel?!

The guys from DevLabs came up with a pretty ingenious way to solve this. Let’s look at the definition of IScheduler, the interface through which we send all of our deferred processing:

So, we can schedule code to run right now, we can schedule it to run after a certain amount of time has elapsed, and then there’s that third member: Now. You might ask, “Why do I need to know Now, don’t I get it from DateTime.Now?” Here’s the clever bit: What if you made a scheduler where Now was settable? This scheduler would never run anything, just queue it to a list of stuff to run. Then, when “Now” is set (i.e. we “move through time”), we activate anything that would have run in that time period.

How does the TestScheduler work?

In fact, this is exactly how TestScheduler works. When Rx operators call Schedule(), nothing happens. Then, TestScheduler has two interesting methods, Run(), which will run all of the queued items (i.e. execute anything that it can), and RunToMilliseconds(), which lets you travel to a certain time period n milliseconds away from t=0.

Faking out an asynchronous web call

Sounds great, right? Here’s the caveat about TestScheduler though – if you use any other asynchronous methods like Event or Task.Wait(), it’ll be tougher to integrate TestScheduler, since not all sources of async’ness are going through the TestScheduler. However, if you’re using Rx in a project, I consider using other sync/thread patterns to be an Rx Code Smell – like casting IEnumerables in LINQ to Array because I happen to know it’s an Array.

Let’s see how we can create a fake async Read method, that will simulate taking up some time and returning a result:

The cool thing about this mock, is that if you used it in a normal environment or under an EventLoopScheduler, it’d do exactly as it said: wait 10 seconds, then return that array. Under the TestScheduler, we’ll make it return immediately!

Writing the Unit Test

Here’s how we could write the Unit Test above to execute instantly using TestScheduler (actually fleshing out the MyCoolViewModel so you can see how it’s wired up). Inverting the control to actually get the mock function here is pretty ugly, there are certainly better ways to go about it.

Cool, right??

Okay, well maybe not cool, but learning about this definitely helped the ReactiveUI unit tests themselves become much more reliable and run way faster once I rewrote them to take advantage of TestScheduler – those Sleeps really add up! If you want to learn more about TestScheduler, Wes Dyer and Jeffrey Van Gogh from the Rx team talk about it in-depth here: Wes Dyer and Jeffrey Van Gogh: Rx Virtual Time

Written by Paul Betts

January 18th, 2011 at 2:19 am