File size

File size

File size

File size

I caught up with Bart at his whiteboard (of course) to discuss the significance of this release as well address some of the great additions to Rx as outlined below (many of the topics below have been discussed in depth in other Rx interviews with Bart.) We also talk about the new experimental build shipping model. Much of the time is spent talking about the portable libraries architecture for Rx for Windows 8, .NET 4.5, WP7/7.5 and beyond. Bart has been very, very busy and as usual his engineering is golden.

Tune in! It's always a pleasure to geek out with Bart. So much to learn. Congratulations to the Rx team!!!

The highlights of Rx 2.0 include:

Support for building Windows Store apps for Windows 8. This includes primitives to synchronize with the Windows XAML CoreDispatcher and interop with WinRT events and IAsync* objects.

Integration with the new C# 5.0 and VB 11 "async" and "await" features. In Rx v2.0, you can await an observable sequence, allowing one to apply the power of Rx to the new asynchronous programming model.

@Richard.Hein:Hehe, the name doesn't have any real hidden meaning. I knew I wanted to promote the PUSH messaging application and the Queryable aspect, I guess I added the "A" to make it sound kiwi/Canadian

Thanks to Bart and Charles for yet another excellent Rx video. Here's a thought and question for you guys:

I could be reading this wrong, but it seems to me that if the Rx team has a hard time creating portable libraries (e.g. last-minute change in binary deployment/partitioning strategy between RC and RTM), the rest of us are probably going to do it wrong every time. I lead a small OSS .NET library project, and it's pretty intimidating to come up with a plan for deploying device-specialized libraries that themselves depend on platform-specific BCL classes, not to mention the collisions Bart mentions between portable and non-portable binaries.

This "platform enlightenment" and versioning stuff seems to be emerging as a pattern in itself - a virtual requirement of the new level of platform fragmentation in .NET. What's the hope that we can get tooling, or at least guidance, to help other library devs out there on this topic? I presume the platform specialization and discovery process would be implemented with something like MEF. Can you share the bootstrapper process for this? Can we expect IJW-like behavior in a future major .NET version?

@dcuccia: In fact, the hardest part was working with a moving target, i.e. .NET Framework 4.5 Beta, RC, and internal interim builds, while developing Rx v2.0. If we'd only start now, with the final bits of .NET 4.5 and Portable Library support, it wouldn't be as hard.

The main thing to decide is what you want to do with platform-specific functionality that ended up in a bottom layer of your library: keep the API surface there, discover it at runtime, and mark it deprecated to stimulate new usage patterns; or have a clean slate release for Portable Library with migration guidance for the types/members that moves. (In fact, if you don't have to slice a type because it had both platform neutral and platform-specific stuff in it, you can simply move the type up the layer map.) As explained, we went with the second approach initially, but the benefits diminished as we went along, simply because Portable Library's intersection between our target platforms got much better by RTM.

If I'd be doing it again now, I'd really strive for a portable core that eliminates platform-specific copies right from the start. Based on what falls out of the intersection, I'd decide whether some kind of enlightenment mechanism is required / warranted or not.

To implement such an enlightenment mechanism, the main trick is Type.GetType(string, bool) to look for a known type in a known assembly (ideally demanding an exact version match, saving you from future headaches) implementing a known interface. Then decide whether you can do a graceful fallback if the module is missing. At the same time, try making all deployment vehicles such that the enlightenment assembly is always installed (e.g. as part of a NuGet package, or in an Extension SDK).

I'll chat with the Portable Library team about documentation and guidance plans.

@Minh You can also get the zero-to-hero guidance from www.IntroToRx.com. If it doesn't provide what you need then (as you sound like the target audience) then we will try harder for version 2 of the book/site, if you provide the feedback.

I am waiting for the RTM of the Windows Phone 8 SDK. I heard its under embargo until September 7th. Is version RX2 in that SDK? I used a ForkJoin in RX1, used 3 async calls in that, projected those results in 3 object types, because the results must be of the same type, after receiving the complete result of the 3 calls, I converted those object results back to the types I needed. How is that implemented in RX2?, the same as in RX1?

@Herman van der Blom: Rx v2.0 won't be part of the Windows Phone 8 SDK, but the existing Microsoft.Phone.Reactive will still be supported in order for users of WP7 to migrate to WP8. We will release an Rx v2.0 build with Windows Phone 8 support though, also based on Portable Library to allow sharing between .NET 4.5, .NET 4.5 for Windows Store apps, and Windows Phone 8.

In order to use ForkJoin, you'll have to add a reference to the experimental Rx assembly, but it should continue to work as it did before. Alternatively, if this is single-value async, you could also use Task.WaitAll or Observable.CombineLatest to achieve a similar effect, without having to rely on the experimental functionality.

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.