In 2018, I conducted a period of research on Android DataBinding (say it was a research, probably lasted for less than two weeks), stepped on some pits, and put all the summary things in the Evernote Today, by chance, I turned to the things I summarized before, and I feel that I should share them. I hope that I can be helpful to friends who encounter similar problems.
The whole is divided into three parts:
Application scenarios, disadvantages, advantages
1. Application scenarios
1. The screen fields are many and complex, and they are basically display-oriented, with less interaction.
2. Disadvantages
1. The prompt message is very painful when the compilation fails and an error is reported
such as:
This error is actually caused by a problem with the writing of the calling method on the screen, and it has not been compiled.
code show as below:
<TextView
android:id="@+id/tv_order_state"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_alignParentRight="true"
android:textSize="@dimen/common_font_size_level_3"
android:textColor="@{orderDetailActivity.showOrderStateTextColor()}”/>However, the error report is basically information that has nothing to do with this problem. The most valuable part is that it can be directly located in the error information.
android:textColor="@{orderDetailActivity.showOrderStateTextColor()}”/>In this line, the rest of the information is basically useless.
2. The static error prompt page of the xml editor is very painful. Codes that run without problems will also give a red tilde (this is the compiler used in 18 years, and it is now much smarter than before. You may not see the red tilde in the screenshot in the latest version 3.3 of AS. )
such as:
The red line appears, and the prompt message is:
But the actual code can be run, and it runs without problems.
3. When the writing method is not standard, the error message prompted cannot provide reference
For example, according to the code written in the official documentation of databinding:
Finally, there will be a warning after the compilation is successful:
The online solution is to remove the "binding:" attribute prefix in @BindingAdapter.
Personally feel very cottage. However, no other solutions have been found yet.
4. In the expression and grammar of @DataBinding, mipmap resources are temporarily not supported.
In other words, you can write this in the layout file:
bind:error="@{@drawable/list_default}"But you can’t write like this:
bind:error="@{@mipmap/list_default}"An error will be reported when writing mipmap. as follows:
Very speechless.
5. The code hints in xml are not as powerful as those in java files.
6. If the imported tool class in xml needs to use other non-pojo type objects, how to inject it?
Answer: According to the normal method of injection, there is no difference from pojo, but sometimes it is limited by some bugs of the IDE, which will cause many problems, such as: a method that has been generated clearly, and an error will be reported in the IDE when it is called. At this time, you need to restart the IDE to return to normal.
7. In the screen template file, the method corresponding to the screen cannot be used directly, and injection is required, which is slightly different from AngularJS.
8. For those who are not familiar with the framework, many problems are difficult to locate.
For example, in the product details screen, the banner control is used, but the picture is not displayed in life and death. If it is written normally, it should be displayed. But after using the data binding framework, it can not be displayed, this kind of problem.
Later, it was found that it was not the problem of the banner control, but the problem of forgetting to call the start method of the banner control. However, due to the use of a data binding framework, there will be some interference with troubleshooting.
9. The compilation error prompt is not friendly:
For example, I have encountered a problem:
提示：Error:(42, 34) Cannot find the setter for attribute 'bind:imageUrl' with parameter type java.lang.String on com.makeramen.roundedimageview.RoundedImageView.
However, bind:imageUrl and bind:error are clearly declared in BindingAdapter, but an error is reported when bind:imageUrl is specified.
The hint is: the setter of bind:imageUrl cannot be found, but this property has been declared with BindingAdapter.
In fact, the real reason is:
参见url：http://blog.csdn.net/gdut_lemon/article/details/53330631
The wrong prompt is really unfriendly. It can be considered as basically useless for eggs.
10. The injection of the object needs to be done manually, and sometimes the manual injection step is forgotten.
For example: when the onClick event is injected, although it is written like this:
android:onClick="@{fragment::onAllCommentsClick}"However, if you forget to call the corresponding method of injecting the fragment object in the Java code, this listener will not work.
binding.setFragment(this);And the injection of this listener object is easy to forget,
Because in traditional development, we could write directly in the control like this:
android:onClick=“onBtnClick"At this time, just write a method in the corresponding Activity:
public void onBtnClick(View v){
// Do something
}That's it. This saves a step compared to DataBinding.
11. The databinding framework does not support using the features provided by the framework on the fragment tag. In other words, we cannot bind variables to the fragment tag.
If we do this, an error will be reported when compiling first. The error message is: data binding cannot be used on the fragment (the meaning of the wrong English prompt translated)
The second problem is,
When you try to define a @BindingAdapter to handle Fragment, the following error will be reported:
Error:(36, 24) 错误: @BindingAdapter bindFragmentParams(android.support.v4.app.Fragment,java.lang.String,java.lang.String) is applied to a method that doesn't take a View subclass as the first or second parameter. When a BindingAdapter uses a DataBindingComponent, the component parameter is first and the View parameter is second, otherwise the View parameter is first.
The translation of the above words is: if you use BindingAdapter to define new properties, the first parameter is either a DataBindingComponent or a View, otherwise it won't work. The error code is as follows:
@BindingAdapter({"bind:fragmentParamKey", "bind:fragmentParam"})
public static void bindFragmentParams(Fragment fragment, String paramKey,String param) {
Bundle bundle = new Bundle();
bundle.putString(paramKey,param);
fragment.setArguments(bundle);
}
12. When using include for nesting in the layout, the binding object cannot get the controls in the include layout by id.
13. When reconstructing resources such as character strings with parameters, the corresponding variable names in the databinding layout file cannot be reconstructed directly through reconstruction. such as:
<TextView
android:id="@+id/tv_order_total_fee"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_centerVertical="true"
android:layout_toRightOf="@+id/tv_sum_title"
android:textColor="@color/common_warn_font_color"
android:textSize="@dimen/common_font_size_level_2"
android:text="@{@string/common_item_price(orderDetailModel.totalAmount)}"/>Here, if the string variable is reconstructed in strings.xml and common_item_price is reconstructed to common_item_price_with_symbol, the red part of the code here cannot be reconstructed directly through the reconstruction of AS. You must manually modify it yourself.
14. CustomListView (used for the list control nested in ScrollView) has pits when using databinding development mode to develop Adapter. Mainly reflected in: when the text of the TextView control in the list item is more than one line, there is a problem with the calculation of the list height, which causes the list to be displayed incompletely (the actual display height of the list is smaller than the real height of the list, resulting in part of the content being truncated).
When using the traditional holder mode to write the adapter, there is no such problem.
3. Advantages:
1. The code becomes streamlined
After rewriting the order details screen with the DataBinding framework, the Java code 354->264 layout file: 537->510 (The code reduction is due to the optimization of the layout, so this part is actually not reduced under normal circumstances, but instead There will be an increase. Before the layout is optimized, it is about 537->550+, that is, about 20 lines more)
Therefore, the amount of code after using databinding is reduced by about 70 lines, and the overall amount of code is 891->814, which reduces the amount of code by 10%.
2. The logic on the page becomes simple and clear.
It's like the feeling of JQuery changed to Angular. With data binding, there is no need to write a large section of code for data binding processing of the control.
3. Eliminate findViewById (actually, it does what ButterKnife this kind of annotation framework does for us, but databinding is more convenient in actual use, because it allows us to not even write annotations)
In a layout file that uses databinding, as long as we specify an id for a control, a control corresponding to the corresponding id will be generated in the corresponding binding object. We can directly refer to this object through the binding object.