Awkward Coder

I realised this week I'm not being as functional when creating an Rx extension method as I should could be. This came out of a discussion I was having with @leeoades about a Pausable<T> extension we thought we needed at work. Lee had a solution and I thought I'd try to create one without looking for the answer on the t'internet. 1: public static IObservable<T> Pausable<T>( this IObservable<T> stream, IObservable< bool > paused, bool initialState = false ) 2: { 3: ... 4: } Hopefully the idea of the method is obvious - have the ability to pause & resume the publishing of instances to the stream. Before implementing Pausable<T> I thought I'd implement an extension that didn't remember state whilst paused - Suspendable<T>, as you can see the same signature. 1: public static IO...

I wanted to see how easy it was to build a Portable Class Library, and the answer is very easy. What follows is my experience. First off create the project... Next choose the platforms you want to support, you can changes these later via the project settings page: At this point you're ready to start creating your masterpiece... For this demo I thought I would revisit the WP7Contrib . Last year I built as part of the WP7Contrib a set of wrapper class around   HttpWebRequest  &  HttpWebResponse  classes to make communicating with a RESTful web service easier -  ResourceClient . I was interested to see how this would turn out when implemented as a PCL. Also I was interested to see which framework features weren't supported for the selected target frameworks. I knew I wanted to use Task<T> for the asynchronous nature of my library's interface: 1: public interface IRestClient 2: { 3: Task<IRestRes...

When using WebAPI inside a test fixture make sure you shutdown the HttpSelfHostServer instance correctly or your tests will more than likely fail when run from a continuous testing framework like nCrunch. See this post for info about using the self hosting version of WebAPI inside a test fixture. So my tests were running successfully when run inside Visual Studio from either the inbuilt runner or via Reshaper, but were failing when run from nCrunch: The failing tests weren't consistent either, sometimes none would fail, sometimes a couple, sometimes all... What the tests had in common was they were using a shared resource setup inside the test fixture setup method - this is like the setup method for a test but scoped at the class (test fixture) level. The setup was failing randomly were it was setting up the WebAPI self host - see highlighted yellow area, you can see the failing icon for nCrunch at the side: The exception was telling me it was trying to crea...

I've been unit testing a method which has a return type of Task<T> and I need to handle cases where  exceptions will be thrown. Should I use the Task approach or convert to an Rx observable stream? Task try-catch approach: or Rx declarative style: I know which one I prefer :)

I have a class which handles all the communication to any back-end RESTful service, it wraps up all the complexity of using HttpWebRequest and provides a simple API: 1: public interface IRestClient 2: { 3: Task<RestResponse<T>> GetAsync<T>(Uri url) where T : class ; 4: Task<RestResponse> PutAsync<T>(Uri url, T resource) where T : class ; 5: Task<RestResponse<T>> PostAsync<T>(Uri url, T resource) where T : class ; 6: Task<RestResponse> DeleteAsync(Uri url); 7: } The implementation of this class isn't relevant for this post - it's all about the behaviour. The behaviour is what I'm trying to test not the internal implementation... So how can I test this in a standard test fixture? I knew it was possible but I didn't think it would so easy... Having used asp.net WebAPI  for hosting services in IIS I knew this was the tech stack I wanted to use, but could...

I've been building a small Portable Class Library  and it makes use of the WebRequest class. I'm targeting .Net 4.0 (and above), Silverlight 5 and Windows App Store. I would target the phone as well but it doesn't support the TPL  at the moment - WP8 is just around the corner: I wanted to use async method GetRequestStreamAsync  & GetResponseAsync but these aren't supported in .Net 4.0 and when creating a Portable Class Library you only get the commonly supported methods across the configured platforms - so no support then or may be not... Why not just create a couple of extension methods? 1: public static class HttpWebRequestExtensions 2: { 3: public static Task<Stream> GetRequestStreamAsync( this HttpWebRequest request) 4: { 5: var tcs = new TaskCompletionSource<Stream>(); 6:   7: try 8: { 9: request.BeginGetRequestStream(iar => ...

If you've been doing Rx for a while it's very likely you're also be into testing with TDD. In which case you'll have come across testing observable timers but if not then what follows is how easy this is. So lets say I want to test the following method, it generates a 'tick' according to the time span parameter: 1: public IObservable<Unit> TickEvery(TimeSpan timeSpan) 2: { 3: return Observable.Interval(timeSpan).TimeInterval() 4: .Select(_ => new Unit()); 5: } When testing this I don't want to be dependent on the scheduler clock, what I mean is you don't want the test code to have to do some kind of 'wait' operation whilst the Observable.Interval is generating values. The answer is to use the Reactive Extensions Testing Library . It provides the TestScheduler  which allows to manipulate the underlying clock using the AdvanceBy & AdvanceTo methods which then means you can trigger any...

To help make an object eligible for collection by the GC (garbage collector) one would implement the IDisposable interface. Executing the dispose methods on muliple implmentations at the correct same time is often done using a custom DisposeWith extension method: 1: public static class DisposableExtensions 2: { 3: public static T DisposeWith<T>( this T disposable, CompositeDisposable disposables) where T : IDisposable 4: { 5: disposables.Add(disposable); 6:   7: return disposable; 8: } 9: } Typically used as follows - explicitly creating a CompositeDisposable instance and then disposing the child view model with the instance: Firstly can I get away without having to explicitly create an instance? Also can I get to a point where I can just do something like this: Inheritance seems the obvious choice but as you might already know, all the disposable types in the System.Rea...