Streamline & Simplify Events with Reactive Extensions | Xamarin Developer Summit

Posted By on August 13, 2019


>>All right. Hello.
How is everyone doing? Fourth to the way through
our Xam Summit here. So yeah, I’m Shane
Neuville. Spelled it right? Yeah. Shane Neuville. I’m
with the Xamarin Forms team. Prior to being with Xamarin Forms, I worked a decent amount
with the ReactiveUI. So I still try to champion
that as much as I can even from within Microsoft. So the talk here is going to be
heavily about Reactive Extensions, specifically just the concepts
behind the drive reactive, how they near to events. Then later, Michael’s going to do a more extensive talk on
mapping out over like MVVM and how to power
your frameworks for that. So to get us started with this, how many people have used
Reactive Extensions, just to get, “Oh, hey. That’s nice.”? Every time I asked,
there’s more hands. So that’s a good sign. Let’s see. So how many people think I’m talking
about JavaScript and ReactJS? That guy over there, him? All right. So some of the vernacular
started to clear up as well. Does anyone think I’m going to
talk about observable collections for about an hour? No. All right. So along that, this frame becomes a little less
relevant as the talks go on. There was definitely
some confusion that started out. So I remember the first
time I heard of ReactJS. I’d been doing RxJS for some time. It was about five minutes
into the conversation, I realized we weren’t having
the same conversation. So there’s not really any relationship there besides
the first five letters. The angular has started
heavily using RxJS. So Angular is probably
more synonymous with RxJS at this point, but yeah. Then, the next area
where people get thrown off has to do with the
ReactiveX and ReactiveUI, and where those division points are. So ReactiveX is
a platform-agnostic concept. So the ReactiveX concept is implemented across
multiple frameworks. So there’s a coco, a Java, RxJS. There’s a whole swath of languages
that implement the concepts. Then, ReactiveUI is the MVVM layer that helps plug ReactiveX
into your MVVM. So when people are
talking about Reactive, they’re not just talking
about ReactiveUI. They’re mainly talking about functional reactive programming and how observable based
programming paradigms work. So the ReactiveX aspect is largely what this talk is
going to revolve around, which will be a good precursor
for Michael’s talk later. So why did it beep at me? Hold on. I probably
maybe I don’t have it highlighted. There we go. So let’s break down what
we’re really looking at here. So let’s talk about
events really quick. So how do you subscribe to
events? It’s all pretty basic. We’ve all seen this code before. There you go. Pretty exciting, right? So effectively, you have
your publisher on the left. You have your events
and then you have your observer on the right there. So that, it’s a basic event
notification pattern, your basic observer pattern. So this was the syntax in C# one. Effectively, the top
one does the same thing as the bottom, but syntactic sugar. So let’s break down what an event is. So an event is essentially, it’s a series of individual things
that occur to the produce data. So if I’m typing my name, I type S, there’s
an event, h and event, a and event, I think you see
where all those is going, and the representation
of that data is here. So that is the set of data that have occurred based on those events. So that’s your event. So nothing too mind-blowing
at this point. So steps to stop observing an event. So how do you stop
observing an event? We’ve all unobserved
front events, right? Like we’ve all said, “Hey, I no longer care about what
this thing happens.” So usually, the process
of figuring out how to unsubscribe event starts with the customer complaining
that your app is slow. So the customer files
an issue and says, “Hey, my app slows down after using it. What’s going wrong? The more I’m using it,
it’s not working.” So first, you don’t believe them. You think they’ve
installed something like Dilbert screensaver that’s taking up the whole browser window
or something like that. Because when you start
up your application and you use it for
about 15 seconds, it’s fast. Everything works great.
It’s responsive. You’ve figured out that it’s perfect. So then, you’re like, “All
right. I guess I believe them.” So at this point, you dust
off your debugging hat, reread through all of
tests and blogs on how to analyze stack frames, and you start pulling everything in. You get the stack DOMs. You look at how long
objects are living. You do it over and over again. Finally, you’re getting down. There’s lots of staring at
arrows pointing at things, and wondering what objects matter, and subtracting this
from that until you finally see that there was that one line of code or
you forgot to write that. You’re like, “Oh, man.”
Then, all of a sudden, everything starts running super fast. So yeah, I mean, basically, subscribe and unsubscribe from them. So that’s the semantics of it. But the semantic, it’s
a little gnarly I feel like. Because one, you have to
remember to do two things. Anytime I have to remember
to do more than one thing, you’re going to fail
usually in programming. Plus, you have to retain
your references to everything. So in order to do the importance
of that second one, you need everything that’s in your first one to do
everything in your second one, like you have to
maintain those ideas. So in general event management
is just, it’s messy. It’s not the cleanest type
of operation. I mean, like let’s say, you only care about
a single event, for example, like we’ve all written this code, where if you want to
unsubscribe from something like you only wanted to fire one. So let’s say, like an appearing page
or something of that nature, so you have to have
the reference at top so that the closure
inside has access to it, then you assign the handler, and then you do
the handler at the end. So there’s this successive ceremony that comes from the
set of operations. So this looks familiar. Is
everyone written this code before? Yeah? All right. So and here I’m still
talking about events. This is what I call my
IObservable Infomercial. Where you do something
crazy and you’re like, “Oh my God, it’s so terrible.” It’s not that bad. But here
I’m indicating all the stuff. This isn’t Xamarin Forms, when you’re wiring up to an event. So you wire up to the event, you have to find okay,
where’s my dispose aspects? Okay, it’s down here. I have to make sure to
dispose from the events and all this stuff is in disparate
locations in your entire file. These are all these things. This ceremony you have to do with all these event
management systems. Look right up there, you
have to subscribe to it. Then you have your handler down here. You’re dealing with the data in a separate spot and
then bends up here. It’s this very
disconnected experience. So here I even typed
the wrong things, I’m so flustered to how hard it is. But yeah. So I got the infomercial,
where did the soda go? So that’s the thing. So events are these singular
synchronous data points. So you get a text change events and then all you have is
that text change event. You just have that letter.
You just have that letter S that you have to deal with. But what if you want
to do more with that? What if, because whenever
you have an event, you very rarely care
about the one event. You care about the data
set of events. You care about everything that’s happening over the period of time. So what if you want to do
something very exciting. So what if you want to say, skip your first five events and then only care about the next four, then you want to debounce the events, so if they’re typing super-fast
only wait two seconds, then let’s say you want to filter out any events that are corn flower blue just because it’s a horrible color
possibly, I don’t know. Then you want to kick off the web request
and then they start over, so you want to just throw that away. Like this type of pattern is very common as far as
your event management, especially in MVVM frameworks and
things that are more UI based. You’re always having to react against incoming data points
with connectivity getting lost. So like what if
your connectivity gets lost at the web requests to point? How do you interrupt that web request once
the connectivity is lost? How do you do that in a reliable way
that is easy to manage. So all of these concepts have very clear versions of the verbs
that mapped them in the reactive. So these are all
actual things you can use in reactive to articulate all of these attempts over your data, over year event stream. All right. So what else
can we do with events? Not really that much.
The very simple basic patterns. So that’s my tear-down of events. So at this point, if
you haven’t really used reactive you’re probably like,
“Oh I’ve been so terrible. I’ve been doing this wrong the
whole time,” and you’re having an existential crisis about all the issues that you didn’t
know you had that now you have. So let’s translate this
over to Observables. So IObservable has been
around for a while. It’s essentially just like a publish subscription model that’s inside the core
framework of.Net and then ReactiveX is more of an expression of how to interact
with those Observables. So let’s break down what
an Observable is here. So it’s essentially
an Observer Pattern. Fundamentally, it’s
the same thing as an event. An event is effectively
an observer pattern. So you have your event here, your handler and your publisher and then that’s analogous
to this right here. So you have your observable
that is watching, its doing the same thing. So you have the same idea. Effectively, you can do the exact
same thing with both of those at the base layer and
get your data points. But the exciting thing now, so this is where the exciting points of everything comes into play. With an event, you don’t
really have anything. You just have an event. But now with an observable, you have a representation
of that event. You actually have like a data object
that you can do things with. So it’s the difference
between having one item from a list instead of other than having say the entire list
that you can now operate over. So that’s where your
differences come into play. So you can think of the
observable very much as the Iterator Pattern. So this is taken from reactivex.Io which is one of the main sources, which is a really good source. It has a breakdown of
all your operators and everything. So I’ve a link to it there
at the bottom for you. Yeah it’s effectively mapping your observable idea to the same things you can
do with an iterator. There’s almost a perfect one-to-one comparisons
there, when you iterate. So an iterator is like IEnumerator. That’s the equivalent. IEnumerator’s what’s equivalent
to IObservable, basically. So anything you can
do to an IEnumerator, you can do it to an IObservable. So that was like remember
when Link first came out and everyone was
super excited about Link like Link over objects and Link to SQL and then they were
less excited about Link to SQL, but Link was so exciting. So effectively you have your
retrieved data which is next, onNext. So as each of your data
points come through. That’s where it stops as far as where Observables become more
exciting than your events. So you get these other things. So you get an air for example. If your event that you’re
observing manifests an exception, you can deal with that as
part of the observable. So as part of the data flow of
the operation, you can indicate, hey there’s this event
through an exception. So for example, a web request. If a web request is occurring and it throws an exception because the Internet goes down or
something similar to that, then you can effectively catch that and deal with that
within that construct. So it makes your code a lot more robust and then you
also get this idea of completion where you can fire if somebody has indicated that they no longer care
about the data points, you can then act upon that. All of those things
become features of how you interact with your data. So here’s some more
comparison points. So this is also taken from ReactiveX. As you can see here, you have your
Iterable which is your lapse, so that’s like your IEnumerator and you’re right which
is your IObservable. So one is getting data
from local memory, so that’s going to be maybe like a synchronous operation where you just have your data’s realized at the top and you’re right
one is from network, it might be slower data feed. So there, you can see
you get these same ideas over your event streams which
is just, it’s super-powerful. Neat stuff. All right. Let’s break down how the building blocks of
your IObservables a bit here. So this is the basic idea of
how you build up IObservable. So as you see in
that first step there, you see the familiar subscribe
and unsubscribe, it’s not that exciting,
it’s just passing through different functions to the observer, so the observer knows how to deal with subscriptions and unsubscribes, so that it can containerize that
behavior within the IObservable. So here’s the comparative
versions of those, of what those represent. So subscribe is effectively
invoking that top guy, the top one clicked
and saying, “Okay, now I care about my events,” and then the bottom one there
is now disposing, which is then unsubscribing. This is where it starts
to get really powerful, because you have
this whole representation is encapsulated in familiar pattern. So you have IDisposable
which we’ve all used, and we have logical data structures and ways that we can use those more effectively than
just say unsubscribing. So some really cool
ways you can do that, you can easily manage
these life times. So remember before where you have
to make sure to unsubscribe, so like in Xamarin Forms for example, if you’re changing an element
or if something new comes in that you want to subscribe to and you don’t care about
the old thing anymore, you have to do this thing where
you unsubscribe from the old one, subscribe to the new one, then also your dispose point have to make sure you’re unsubscribing
from those events as well. So that’s what’s neat though, is that your entire event
observation management system can be articulated
through disposables. We act to that and a lot
of these things here I wish they would just pull
into the.Net Framework, but for now, in ReactiveX you have these things
like CompositeDisposable. So the idea there is
you can aggregate all your disposables into
a single data structure, and then that data structure now, you can just dispose of once, once the lifetime of
the containing class is gone, and now all your event
management is taken care of. So you can attach your
PropertyChanged subscriptions there, your TextChanged subscriptions,
and then you just dispose of it. So it’s neat because you’re getting these object concepts that
you can apply to your events, so it’s nice, I like it. For example, like I was
talking about before, where you have an instance where you have an old element
that you’re subscribed to, I mean a new element comes in so you don’t care about
the old one anymore. So it has like these cool concepts here with like a serial disposal, where anything that you
assign to that will automatically dispose
of the thing before it. So in these ideas here, you don’t have to unsubscribe for what came in
there, which is really neat. But you know that this is
the new hotness that you care about, and then once that comes in, you just get rid of
whatever was there before, so then that allows you to set-up these really cool expressions
of what you want to do. Because a lot of the stuff with
Reactive which is really nice, is having all of your intent
in a single location. Event management is
very callback-based, you don’t get in as bad styles
like a total callback hell, but it’s still kind
of the same thing. It’s callback management
and then interacting all these different callback
scenarios when you have the same thing with how you
manage the lifetime of it. But has anyone here done
Xamarin Forms stuff? I’m just mapping
logical modelings here. So you have this idea now where the way you can manage the entire life cycle of something is just right
there in that middle part, and that’s everything you have to do. Once that’s set-up there, now any time you come in and
you have an element change, and you only care
about the new element, assigning a new disposable causes
the previous one to dispose, so now all of your events
are totally unwired, and then now you start
wiring up your new ones. Then in your disposed, you just have a single
serial dispose which is your class level managed resource
that you’re disposing of. So now there’s not this complexity of management as
far as your advance handling. So this actually was
the first thing that got me into Reactive Programming was
the disposable management, I think it was like a year before
I’d even used anything else. Just because I had a Silverlight
application that was having some subscription issues and
then I happened upon this stuff, so this stuff is cool, the disposables make me super happy. So these are still mapping some of these ideas which are
really neat, so like here, remember before when you
wanted to only subscribe to that one event and you only
wanted to see it once? With Reactive, you can do that entire concept here
with this one expression. So all this does it says, “I only want one value from
this Property Changed, and then at that point I
want you to get rid of it.” So I mean that’s awesome right there, Take one and then switch, which is a little tricky to
understand but those are just enough reasons
to use it forever, it’s nice, I like it. So that’s the breakdown of
how the operations work. So I have a couple of demos of
realizing this in code a bit more, but I wanted to give some concept
prep to you as well, to some of the types of Reactive
structures that we’re using, just so it makes a little more sense. So one of the ways you describe stuff with Reactive is by
using Marble Diagrams, so there are these ideas of seeing your input and what the output is. So the top two here, this is the vernacular for
most Reactive information, so anytime you see
Reactive Operators described, they’re always described
in this format. So the idea here is that
the top two things are data streams, and then the bottom one is
what your subscriber sees. Merge would be two subscribers, so like if you were subscribing
to say a TextChanged event on a username box and a
password box for example, anytime either of
those change this is what your output would look like. So these are some of
the operators I used in the demo, so I just wanted to make sure they were
understood before I moved on. So Filter, this is
basically like a where, so on link to IEnumerable, it’s just like a where. So effectively any event that comes through, simple enough to understand. Debounce, so this is
the other really cool feature, so this is throttling your inputs. So in this example what they’re demonstrating here is
that they only want the most recent value to come out after a certain
set amount of time. So you can see there’s a lag
between one and five because two, three, and four are happening so close together
that five is now coming out. So this is the quintessential
example for Reactive stuff, so cases where users are doing like search with Google when they’re typing
in their Autocomplete, but you don’t want to like kick
off a web request every time, so that’s effectively what
this is demonstrating, which we have an example of. Then TakeUntil is
the last operator that I use, so TakeUntil is really neat, because that’s for example
look like a web request. So let’s say a web request
is kicking off, and then the user
starts typing again, or they say cancel, like they don’t want
it to happen anymore, so all of those are another
event points that you can enact, and at that point it cuts
off your stream anymore. So that’s like a really
simple way to say cut off, if you don’t want a web request
or something like that to finish. So that’s the breakdown
of the observable stuff, so let me switch over, hold on one sec. Cool, let’s see. Is that too small?>>Yeah.>>It is things you
do when you realize that you’ve never done
these on the demos before, I’ve actually never increased
its font size on Obs Mac before. Let’s see. I’m trying to
do my Windows stuff here, there we go, I’m guessing that’s it. All right I was trying on
my gestures on the pad. I did the swipe. I did two fingers, I did this. I don’t know. I didn’t happen upon it I guess. So there we go. Okay yes. So as you start windows
where you just hit control and split it up. All right so that everyone
can see that. All right? So let me run the demo real quick just so we have context
of what we’re doing here. So this is kind of
a basic application. It’s just a login logout idea. Yeah, so below I have a set
of events that are occurring, so this is effectively
the data stream of the observables. So all the events that are
happening with the observables. So here we have log in. So this is user and password that I should have put
a placeholders log. But so the idea here you
can see if I hit a letter. There. So hit a letter and at that point it’s
validating the input. Now you can see that
there’s kind of this delay. Right? So if I hit
“O” there’s a delay. So the idea behind
that is that you’re not- that’s that debouncing
that you’re talking about. So if I type in the “Username”
and the “Password”. There. You can see that once
that validation happens. So that’s just we’ll kind of break
down these structures once I get in there but that’s
the idea behind it. So. Yes. So pretty exciting. Now we have a simulated for login. So the idea here I click “Login”. It starts a web request and then
at that point you can log out. So and there’s kind of an additional let’s see how many times
it takes before this triggers. So I have a randomizer
in there to randomly generate errors. There it is. Cool. So you can see here what happens is that I
clicked the “Login”. It generated an exception. So like the Web Request exception. Then it said okay let’s just
try the Web Request again. Then at that point it
then logged me in, right? Then the other aspect
of this which is me. Like let’s say the user
wants to cancel it. So if they click “Login”
they can click “Cancel”. There you can see now it’s no
longer processing the data. Right? So that because there’s an operation kind
of canceling that. So this is to demo. Yeah, so this is the idea behind. This is the code. Yeah, so the idea behind this to kind of
break down the structures. Since we’ve all seen a lot
of these things is that this is the composability
aspect of observables. The composability aspect
is that you have this representation of your events as these single data streams
that you can then start to intermix to articulate
the behavior of your application. So if we have the app what are
all the event streams on here. The event streams are
we have the entry on the top we have the entry
on the second fields. As the user types we have
the Login button click. We have the Cancel button click
and we have like the Web Request. So we have effectively
five different events. Streams that we need to describe. So we can break these up
into their reactive parts. So these are all pretty unexciting. This is that same stuff you
saw before which is basically just saying Hey I want to create this observable that’s listening
to the clicked event. So this is the core aspect
of this that’s exciting. So we create an observable for
each of these different elements. We have our login. So that’s when they click. We have our logout. That’s when they log out. We have our cancel. That’s
when they click “Cancel”. We have the Text Change
here which is when they’re typing in the username and we have the Password here when they’re
typing in the password. Then, we make
a fake Web Request call. So this is just demonstrating. It’s essentially just
waiting two seconds. Then once it finishes it generates an error if some random
number equals two. Yeah. So that’s our application. That’s in observable
representation of all the events that can occur
in the application, right? So now this is where the composability aspect comes
into play which is really cool. Now, all of these
different observables take a life of their own. So the entirety of
the logic that you see there is embodied with a fairly
simple amount of code, right? So here this is our validation code. So now what we do is
we’re building up additional observables on
these other observables. Right? So that’s what’s
the composability aspect of it. So the first one is we say okay we want an
authenticated observable. The authenticated observable
is the user clicking “Login” and clicking
off “Web Request”. So now we’ve composed these two
ideas of observable events. We’ve now merged this data
stream with a logout. So if a user clicks “Logout”
then that’s saying “Hey, I want you to log out.” So we have the entire
authentication state of the application represented by
a new observable authenticated. Authenticated observable. So that’s the only observable
we care about at this point. So that’s how now we can use that observable anywhere else where we want to ask about what is
the user authenticated. You know which is need. Then here we have our validation. Our validation is a composition of our Username and our Password
there which is nice. So that essentially comes in. It says “Hey, these are the data points
that represent the validity.” It transforms those events into a true or a false value that we
can now use to say, “Okay. What is the state of the events
that have been coming in? ” So then this let’s us now put together- Now we can put
all of this stuff together. This is where kind of
like the functional reactive programming aspect
comes into play. We can now put all these different
observables together into one nice little place here that describes everything
that’s going to be happening. So this is the part of
it that’s really neat. Because with this
application you can get a perspective scope on all of the logic just by being right
here in this code point. There’s no having to
jump around or anything. It’s an immutable location based on immutable data to modify
how these data points work. So it’s nice because
it’s a nice easy way. So like the data that comes
in this result value here is an immutable structure. Then based on this data you
know authenticated observable. So what this is doing
here is saying what’s your authentication state is whether
you’re authenticated or not. Valid is saying whether the
credentials they entered as are valid. Then based on that, you set up the visibility
of your application. Yeah, so you can set up
like the visibility of your application. So it’s neat. So let’s see. I have one more demo real quick, just a small one. Oops, a little too big
there. There we go. Does everyone see that, all right? Yeah. All right. I have these
up in like GitHub repos. This is using a little bit
of the reactive UI stuff, but let me just show. This has a few different samples
that you can take a look at. Hopefully, it runs. Is it
already running? There it goes. So a lot of these are
simple things that you see. Let’s look at the
position demo since we’re running low on time here. So the idea of the position demo is that it’s you’re tracking
your mouse pointer. This has another popular example
for reactive concepts. So you push down. It’s detecting that you press. If you move your mouse around, now it’s detecting that you moved, and then you let go, and it gives you an aggregation of all your data. It’s broken up a little bit because I need to have
the descriptions, but it’s really neat because
all you have to really do, you have your pointer pressed event. So you have the pointer
press which says, “Hey, I’ve pressed the mouse down.” Now, once this has
happened, you say, “Okay, I want to subscribe to
the pointer being moved around.” So this is now the pointer
being moved around. As it’s moving now, you’re pulling all this data
together here, and then the two list operator, here, is now able to
aggregate all that data together into a single data set. Then here, the take until that was the one operation that
we were showing here. It says, “Hey, okay,
I only want you to take this data and tell
the pointers released.” So you get this really
cool interaction of all these events to say, because all you really wanted
to say is I want to move the mouse around and when
they let go of the mouse, I want all the data that was there. So you can get all of this represented in this nice
little subscription here. So this is one of
those main examples. Yes, so that’s a quick primer
into the reactive concepts. There’s a lot of
good frameworks out there. Oops, not helpful. There we go. Yeah. So that’s the idea behind
most of the observables. Michael’s going to talk
a bit more about using these frameworks with MVVM. There’s a lot of really powerful
tools like dynamic data. Select Dynamic Data, it’s a really cool platform for superpower in your lists
with observables. So the idea is that you can essentially make
everything and observable. You can to sign it,
I didn’t know that. So I guess real quick, does anyone have questions? Yes, Sam. Well, yeah. We’ll let’s just go there. We’ll
do questions some 35 minutes.>>So talk about the disclosing of the
[inaudible] and all that stuff. Talk about why observables
are better [inaudible].>>Yeah, so I guess I would say because
the management- So the question was, with the memory leaking, why is the fact that it returns a disposable better first
say memory management? The idea there is just, yeah, it’s it’s the fact that
it’s the lifetime of the observable is an aspect
of the subscription. So when you’re subscribing
to it, you get back, because anytime you get
a disposable from something, you know that you have
to dispose of it. Like that’s the paradigm that we use. So that’s the idea about it. It’s that with the venting
especially for new programmers, they’re always going to
make that as mistake where are like something’s going to outlive something else because you have to understand that. But a disposable is
a very basic concept. So having that as part
of the subscription makes your memory management
scenarios easier. Yeah. Any other questions? Yeah.>>[inaudible].>>Yeah. So the question was, can you use Reactive Programming with things like tasks or
asynchronous programming? Yeah. So a task is effectively
a one-point notification. So when you have a task, there’s three data points for
a task which is exactly like our iterator when we were indicating. So when you write a task- Okay, I don’t know where it’s
coming up. All right. So when you have a task, you create the task so that’s
you having it in the beginning, then you start the task
so now it’s running, and then the task produces a value, that’s your dot results
which none of us are typing, and then it completes at
the completion of that. So at that point, you have one data point observable. So disposable creates things that work exactly against the task so that you can create an
observable against the task. So then what will happen is when
you subscribe to that observable, is it’ll effectively start the task
and then once that happens, that kicks back a results. So that produces one value
and then it completes. Then that’s another thing
that’s really super helpful because if that task fails, you get your stuff with observables where you
can catch the exception. So for example, scenarios
like async void, for example. Async void is a non-issue
with observables. You never have to worry about async void If you’re
doing observables. So for example, you know how you
maybe want to start an async task from a constructor or things like that or these issues from
those with observables, that’s not even a scenario, because you just wrap the task in an observable and then you have the exception behavior as part
of the observable with the task. So yeah, they work. They’re great for tasks. So there I forget who does a talk. Jeffrey or something like
that does a talk on that; talking about how tasks are super bad and you should
just use observables. But yeah, once you start using observables especially
in your UI code, you’ll effectively just put a facade in front of all
of your tasks because it becomes so much simpler to
manage through observables. Any other questions? I’m getting the shhh. Can I take one more
question? No? Okay, no. I’ll answer your
question right after. Cool. So yeah, I’m Shane. That’s my observables.

Posted by Lewis Heart

This article has 3 comments

  1. I think that CompositeDisposable can never be builtin library thing. Its fine for things you know will never fail (such as unsubscribing from event). However dispose pattern is mainly intended for unmanaged resources and having exceptions there can complicate things.

    Reply
  2. While the speaker obviously has knowledge I think he should practiced the talk more. It kind of looked like he never gone through it once. The presentation of operators (event stream lines) was pretty unclear. Also IMO demo should have been split into multiple demos. As it is there is too many things happening at once.

    Reply
  3. I did not understand anything at all. Unlike the other sessions, nothing is clear in this presentation, not even the demo.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *