Skip to main content

Posts

Showing posts from September, 2012

Listening to a single value from an Rx observable sequence

I have an observable sequence and I want to observe only a defined number of values, the number is immaterial, the important part is the fact I don't want to be notified of any further values. How can this can be achieved? The answer is easy, use the Rx extension method  Take , it'll return the required number of values only. A simple example: 1: Observable.FromEventPattern<RoutedEventArgs>(clickButton, "Click" ) 2: .Take(1) 3: .ObserveOn(Scheduler.CurrentThread) 4: .Subscribe(vt => Debug.WriteLine( "{0}: Click called..." , ++count)); When the button is clicked in the UI it produces a line in the output window in visual studio: So using the Take method I can limit the number of observations irrespective of the number of times I click the 'Click Me!' button: 1: Observable.FromEventPattern<RoutedEventArgs>(clickButton, "Click" ) 2: .Take(1) 3: .Observ

Applying LINQ principles to business logic

This was inspired by a conversation I was having with @leeoades & @hamishdotnet at work earlier this week, we were discussing the use of Yield keyword to short-cut method execution. Lee has a great post about sequences here . I wanted to get down how my thinking about the Yield keyword has now changed. Historically I've always thought about using the yield when I'm defining a custom enumerator method, something like GetFooEnumerator - typically I'd have placed this on some kind of model object to allow the easy iteration of some child model instances. Lee was saying why not use yield where ever you have the following usage pattern: 1: public IEnumerable< int > Range( int start, int end) 2: { 3: var numbers = new List< int >(); 4: for ( var i = start; i < end; i++) 5: { 6: // Do some business logic here... 7: numbers.Add(i); 8: } 9:   10: return numbers

How do I flatten an enumerable IObservable to IObservable?

The title of this post should be  'How do I flatten IObservable<IEnumerable <T> > to IObservable<T>?' But blogger says 'no'... This seems like a simple & legitimate Rx question and if you're one of the initiated it's very easy simple. It came up the other day because a back-end service we're talking to returned an array of stuff and we wanted to flatten it into a stream of single values we could observe. So what do I replace CONVERT_SOMEHOW with? voilà... 1: IObservable< int []> numbers = Observable.Return( new [] {1, 2, 3, 4, 5}); 2:   3: IObservable< int > number = numbers.SelectMany(n => n); In a simple app: produces the following output:

Does the Rx subscriber get disposed when OnCompleted is called?

We use an implementation of an observable command - ObservableCommand<T> in our view models not only to wire the actions of controls defined in the XAML but to allow the other interested parties to be notified when the command has executed. We were wondering what happens when the observable command is disposed, does the OnCompleted method for the subscribers get called and importantly are the subscribers disposed? Our observable command has an implementation similar to this: 1:   2: public class ObservableCommand<T> : ICommand, IObservable<T> 3: { 4: private readonly Subject<T> _subj = new Subject<T>(); 5:   6: public void Execute( object parameter) 7: { 8: _subj.OnNext((T)parameter); 9: } 10:   11: public bool CanExecute( object parameter) 12: { 13: return true ; 14: } 15:   16: public event EventHandler CanExecu

Using PostSharp for AOP with Reactive Extensions - update

After digging further into the use of AOP with Reactive Extensions my first post about can be improved by using the Do method instead of the Subscribe method on the IObservable<T> inside the AOP aspect OnExit method. Why? The previous implementation I gave would worked well for a hot observable , but for a cold observable this wouldn't apply as it would instantiate a new stream for each subscription setup in the aspect - Lee campbell has a good definition for hot & cold observables. This means the OnExit method changes from: to: There isn't much difference in the implementation, the significant part is re-assigning the ReturnValue for the method execution arguments.