Observable FromEventPattern when object rasing events is reinstantiated
I am trying to set up an observable in a class that will tick each time an event fires on a member.
public class FooService
private BarProvider _barProvider;
public IObservable<BarChangedEventArgs> BarChanged get;
public FooService()
BarChanged =
Observable
.FromEventPattern<BarChangedHandler, BarChangedEventArgs>(
h => _barProvider.Changed += h,
h => _barProvider.Changed -= h)
.Select(p => p.EventArgs);
public void OccursSomeTimeAfterFooServiceCreation
(
Func<BarProvider> barProviderFactory
)
_barProvider = barProviderFactory();
What I think I need to do is set up the event handler observable after assigning the new value of _barProvider in the OccursLater method, as this is a new event source. However, I believe setting BarChanged at this later point, after consumers may have already subscribed, will break those existing subscriptions.
I would like consumers of the FooService to be able to subscribe to BarChanged at any point, and see the observable as one stream of event args, regardless of how many times OccursSomeTimeAfterFooServiceCreation is called after the subscription is created.
system.reactive
add a comment |
I am trying to set up an observable in a class that will tick each time an event fires on a member.
public class FooService
private BarProvider _barProvider;
public IObservable<BarChangedEventArgs> BarChanged get;
public FooService()
BarChanged =
Observable
.FromEventPattern<BarChangedHandler, BarChangedEventArgs>(
h => _barProvider.Changed += h,
h => _barProvider.Changed -= h)
.Select(p => p.EventArgs);
public void OccursSomeTimeAfterFooServiceCreation
(
Func<BarProvider> barProviderFactory
)
_barProvider = barProviderFactory();
What I think I need to do is set up the event handler observable after assigning the new value of _barProvider in the OccursLater method, as this is a new event source. However, I believe setting BarChanged at this later point, after consumers may have already subscribed, will break those existing subscriptions.
I would like consumers of the FooService to be able to subscribe to BarChanged at any point, and see the observable as one stream of event args, regardless of how many times OccursSomeTimeAfterFooServiceCreation is called after the subscription is created.
system.reactive
1
Could you please provide a Minimal, Complete, and Verifiable example?
– Enigmativity
Nov 12 '18 at 23:41
add a comment |
I am trying to set up an observable in a class that will tick each time an event fires on a member.
public class FooService
private BarProvider _barProvider;
public IObservable<BarChangedEventArgs> BarChanged get;
public FooService()
BarChanged =
Observable
.FromEventPattern<BarChangedHandler, BarChangedEventArgs>(
h => _barProvider.Changed += h,
h => _barProvider.Changed -= h)
.Select(p => p.EventArgs);
public void OccursSomeTimeAfterFooServiceCreation
(
Func<BarProvider> barProviderFactory
)
_barProvider = barProviderFactory();
What I think I need to do is set up the event handler observable after assigning the new value of _barProvider in the OccursLater method, as this is a new event source. However, I believe setting BarChanged at this later point, after consumers may have already subscribed, will break those existing subscriptions.
I would like consumers of the FooService to be able to subscribe to BarChanged at any point, and see the observable as one stream of event args, regardless of how many times OccursSomeTimeAfterFooServiceCreation is called after the subscription is created.
system.reactive
I am trying to set up an observable in a class that will tick each time an event fires on a member.
public class FooService
private BarProvider _barProvider;
public IObservable<BarChangedEventArgs> BarChanged get;
public FooService()
BarChanged =
Observable
.FromEventPattern<BarChangedHandler, BarChangedEventArgs>(
h => _barProvider.Changed += h,
h => _barProvider.Changed -= h)
.Select(p => p.EventArgs);
public void OccursSomeTimeAfterFooServiceCreation
(
Func<BarProvider> barProviderFactory
)
_barProvider = barProviderFactory();
What I think I need to do is set up the event handler observable after assigning the new value of _barProvider in the OccursLater method, as this is a new event source. However, I believe setting BarChanged at this later point, after consumers may have already subscribed, will break those existing subscriptions.
I would like consumers of the FooService to be able to subscribe to BarChanged at any point, and see the observable as one stream of event args, regardless of how many times OccursSomeTimeAfterFooServiceCreation is called after the subscription is created.
system.reactive
system.reactive
asked Nov 12 '18 at 21:07
Max Hampton
434315
434315
1
Could you please provide a Minimal, Complete, and Verifiable example?
– Enigmativity
Nov 12 '18 at 23:41
add a comment |
1
Could you please provide a Minimal, Complete, and Verifiable example?
– Enigmativity
Nov 12 '18 at 23:41
1
1
Could you please provide a Minimal, Complete, and Verifiable example?
– Enigmativity
Nov 12 '18 at 23:41
Could you please provide a Minimal, Complete, and Verifiable example?
– Enigmativity
Nov 12 '18 at 23:41
add a comment |
2 Answers
2
active
oldest
votes
If your Observable - creation depends on stuff that can change e.g. your barProvider, you should always retrieve those from other Observables and then utilize the Switch() operator.
To achieve this I utilized the BehaviorSubject.
public class FooService
public BehaviorSubject<BarProvider> _barProviderSubject = new BehaviorSubject<BarProvider>(null); //or initialize this subject with the barprovider of your choice
public IObservable<BarChangedEventArgs> BarChanged get;
public FooService()
var barChangedChanged = _barProviderSubject.Where(bP => bP != null).Select(bP =>
Observable.FromEventPattern<BarChangedHandler, BarChangedEventArgs>(
h => bP.Changed += h,
h => bP.Changed -= h)
.Select(p => p.EventArgs)
);
BarChanged = barChangedChanged.Switch();
public void OccursSomeTimeAfterFooServiceCreation
(
Func<BarProvider> barProviderFactory
)
_barProviderSubject.OnNext(barProviderFactory());
The answer I accepted because it appears to be working. I believe the .Select(subject) should be .Subscribe, making it so the subject acts as observer for each _barProvider's event. That subject is exposed through BarChanged => subject.AsObservable();
– Max Hampton
Nov 14 '18 at 17:20
I actually updated my code to use the BehaviorSubject. My initial thought was that I should be somehow picking up the barProvider change in an observable but wasn't sure how to do that. This addresses exactly that with a tool designed for monitoring this sort of change over time. Going to change this to my accepted answer for this problem.
– Max Hampton
Nov 14 '18 at 19:32
A Subject<T> is both andIObservable<T>
that you can subscribe to and anIObserver<T>
that can subscribe to any observable.
– Paulo Morgado
Nov 15 '18 at 0:18
Oh, I get it! There were "a few characters" "missing". :)
– Paulo Morgado
Nov 15 '18 at 0:21
add a comment |
The problem is that you don't observe classes or variables. You observe instances.
If I understand it correctly, you want your subscribers to be oblivious of the fact that the observed instance changes.
Try something like this:
public class FooService
private BarProvider _barProvider;
private Subject<BarChangedEventArgs> subject = new Subject<BarChangedEventArgs>();
public IObservable<BarChangedEventArgs> BarChanged get; = subject.AsObservable();
public FooService()
public void OccursSomeTimeAfterFooServiceCreation
(
Func<BarProvider> barProviderFactory
)
_barProvider = barProviderFactory();
BarChanged =
Observable
.FromEventPattern<BarChangedHandler, BarChangedEventArgs>(
h => _barProvider.Changed += h,
h => _barProvider.Changed -= h)
.Select(p => p.EventArgs)
.Subscribe(subject);
I ended up doing something very similar to this approach. As opposed to reassigning BarChanged each time _barProvider changes, I havepublic IObservable<BarChangedEventArgs> BarChanged => subject.AsObservable().
With this, I got rid of the BarChanged assignment when _barProvider is assigned. If I set BarChanged again to a new Observable instance, wouldn't that cause existing subscriptions to break still?
– Max Hampton
Nov 13 '18 at 16:59
I don't think I get what you're saying.
– Paulo Morgado
Nov 14 '18 at 0:43
What I mean is that I may have a class that consumes the FooService. I get my FooService instance through constructor injection, and subscribe to BarChanged in the constructor. Much later in the code I may call _fooService.OccursSomeTime... after the BarChanged subscription is set. I don't want the consuming class to have to subscribe to BarChanged again in this scenario, I want it to be handled internally by the FooService.
– Max Hampton
Nov 14 '18 at 17:32
And the code I posted isn't doing that?
– Paulo Morgado
Nov 15 '18 at 0:13
I didn't test your code exactly as written. In the OccursSomeTime function, BarChanged is being assigned again. It looks like after the edit it is trying to assign an IDisposable subscription to an IObservable<Args>. If we take awayBarChanged = ...
and just set up the subscription (how I adapted your answer) I'm concerned with how to handle disposing the subscriptions that are created each time. I feel like the BehaviorSubject handles this cleanly.
– Max Hampton
Nov 15 '18 at 17:00
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53270118%2fobservable-fromeventpattern-when-object-rasing-events-is-reinstantiated%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
If your Observable - creation depends on stuff that can change e.g. your barProvider, you should always retrieve those from other Observables and then utilize the Switch() operator.
To achieve this I utilized the BehaviorSubject.
public class FooService
public BehaviorSubject<BarProvider> _barProviderSubject = new BehaviorSubject<BarProvider>(null); //or initialize this subject with the barprovider of your choice
public IObservable<BarChangedEventArgs> BarChanged get;
public FooService()
var barChangedChanged = _barProviderSubject.Where(bP => bP != null).Select(bP =>
Observable.FromEventPattern<BarChangedHandler, BarChangedEventArgs>(
h => bP.Changed += h,
h => bP.Changed -= h)
.Select(p => p.EventArgs)
);
BarChanged = barChangedChanged.Switch();
public void OccursSomeTimeAfterFooServiceCreation
(
Func<BarProvider> barProviderFactory
)
_barProviderSubject.OnNext(barProviderFactory());
The answer I accepted because it appears to be working. I believe the .Select(subject) should be .Subscribe, making it so the subject acts as observer for each _barProvider's event. That subject is exposed through BarChanged => subject.AsObservable();
– Max Hampton
Nov 14 '18 at 17:20
I actually updated my code to use the BehaviorSubject. My initial thought was that I should be somehow picking up the barProvider change in an observable but wasn't sure how to do that. This addresses exactly that with a tool designed for monitoring this sort of change over time. Going to change this to my accepted answer for this problem.
– Max Hampton
Nov 14 '18 at 19:32
A Subject<T> is both andIObservable<T>
that you can subscribe to and anIObserver<T>
that can subscribe to any observable.
– Paulo Morgado
Nov 15 '18 at 0:18
Oh, I get it! There were "a few characters" "missing". :)
– Paulo Morgado
Nov 15 '18 at 0:21
add a comment |
If your Observable - creation depends on stuff that can change e.g. your barProvider, you should always retrieve those from other Observables and then utilize the Switch() operator.
To achieve this I utilized the BehaviorSubject.
public class FooService
public BehaviorSubject<BarProvider> _barProviderSubject = new BehaviorSubject<BarProvider>(null); //or initialize this subject with the barprovider of your choice
public IObservable<BarChangedEventArgs> BarChanged get;
public FooService()
var barChangedChanged = _barProviderSubject.Where(bP => bP != null).Select(bP =>
Observable.FromEventPattern<BarChangedHandler, BarChangedEventArgs>(
h => bP.Changed += h,
h => bP.Changed -= h)
.Select(p => p.EventArgs)
);
BarChanged = barChangedChanged.Switch();
public void OccursSomeTimeAfterFooServiceCreation
(
Func<BarProvider> barProviderFactory
)
_barProviderSubject.OnNext(barProviderFactory());
The answer I accepted because it appears to be working. I believe the .Select(subject) should be .Subscribe, making it so the subject acts as observer for each _barProvider's event. That subject is exposed through BarChanged => subject.AsObservable();
– Max Hampton
Nov 14 '18 at 17:20
I actually updated my code to use the BehaviorSubject. My initial thought was that I should be somehow picking up the barProvider change in an observable but wasn't sure how to do that. This addresses exactly that with a tool designed for monitoring this sort of change over time. Going to change this to my accepted answer for this problem.
– Max Hampton
Nov 14 '18 at 19:32
A Subject<T> is both andIObservable<T>
that you can subscribe to and anIObserver<T>
that can subscribe to any observable.
– Paulo Morgado
Nov 15 '18 at 0:18
Oh, I get it! There were "a few characters" "missing". :)
– Paulo Morgado
Nov 15 '18 at 0:21
add a comment |
If your Observable - creation depends on stuff that can change e.g. your barProvider, you should always retrieve those from other Observables and then utilize the Switch() operator.
To achieve this I utilized the BehaviorSubject.
public class FooService
public BehaviorSubject<BarProvider> _barProviderSubject = new BehaviorSubject<BarProvider>(null); //or initialize this subject with the barprovider of your choice
public IObservable<BarChangedEventArgs> BarChanged get;
public FooService()
var barChangedChanged = _barProviderSubject.Where(bP => bP != null).Select(bP =>
Observable.FromEventPattern<BarChangedHandler, BarChangedEventArgs>(
h => bP.Changed += h,
h => bP.Changed -= h)
.Select(p => p.EventArgs)
);
BarChanged = barChangedChanged.Switch();
public void OccursSomeTimeAfterFooServiceCreation
(
Func<BarProvider> barProviderFactory
)
_barProviderSubject.OnNext(barProviderFactory());
If your Observable - creation depends on stuff that can change e.g. your barProvider, you should always retrieve those from other Observables and then utilize the Switch() operator.
To achieve this I utilized the BehaviorSubject.
public class FooService
public BehaviorSubject<BarProvider> _barProviderSubject = new BehaviorSubject<BarProvider>(null); //or initialize this subject with the barprovider of your choice
public IObservable<BarChangedEventArgs> BarChanged get;
public FooService()
var barChangedChanged = _barProviderSubject.Where(bP => bP != null).Select(bP =>
Observable.FromEventPattern<BarChangedHandler, BarChangedEventArgs>(
h => bP.Changed += h,
h => bP.Changed -= h)
.Select(p => p.EventArgs)
);
BarChanged = barChangedChanged.Switch();
public void OccursSomeTimeAfterFooServiceCreation
(
Func<BarProvider> barProviderFactory
)
_barProviderSubject.OnNext(barProviderFactory());
edited Dec 18 '18 at 10:02
answered Nov 14 '18 at 13:20
Felix Keil
1,4381318
1,4381318
The answer I accepted because it appears to be working. I believe the .Select(subject) should be .Subscribe, making it so the subject acts as observer for each _barProvider's event. That subject is exposed through BarChanged => subject.AsObservable();
– Max Hampton
Nov 14 '18 at 17:20
I actually updated my code to use the BehaviorSubject. My initial thought was that I should be somehow picking up the barProvider change in an observable but wasn't sure how to do that. This addresses exactly that with a tool designed for monitoring this sort of change over time. Going to change this to my accepted answer for this problem.
– Max Hampton
Nov 14 '18 at 19:32
A Subject<T> is both andIObservable<T>
that you can subscribe to and anIObserver<T>
that can subscribe to any observable.
– Paulo Morgado
Nov 15 '18 at 0:18
Oh, I get it! There were "a few characters" "missing". :)
– Paulo Morgado
Nov 15 '18 at 0:21
add a comment |
The answer I accepted because it appears to be working. I believe the .Select(subject) should be .Subscribe, making it so the subject acts as observer for each _barProvider's event. That subject is exposed through BarChanged => subject.AsObservable();
– Max Hampton
Nov 14 '18 at 17:20
I actually updated my code to use the BehaviorSubject. My initial thought was that I should be somehow picking up the barProvider change in an observable but wasn't sure how to do that. This addresses exactly that with a tool designed for monitoring this sort of change over time. Going to change this to my accepted answer for this problem.
– Max Hampton
Nov 14 '18 at 19:32
A Subject<T> is both andIObservable<T>
that you can subscribe to and anIObserver<T>
that can subscribe to any observable.
– Paulo Morgado
Nov 15 '18 at 0:18
Oh, I get it! There were "a few characters" "missing". :)
– Paulo Morgado
Nov 15 '18 at 0:21
The answer I accepted because it appears to be working. I believe the .Select(subject) should be .Subscribe, making it so the subject acts as observer for each _barProvider's event. That subject is exposed through BarChanged => subject.AsObservable();
– Max Hampton
Nov 14 '18 at 17:20
The answer I accepted because it appears to be working. I believe the .Select(subject) should be .Subscribe, making it so the subject acts as observer for each _barProvider's event. That subject is exposed through BarChanged => subject.AsObservable();
– Max Hampton
Nov 14 '18 at 17:20
I actually updated my code to use the BehaviorSubject. My initial thought was that I should be somehow picking up the barProvider change in an observable but wasn't sure how to do that. This addresses exactly that with a tool designed for monitoring this sort of change over time. Going to change this to my accepted answer for this problem.
– Max Hampton
Nov 14 '18 at 19:32
I actually updated my code to use the BehaviorSubject. My initial thought was that I should be somehow picking up the barProvider change in an observable but wasn't sure how to do that. This addresses exactly that with a tool designed for monitoring this sort of change over time. Going to change this to my accepted answer for this problem.
– Max Hampton
Nov 14 '18 at 19:32
A Subject<T> is both and
IObservable<T>
that you can subscribe to and an IObserver<T>
that can subscribe to any observable.– Paulo Morgado
Nov 15 '18 at 0:18
A Subject<T> is both and
IObservable<T>
that you can subscribe to and an IObserver<T>
that can subscribe to any observable.– Paulo Morgado
Nov 15 '18 at 0:18
Oh, I get it! There were "a few characters" "missing". :)
– Paulo Morgado
Nov 15 '18 at 0:21
Oh, I get it! There were "a few characters" "missing". :)
– Paulo Morgado
Nov 15 '18 at 0:21
add a comment |
The problem is that you don't observe classes or variables. You observe instances.
If I understand it correctly, you want your subscribers to be oblivious of the fact that the observed instance changes.
Try something like this:
public class FooService
private BarProvider _barProvider;
private Subject<BarChangedEventArgs> subject = new Subject<BarChangedEventArgs>();
public IObservable<BarChangedEventArgs> BarChanged get; = subject.AsObservable();
public FooService()
public void OccursSomeTimeAfterFooServiceCreation
(
Func<BarProvider> barProviderFactory
)
_barProvider = barProviderFactory();
BarChanged =
Observable
.FromEventPattern<BarChangedHandler, BarChangedEventArgs>(
h => _barProvider.Changed += h,
h => _barProvider.Changed -= h)
.Select(p => p.EventArgs)
.Subscribe(subject);
I ended up doing something very similar to this approach. As opposed to reassigning BarChanged each time _barProvider changes, I havepublic IObservable<BarChangedEventArgs> BarChanged => subject.AsObservable().
With this, I got rid of the BarChanged assignment when _barProvider is assigned. If I set BarChanged again to a new Observable instance, wouldn't that cause existing subscriptions to break still?
– Max Hampton
Nov 13 '18 at 16:59
I don't think I get what you're saying.
– Paulo Morgado
Nov 14 '18 at 0:43
What I mean is that I may have a class that consumes the FooService. I get my FooService instance through constructor injection, and subscribe to BarChanged in the constructor. Much later in the code I may call _fooService.OccursSomeTime... after the BarChanged subscription is set. I don't want the consuming class to have to subscribe to BarChanged again in this scenario, I want it to be handled internally by the FooService.
– Max Hampton
Nov 14 '18 at 17:32
And the code I posted isn't doing that?
– Paulo Morgado
Nov 15 '18 at 0:13
I didn't test your code exactly as written. In the OccursSomeTime function, BarChanged is being assigned again. It looks like after the edit it is trying to assign an IDisposable subscription to an IObservable<Args>. If we take awayBarChanged = ...
and just set up the subscription (how I adapted your answer) I'm concerned with how to handle disposing the subscriptions that are created each time. I feel like the BehaviorSubject handles this cleanly.
– Max Hampton
Nov 15 '18 at 17:00
add a comment |
The problem is that you don't observe classes or variables. You observe instances.
If I understand it correctly, you want your subscribers to be oblivious of the fact that the observed instance changes.
Try something like this:
public class FooService
private BarProvider _barProvider;
private Subject<BarChangedEventArgs> subject = new Subject<BarChangedEventArgs>();
public IObservable<BarChangedEventArgs> BarChanged get; = subject.AsObservable();
public FooService()
public void OccursSomeTimeAfterFooServiceCreation
(
Func<BarProvider> barProviderFactory
)
_barProvider = barProviderFactory();
BarChanged =
Observable
.FromEventPattern<BarChangedHandler, BarChangedEventArgs>(
h => _barProvider.Changed += h,
h => _barProvider.Changed -= h)
.Select(p => p.EventArgs)
.Subscribe(subject);
I ended up doing something very similar to this approach. As opposed to reassigning BarChanged each time _barProvider changes, I havepublic IObservable<BarChangedEventArgs> BarChanged => subject.AsObservable().
With this, I got rid of the BarChanged assignment when _barProvider is assigned. If I set BarChanged again to a new Observable instance, wouldn't that cause existing subscriptions to break still?
– Max Hampton
Nov 13 '18 at 16:59
I don't think I get what you're saying.
– Paulo Morgado
Nov 14 '18 at 0:43
What I mean is that I may have a class that consumes the FooService. I get my FooService instance through constructor injection, and subscribe to BarChanged in the constructor. Much later in the code I may call _fooService.OccursSomeTime... after the BarChanged subscription is set. I don't want the consuming class to have to subscribe to BarChanged again in this scenario, I want it to be handled internally by the FooService.
– Max Hampton
Nov 14 '18 at 17:32
And the code I posted isn't doing that?
– Paulo Morgado
Nov 15 '18 at 0:13
I didn't test your code exactly as written. In the OccursSomeTime function, BarChanged is being assigned again. It looks like after the edit it is trying to assign an IDisposable subscription to an IObservable<Args>. If we take awayBarChanged = ...
and just set up the subscription (how I adapted your answer) I'm concerned with how to handle disposing the subscriptions that are created each time. I feel like the BehaviorSubject handles this cleanly.
– Max Hampton
Nov 15 '18 at 17:00
add a comment |
The problem is that you don't observe classes or variables. You observe instances.
If I understand it correctly, you want your subscribers to be oblivious of the fact that the observed instance changes.
Try something like this:
public class FooService
private BarProvider _barProvider;
private Subject<BarChangedEventArgs> subject = new Subject<BarChangedEventArgs>();
public IObservable<BarChangedEventArgs> BarChanged get; = subject.AsObservable();
public FooService()
public void OccursSomeTimeAfterFooServiceCreation
(
Func<BarProvider> barProviderFactory
)
_barProvider = barProviderFactory();
BarChanged =
Observable
.FromEventPattern<BarChangedHandler, BarChangedEventArgs>(
h => _barProvider.Changed += h,
h => _barProvider.Changed -= h)
.Select(p => p.EventArgs)
.Subscribe(subject);
The problem is that you don't observe classes or variables. You observe instances.
If I understand it correctly, you want your subscribers to be oblivious of the fact that the observed instance changes.
Try something like this:
public class FooService
private BarProvider _barProvider;
private Subject<BarChangedEventArgs> subject = new Subject<BarChangedEventArgs>();
public IObservable<BarChangedEventArgs> BarChanged get; = subject.AsObservable();
public FooService()
public void OccursSomeTimeAfterFooServiceCreation
(
Func<BarProvider> barProviderFactory
)
_barProvider = barProviderFactory();
BarChanged =
Observable
.FromEventPattern<BarChangedHandler, BarChangedEventArgs>(
h => _barProvider.Changed += h,
h => _barProvider.Changed -= h)
.Select(p => p.EventArgs)
.Subscribe(subject);
edited Nov 15 '18 at 0:20
answered Nov 12 '18 at 23:43
Paulo Morgado
5,57611531
5,57611531
I ended up doing something very similar to this approach. As opposed to reassigning BarChanged each time _barProvider changes, I havepublic IObservable<BarChangedEventArgs> BarChanged => subject.AsObservable().
With this, I got rid of the BarChanged assignment when _barProvider is assigned. If I set BarChanged again to a new Observable instance, wouldn't that cause existing subscriptions to break still?
– Max Hampton
Nov 13 '18 at 16:59
I don't think I get what you're saying.
– Paulo Morgado
Nov 14 '18 at 0:43
What I mean is that I may have a class that consumes the FooService. I get my FooService instance through constructor injection, and subscribe to BarChanged in the constructor. Much later in the code I may call _fooService.OccursSomeTime... after the BarChanged subscription is set. I don't want the consuming class to have to subscribe to BarChanged again in this scenario, I want it to be handled internally by the FooService.
– Max Hampton
Nov 14 '18 at 17:32
And the code I posted isn't doing that?
– Paulo Morgado
Nov 15 '18 at 0:13
I didn't test your code exactly as written. In the OccursSomeTime function, BarChanged is being assigned again. It looks like after the edit it is trying to assign an IDisposable subscription to an IObservable<Args>. If we take awayBarChanged = ...
and just set up the subscription (how I adapted your answer) I'm concerned with how to handle disposing the subscriptions that are created each time. I feel like the BehaviorSubject handles this cleanly.
– Max Hampton
Nov 15 '18 at 17:00
add a comment |
I ended up doing something very similar to this approach. As opposed to reassigning BarChanged each time _barProvider changes, I havepublic IObservable<BarChangedEventArgs> BarChanged => subject.AsObservable().
With this, I got rid of the BarChanged assignment when _barProvider is assigned. If I set BarChanged again to a new Observable instance, wouldn't that cause existing subscriptions to break still?
– Max Hampton
Nov 13 '18 at 16:59
I don't think I get what you're saying.
– Paulo Morgado
Nov 14 '18 at 0:43
What I mean is that I may have a class that consumes the FooService. I get my FooService instance through constructor injection, and subscribe to BarChanged in the constructor. Much later in the code I may call _fooService.OccursSomeTime... after the BarChanged subscription is set. I don't want the consuming class to have to subscribe to BarChanged again in this scenario, I want it to be handled internally by the FooService.
– Max Hampton
Nov 14 '18 at 17:32
And the code I posted isn't doing that?
– Paulo Morgado
Nov 15 '18 at 0:13
I didn't test your code exactly as written. In the OccursSomeTime function, BarChanged is being assigned again. It looks like after the edit it is trying to assign an IDisposable subscription to an IObservable<Args>. If we take awayBarChanged = ...
and just set up the subscription (how I adapted your answer) I'm concerned with how to handle disposing the subscriptions that are created each time. I feel like the BehaviorSubject handles this cleanly.
– Max Hampton
Nov 15 '18 at 17:00
I ended up doing something very similar to this approach. As opposed to reassigning BarChanged each time _barProvider changes, I have
public IObservable<BarChangedEventArgs> BarChanged => subject.AsObservable().
With this, I got rid of the BarChanged assignment when _barProvider is assigned. If I set BarChanged again to a new Observable instance, wouldn't that cause existing subscriptions to break still?– Max Hampton
Nov 13 '18 at 16:59
I ended up doing something very similar to this approach. As opposed to reassigning BarChanged each time _barProvider changes, I have
public IObservable<BarChangedEventArgs> BarChanged => subject.AsObservable().
With this, I got rid of the BarChanged assignment when _barProvider is assigned. If I set BarChanged again to a new Observable instance, wouldn't that cause existing subscriptions to break still?– Max Hampton
Nov 13 '18 at 16:59
I don't think I get what you're saying.
– Paulo Morgado
Nov 14 '18 at 0:43
I don't think I get what you're saying.
– Paulo Morgado
Nov 14 '18 at 0:43
What I mean is that I may have a class that consumes the FooService. I get my FooService instance through constructor injection, and subscribe to BarChanged in the constructor. Much later in the code I may call _fooService.OccursSomeTime... after the BarChanged subscription is set. I don't want the consuming class to have to subscribe to BarChanged again in this scenario, I want it to be handled internally by the FooService.
– Max Hampton
Nov 14 '18 at 17:32
What I mean is that I may have a class that consumes the FooService. I get my FooService instance through constructor injection, and subscribe to BarChanged in the constructor. Much later in the code I may call _fooService.OccursSomeTime... after the BarChanged subscription is set. I don't want the consuming class to have to subscribe to BarChanged again in this scenario, I want it to be handled internally by the FooService.
– Max Hampton
Nov 14 '18 at 17:32
And the code I posted isn't doing that?
– Paulo Morgado
Nov 15 '18 at 0:13
And the code I posted isn't doing that?
– Paulo Morgado
Nov 15 '18 at 0:13
I didn't test your code exactly as written. In the OccursSomeTime function, BarChanged is being assigned again. It looks like after the edit it is trying to assign an IDisposable subscription to an IObservable<Args>. If we take away
BarChanged = ...
and just set up the subscription (how I adapted your answer) I'm concerned with how to handle disposing the subscriptions that are created each time. I feel like the BehaviorSubject handles this cleanly.– Max Hampton
Nov 15 '18 at 17:00
I didn't test your code exactly as written. In the OccursSomeTime function, BarChanged is being assigned again. It looks like after the edit it is trying to assign an IDisposable subscription to an IObservable<Args>. If we take away
BarChanged = ...
and just set up the subscription (how I adapted your answer) I'm concerned with how to handle disposing the subscriptions that are created each time. I feel like the BehaviorSubject handles this cleanly.– Max Hampton
Nov 15 '18 at 17:00
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53270118%2fobservable-fromeventpattern-when-object-rasing-events-is-reinstantiated%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Could you please provide a Minimal, Complete, and Verifiable example?
– Enigmativity
Nov 12 '18 at 23:41