Observable FromEventPattern when object rasing events is reinstantiated










1














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.










share|improve this question

















  • 1




    Could you please provide a Minimal, Complete, and Verifiable example?
    – Enigmativity
    Nov 12 '18 at 23:41















1














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.










share|improve this question

















  • 1




    Could you please provide a Minimal, Complete, and Verifiable example?
    – Enigmativity
    Nov 12 '18 at 23:41













1












1








1







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.










share|improve this question













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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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












  • 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












2 Answers
2






active

oldest

votes


















0














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());







share|improve this answer






















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


















0














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);







share|improve this answer






















  • 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










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










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
);



);













draft saved

draft discarded


















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









0














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());







share|improve this answer






















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















0














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());







share|improve this answer






















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













0












0








0






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());







share|improve this answer














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());








share|improve this answer














share|improve this answer



share|improve this answer








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
















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















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













0














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);







share|improve this answer






















  • 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










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















0














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);







share|improve this answer






















  • 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










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













0












0








0






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);







share|improve this answer














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);








share|improve this answer














share|improve this answer



share|improve this answer








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










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










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

















draft saved

draft discarded
















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Top Tejano songwriter Luis Silva dead of heart attack at 64

政党

天津地下鉄3号線