Reactive Extensions API in depth: Contract (Channel 9)

Wes talks about the part of Rx's IObservable contract that is not expressed in the type. What order of messages is allowed, when are methods allowed to throw, on what thread callbacks happen, etc...

Follow the Discussion

Follow
Oops, something didn't work.

Try again?

Sign In to be begin to follow these comments

What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.

Getting "follow" information

Stop following these comments

Start following these comments

What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.

Removing your "follow"

Setting up your "follow"

Did you know you can
sign up for email notifications?
- Subscribe to this comments

keithfl keithfl

Nov 26, 2009 at 7:07 AM

Wes .. (or someboyd else )

You mentioned in the previous 'Subscribe' video that 'unSubscribe() methods in many event frameworks are not compositional' ...

Why??? What makes dispose() more compositional than unSubscribe()?

Could you explain?
Flatliner With our thoughts we make the world.

Nov 26, 2009 at 2:22 PM

My understanding is that the Dispose() method is more compositional than unsubscribe because if your code doesn't call unsubscribe, the .NET Framework Garbage collector will do it for you (eventually). This can help alleviate issues that Event handlers suffer from, where if you do a += handler and not a -= handler it won't leak memory. Also Dispose() is called automatically when the IObservable completes or errors.
keithfl keithfl

Nov 26, 2009 at 7:28 PM

Thanks for the explanation!
jweber

Dec 05, 2009 at 12:33 PM

Hi all,

Regarding the contract, I'm wondering about the case where an IObservable<> represents a finite source of (uncached) external "events".

Just imagine a postal service that exposes (for each handled letter or parcel) a member of type IObservable<DeliveryStatus>, where DeliveryStatus represents the location of the letter/parcel; whenever the barcode of the parcel is scanned, the location is notified to the subscribed observers; the IObservable<> is done (invocation of observers' OnDone() method) when the recipient receives the letter/parcel.

My idea is that when a client application receives/gets this IObservable<> and subscribes a matching IObserver<>, the letter may already have reached its destination since seconds/minutes/days (my country has a very efficient postal service).

Would each of the following be considered as an acceptable behavior?

1- The observer never gets any of its members invoked.

2- The observer's OnDone() is invoked on subscription.

3- The observer's OnNext() is invoked with the final location, then OnDone() is invoked; both invocations being done on subscription.

4- The observer's OnException() is invoked on subscription ("Parcel already arrived, dummy !")

Is one of these behaviors preferable?

Moreover, as a designer of such a "postal service notification framework", do I have a mean to force implementors to adopt one of the behaviors described above (1-4)? (I guess not)

Thanks for your insight.
J.Van.Gogh

Dec 07, 2009 at 12:22 PM

Hi JWeber,

Rx allows all of the above options. It really depends on what you're looking for. option 1 would be the default behavior. if you had used a AsyncSubject or ReplaySubject, you could get option 3. option 1 and 4 you'd have to implement manually using Observable.Create.

Hope this helps,

Jeffrey
jweber

Dec 07, 2009 at 3:19 PM

Hi Jeffrey,

First of all, thanks for your answer: I'm now sure the options I listed are valid implementations from Rx point of view.

And as the behavior of the IObservable depends on the choices made for the concrete type implementation, this also answers my second question.

So yes, your answer helped.

Thanks again (and please don't stop your "Rx in Depth" post series !)

J.