Menu
One of the coolest features of the Android data binding support is that it also generates fields for View with IDs set. This tidies up the codebase as no field or findViewById() calls are necessary.
But the problem is that the binding instance can only be retrieved via the bind() call which tends to schedule binding. This is bad when the data is being received asynchronously and commonly the NullPointerException gets thrown.
Can the binding instance with View fields be retrieved minus the actual data binding process?
Stack-trace:
java.lang.NullPointerException: Attempt to invoke virtual method 'boolean java.lang.Boolean.booleanValue()' on a null object reference
at com.app.android.databinding.ActivityRestaurantDetailsBinding.executeBindings(ActivityRestaurantDetailsBinding.java:381)
at android.databinding.ViewDataBinding.executePendingBindings(ViewDataBinding.java:350)
at android.databinding.ViewDataBinding$6.run(ViewDataBinding.java:167)
at android.databinding.ViewDataBinding$5.onViewAttachedToWindow(ViewDataBinding.java:137)
at android.view.View.dispatchAttachedToWindow(View.java:14525)
491
Using data binding can lead to faster development times, faster execution times and more readable and maintained code. Android data binding generates binding classes at compile time for layouts.
Data Binding allows you to effortlessly communicate across views and data sources. This pattern is important for many Android designs, including model view ViewModel (MVVM), which is currently one of the most common Android architecture patterns.
View binding and data binding both generate binding classes that you can use to reference views directly. However, view binding is intended to handle simpler use cases and provides the following benefits over data binding: Faster compilation: View binding requires no annotation processing, so compile times are faster.
The Data Binding Library is a support library that allows you to bind UI components in your layouts to data sources in your app using a declarative format rather than programmatically. Layouts are often defined in activities with code that calls UI framework methods.
This doesn't seem to make sense, data binding will ignore null variables thus no null pointer should be thrown, that is, i believe, one of its most promoted features. If you need to modify variables after async calls etc you can just use dataBinding.executePendingBindings()
From the docs
The generated binding class will have a setter and getter for each of the described variables. The variables will take the default Java values until the setter is called — null for reference types, 0 for int, false for boolean, etc.
and
Generated data binding code automatically checks for nulls and avoid null pointer exceptions. For example, in the expression @{user.name}, if user is null, user.name will be assigned its default value (null). If you were referencing user.age, where age is an int, then it would default to 0.
196
Got the same problem with java.lang.Boolean. Solved by using primitive boolean type instead.
<variable
name="var"
type="boolean" />
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
