Closed mthiele closed 8 years ago
Unsubscribe all observers for a given message key isn't a good idea in my opinion as it leads to a tighter coupling between the sender and the observers. You don't know if there are other observers for a message key that may be still interested in getting messages for a key.
But I've changed the DefaultNotificationCenter to use WeakReferences to hold the observers. I hope that there are no unexpected side effects resulting from this change. Could you please review the code to see if I've missed something? I have the feeling that this change needs a lot of manual testing to be sure no existing apps will break.
I've reverted the commit as it leads to unexpected behaviour like listeners that aren't notified anymore.
Instead of using WeakReferences we will stay with hard references and make it easier for the user to manage subscriptions and make individual unsubscribes. For example RxJava returns a Subscription
object that has a unsubscribe
method. The user can store the Subscriptions
in a Collection and unsubscribe when the component is removed. From mvvmFX perspective we should try to provide livecycle methods that the user can use to react on removal of a View/ViewModel.
Related issue: #251
We will address this issue when we implement the typesafe notificationcenter, see #250
Add the possibility to do a weakSubscribe on the NotificationCenter
With PR #390 we introduces the possibility to use weak observers.
When registering an observer to the
NotificationCenter
, this instance will never be garbage collected, since the NotificationCenter holds a hard reference on the observer even though it might not be referenced anywhere else. The solution is to manually keep track of when which observer is destroyed and the unregister it from the NotificationCenter by hand which is clumsy or live with possible memory leaks. It would also be helpful to have a method to unsubscribe all observers.