[RELEASED] Data Bind for Unity

Hi there!

The first version of Data Bind for Unity is available in the Asset Store! Check it out now for a very low initial price and help me with your feedback to further develop it for your needs!


Introduction:
A clean separation between logic/data and visualization is a must-have, not only in software projects (http://en.wikipedia.org/wiki/Separation_of_presentation_and_content). This guarantees that the business logic of the application isn't dependent on the presentation, so the visualization can be easily adapted.

One famous architecture, at least in the Microsoft universe, is the MVVM pattern (http://en.wikipedia.org/wiki/Model_View_ViewModel) which is highly utilized in Windows Presentation Foundation (WPF, http://en.wikipedia.org/wiki/Windows_Presentation_Foundation). I don't want to get too much into detail of this framework as it a fully developed business framework with a huge amount of complex stuff.

The part we are interested in is the data binding between the view and the view model. The view model is an additional structure which sits between the view and the logic. It gets its data from the logic of the application and provides an interface for the view to use. Via data bindings the view can use the data provided by the view model to show it to the user.

This is what we adapted with our plugin, so you'll have a common way how your UI is separated from you game logic to get many cool advantages:

• Don't be afraid that UI changes break your game any more, the logic is completely separated
• Exchange your UI system without touching any logic (e.g. from NGUI to Unity UI)
• Easily extend the plugin to use it with a custom UI, world objects or custom input commands

Example: Easy Health Bars

Tired of remembering to update two variables (actor.Health = 20.0f, healthLabel.Text = „20“) if the health of your character changed, so the UI is updated correctly?

No problem, Data Bind will take care of this from now on. You just update the data in your context and the UI will update magically!

Okay, not really magically, but without any work on your side. In principal it works like this:

• The data variables in your context are wrapped in a so called "Data property"
• The bindings on UI side register for value changes on this properties
• When your code sets a new value for your data, the property informs its listeners, so they can update the UI properly.

In your code...

Code (CSharp):

1. public class PlayerContext : Context
2. {
3.     #region Fields
4.  
5.     /// <summary>
6.     ///   Data binding property, used to get informed when a data change happened.
7.     /// </summary>
8.     private readonly Property<int> healthProperty = new Property<int>();
9.  
10.     #endregion
11.  
12.     #region Properties
13.  
14.     public int Health
15.     {
16.         get
17.         {
18.             return this.healthProperty.Value;
19.         }
20.         set
21.         {
22.             this.healthProperty.Value = value;
23.         }
24.     }
25.  
26.     #endregion
27. }

...at the same time on the UI side:

More information

Check out the official documentation with tutorials, examples, API and explanations. If any questions are left, just send me a message or post in this thread!

Hope our asset serves you as well as it does for our projects to keep your logic and presentation separated from each other! A big update with many additional bindings was already created and is reviewed currently. I'll keep you updated when it arrives.

 

Version 1.0.1 is now available in the store! It contains many new bindings and some fixes/refactorings. Here is the detailed changelog:

• CHANGED: Structure - Local path changed from DataBind to Slash.Unity.DataBind to fit namespaces
• ADDED: Context - Getting value for context node possible from field as well.
• FIXED: Property - Null reference check before converting value of data property.
• CHANGED: Collection - Collection base class implements IEnumerable, not IEnumerable[object] so the type of the concrete collection is identified correctly in Linq queries.
• CHANGED: Bindings - Only triggering setters in OnEnable if data binding was already initialized with initial data values.
• FIXED: Command - Safe cast to delegate in Command.
• CHANGED: Foundation - Changed BehaviourSingleGetter/Setter to ComponentSingleGetter/Setter.
• CHANGED: Foundation - Created base class for ItemsSetter to use it for other collection setters as well.
• CHANGED: UnityUI - Made GridItemsSetter for UnityUI more generic to work for all LayoutGroups.
• CHANGED: Active Setter - Changed naming in menu from "Active" to "Active Setter".
• ADDED: Command - Reset method is used to set initial target behaviour.
• ADDED: Bindings - Added several checks, formatters and setters: ComparisonCheck, EqualityCheck, ArithmeticOperation, InvertBoolFormatter, LogicalBoolFormatter, PrependSign, RoundToNearestOperation, TextFileContentFormatter, TimeFormatter, AnimatorBooleanSetter.
• ADDED: NGUI - Added several setters/getters for PopupList, Button and Slider.
• ADDED: Unity UI - Added serveral setters/getters for Slider and Image control.
• ADDED: Foundation - ComponentSingleSetter checks if target is null before updating the component.
• ADDED: Core - Throwing exception if invalid path is passed to context in RegisterListener, RemoveListener or SetValue.
• CHANGED: Game Object Items Setter - Only created items are removed on clear, not all children.

Furthermore I wrote up a dev post on the weekend to explain how data binding in general and Data Bind for Unity in particular works:

http://unity-coding.slashgames.org/the-magic-behind-data-binding-part-1/

It's the first part of a series of posts, covers how data properties and data contexts work internally and hopefully give you some insights. It isn't required to understand the internals to use the asset though, but if you are as curious as I am it might be interesting to read anyway

Ask all your questions about the asset right here in the thread, I'm eager to answer them!

 

This is interesting, I may be looking at this wrong but is this primarily for UI?

 

Hi @cybervaldez,

Happy to hear that it is interesting for you

Many of the scripts are there to set the correct data values on UI controls, that's right. But the data binding itself isn't limited to UI, we already use it in our projects to place and setup the game objects in the game world.

For example the ActiveSetter just activates/deactivates a game object depending on a boolean data value, this doesn't have to be a UI control. The GameObjectItemsSetter creates child game objects for a game object depending on a collection from the data context.

The thing is that the scripts for world objects are quite specific to the project, so that's why there are not that many generic ones. I added some like the PositionSetter and the LocalPositionSetter. Something similar for rotation and scaling is very quickly done. See http://slashgames.org:8090/display/DBFU/Create+Your+Own+Setter for a short documentation how to add new setters.

If you can think of any further generic setters or need help writing your own ones, let me know

 

Really interesting!
How is hard to use it with NGUI?

 

Hi @kenshin,

Pretty easy, the steps are almost the same as with Unity UI. Many scripts are available for both UIs, Unity UI as well as NGUI. The examples are available for both, too.

All you have to do after importing the package is to extract the package NGUIExtensions in the Addons folder. This will import all NGUI specific scripts.

 

Great, thanks for the quick answer!

 

No problem If you try the asset let me hear your feedback, I'm always looking for ways to improve it!

 

Some more coding monkey gibberish on this boring Sunday? Here you go! It's about commands in data binding and how the data of a data context is arranged (It's a tree!).

http://unity-coding.slashgames.org/the-magic-behind-data-binding-part-2-commands-and-data-tree/

It should describe how our asset works behind the scenes. If you have any further questions, don't hesitate to ask!

 

This time Unity was a lot faster reviewing the update for Data Bind, so version 1.0.2 is already available in the Asset Store!

Besides some additional generic bindings which could be useful in many projects and some code refactoring, the biggest addition is a drop down to select the context data path from! This means you don't have to type in the path manually anymore which should prevent type errors and let's you also make sure you set up your hierarchy the way you wanted to:



It works for:

• Setters
• Getters
• MasterPaths
• Commands

To make the drop downs work correctly, the context type has to be specified in the ContextHolder script which is probably located at the root node of your UI.

Custom paths are still possible, e.g. if you want to access an ancestor data context with the "#" syntax.

Thanks to @sonicviz who wished for this feature after he had a look at our asset!

Here's the full changelog of version 1.0.2:
* ADDED: Core - Added exceptions if trying to set a read-only property or method.
* CHANGED: Core - DataNode sets value of field or property instead of data property, so even raw members of a context are updated correctly.
* CHANGED: Bindings - Renamed GameObjectSetter to GameObjectSingleSetter.
* CHANGED: Core - Made some methods of context holder virtual to allow deriving from the class if necessary.
* FIXED: Data Bind - Returning path to context if no path is set after #X notation.
* CHANGED: Data Bind - Logging error instead of exception if invalid path was specified (on iOS exceptions caused a crash).
* CHANGED: Editor - Adjusted component menu titles for bindings to be more consistent.
* ADDED: Setters - Added binding to create a child game object from a prefab with a specific context.
* ADDED: GraphicColorSetter - Setter for color of a Graphic component (e.g. Text and Image).
* CHANGED: ArithmeticOperation - Checking second argument for zero before doing division to avoid exception.
* ADDED: Unity UI - Added SelectableInteractableSetter to change if a selectable is interactable depending on a boolean data value.
* ADDED: Operations - Added sprite loader which loads a sprite depending on a string value.
* ADDED: Core - Added log error when context is not derived from Context class, but path is set. This may indicate that the user forgot to derive from Context class.
* ADDED: Context Path - Added property drawer for a context path property.
* CHANGED: Context Holder - Only creating context automatically if explicitly stated and no context is already set in Awake.

 

My co-founder Nick wrote a new tutorial where he describes how you can extend the asset with your own scripts, e.g. one that converts a string to upper characters before assigning it to a text/label:



http://slashgames.org:8090/display/DBFU/Create+Your+Own+Formatter

It's a really clean and reusable way of extending the functionality. If you have ideas for cool scripts that we should add to the asset, let us know!

Enjoy the read!

 

The Link does not work on my end

 

Hi @zyzyx,

Which one doesn't work, http://slashgames.org:8090/display/DBFU/Create+Your+Own+Formatter ? Just tested it on my side, it works here. Or do you mean another link?

 

Yes the Formatter link and the link to the documentation. Mybe it gets blocked somewhere on my end.

 

That's strange, never heard of a problem with the address. Does http://www.slashgames.org/ work?

 

I'm in the office so it probably gets blocked by the firewall. If I use a proxy it works

 

Phew, so it's not on our side, good Thanks for checking out! Hope you like the asset and find it useful.

 

Thanks! I intend using your asset in two of our upcoming mobile apps

 

Nice Let me know if you run into any problems. We used the asset for our own projects already but there might be some issues which weren't discovered yet.

 

Next version 1.0.3 is out! Main change in this one is the correct Windows 8 Phone and Store support. It was already in there, but not properly tested. Now it should work without problems

Here's the full changelog:

 

I'm having some problems understanding this data binding method. I have an inventory, so I always want my inventory slots contain the number of items in each slot. The Slot class is basically like this:

Code (CSharp):

1. public class Slot {
2.     List<Item> Items;
3.  
4.     void AddItem(Item item) {
5.         // ...
6.     }
7.  
8.     public string ItemCount {
9.         get {
10.             return Items.Count.ToString();
11.         }
12.     }
13. }

How would I go about to bind ItemCount to a text field in my GUI? The documentation shows examples of using getters and setters, but the item count number is really never set (except internally whenever the List changes).

Thanks in advance!

 

Hi @toreau

Thanks for your question. To provide data to the UI you have to create data contexts. In your case I would create two: One for a single inventory item and one for the inventory.

Code (CSharp):

1.  
2. public class InventoryItemContext : Context
3. {
4.     #region Fields
5.  
6.     private readonly Property<int> amountProperty = new Property<int>();
7.     private readonly Property<string> typeIdProperty = new Property<string>();
8.  
9.     #endregion
10.  
11.     #region Properties
12.  
13.     public int Amount
14.     {
15.         get { return this.amountProperty.Value; }
16.         set { this.amountProperty.Value = value; }
17.     }
18.  
19.     public string TypeId
20.     {
21.         get { return this.typeIdProperty.Value; }
22.         set { this.typeIdProperty.Value = value; }
23.     }
24.  
25.     #endregion
26. }
27.  

Code (CSharp):

1.  
2. public class InventoryContext : Context
3. {
4.     #region Fields
5.  
6.     private readonly Property<Collection<InventoryItemContext>> slotsProperty=
7.         new Property<Collection<InventoryItemContext>>(new Collection<InventoryItemContext>());
8.  
9.     #endregion
10.  
11.     #region Properties
12.  
13.     public Collection<InventoryItemContext> Slots
14.     {
15.         get { return this.slotsProperty.Value; }
16.         set { this.slotsProperty.Value = value; }
17.     }
18.  
19.     #endregion
20. }
21.  

If you change a property or add a new InventoryItemContext to the Slots property, your UI should reflect those data changes immediately.

Let me know if you got it working, I'm happy to help if you have more questions

 

Hi @coeing -- thanks for Data Bind and also for your informative "behind the scenes" blog posts, which I've been reading and enjoying. I bought and have been hacking around with Data Bind this morning to see how it works. One (open-ended) question for now: how would you compare your package to the open-source Unity3d-Databinding project by NVentimiglia?

 

Another question @coeing -- any fundamental reason you chose to not use UnityEvents to integrate the new-style Unity GUI with the DB contexts?

EDIT: I realize I didn't ask my question very well. I know you ARE using UnityEvents in the code. My question is about the Inspector interface in the Editor. Why for instance add a ButtonClickCommand script to a UI element instead of some way to hook things up via the On Click interface in Inspector?

 

Hi @Ghopper21!

Thanks for trying out my asset and playing around with it!

Considering the comparison: I haven't checked out the other project, so I can't tell you the difference, advantages and disadvantages. At a first glance it has some of the same features, but it's more important with which you can work better and that's something you have to try

About your UnityEvents question: They work with MonoBehaviours and the data contexts are not MonoBehaviours. So you can't just drag them on to the OnClick interface and select the method to call. I tried to keep the data side (contexts, properties,...) independent from Unity as the bindings (setters, getters, commands) do the whole connection to the UI controls.

Hope my information is helpful. Feel free to ask if you have more questions! By the way: We use Data Bind again for our current project, so any tips for useful features are welcome and if we develop new additions, I will put them into the package for everyone to use

 

Hi there!

I'm writing a little development blog for a few months now to share my experience in Unity game development. Today I finished a post about how we made our Data Bind for Unity asset work together with our component-based entity framework called Slash framework:

http://unity-coding.slashgames.org/creating-a-component-based-game-part-v-data-binding/

It isn't limited of using the asset with our framework thought, most of it is easily applicable to other architectures with which you implement your logic as well.

So if you gave it a read, I'm very eager to hear your feedback about it. Anything that remained unclear? Suggestions about doing things different?

Cheers
Christian

 

By the way: The project of the blog post series now contains a stripped version of Data Bind, so if you want to get a feel how it works, check out the git repository: https://bitbucket.org/coeing/kill-stuff

 

I just submitted the update for Data Bind to version 1.0.4 There is not one big change, but several small ones that were very helpful in our current projects. Here is a short overview, you can find the whole change log in the API documentation and in the Readme.txt which comes with the project.

Bugfixes:
- PathPropertyDrawer - Custom path wasn't shown initially
- EqualityCheck - Converting data value before doing equality check to consider comparison e.g. to string constant
- PathPropertyDrawer - All arguments of StringFormatter switched to custom path if switching one to it. Storing custom path flag for each property path separately. (Issue: https://bitbucket.org/coeing/data-bind/issue/3/custom-path-is-shown-for-all-path).
- Clearing cached contexts when hierarchy changed. Otherwise a wrong cached context is used when a game object is placed under a new parent game object, e.g. on lists.
- StringFormatter - Forwards the format string if string.Format fails.
- Private fields of base classes for derived types are not reflected, so base classes have to be searched for data property holders as well.

Core:
- Paths are now relative if there are multiple master paths in between a data binding and the next context.
- Added indexer, IndexOf and RemoveAt method to Collection class.

Providers/Setters/Getters:
- Setter/Getter for Unity Toggle.isOn property
- Getter for values of a specific enum
- EqualityCheck: Works with enums now
- ArithmeticOperation/InvertBoolOperation/TimeFormatter: Some renaming to be more consistent
- ItemsSetter - Creating items even if value is just an enumeration and no Collection
- Setters - Added non-abstract GameObjectItemsSetter to use to instantiate game objects for the items of a collection.

Examples:
- StringToUpperFormatter which converts all characters of a text into upper case.
- Equality check and unit tests for enums

Misc:
- Testing: Added ContextHolderInitializer to create a context of a specific type and set it on a ContextHolder​

As you can see, a lot of small changes, but summing them together definitively worth an update.

But there is more: I wrote a blog post on how to connect Data Bind to the logic of your game, it might be worth a read:



http://unity-coding.slashgames.org/creating-a-component-based-game-part-v-data-binding/

The source code of the example game which is developed there also contains a stripped version of Data Bind, so you might use it to check if data bind works for you: https://bitbucket.org/coeing/kill-stuff

Last, but not least: The price of the asset will raise to 20$ with this update. So if you consider buying it, you should think about purchasing it before the update is rolled out by Unity

For any questions: Don't hesitate to ask me!

 

Just a quick update: The update 1.0.4 is live! Hope you enjoy the new possibilities. Let me know if any problems occur. And if you are content with our asset, make sure to leave a review

 

What is the intended use of the Master Path component?

 

Hi @kru!

The MasterPath script is meant to specify that you want to use a sub context/path for all the children of the game object you put the script on.

Example:

Context
- Data Property A
- Data Property B
-- Data Property B1
-- Data Property B2

Now if you have e.g. a UI widget which doesn't really care about the main context, but only about the context that is stored in Data Property B, you can put a MasterPath script on the root game object of the UI widget and set the path to "B". Now to access the properties of Data Property B inside the widget, you don't have to write B.B1, but only B1.

It is quite useful when you have prefabs that work on specific contexts which you use in different locations. With the master paths, the paths in the prefab stay the same all the time, you just have to point to the correct place where the expected context is.

 

Hey,

Just started with your lib. I was wondering I have several objects that use the same scripts. When I click on one of the objects i need to show a popup and display their stats. How would you switch between objects without creating duplicate contexts?

Edit:

I'm not entirely sure how the changes are made. Do I have to make calls on the contexts getters and setters?

 

Hi @SidarVasco,

Thanks for trying out our asset

From the first read I would do it like this: You have a specific handler which is called when an object was clicked and which knows which object was clicked. This handler creaes (or just activates, as you need it) the popup window, creates or adjusts the data context for the window and sets it on the ContextHolder of the window.

You can then re-use a window or context you have created once.

About how changes are made: You just work on the data context and don't have to access the mono behaviours themselves at all. The only connection between the data and the UI is the ContextHolder script where the data context is set on initialization.

Hope it helps, let me know if you have more questions!

 

Hey,

Thanks for the reply. Im not entirely sure if I get it.

In one of your examples you change the "Text" property in the Start() function. Im assuming I have to call changes on the getters and setters I define in the Context files I make? Otherwise I have no clue how it would know what has changed.

Code (csharp):

1.  
2. using UnityEngine;
3. using System.Collections;
4. using Slash.Unity.DataBind.Core.Data;
5.  
6. public class ResourceGeneratorContext : Context
7. {
8.     /// <summary>
9.     ///   Data binding property, used to get informed when a data change happened.
10.     /// </summary>
11.     private readonly Property<string> power = new Property<string>();
12.     private readonly Property<string> capacity = new Property<string>();
13.  
14.     public string Power
15.     {
16.         get
17.         {
18.             return this.power.Value;
19.         }
20.         set
21.         {
22.             this.power.Value = value;
23.         }
24.     }
25.  
26.     public string Capacity
27.     {
28.         get
29.         {
30.             return this.capacity.Value;
31.         }
32.         set
33.         {
34.             this.capacity.Value = value;
35.         }
36.     }
37.  
38. }
39.  
40.  

This is what I have.
And I've tried following your examples but my text isn't updating.

Do I have to do myContext.Capacity = " blah " ?

 

Bump

 

Hi @SidarVasco,

Sorry, I was quite busy the last days

I got your last question wrong, using the property getter and setter is the correct way of using the data contexts.

We had a context for each entity/object (e.g. for each ResourceGenerator) which we created once the object was created and adjusted when it was updated (e.g. by listening for PowerChanged events or something similar).

Then when it is clicked we would create the UI for the popup and assign the correct context to it. After the popup is closed you can throw away the UI but keep the contexts as they are.

Does this help?

 

Thanks for the reply,


Edit:

I think my confusion comes from the fact that I don't understand from the tutorials which object needs to have the ContextHolder. If I add the ContextHolder to the same object that has the TextTextSetter the paths are automatically populated with the properties to choose from. However I don't have a clear understanding how it would work if I don't add the ContextHolder to the same object with TextTextSetter.

But then what exactly do I need to instantiate in my " power generator" object?

The create Context escapes me as well. When I set that to true, what exactly am I dealing with? What is changing the properties and how? Do I have to cast the Context to ResourceGeneratorContext as apposed to " setting " the context?.

 

Normally we have only one ContextHolder script for one UI, e.g. for a window. This script is located on the root game object (the Canvas game object may be a good place).

The TextTextSetter will use the context of the first ContextHolder it finds when moving up the hierarchy. So you don't need a ContextHolder on each game object that has a setter.

The "Create Context" property on the ContextHolder script is mainly for testing or for simple setups. In your case with the popup for multiple different objects a custom script would take care about setting the correct context for the context holder, e.g. when an object is clicked. Casting anything shouldn't be necessary.

 

Cool, thanks. I was going in that direction. Although my text isn't changing. But ill look into that.

So the only "Hard" reference here is the root of the gui with the context holder. Again thanks for your help.

 

Yes, that's right The context holder does the connection between the mono behaviours (e.g. TextTextSetter) and the pure logical data context. This way the two are separated in a clean way. Let me know when you have other questions!

 

It looks like there is some connectivity. The ui elements update nicely when I switch between contexts. But when I change context values the UI is not updated ( I've logged the values of my Context properties and they have the correct values). Any idea why this might happen?

Unity 5.2 btw.

 

The only thing that comes to my mind without seeing the code is that you may not have the right naming for your private data bind property fields. They have to be called NameOfData + Property (see http://slashgames.org:8090/display/DBFU/Data+Context,+Property+and+Collection at "Naming Conventions")

 

Ah! I did read that article but completely missed the "Property" part was mandatory. It works now. Cool stuff.

Although why does it work on the initial setup?

 

Great to hear!

The bindings are designed to work with "normal" fields/properties as well, it just takes the current value from them, but they can't register for the event when the data changes. So the initial value is correct, but the bindings are not updated when the value changes.

I made a note and will check if I can print out a warning or something as the naming convention is not too obvious and a common mistake.

 

Noted. This lib really speeds up development. Using the same Context objects for different UI is superb. Saving me a lot of time and headache from boredom ( drag and dropping gameobjects in inspectors )

 

Yes, reusing contexts is really great We generally have one custom window context (e.g. for the actions you can do in that window like closing it or performing an action) where we set the general data contexts like the player context or a unit context. Glad you like it, too!

 

Hi,

I was wondering how I could implement this with a multiplayer game. Would I need a new context for each player?

 

Hi @Hodgson_SDAS,

Thanks for trying out our asset. In a multiplayer game Data Bind would be used on the client between the logic that handles the game on the client and syncs itself with the server and the UI/presentation. So it doesn't really matter if you have a single or multiplayer game.

You would probably have a context for each player which consists of the data each player has (name, health, level,...). Inside the PlayerContext you could have sub contexts like a WeaponContext that hold the data of the current weapon the player is carrying. So the structure of the contexts is very close to how the player sees the game. This makes it easier to use the contexts to visualize the data inside the UI or in the game.

You just have to have a way to update the data in the contexts from your logic which depends on the kind of architecture you use for your logic. We use an event-driven framework, so we update the contexts when events occur that indicate a data change (e.g. HealthChanged).

Hope this helps!

Cheers
Christian

 

Hey,

Just wondering as I'm not concerned with performance for my use case but using the collection context, is there a way to pool the objects?

 

Hi @SidarVasco,

There is no generic way right now, but it shouldn't be too hard to add. The GameObjectItemsSetter is derived from the ItemsSetter and just does the instantiation of the item game objects from the provided Prefab. You could use some kind of PooledGameObjectItemsSetter which doesn't destroy its game objects but disables and reuses them instead.

I added it to the nice-to-have list of our asset as well, so thanks for your feedback!

Cheers
Christian