Adventures after Google I/O-4(Databinding)
Table Of Contents
Apart from NDK builds, Databinding is one of the most surprising announcement from android developer tools team. It takes away one more boilerplate coding from developers, and enables proper abstraction regarding to MVC patterns. While reading the guide, we can easily make it up and running, and many of boilerplate coding is just gone, this databinding plugin will handle many things on its own.
Many of us have started or already using Butterknife to reduce findViewById() codes. As a plugin Databinding not only replaces Butterknife but also reduces efforts from Java side to set values directly from Model. We just have to define some values to respected properties. These values must reflect to a certain variable or getter setter method. Then we have to go to our corresponding Java file, where we get an object of databinding file. The file is named on basis of our layout file.
Quoting the guide, By default, a Binding class will be generated based on the name of the layout file, converting it to Pascal case and suffixing “Binding” to it. Pascal Case (by definition of MSDN) is The first letter in the identifier and the first letter of each subsequent concatenated word are capitalized. For example if our layout file is named layout_user_details.xml , converting it to Pascal case is LayoutUserDetails and suffixing Binding makes it LayoutUserDetailsBinding.
You may wonder why I have not put .java after my class. I did this because we can refer to LayoutUserDetailsBinding as a normal java object but there is not any Java file we can refer to. Clicking on any link will lead us to respected layout file. There must be some kotlin used here, where folks developing with kotlin can shed a light on what happens. However, using databinding object will give us access to (almost) all ids in the layout file. Thus we can replace Butterknife when we are using databinding.#1
Well in above paragraph I have said databinding will give us access to almost all ids, not all ids. There are some exceptions, and this is where adventure starts.
What is Problematic:
Databinding does not have (or choose not to give) access to ids from android.R class. If your id in xml is "@+id/anyThingYouWant", we can access in java using BindingClass.anyThingYouWant. Problem arises when we use ids such as @android:id/empty. In first version (1.0-rc0) when we put this id in our xml, compiler gives build error. I have filed an issue for that. This issue was processed and later made resolved. In latest version of databinding plugin(1.0-rc1) using same layout, our app will compile, but we do not have access to such ids from databinding class. We can easily come across this issue because many of us use @android:id/empty to denote empty views in our lists.
Workaround:
Well like GCM3.0 it was well thought design. As per comment#1 in the issue, android.R ids are reserved for android internal fields. And we should not use any of them in our builds. In my example where I have denoted a text view as my recyclerview’s empty view. I have solved this issue by giving something other as an id to my empty text view.
In my knowledge andorid:id s will be handled by SDK and framework themselves and we should not have any modification to them. If you are ok with that you can continue using these ids. If you want to access such views findViewById is always there. If you want databinding advantages you must let go android:id s.
That’s it for now, My primary adventures after Google I/O takes rest here. Thanks for reading this.