Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Reactive Extensions API in depth: Contract

4 minutes, 40 seconds


Right click “Save as…”

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

  • Oops, something didn't work.

    Getting subscription
    Subscribe to this conversation
  • keith flokeithfl keithfl

    Wes .. (or someboyd else Smiley )


    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?


  • FlatlinerFlatliner With our thoughts we make the world.

    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.

  • keith flokeithfl keithfl

    Thanks for the explanation!


  • 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.

  • 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,



  • 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 !)



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.