What’s New

Xamarin.iOS and Xamarin.Mac support

This release brings initial support for the latest Xamarin.Mac and Xamarin.iOS. Using ReactiveUI and Xamarin Studio, you can write cross-platform ViewModels and Model classes and bind them to Views using the same RxUI 4.x binding syntax.

• ReactiveUI knows how to bind to Cocoa objects using Key-Value Observing
• DeferredScheduler automatically runs code on the Cocoa main runloop
• Routing and ViewModelViewHost is supported via a class that attaches to NSView
• Command binding understands Cocoa controls via Cocoa target/action framework, including automatically disabling the control when CanExecute is false
• Many common controls have implicit binding support

Caveat Emptor

There’s one hack that you have to do on iOS, due to assembly loading working differently. Put in the following lines in your AppDelegate.cs:


(new ReactiveUI.Xaml.ServiceLocationRegistration()).Register();
(new ReactiveUI.Routing.ServiceLocationRegistration()).Register();
(new ReactiveUI.Cocoa.ServiceLocationRegistration()).Register();


Experimental Xamarin.Android support

This release also includes very basic Xamarin.Android support, including a scheduler that will run code on the Activity’s main thread.

What do I need to run this??

You need to run Xamarin Studio and make sure to have the latest updates installed from the Alpha Channel.

What else is New?

• Bug fixes in UserError Handling
• Extra documentation (thanks @ArturPhilibin!)
• Add Debugger support for ReactiveCollection (#204, thanks @distantcam!)

Where can I see a good demo of a basic ReactiveUI 4.2 application?

A great example of ReactiveUI 4.2 in action is the sample I did for Erik Meijer and my presentation at QCon. Check out the code on GitHub – each commit is an interesting, self-contained step, and it is highly recommended that you step through commit by commit.

What does this do again?

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.

What’s new?

The main thing that is new in ReactiveUI 4.x is the new View Binding support – check out the blog post about the 4.0 Preview Release to learn more about the syntax for view bindings.

Since then, the features added in the 4.1 and 4.2 releases are incremental improvments.

Async / Await everywhere

ReactiveUI now integrates the BCL Async Targeting pack in order to enable async / await support on all platforms that ReactiveUI supports, as long as you’re using VS2012, as well as porting the Rx await support. This means that you can await IObservable, as well as use await alongside ReactiveUI:

View Binding Converter support

In the initial release of ReactiveUI 4.0, view bindings had to be exact
matches in terms of types when execuiting a binding, which was frustrating to
use when trying to bind a TextBox to an Integer for example.

In ReactiveUI 4.2, View Bindings automatically support conversions between types. This feature is analagous to the IValueConverter class in XAML bindings.These converters are registered using Service Location (RxApp.Register), and custom ones can be easily registered as well. In WPF, the TypeConverter framework is used to convert between many common types.

CallerMemberName support

Along with async / await comes CallerMemberName support for RaiseAndSetIfChanged. This means that declaring read/write properties is now even cleaner:

Other changes

• Routing behavior changes – RxRouting will now attempt several common ways to map ViewModels to Views, and ViewModelToViewFunc is now properly respected (i.e. it will use exactly the view class name returned now)
• Service location now always works, even if you don’t register a custom one. This means that small projects don’t need to reference NInject or another IoC container.
• ReactiveCollection is now completely rewritten for performance and adds a number of new features, like being able to add ranges of values.
• Reflection helpers that were internal methods in ReactiveUI 3.x are now exposed via a public static class called Reflection.
• Many, many bugfixes!

Thanks!

Thanks to the following people who contributed to this release:

• Phil Haack
• Johan Laanstra
• Peter Klavins
• Cameron MacFarland
• Wojciech Bardziński
• Brendan Forster
• Jimit Ndiaye
• John Stovin
• Lucas Maloney
• Rob Horvath

• install-package reactiveui -pre or install-package reactiveui-winrt -pre
• Download the Zip release from GitHub

How does this break backwards compatibility?

A few types have been renamed from 3.x (IViewForViewModel => IViewFor), a few deprecated methods have been removed (CollectionExtensions), and the biggest one is that NLog is now optional – if you want to use it, make sure to install the reactiveui-nlog package (it comes by default in the reactiveui metapackage)

WhenAny now works with any object!

WhenAny and ObservableForProperty now work with any .NET object. The runtime will detect what kind of object it is (DependencyObject, INPC, etc) and will determine how to get notifications from it. Note that if you use WhenAny with an object that doesn’t notify (like a regular .NET object), it will warn you on the logger that changes won’t be reported. This framework is extensible as well, so on MonoMac for example, notifications for NSObjects will be derived using Key-Value Observing (KVO).

This means that the old ObservableForDP method is now deprecated – use WhenAny instead.

View Bindings: A Compelling Replacement for XAML bindings

There are currently two methods that are used in the XAML world for binding Views to ViewModels. The original method, XAML Bindings (i.e. {Binding Foo}), is quite flexible, but a frustrating aspect of it is that Bindings that are incorrect, due to typos or other mistakes, don’t generate errors – you only see the error in the trace output. The Binding syntax can also get quite verbose, and isn’t always easy to verify because paths are relative to the “nearest” DataContext set.

Caliburn Micro decided to take a different approach, with their “Convention-Based Wireup” – this approach decides to automatically wire up named controls with the properties of the same name (even being smart enough to realize that the most “common” property of TextBox is the Text property). While this approach is much more “wrist friendly”, it suffers from the same type of run-time failures: CM cannot know whether a binding should exist or not.

ReactiveUI is presenting a new approach: wiring up controls via a declarative syntax. This has a number of advantages:

• It’s still wrist-friendly
• Bindings are clearly described in one place
• Bindings that are never valid (i.e. because the property name has changed)
  break the build.
• This binding syntax isn’t tied to Xaml – you can effectively use ReactiveUI
  bindings with any UI framework with a bit of work, including Cocoa (MonoMac)
  and GTK#.

Consider the following ViewModel, which is valid RxUI 3.x code as well:

  ObservableAsPropertyHelper<string> _FooMirror;
  public string FooMirror {
      get { return _FooMirror.Value; }
  }

  public ReactiveCommand Ok { get; protected set; }

  public MainPageViewModel()
  {
      this.WhenAny(x => x.SomeText, x => x.Value)
          .Select(x => "Foo" + x ?? "")
          .ToProperty(this, x => x.FooMirror);

      Ok = new ReactiveCommand();
  }

}

In ReactiveUI 4.0, this is the way to wire up the View:

      // Connect the ViewModel's SomeText to the View's SomeText.Text
      this.Bind(ViewModel, x => x.SomeText, x => x.SomeText.Text);

      // Since the View half isn't specified here, it will default to the
      // control with the same name, and use the most "reasonable"
      // property, just like Caliburn Micro
      this.OneWayBind(ViewModel, x => x.FooMirror);

      // Ditto with Commands, find a Control named "Ok"
      this.BindCommand(ViewModel, x => x.Ok);
  }

  object IViewFor.ViewModel {
      get { return ViewModel; }
      set { ViewModel = (MainPageViewModel) value; }
  }
  public MainPageViewModel ViewModel { get; set; }

}

This feature is a work in progress, and there are definitely some cases that need to be smoothed out. However, I’d love feedback on whether this is useful or not.

Check it Out:

• The Blog Post
• The website

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.

What’s New in 3.1

Tons of stuff.

ReactiveUI has improved dramatically since the previous version. Over the next few weeks I’ll be posting blog articles on how to use new features in ReactiveUI, but here’s the short list:

• User Errors: – A new API to separate the generation and presentation of errors that should be presented to the user in a friendly way. This is the Testable, Elegant, user-friendly way to make that MessageBox.Show() call.

• ReactiveUI.Routing – An entirely new component to ReactiveUI, designed for creating multi-page applications using Dependency Injection / IoC, while not being tied to any specific IoC container.

• First Class Async / Await Support – ReactiveUI now allows you to use Task<T> in many places in the framework where it makes sense.

• Ordering and Filtering of Models – using the new CreateDerivedCollection methods, ViewModel collections that “follow” Model collections and apply custom filtering / ordering are now easy to create.

• NLog Logging – A rewritten logging framework, based on NLog

• Preliminary support for WinRT (including async/await via LinqToAwait) and Gtk# on Mono 2.10.

• An overhaul of how ReactiveUI handles binding errors that results in more reliable applications.

• Many cleanups to APIs to make using ReactiveUI more straightforward and intuitive

A new sample: Play for Windows

Many of the new features in ReactiveUI 3.1 were prototyped and refined in Play for Windows, a .NET 4.5 client for the Play Music Server. This application is a production-quality application that demonstrates many of the new ReactiveUI features, especially Routing and RxUI.Testing.

Breaking Changes

ReactiveUI is now following the SemVer versioning scheme. This means, that v3 now has breaking changes. However, apart from one, these changes shouldn’t be overly difficult to fix.

• Deprecated Platforms – ReactiveUI has dropped support for .NET 3.5, SL4, and WP7.0. You must upgrade to .NET 4.0/4.5, SL5, or WP7.1 (Mango) to use ReactiveUI 3.1. Rx has decided to deprecate these platforms soon as well.

• Logging Changes – The interface between RxUI 2.5’s Log() method and RxUI 3.1’s is slightly different (methods like “InfoFormat” are now just “Info”, etc.)

• Disabled Bindings now Crash – In ReactiveUI 2.5, if an ObservableAsPropertyHelper or the CanExecute of a ReactiveCommand terminates with OnError, the exception disappears into the ether and the binding stops working. In RxUI 3.1, this will result in an item being sent to the new ThrownExceptions Observable.

  This Observable is special, in that if there are no Subscribers, items gets sent to the global RxApp.DefaultExceptionHandler, which by default, crashes the application.

• Deprecated / Changed Methods – Some methods, particularly in MessageBus and ReactiveUI.Testing, have changed names to be more consistent with Rx (i.e. AdvanceByMs vs. 2.5’s RunToMilliseconds), or have been removed, such as ObservableCollectionView (use CreateDerivedCollection() instead).

Thanks!

Thanks to the following people for contributing patches to ReactiveUI 3.1:

• Phil Haack
• Johan Laanstra
• Lowell Smith
• Stanislaw Swierc
• Tim Clem

The Details

On startup, we write out the V8 DLL to a temporary directory and call Assembly.Load to load it. Unfortunately, even though the write succeeds, the Load fails for some reason. On AppHarbor, we would always fall back to Jurassic, but in 1.1 I disabled this fallback because of performance issues (and because it made it harder to debug the V8 load failures).

Can I make an ISO out of a Windows install directory? Definitely!

Here’s how to take any Windows Install directory from Vista onward and turn it into a DVD ISO:

1. Download oscdimg.exe from here, which I’m certainly hosting illegally. Don’t tell anyone in Redmond. (This is a public tool, just normally wrapped in a huge download; I’m hosting it solely for convenience sake)
2. Open up cmd and copy oscdimg.exe to the *parent* directory of the Windows install (i.e. if it’s in E:\Windows8, copy it to E:\)
3. Cd to inside the Windows directory (i.e. the folders should be “Boot”, “Efi”, “Sources”, etc)
4. Run the following command:
..\oscdimg.exe -u2 -h . -bboot\etfsboot.com ..\MyCoolNewImage.iso

That’s all there is to it! Now you’ve got a shiny new bootable ISO that you can load into a VM or burn to DVD.

SassAndCoffee is a library for ASP.NET (both MVC and old-school WebForms) that adds drop-in support for two new languages: Sass and SCSS, a language that allows you to write reusable, more structured CSS, as well as CoffeeScript, which is a JavaScript dialect that is much more syntactically elegant, but still preserving 100% compatibility with regular JavaScript.

How to use SassAndCoffee

• Add the package reference via NuGet
• Add a .coffee, .scss, or .sass file to your project (an easy test is to just rename a CSS file to .scss)
• Reference the file as if it was a CSS or .JS file (i.e. to reference “scripts/test.coffee”, you should reference “scripts/test.js” in your SCRIPT tag)
• To get the minified version of a file (either a coffee file or a standard js file), ask for the “.min.js” version (i.e. “scripts/test.min.js”)

What’s New in SassAndCoffee 1.1 – Update All The Things

SassAndCoffee updates its version of V8 to the latest released code that runs even faster, as well as the latest released version of CoffeeScript, version 1.1.2. In an attempt to catch some tricky-to-debug errors that folks are having on 64-Bit IIS, I’ve also disabled Jurassic on 64-bit AppPools, since it was unusably slow anyways. This means that if V8 fails, SassAndCoffee will crash and hopefully provide some debugging information to assist in telling me what’s going on.

What else is new?

SassAndCoffee now correctly handles JavaScript with non-ASCII characters, as long as the file is encoded in UTF-8. Thanks to Roman Kvasov who taught me a thing or two about V8 that I didn’t know, as well as contributing the code to fix it!

SassAndCoffee is a library for ASP.NET (both MVC and old-school WebForms) that adds drop-in support for two new languages: Sass and SCSS, a language that allows you to write reusable, more structured CSS, as well as CoffeeScript, which is a JavaScript dialect that is much more syntactically elegant, but still preserving 100% compatibility with regular JavaScript.

How to use SassAndCoffee

• Add the package reference via NuGet
• Add a .coffee, .scss, or .sass file to your project (an easy test is to just rename a CSS file to .scss)
• Reference the file as if it was a CSS or .JS file (i.e. to reference “scripts/test.coffee”, you should reference “scripts/test.js” in your SCRIPT tag)
• To get the minified version of a file (either a coffee file or a standard js file), ask for the “.min.js” version (i.e. “scripts/test.min.js”)

What’s New in SassAndCoffee 1.0 – Rigging VS2010 to be compatible

The most common issue that people experience with using SassAndCoffee wasn’t actually an issue with the code at all – the symptoms were that it would work fine on their development machine, but when they deployed to production, all the SCSS/CoffeeScript files would return 404 File Not Found.

Why? Since VS2010 doesn’t recognize these files, it sets its build action to ‘None’, which means the files won’t be deployed. However, since VS runs your app locally from the same directory, it would still find the files on your box. The ultimate case of “Works On My Machine”!

The Properties Dialog, where you can reset this property

Well that’s annoying. How do you fix it?

Now, when you install SassAndCoffee, you will see a dialog offering to install a file onto your box – this “pkgdef” file will configure VS to consider Sass/SCSS/Coffee files as Content. Here’s the details on how this works.

Configurable Caching Support

SassAndCoffee now has three types of cache options, which can be configured by adding a setting to the appSettings block with a key of SassAndCoffee.Cache:

• NoCache – Compile every file when requested, don’t cache anything
• InMemoryCache – Cache a limited number of files in-memory, but don’t persist anything to disk
• FileCache – The default option (and previous behavior) – cache compiled files in App_Data

What else is new?

• SassAndCoffee had its first external contributions by Steven Robbins and Ken Browning! You have no idea how excited I am about this.
• The biggest change was support for NancyFx by Steven’s Herculean effort to decouple the core compilation code from the ASP.NET pipeline. SassAndCoffee is now in a great place for other non-ASP.NET frameworks to use as well, such as Manos.