How to Manage Event Subscriptions at run time

Question

Ok Thanks for the comments and suggestions I've revised my question to more accurately reflect what I need.

I'm reading up on how INotifyPropertyChanged works in WPF so that I can implement a sort of bastardization of it in another technology where my UI gets notified any time a property I am tracking on the UI changes (Unity 4.6).

Basically what I need is from how the XAML manages data binding and events for INotifyPropertyChanged when Properties in the code are changed

I have a Unity Project where I need to know how I should have my UI class setup to subscribe to events that tell the UI there has been a change to a property displayed on the UI, and to make all instances where there is Text on the UI associated with that property to update. I need to have the events subscribed to at Run Time because when I am subscribing to them at compile time I am getting Null Reference Exceptions from objects that are null at the time when I have properties displayed on the screen when that object is not null. I.e a class MyObject with a property Property1 where I want to display

var MyGameObject1 = new MyObject();
MyGameObject1.Property1 = "Bob";

where in my setter I have

public string Property1
{
get
{
return _property1;
}
set
{
_property1 = value;
NotifyPropertyChanged("Property1");
}
}
public event EventHandler<UnityPropertyChangedEventArgs>  PropertyChanged;

private void NotifyPropertyChanged(string propertyChanged)
{
    if (PropertyChanged != null)
    {
        PropertyChanged(this, new UnityPropertyChangedEventArgs(propertyChanged));
    }
}

How can I get my UI to manage at runtime the UI elements I am displaying via text and receive events fired from their setters any time their value changes.

Answer 1

Since you want to implement something similar in your Unity-based environment, it may be that you would be better off asking a question that addresses that specifically. That said, to answer your specific questions:

1. "What subscribes to PropertyChanged to register a change has occurred."

WPF subscribes to it.

2. "Where does it subscribe to it. if at runtime, how?"

It depends on the exact context. In some cases, the XAML compiler can generates code that subscribes to the event. In other cases, this can't be done until runtime, which is accomplished by checking that the object implements INotifyPropertyChanged and subscribing to the event if it is.

3. "Is this something automatic through INotifyPropertyChanged."

It is automatic in the sense that WPF is automatically handling the event provided by that interface. The interface itself does not cause this to happen automatically per se. I.e. simply implementing that interface would not, in some other context, cause the same things to happen.

4. "Next, how does it know WHICH property on the UI to update based on the fact it only knows the PropertyName (as far as I can tell) when the event is fired when whatever is subscribing to the event receives it."

In XAML-based applications, there is information in the XAML itself that refers to a specific property, binding that property to some UI element (e.g. a property of the element, its style, etc.). You didn't show any XAML, so it's not possible to state specifically how it works in your examples.

Answer 2

have a null object that I want to display a property of on my UI "SelectedObject.Property1" when it gets set.

Just use an observer pattern -- it's as simple as that. Add a "property updated" event to your source model class, and have your UI classes subscribe to the event.

What subscribes to PropertyChanged to register a change has occurred.

If you look at the "PropertyChanged" invocation list of a UI-bound property, you will notice that there is a "WeakEventListener" attached for each bound XAML property. Weak event listeners can attach to an event without preventing garbage collection on the object that owns the event.

Where does it subscribe to it. if at runtime, how?

This is where you get into the internals of the framework. The basic idea is that UI elements have an associated data context, and when the data context is set or changed, then any bindings subscribe to the source events. The runtime stores a visual tree for the XAML, and the data context is inherited down the visual tree. (Note that XAML also supports inter-UI bindings such as "ElementName" and "RelativeSource", which attach to other elements in the visual tree, not to the data context.)

Next, how does it know WHICH property on the UI to update based on the fact it only knows the PropertyName (as far as I can tell) when the event is fired when whatever is subscribing to the event receives it.

That's not quite right. The binding holds information about the source, as well as the target. It actually holds a reference to the source object, so that it can retrieve the value using the property name when it receives a change notification.

The more I look at this the more it seems magic is involved somewhere with setting up binding and having UI updates performed.

The runtime handles the plumbing, so you don't really see it. I think the key point is to use a mediator object like the XAML "binding", which subscribes to events on the source, and updates the target as needed. That way the source (view model) and target (view) objects keep their autonomy -- again, that decoupling is the key point of the observer pattern.