The idea is to create a class named Bind which permits to bind properties to the views.
They can as well be populated and recollected, they will be annotated by default by an annotation @Bind (even if they doesn't have this annotation, it will be injected with ADI). The main idea is to have an easier way to bind specific properties. In order to reduce the huge amount of @Populate fields generated for instance while implementing MVVM pattern with DecleX.
Bind class will be auto generated depending of the requirements in the project, also it can be bind to more than one view if it is necessary,
Bind has two modes, LayoutInferred, and CodeInferred, in the CodeInferred mode, bind accepts any new method, and it will connect to the view if it finds equivalents. In the LayoutInferred method it will accept only methods existent in the Layouts connected to the View.
Bind can also be automatically updated, or only through $Populate and $Recollect. By default they will be automatically updated, this mean that a change in the field will be automatically reflected in the UI, all the updates will be by default Thread Safe, and State Safe (they will update the UI only if it is in the correct state).
Bind will be implemented following MVVM pattern, it will generate the getters for each one of the methods used, in the case above, for instance it will generate the method "getButton1Visibility()" and "getButton2Visibility()" in this way it can be easily unit tested.
In fact, to simplify unit testing, Bind will generate as well the methods assert, so it can be used also:
Another feature which will be added, is the @Bind listeners. with MVVM a common problem is to "listen" for the changes to the properties, which could trigger "Animations". Animations should be handled by the View itself, but with the current @External MVVM pattern in DecleX, you are false to broadcast events to the View in order to execute these animations.
Following a @BindListener mechanism, listeners could be executed automatically:
The word "Changed" it is keyword, and Visibility it is the property. The bind listeners are available only if the property is using @Bind, you can specify also several properties:
The idea is to create a class named Bind which permits to bind properties to the views.
They can as well be populated and recollected, they will be annotated by default by an annotation @Bind (even if they doesn't have this annotation, it will be injected with ADI). The main idea is to have an easier way to bind specific properties. In order to reduce the huge amount of @Populate fields generated for instance while implementing MVVM pattern with DecleX.
Bind class will be auto generated depending of the requirements in the project, also it can be bind to more than one view if it is necessary,
State tables are also easily implemented with Bind, when you have a set of views, you can use Bind to set the states for all them:
Bind has two modes, LayoutInferred, and CodeInferred, in the CodeInferred mode, bind accepts any new method, and it will connect to the view if it finds equivalents. In the LayoutInferred method it will accept only methods existent in the Layouts connected to the View.
Bind can also be automatically updated, or only through $Populate and $Recollect. By default they will be automatically updated, this mean that a change in the field will be automatically reflected in the UI, all the updates will be by default Thread Safe, and State Safe (they will update the UI only if it is in the correct state).
Bind will be implemented following MVVM pattern, it will generate the getters for each one of the methods used, in the case above, for instance it will generate the method "getButton1Visibility()" and "getButton2Visibility()" in this way it can be easily unit tested.
In fact, to simplify unit testing, Bind will generate as well the methods assert, so it can be used also:
Another feature which will be added, is the @Bind listeners. with MVVM a common problem is to "listen" for the changes to the properties, which could trigger "Animations". Animations should be handled by the View itself, but with the current @External MVVM pattern in DecleX, you are false to broadcast events to the View in order to execute these animations.
Following a @BindListener mechanism, listeners could be executed automatically:
The word "Changed" it is keyword, and Visibility it is the property. The bind listeners are available only if the property is using @Bind, you can specify also several properties:
In this case, the name of the method it is arbitrary. The property can take as parameter the view (s), and the value of the properties (new and old).