Status Update
Comments
il...@google.com <il...@google.com>
il...@google.com <il...@google.com> #2
this would be nice but given Compose and all other priorities, we are not planning to make any big investments in data binding (support KSP is a very big task).
as...@gmail.com <as...@gmail.com> #3
Makes sense. And is there any way to trigger data binding without kapt plugin, assuming there are no custom binding adapters in given module?
ju...@gmail.com <ju...@gmail.com> #4
unfortunately no. data binding still needs to be able to read your code and annotation processing is the only API that allows us to do it :(
[Deleted User] <[Deleted User]> #5
It's a very disappointing decision for many projects who heavily depend on data binding, which will never be able to get rid of all bindings code and especially rewrite all UI to Compose.
It means that bindings are essentially deprecated
[Deleted User] <[Deleted User]> #6
It does not mean data binding is deprecated unless KAPT is deprecated (if that happens, we would need to support KSP).Unfortunately, moving data binding to KSP is a large order so it makes more sense to keep focusing on KAPT than rewrite data binding.
We might re-consider this in the future based on KSP becoming stable, Compose adoption and KAPT stability but it is very unlikely to happen.
jd...@gmail.com <jd...@gmail.com> #8
Unfortunately this is still a NO for 2022 planning due to reasons mentioned in #2.
re...@gmail.com <re...@gmail.com> #9
kapt seems no longer adding new feature
kapt is in maintenance mode. We are keeping it up-to-date with recent Kotlin and Java releases but have no plans to implement new features. Please use the Kotlin Symbol Processing API (KSP) for annotation processing. See the list of libraries supported by KSP.
So this mean databinding will also deprecated or will be support KSP?
je...@gmail.com <je...@gmail.com> #10
We don't plan to support KSP nor recommend data binding usage at this stage since compose is our recommended UI solution.
hd...@gmail.com <hd...@gmail.com> #11 Restricted
ba...@gmail.com <ba...@gmail.com> #12
ch...@gmail.com <ch...@gmail.com> #13
So if you are using Views, ViewBinding will keep working.
It is the same for Data Binding as well though. The main difference is that if KAPT stops working, DataBinding will stop working whereas ViewBinding will keep working. Hopefully, any such situation will be far enough that no-one will care and everyone will be using Compose :)
ap...@google.com <ap...@google.com> #16
#14 Kapt will be supported on K2, there are no plans to stop supporting it in Kotlin
Description
Version used: 28.0.0-rc01
Theme used: n/a
Devices/Android versions reproduced on: Pixel 2.0, Android 8.0
The sample app is an simple activity with a ViewPager of fragments for which each fragment is observing "TestLiveData" subclass of LiveData . When an instance of "TestLiveData" is observed with the fragment as its LifecycleOwner both LiveData.onActive()/onIsactive() is triggered if the app is foregrounded and backgrounded. However, if a Fragment.getViewLifecycleOwner() is provided to observe LiveData.onInactive() is never called.
Simply launch the sample app and notice the log output of "onActive()" and then push the app into the background. You will notice that there is no "onInactive" called. It is however called when cycling thru the ViewPager but shouldn't it be called when the app is backgrounded?