[RELEASED] Data Bind for Unity

Hi,

I have created a subclass of ItemsSetter, and I have noticed that CreateItem receives different associations of "itemContext" and "itemIndex" for the same collection.

After further investigation, it looks like if ItemsSetter.OnCollectionItemAdded calls CreateItem with an index of "collection.count" (therefore passing an index of 1 to CreateItem for the first itemContext added to the collection).
On the other hand, ItemsSetter.CreateItems calls CreateItem with an index of 0 for the first item in the IEnumerable. In my case, ItemsSetter.CreateItems gets called upon enabling the behavior, even when items have not changed in the collection, and my implementation of CreateItem.

Question: is there a way for CreateItem to always receive the same itemIndex for the same itemContext when the collection is unchanged?

Thanks
Nicolas

In ItemsSetter.OnCollectionItemAdded, CreateItem is called with an index of 1 for the first item added to the collection (I am tempted to change it to "this.collection.Count - 1" as a temporary fix.)

Code (CSharp):

1.  
2.  
3.         private void OnCollectionItemAdded(object item)
4.         {
5.             // Create game object for item.
6.             this.CreateItem(item, this.collection.Count);
7.             this.OnItemsChanged();
8.         }

In ItemsSetter.CreateItems(IEnumerable itemContexts), CreateItem is called with an index of 0 for the first item added to the collection.

Code (CSharp):

1.             // Fill with objects from collection.
2.             var itemIndex = 0;
3.             foreach (var itemContext in itemContexts)
4.             {
5.                 // Create game object for item.
6.                 this.CreateItem(itemContext, itemIndex++);
7.             }
8.  
9.             this.OnItemsChanged();

 

Hi @nrorn,

This definitively looks like a bug, thanks for reporting! Could you add an issue to the official bug tracker? https://bitbucket.org/coeing/data-bind/issues It's enough if you copy and paste your already great description there. I will try to reproduce the issue with a unit test and fix it in the next version.

 

Hey everyone. I am facing a problem with this asset and was wondering if any has an idea of how to get around a problem. Basically I have several complex UI objects, with their own canvases on a map, and when I go from one view to another; I deactivate them and then activate them again. I do this in order to move the camera to another view of the game.

This fires SingleSetter.OnEnable and GameObjectSingleSetter.Awake consuming a lot of resources needlessly, as the camera change didn't affect any of the values shown in these UI objects. The GC alloc memory and number of calls take too much time, as you can see below:



So do any of you know any way I can disable this from firing? I don't need it as these objects will only update when the game status changes and that is determined from it's logic, not by the Unitys GameObject status. However I do need to deactivate them, as they shouldn't be seen on this other camera mode. Thanks in advance!

 

The new version 1.18 of Data Bind was just submitted with 3 issues which where reported by fellow devs (thanks!) and is now in review

If there are any issues you are still missing, there is a public issue tracker where everybody can add their wishes, bug reports, ideas, feedback,...:

https://bitbucket.org/coeing/data-bind/issues

In the future I will only submit a package for the recent LTS version of Unity (currently 2018.4.20f1). An update to later versions should be possible without any problems (at least it was in the past).

Furthermore I made the full code repository of Data Bind open source!

https://bitbucket.org/coeing/data-bind

This doesn't mean the asset will be completely free (it can be used for free for personal projects and evaluation though). It will make it possible for other devs to send pull requests if there should be use cases which required them to extend the asset. Furthermore it allows other devs to fork the repository, so they can easier adjust it without loosing track of the main branch.

Here is the full changelog:

Spoiler: Version 1.18 Changelog

* Replace deprecated PrefabUtility functions
* Updating to Unity 2018.4.20f1
* #92 Remove possible pending initialization of DataContextNodeConnector, otherwise an exception is thrown if the previous initialization was not yet executed
* #93 Always show component selection picker if a game object was dropped on an component ObjectField
* #91 Fix item index passed to CreateItem of ItemsSetter when item was added to collection

The new version will be available in a few days in the Unity Asset Store:

https://assetstore.unity.com/packages/tools/gui/data-bind-for-unity-28301

 

Version 1.18 is live in the Asset Store: https://assetstore.unity.com/packages/tools/gui/data-bind-for-unity-28301

And don't forget to check out the full Bitbucket repository of Data Bind: https://bitbucket.org/coeing/data-bind

 

Hello,

Thank you very much for providing the evaluation version. I'm currently enjoying the success I'm having with binding the UI to my datasets. (I plan to purchase it after I get an end-to-end UI built from some json proven)

Is it possible to bind inspector values / properties on a game object? This is something I do in AngularJS to do things like tell what UI control to show based on a data value which the user may update, but I can't tell yet if I'm thinking about this databinding/MVVM in unity the right way.

Thanks!

 

Hi @P3ndragonLLC,

Good to hear that open-sourcing the asset helps you to evaluate it.

As far as I know Data Bind was never used with the inspectors of the Unity Editor UI. And because the Editor UI works completely different than the Unity UI for in-game UI I doubt that it will work. Sorry that your use case is not covered!

In general with Data Bind you create plain C# context classes (your data contexts) and bind your in-game UI elements to the values of the properties of those data contexts. The properties are no plain values, but have a wrapper (data property) around it. This wrapping is hidden inside the data context though, so you can handle the context classes like normal data objects.

 

Thanks - that's like a wish list use-case, no worries it's not supported - your explanation makes perfect sense why it's not in the same context.

Still getting my main use-case plugged in to drive building the UI using databinding, but so far so good!

 

I'm not sure but looks like there is quite unstable behaviour with DataProviders class.
I have settings popup with 2 toggles.
If I use old ToggleIsOnGetter - everything works as expected. when popup activated the value taken from the context and update toggle component accordingly. =
But if I use new ToggleIsOnProvider, context updated on the first popup activation immediately. The default value from popup toggle component override context value.

So the idea here is that popup window deactivated by default and activated later after start and on activation children component context updaters override existing context values.

Please let me know if you need additional details.
Thanks.

 

Hi @nicloay,

I'll try to reproduce the issue with the ToggleIsOnProvider on Friday and see what goes wrong. If you have a small sample scene for me that would speed up things a lot

Cheers
Christian

 

Hi @nicloay,

I created a small example which works for me as expected:
1. On startup a Panel with a Toggle is disabled and the Toggle is unchecked
2. A data context with a Boolean (IsOn) exists and the Boolean value is true
3. When the Panel is activated, the Toggle is checked because of the Boolean value

Let me know if you have a different setup than the one in the example in which the behaviours don't work as expected. In that case please adjust the example and send it back to me so I can check what goes wrong.

 

thanks a lot @coeing for fast support

 

Hello @coeing

It's supper strange.
In our project we have reference to 3d party package and that project use castle.core and now in context lookup I see the class from that package


I found source code of the project, and the DictionaryValidateGroup class looks quite ok
And it's only part of the problem.
When in getter and setter when I try to access the property - the lookup dropdown list show fields from previous context.

Is there any way to fix this?

In the runtime by the way everything works ok. This is only problem in editor.

Thanks.

 

Ok. it seems I found the magic place where you define the denyList =). So we have to manually exclude all classes which implement INotifyPropertyChanged and not relate to the context in the cache

added it to ContextTypeCache.

Probably would be great to add this list as a parameter to the configuration as you do for the fields config.
Thanks.

 

Hi @nikolay_i,

Good to hear that you found a solution yourself I added an issue to give users the possibility to add additional namespaces to ignore to the configuration: https://bitbucket.org/coeing/data-bind/issues/95/configuration-additional-namespaces-to It's probably a not-so-common use case, but I'll try to find time to add it in the next version

Cheers
Christian

 

Hi, we've purchased your asset and so far it's been great!

I was wondering though if you know of or can point me in a way to use scriptable objects as a DataProvider? They're quite useful as static data providers to give content to lists for example

 

Hi @tom_fv,

Thanks for using my asset!

About your question: It should be possible by creating a custom data provider script in which you reference the scriptable object to use. I can try to create an example for it when I find time (hopefully end of next week). Please open an issue in the official issue tracker: https://bitbucket.org/coeing/data-bind/issues?status=new&status=open

Have a nice weekend
Christian

 

@tom_fv

Here's a very simple example of using a field of a ScriptableObject as a data provider. In general the data providers are just MonoBehaviour adapters to provide any kind of data. Because ScriptableObjects can be referenced in MonoBehaviours, you can easily drag&drop the concrete ScriptableObject into the provider. But you have to create a specific data provider for each field of your scriptable object class because a data provider serves exactly one value.

It should be possible to add a second field on the data provider which takes the name of the field to serve and use reflection to get this field from the scriptable object. But if this is really needed depends on your specific use case.

 

Hello!
I am a little confused about the way to use this asset. I read the replies of Tinjaw and SidarVasco on Page2 of this forum. So I assume the way is that:

Code (CSharp):

1. public class MyScoreComponent : MonoBehavior{
2.        ScoreContext  scoreContext = new ScoreContext();
3.        public int Score;
4.  
5. //several UI parts that need to update score, need to get the reference in some way
6. public myPanel1 panelContextHolder1;
7. public myPanel2 panelContextHolder2;
8. public myPanel3 panelContextHolder3;
9.  
10. void Start(){
11. panelContextHolder1.GetComponent<ContextHolder>().context = scoreContext;
12. panelContextHolder2.GetComponent<ContextHolder>().context = scoreContext;
13. panelContextHolder3.GetComponent<ContextHolder>().context = scoreContext;
14.     }
15.        public function AddScore(){
16.                    Score  += 1;
17.                    //Auto updates your ui
18.                    scoreContext .PlayerScore = Score;
19.        }
20. }

In traditional unity way:

Code (CSharp):

1. public class MyScoreComponent : MonoBehavior{
2.  
3.        public int Score;
4.  
5. //several UI parts that need to update score, need to get the reference in some way
6. public myPanel1 panelContextHolder1;
7. public myPanel2 panelContextHolder2;
8. public myPanel3 panelContextHolder3;
9.  
10. void Start(){
11.  
12.     }
13.  
14.        public function AddScore(){
15.                    Score  += 1;
16.  
17. panelContextHolder1.updateScore(Score)
18. panelContextHolder2.updateScore(Score)
19. panelContextHolder3.updateScore(Score)
20.        }
21. }

Am I correct or missdoing something? I am confused that it seems not benefit much, if both ways need to get the reference of panelContextHolders.

 

Hi @CHOPJZL,

Thanks for checking out my asset!

There are two points which should make the usage a bit clearer:
1. Normally you only set the root/main data context on exactly one game object, the UI root game object. You can have several sub data context in your main data context, so you will get a data tree structure.
2. You pass the data contexts into your application logic as normal C# objects. In my projects (and in bigger projects in general) you only have visualization and UI logic inside mono behaviours. The main application logic works with pure C# and does not have any (much) links to Unity3D. The data contexts work as the "glue" between the application logic and your 3D visualization in Unity.

Hope those information makes it a bit clearer how Data Bind can be used in your projects! Feel free to also check the examples in the project/package. They also have only one context holder even if they use the data in multiple scripts.

 

Hi @coeing ,

Thanks for the fast reply!

I am still confused. Even if I use root/main data context, or put the main logic works into pure C#, when I need to pass the context from logic parts to the Context Holder, I will need to get the gameObject that contains the Context Holder. But since I have got the gameObject, I can treat it as a UImanager to handle the update the UIelements in traditional unity way.
On the contrary if I pass the context from the Context Holder to logic parts, I can pass the gameObject at the same time. For example by changing ContextHolder.context to ContextHolder.gameObject.

So I am wondering maybe this is not the proper way to use it. I haven't check all the examples, which one is related to this?

Or should I use the context as the data directly in the logic parts?

 

Hi @CHOPJZL,

Sure, passing around game objects to set the data on the UI elements directly would also work. But that really couples the logic and the UI in a way that should be avoided in any projects that are not really small or prototypes.

The data context is meant to enable this decoupling. Maybe an example how we used it in some of our projects will help:

We had a event-driven game logic, so we could easily register for those events that are triggered when data was changed that we want to display in our UI. One of our systems was only responsible for updating the data context by receiving those events and changing the data in the data context. This all works in total isolation of any UI system.

On the other hand we had our UI windows/screens that we designed in Unity. Those were placed under a UI root game object which also had the ContextHolder on it. So within the UI we could add UI scripts (e.g. TextTextSetter or other scripts from the Data Bind package) which update UI elements whenever the data in the data context changed. This was also not dependent on any game logic, so we could easily test our UI screens with some dummy data.

Hope this helps with your understanding! Maybe some fellow devs here could write about their experiences with the asset as well and have some better way to describe its advantages.

 

Hi @coeing ,

The reason I confused is exactly that I felt the decoupling benefit is similar compare to the traditional unity way

Like the example you mentioned, I may place the UI windows/screens under a UI root game object. Instead of adding a ContextHolder, add a UImanager monobehaviour to it. The UImanager will have a bunch of methods and submanagers to update the UI.

In the logic part, wherever I want to change the data in the data context, I assume I need to get the reference of data context, which is in the ContextHolder of the UI root game object. But it will be no different if I get the reference of UImanager on the same gameObject instead. Then instead of changing the data in the data context, I will call the methods of the UImanager.

It seems the traditional unity way is not couples much. But this can be mainly because my lacking of experience. Can you give some detailed example that the traditional way I said has significant disadvantage?

 

@CHOPJZL,

Do you write the UIManager script yourself or is it some script of Unity I haven't heard of?

The main difference between passing around references to mono behaviours and the data context is that the data context is really just a pure C# class. In the project I described our game logic didn't have any reference to Unity at all, so we could easily run it as a pure C# application. This was useful e.g. for unit testing it without having to run Unity3D.

I'm sure you can get the same results with a custom UI Manager. But you would have to write all this logic to update the UI elements in the UI Manager methods. If you set the values on the data context you would just have to put the scripts on the UI elements and they will register themselves for data changes of the data context and pull the required values.

It is much more visual so even UI designers should have no problem to do the setup. You as a developer could focus on the game logic and the update of the values in the data context then.

 

I think this is the point that I am misunderstanding. As I said earlier I may used the asset in a improper way.

If the game logic didn't have any reference to Unity at all, how do you get the reference of the data context? In the way I thought is to get it by getting the reference of the gameObject that contains ContextHolder. So it didn't decouple much.

 

@CHOPJZL:

Most of the times you would do it the other way around and set the data context on the context holder. There is the checkbox to let the context holder create a context itself, but that is mainly used for simple projects and examples/tests.

You would have a class which will create the data context and set it on the context holder. It also serves it to other classes that will synchronize the data context or one of its sub contexts. We called those classes "view models" in our project because they provide the data for the view/UI elements and work very tightly together with a concrete data context class (compare https://en.wikipedia.org/wiki/Model–view–viewmodel).

The only class which would have to know about the ContextHolder in our setup would be the main initializer. All the view models would be initialized by the created data context and the app logic is completely isolated because it communicates only with events (which are received by the view models) and commands (which are sent by the view models to the event manager of the app logic).

 

Hi @coeing ,
Today I read part of your blogs. About the event, I assume it works like this:
A contaxt listens to some events triggered by the logic parts, and use the eventData to set the property. The logic part listens to some events triggered by the context when a command is called, and pass the properties as eventData to the logic part. Am I right?

But what if I don't have the event system?
I assume I will need to have a contaxt manager to organise multiple contaxts, and call the manager's method in different logic elements to update the contaxts.

But the other direction is a bit tricky, How to interact with the logic part by calling the method of a context? The context may need to have a reference of the target logic element, or a logic manager maybe? Otherwise maybe I should give up this direction, and use the view part to interact with the logic directly.

I am sure what I said is not the right way, what do you suggest? Or maybe it is essential to have a event system?

I am not quite familiar with network, which part should be put on the server? It's just the logic part, or both logic and view models?

This is a different question, How to properly use UnityEventTrigger?

 

Hi @CHOPJZL,

Sorry, but your questions become a bit too general and are more about your whole application architecture. Data Bind does not really force you into one specific architecture (and you shouldn't decide on one architecture only because of one asset). If Data Bind does not fit into the architecture you want to use, you should try a different asset and not the other way around

The UnityEventTrigger registers itself on a DataTrigger (https://bitbucket.org/coeing/data-b...ity.DataBind/Scripts/Core/Data/DataTrigger.cs) of a data context. When that DataTrigger is invoked by the logic, the UnityEventTrigger forwards the invocation by triggering a UnityEvent itself, for which other mono behaviours can register themselves. So it's basically just a wrapper for DataTriggers to be able to receive those events as UnityEvents.

 

The new version 1.19 of Data Bind was just submitted and is now in review

If there are any issues you are still missing, there is a public issue tracker where everybody can add their wishes, bug reports, ideas, feedback,...:

https://bitbucket.org/coeing/data-bind/issues

The main additions:

• Update to 2019.4.13f1
• Add example to use data of a ScriptableObject in a data provider
• #95 Add setting to specify namespaces from which no context types should be used

Here is the full changelog:

Spoiler: Version 1.19 Changelog

* Implement Add method in Core.Data.Collection to make it XML serializable

* Use protected fields for SerializeField members to remove invalid warnings

* Update deprecated XR methods

* Update to 2019.4.13f1

* Add example to use data of a ScriptableObject in a data provider

* #95 Add setting to specify namespaces from which no context types should be used

The new version will be available in a few days in the Unity Asset Store:

https://assetstore.unity.com/packages/tools/gui/data-bind-for-unity-28301

 

Doesn't appear to compile out of the box in Unity 2020.2. Will report separate issues on Bitbucket once I track them down.

Looks like it uses deprecated VR features.

 

Hi @jwvanderbeck,

Thanks a lot for your report. I will check and fix the issue in the next version.

Cheers
Christian

 

For now I just deleted the two VR files as I don't need them. I will note that once those errors were fixed, there was an automatic API upgrade performed so something else in the code is currently deprecated as well, but not fatally so at this point

 

Yes, the API upgrade is intended. As I can not provide a package for each Unity version (too time consuming), I build one for the last version of the previous year (2019.4.13 for Data Bind 1.19). This should make sure that it works with the last version (2019) as well as the current version (2020) because Unity provides those automatic API upgrades

You probably use 2020, are you? Could you tell me your exact version so I can reproduce your errors? Deleting the files was the right thing to do, but it shouldn't be necessary. It was probably removed in a recent version, so I did not see it during the last update.

 

https://bitbucket.org/coeing/data-bind/issues/96/vr-features-deprecated-and-no-longer
2020.2.0f1

 

Thanks! I saw your ticket, but overlooked the version you stated.

 

Hey there, I have a question about if there's a better way to link contexts that aren't in the same hierarchy:

Currently I have

• Canvas
  • ...
    • UIElement
• Player (With PlayerDataContext that gets updated)

I'd like that Canvas to have a Context that updates when the PlayerDataContext changes (PlayerDataContext's equippedItemProperty => new ItemDataContext, for example). I have an ItemIdToItemDataContext class created, but I can't find a clean way to link its DataBinding to the external context

The closest I've gotten is a fairly empty StringExternalPassthrough Provider on the Player that uses the equippedItemProperty and just returns it, and then I can reference that Provider from the ItemToItemDataContext class on the Canvas. Feels a little dirty, and that ItemDataContext seems to be regenerated quite a lot (as I'm creating it in the ItemIdToItemDataContext getter).

 

Hi @leafdj,

Thanks for using Data Bind!

It sounds like you can implement the logic best inside your main data context. It should register for changes on the equippedItemProperty and create a new instance of the ItemDataContext when a change occurs. If you post the code of your data contexts I could give you an example implementation.

 

The new version 1.20 of Data Bind was just submitted and is now in review

If there are any issues you are still missing, there is a public issue tracker where everybody can add their wishes, bug reports, ideas, feedback,...:

https://bitbucket.org/coeing/data-bind/issues

Not much has changed this time, but the package was updated to the current LTS version Unity 2020.3.8f1.

The new version will be available in a few days in the Unity Asset Store:

https://assetstore.unity.com/packages/tools/gui/data-bind-for-unity-28301

 

Still heavily in use, thanks!

 

@Asse1 Very happy to hear that!

 

I'm planning on using the plugin to implement some basic UI styling, and I'm wondering if this approach is OK. The styling data would be inside a ScriptableObject asset (colors, fonts, etc.) and the context class would load it and just have a C# property for each property in the asset. The idea is that when modifying the asset data in the editor in play mode, the values would change on the scene objects as well, so adjusting them is more convenient.

To make things as simple as possible, I have added the "Property" ("Property<Color>", etc.) fields to the ScriptableObject asset itself, and the context class has a matching "Property" field for each one in the asset that are initialized to the same instances "owned" by the asset, that way I can just update them from "OnValidate" in the asset and have the UI updated as well, without having to add extra custom events in the asset and add the context as listener, etc. It works fine in a simple editor test, and doesn't seem like there should be any issues, but I'd like to confirm that having the "Property" fields in the ScriptableObject is indeed fine.

 

Hi @DED-Games ,

Thanks for checking out my asset!

I do not see any issues with using the `Property` class like that. In general, the `Property` class does not depend on any special things, it it just a plain C# class which capsules a data value and provides an event for when the data value changes. So feel free to use it where you need that functionality
If you reach a point where you can not figure out an issue, feel free to provide a small example case and I can have a look at it.

Cheers
Christian

 

@coeing Hello, didn't you notice problems on iOs/Android
It runs in editor but throw error on the device like this (unfortunately it doesn't show logs from managed code)

Code (csharp):

1.  
2. #0   0x00000001167414a0 in SingleSetter_1_OnObjectValueChanged_mDFB61F62F0D06984178DB08D8D27D0564BFF094B_gshared ()
3.  

 

Hi @nicloay,

Thanks for the hint, I was not aware of that issue yet. Does it happen on every setter? If not could you send me a sample scene so I can reproduce the issue?

 

The project where it's failing fails immediately, so the app is crushed and not opening.
I'll try to create a demo project in near future, and let you know

 

The new version 1.21 of Data Bind was just submitted and is now in review

If there are any issues you are still missing, there is a public issue tracker where everybody can add their wishes, bug reports, ideas, feedback,...:

https://bitbucket.org/coeing/data-bind/issues

The main additions:
- Cleaner deinitialization of scripts by correctly unregistering event listeners when last data binding was removed from a data property.
- Several bugfixes inside the editor scripts which occurred in specific situations, e.g. null reference exception, and some minor improvements
- Thanks to @Trisibo for pointing out the bugs and requesting the improvements!

Here is the full changelog:

Spoiler: Changelog

• Update to 2020.3.23f1
• #104 Deinit data context node connector instead of only removing value listener
• #104 Destroy data node when the last listener is removed
• #99 Add indicator to path popup to make it easier to find the selected path
• #97 Remove Data Bind Settings.asset and do not include it in packages
• #103 Use EditorGUI.BeginProperty/EditorGUI.EndProperty to have prefab functionality for context types and type selections
• #100 Use EditorGUIUtility.singleLineHeight and EditorGUIUtility.standardVerticalSpacing for custom property drawers instead of hard-coded values
• #101 Add DisallowMultipleComponentAttribute to ContextHolder class
• #102 Fix null reference exception in ContextTypeDrawer.cs

Check out the issue tracker to find the details for a specific issue number.

The new version will be available in a few days in the Unity Asset Store:

https://assetstore.unity.com/packages/tools/gui/data-bind-for-unity-28301

 

Hi coeing, I have been learning about this framework and keeping confusing about many details.

The first question is that what is the meaning represented by the custom path of the Button Click Command below?
Does "#2" mean the upper parent? And is there other any format of custom path, like using "/" or other numbers or names?


The second question is:
Can you give a graph about how to use all the kinds of data binding operations of this framework like this?

from Bringing MVVM to Unity - Part 2: Property and event bindings (codecapers.com.au)
Like how should I update the game data to the Context, is it the updater or observer or getter?
And when should I use the master path or multiple context holders?

 

Hi @randomdragon,

Thanks for trying out my asset. It is indeed a bit more complicated than other Unity assets. On the other side it should not be that different from other data binding frameworks.

Yes, starting a custom path with

Code (CSharp):

1. #X

makes the script go up X context holders above the nearest context holder in the Unity GameObject hierarchy.
- Game Object with Context Holder A
-- Game Object
--- Game Object with Context Holder B
---- Game Object with Context Holder C and script with customPath

So using #2 the "Script with customPath" could access data properties and functions of the "Game Object with Context Holder A"

To update data in your data contexts you do most of the time:
1. Call their functions via a command (~90% of the time)
2. Use a synchronizer to get user input e.g. from input fields

Multiple context holders are useful to make data more local. The best example is a list of items which was generated from a list of data objects. Each item will have a context holder on their root object, so you can easily use a prefab for all the items. If you list of data objects has a dynamic size this is the only possibility anyway.

Hope my answers help a bit! Feel free to ask more questions here

 

The new version 1.22 of Data Bind was just submitted and is now in review

If there are any issues you are still missing, there is a public issue tracker where everybody can add their wishes, bug reports, ideas, feedback,...:

https://bitbucket.org/coeing/data-bind/issues

The only change is an update to the latest Unity LTS Version 2021.3.3f1, so feel free to skip this version if the current one works for you

The new version will be available in a few days in the Unity Asset Store:

https://assetstore.unity.com/packages/tools/gui/data-bind-for-unity-28301

 

Hi!
I want to import the data with the key of the dictionary.
There is a data dictionary, so please tell me how to use it!

DataDictionary<TKey, TValue>