Our project uses kotlin && DataBinding process, you may be in doubt, since using a kotlin, why not use kotlinx? The new page is used kotlinx matter of course, but we have a fairly large history code, and our universal adapter is actually based DataBinding to package. So, we still have to discuss (spit) on the (slot) at the pit of the DataBinding. In fact, this problem when I was asked to interview bytes beating too.
This is a very open question, so to see the small partner of this article got to look at with a colored glasses, the following will list the author encountered the pit as far as possible, of course, limited capacity, there may be a lot of things DataBinding is not a problem, we need to work together and complement the screening.
Earlier Google launched DataBinding is a support to the library, as long as we have the courage to solve the code frequently occurring findViewById()problem, before that, I believe most people have heard of or used Butterknife , until now, have been updated to the library 10.1.0 it, and the author is JakeWharton great God, in fact, very easy to use.
But today we do not Butterknife be too much comment, and transferred to our protagonist DataBinding.
For DataBinding use and do not introduce here tells the story, I suggest that you directly to the official documents
were access to learning, here today, to share and discuss some of the main pit what I stepped in more than a year in DataBinding. I think these tips certainly not all, and some are in fact erroneous operation due to personal, anyway, we give up today its praise, Tucao Tucao this DataBinding.
Extremely difficult positioning error
oh, this should be of little friends using DataBinding most biggest pit, and you must have seen and even hated some of its junior partner in a variety of tire technology development and exchange of population. No matter what is wrong with your code, you will receive the error log is generated classes can not find a lot of DataBinding.
May very many small partners will remain on this question, this is not true in the build log errors are finally able to see it? Really do not see, you can also type in console ./gradlew build --stacktraceview the detailed log.
But what that really true? There is no junior partner experienced no matter how you view the log can not find the real error code.
I think there must have! While we are generally required to commit to maintain the principle of "many small", but this does not guarantee that we always had to strictly comply, in part of the business very disordered, we often do not want to commit, because every commit, we We have to do a compilation confirm the current code without any grammatical problems. As for the huge amount of code, in particular, but also by a variety of historical reasons not thorough enough components of the project, a basic compiler can make you eat a meal. Our project is the case, subject to historical reasons, are not completely overtaken components, resulting in a local compilation was without a cache hit at least 10 minutes, this is the mac pro 16G in. And most people's computer configuration may also be lower, and it is difficult to do other work related things at compile time.
To deal with this problem compiling, our company had to write a script compiler to compile operations are handled on the server, after doing a series of optimization operations, compiling debug package in the absence of a cache hit situation or needs 4.5 minutes, of course, now we can do in the compilation of other interesting things.
Like the previous two paragraphs say a lot of irrelevant things, but! I really want to say is that this time the error occurred, and logs the error can not locate, you will find very painful, you may have dozens of changes to the document, a lot of new XML, because they can not locate the log, you have to line by line syntax checking.
My experience on this issue had coded two hours, checking fails to compile more embarrassing situation problems takes time, generally speaking, such a mistake is not easy to find, I deeply I remember one time because the components of historical issues, a component code had to move to another component, then it happens unexpected errors grief scene. When you stashafter the change can be compiled, but popcame out on the wrong time, you will know what is extremely cruel means.
OK, so for the current situation, or has summarized this case 95% of the problem is the XML code, you can directly check the XML.
Code is extremely difficult to maintain
We use DataBinding when bound to like the two-way binding operation. Directly in XML which do some simple logic, this operation allows our code becomes very simple, and can save findViewById()the unnecessary loss of performance. But such operations so that subsequent maintenance function codes are very painful.
Our code which will have a considerable part of such a code, part of the page is very complex logic, such as a product details page, will involve very large amounts of information display and a variety of promotional spike state, there are a lot of dynamic efficiency, this time after a lot of logic in XML inside, follow-up maintenance colleagues when dealing with product changes, certainly in the hearts of secretly abuse.
Generally speaking, I am accustomed to these complex logic placed in our Java code. For now, see these complex interaction logic in your code handy a lot.
{@} Will not do inspections
Earlier, I committed two consecutive low-level error, so the memories on this issue. We can see, we use a similar XML support inside @{}in such a way as to TextViewdisplay content settings, but in XML which we did not detect mechanism, so that you are prone originally a Numbervalue type, but as a compiler resourceIdhandle the error. In fact, the compiler settings directly in the code which is being given.
A difficult thing to find in the code according to which the control ID
In the early code for our project, XML inside the naming convention is basically xxx_xxx_xxx this format, but DataBinding which variable we generate it uses a hump nomenclature, which leads us to the corresponding class which according to a control id looking for time, had to change their name to hump nomenclature name, a fact that makes us feel very uncomfortable, so our code behind XML naming conventions to follow the nomenclature becomes hump. This may be slightly out and naming conventions, but we firmly believe that for their own, is the best idea.
Expressions section XML's performance differs in different versions gradle
As mentioned earlier, we usually will use server compile, so there had appeared a property to an XML file inside the compiled locally, however, but on the server even other colleagues on the computer can compile issues. Honestly, now I did not find the real reason, I shall say this to the previous question thrown pot colleagues to do this. I changed his subsequent implementation just let this issue be handled properly, but still did not understand where the problem is, because that's the way I think the code itself is no problem. Unfortunately, I do not have time to find the code that is probably a common set onClickListenerof problems.
BindingAdapter poor maintenance
We usually use @BindingAdapter way to do some common logic, rather than directly to the logic on the page to use it by setting the property, so there will be more difficult to maintain these public logic, of course, it is very likely that we project historical issues, but I think this can be considered a pit point. I do not know there is no such situation appear in XML attributes inside without prompting. As you customize View Styleable the same name is not unique.
Multi-module dependencies
The problem I have not noticed before, because we have used the DataBinding each module, so think of each module gradleDataBinding configuration settings are on, and nothing can Tucao very thing, but it looks very serious problem so also in this for everyone to share. Transfer wanAndroid above xujiafeng answer}
DataBinding when a multi-module development, there is such a mechanism:
If a sub-module using DataBinding, you must also add the main module configuration in gradle, otherwise it will error;
if the main modules and sub-modules are added on a DataBinding configuration, then at compile time, Binding class XML file generated by the sub-modules in addition there will be a build your own inside and outside, in the main module will also have a copy.
So, if the main module and sub-module has a layout activity_main.xml root directory, the main module generated ActivityMainBinding will be generated based on the file sub-module! In this case we can also get the main modules and sub-modules using a different name, then the next question is even more terrible:If an XML file sub-module uses some third-party control, the main module will be generated due to the Binding class this file, and it will be a reference to third-party controls, this time due to the main module is not introduced these controls, it We will complain, the solution is when a third-party application control sub-module, using the API application the way, so the main module resolutely references to these third-party controls, which are so contrary to the principle of decoupling.
Hey, limited personal ability, I think of where it comes to where the. There may be a lot of databinding is not really pit, personal use is a problem, but also to understand that people can directly point out. PS: Give me a chance, I do not want to use Databinding.
We hope to have other slots point above or think something is a better way to deal with the junior partner must leave a message below, Panfu Panfu ~