What is data binding?

A good example of this is a list box that shows several items. If you’re writing a list box that can only show an alphabetical list of country names, it won’t be very useful in other applications. It would be really bad if anytime we wanted to use a list box, we had to write it all over again for each scenario.

List boxes normally have methods you can call to add and remove items displayed. That’s not data binding though. A list box capable of data binding will have a property such as dataSource. All you have to do is point the list box to the source of the data and it can go get the items to be displayed itself. This really helps simplify your code. All you have to do is change sources and you get new data.

But if there’s a bigger benefit, it has to be that the link between the consumer of the data and the source of the data can remain even though the data itself changes.

This is called a master-details pattern. You need a data source of all the items and you start out by setting the data source for your list control to this source. But you also need to tell it what properties to use. Maybe the data source has many different collections of items. You need to let the list box know which property on the source has the data it needs to display. You can get as specific as you need and you might also need to tell the list box which property to use as a unique identifier and which property to use for the display text. Users don’t normally care about identifiers. They just want a friendly name for things.

Listen to the episode or read the full transcript below for additional benefits to using data binding.

Transcript

Imagine you work for a construction company and your job is to gather information about how many cars pass by with just a single passenger. Your company needs this information to plan the best way to build roads and you can’t use the automatic counters because they count too many vehicles.

All you really need to do is take notes and write a report each day about what you saw. You don’t look everywhere at once. You’re given a specific location to observe each day. The work is the same and the only thing that’s different is where you get your information. Over time, you get really good at this. Almost as if you just run a mental program.

I know, that’s a strange example. But it does represent the essentials of data binding. You have some code that performs some task and needs data. Where it gets the data can change without affecting the code. In other words, the data is bound to a particular source and then later to another source.

A good example of this in programming is a list box that shows several items. If you’re writing a list box that can only show an alphabetical list of country names, it won’t be very useful in other applications. It would be really bad if anytime we wanted to use a list box, we had to write it all over again for each scenario.

List boxes normally have methods you can call to add and remove items displayed. That’s not data binding though. A list box capable of data binding will have a property such as dataSource. All you have to do is point the list box to the source of the data and it can go get the items to be displayed itself. This really helps simplify your code. All you have to do is change sources and you get new data.

But if there’s a bigger benefit, it has to be that the link between the consumer of the data and the source of the data can remain even though the data itself changes.

Have you ever used an application that presents a list of items and allows you to select one and get more information about it? Sure you have. Even this podcast is a list of episodes and once you select an episode, you can see details about the episode and play it.

This can all be done with data binding. And I’ll explain how right after this message from our sponsor.

A source of information can supply all sorts of data. How will a consumer know what it needs? While knowing the source of data is important for data binding, the consumer also needs to know which properties to use.

The example I gave earlier about being able to select an item from a list and then interact with just the selected item is called a master-details pattern.

You need a data source of all the items and you start out by setting the data source for your list control to this source. But you also need to tell it what properties to use. Maybe the data source has many different collections of items. You need to let the list box know which property on the source has the data it needs to display. You can get as specific as you need and you might also need to tell the list box which property to use as a unique identifier and which property to use for the display text. Users don’t normally care about identifiers. They just want a friendly name for things.

Then your list control can update its own property that it uses to let other code know which item is currently selected.

That enables the other benefit of a well designed data binding system to allow just the data to change while the source remains unchanged. A data source can let other code know when properties change. Listen to episode 77 about the observer design pattern for more information.

We need a data source for the details view and while this could be the list control, it would be better to introduce another object that’s focused on just a single item at a time and that binds to the currently selected item in the list control. This object will use the currently selected identifier to fill in various details about the selected item and will act as a controller for the details view. When the user selected a new item, the source of the currently selected item remains the same and only the data that identifies which item is selected needs to change. That’s the data that the new controller object will be watching out for.

Then you can have a whole page of views that each bind to one or more of the detailed properties. If this is a list of podcast episodes, then maybe one of them is the name and another is the length. You may or may not want to show the name again. That’s up to designers and usability tests to find out what customers need and expect. But something like the length of the episode probably won’t appear in the main list of episodes. I mean, it could, but in general, you don’t want to put all the information into a big list control. You just want to put enough information so the user can find what they’re looking for and then display all the other details in the details view.

The details view will then have a bunch of controls, edit boxes, numeric controls, check boxes, etc. that all work together to show the details for whichever item is selected in the master list control. Each of these controls will bind to the controller object that exists to focus on just one item at a time. That’s why this pattern is called master-details.

And a great way to design something like this is with data binding. Because all the connections and relationships that control where the information comes from can be coded so it can change dynamically.

Now an example like this really only shows a fraction of the power of data binding. There’s still two big benefits to explain.

So far, I’ve only explained how data binding works to consume information. But it can be used to synchronize too. While your podcast app may allow you to select an episode and then interact with that selected episode, you can’t really change anything. But other applications might let you change stuff.

Maybe you have an application that displays several alarms to wake you up at different times. This is also a master-details application. You select an alarm and then view the details about that alarm. But here, the data binding allows you to make changes. You can change the time and that change travels back through the data binding so that the original source of the information gets updated. This is called synchronization or also two-way data binding.

I’ll mention one last benefit of data binding. I already explained how the data bindings can either change entirely or remain in place while the data changes from one selected item to another at runtime. But where are these relationships specified? They can be written into your code, sure. But a good data binding system will allow you to setup the bindings outside of your code. In other words, it uses data to specify the data bindings.

This is really powerful because it means that you can change how your application behaves at runtime and even who creates the bindings during development. Normally, we think of developers having full control over how an application behaves. But data binding because it’s not written in code but in simple statements that identify sources and properties, one-way, two-way, even triggers that can react to events, all this means that a designer can play a much bigger role in application development.