UPDATE Check the CallMemberName-Possibility here
In the first part I told something about the databinding here. The second part should be something about refreshing the data at the UI. We said that the UI only knows the datacontext and its properties. So far so god. It is binding them at startup and we’re done so far.
Just to calm down the ones who expect a solution: Can be found in the third article here
But what if the data underneath is changing. What if a service or anything else has new data and want to tell the UI “Hey there, I have something new!”
Therefore the binding has to be “refreshed” and we have the INotifyPropertyChanged-Interface to get this job done.
Lets take our code from before and give it a timer which sets the name we want to display after 3 seconds:
”Hallelujah” is always my testword because im pretty sure it occurs nowhere else in a solution ;) So if you see this, its mine
So, if you debug this you will see that the timer gets into the timer_elapsed-function and sets the name but the UI does not change. So lets implement a way to refresh the UI! Only implement the INotifyPropertyChanged-interface:
So everthing we do is throwing the event that something has changed with the name of the property as a string. If you let this run you will see that the UI refreshes and after 3 seconds the “hallelujah” is displayed. But this has some disadvantages:
- We are throwing the event in the timer_elapsed. So only when this is done the property is refreshed
- We are having the name of the property as a string in it. So renaming the property will mostly NOT rename the string. (Magic String). And the refresh does not work again.
- Refreshing the UI is a base function. It should be outsourced in like a base file or something.
Lets tune this:
- First we will make a namespace for this (I love namespaces) called “Common” and make a basefile in there.
- We will make this function generic expecting a lambda-Expression to erase the magic string
- We will call the refreshing thing in the setter of the property itself. Then its getting refreshed everytime someone in the code sets it.
which looks like:
This is taking the member and throwing the event for us on this member. That was Point 1 and 2. Let it be (three)!
We do inherit from the just created class and can access the event with the lambda-expression, which is more generic:
Remeber: In the elapsed-method we are setting the property (not the private variable) directly that the setter is called and the event is thrown.
This is not the only way to implement this. This can be done in several ways. But for beginners this should do the trick.
Run it, it will show you the text after three seconds.
If you want to, read further how you can get this cleaner with services and erase the NotifyPropertyChangedBase from the viewmodel.
Lets tune this a little bit: The viewmodel does a lot of work. It does not have to do this, so lets extract this a bit and make it more clean.
First we do a NameProvider, which gives us the name. In my case again with a timer to see the UI changing. Normally this could be a service or something else without a timer. Could be anything which triggers the UI to change (not only) after a piece of work.
Everything we did here is moving the timer-logic into a provider and offering the property through an interface to the outside.
Our viewmodel now has nearly no logic anymore:
This principle I am also describing here.
Now we have to change the binding a bit. Because now the viewmodel is giving us the property to bind not directly but onto another property “NameProvider”. So the Binding looks like this:
Run this and you will see the result stays the same: After three seconds our string is displayed.
So what we did now is: Getting our Viewmodel nice and clean. It gives us an overview of services and providers which the UI can use. It does not inherit from NotifyPropertyChangedBase. You saw how flexible databinding is. Not only with strings but you can bind also lists of objects etc.