Fragment ViewModel's onCleared not called [74139250]

Fixed

Bug

[AOSP] assigned

Status Update

No update yet.

Description

bo...@gmail.com

created issue #1

Mar 3, 2018 10:11AM

Library used (support-v4, appcompat-v7, ...):

implementation 'com.android.support:appcompat-v7:27.1.0'

implementation "android.arch.lifecycle:runtime:1.1.0"
implementation "android.arch.lifecycle:extensions:1.1.0"
implementation "android.arch.lifecycle:common-java8:1.1.0"

Version used: 27.1.0
Theme used: N/A
Devices/Android versions reproduced on: Emulator 24

- Relevant code to trigger the issue.

Make an Activity that contains a Fragment.
Make the Activity use a ViewModel, and make the Fragment also use a ViewModel.
Start the Activity and press back.
The Activity's ViewModel's onCleared method is called.
With AppCompat 27.0.2, the Fragment's ViewModel's onCleared method is called (as it should)
With AppCompat 27.1.0, the Fragment's ViewModel's onCleared method is not called (incorrect).

See the attached project that shows the issue.

With 27.0.2, the logs read:
---------------------------

org.jraf.android.viewmodelproblem.MainActivity: onCreate
org.jraf.android.viewmodelproblem.MainActivityViewModel: constructor
org.jraf.android.viewmodelproblem.MainFragment: onCreate
org.jraf.android.viewmodelproblem.MainFragmentViewModel: constructor

[back is pressed]

org.jraf.android.viewmodelproblem.MainActivity: onDestroy
org.jraf.android.viewmodelproblem.MainActivityViewModel: onCleared
org.jraf.android.viewmodelproblem.MainFragmentViewModel: onCleared
org.jraf.android.viewmodelproblem.MainFragment: onDestroy

With 27.1.0, the logs read:
---------------------------
org.jraf.android.viewmodelproblem.MainActivity: onCreate
org.jraf.android.viewmodelproblem.MainActivityViewModel: constructor
org.jraf.android.viewmodelproblem.MainFragment: onCreate
org.jraf.android.viewmodelproblem.MainFragmentViewModel: constructor

[back is pressed]

org.jraf.android.viewmodelproblem.MainActivity: onDestroy
org.jraf.android.viewmodelproblem.MainActivityViewModel: onCleared
org.jraf.android.viewmodelproblem.MainFragment: onDestroy

This seems to happen because of line 1645 of Fragment, this test:
if (mViewModelStore != null && !mHost.mFragmentManager.isStateSaved()) {
is always false because mHost.mFragmentManager.isStateSaved() is true.

ViewModelProblem.zip

144 KB

Download

Comments

il...@google.com <il...@google.com> Mar 3, 2018 03:58PM

Accepted by il...@google.com.

il...@google.com <il...@google.com> #2Mar 3, 2018 05:15PM

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).

il...@google.com <il...@google.com> Mar 5, 2018 09:55PM

Marked as fixed.

lo...@gmail.com <lo...@gmail.com> #3Mar 6, 2018 08:58AM

Makes sense. And is there any way to trigger data binding without kapt plugin, assuming there are no custom binding adapters in given module?

ja...@gmail.com <ja...@gmail.com> #4Mar 8, 2018 07:06AM

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 :(

b9...@gmail.com <b9...@gmail.com> #5Mar 8, 2018 07:13AM

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

ka...@gmail.com <ka...@gmail.com> #6Mar 8, 2018 12:51PM

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.

b9...@gmail.com <b9...@gmail.com> #7Mar 14, 2018 05:01PM

KSP is now stable stage.
https://android-developers.googleblog.com/2021/09/accelerated-kotlin-build-times-with.html

Can google reconsider to adapt KSP on databinding compiler?

yc...@gmail.com <yc...@gmail.com> #8Mar 16, 2018 09:45AM

Unfortunately this is still a NO for 2022 planning due to reasons mentioned in #2.

il...@google.com <il...@google.com> #9Mar 16, 2018 04:48PM

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.

https://kotlinlang.org/docs/kapt.html

So this mean databinding will also deprecated or will be support KSP?

[Deleted User] <[Deleted User]> #10Mar 19, 2018 03:28AM

Databinding is in maintenance mode as well.
We don't plan to support KSP nor recommend data binding usage at this stage since compose is our recommended UI solution.

kk...@google.com <kk...@google.com> #11Apr 10, 2018 04:14AM

We don't plan to support KSP nor recommend data binding usage at this stage since compose is our recommended UI solution.

I have been waited this answer in several years.

Because it is an important basis to convince co-workers and for determining the technology stack of an app.

[Deleted User] <[Deleted User]> #12Apr 16, 2018 03:15PM

Databinding is in maintenance mode as well.

We don't plan to support KSP nor recommend data binding usage at this stage since compose is our recommended UI solution.

A bit of a tangent here, but what about ViewBinding? Will that one stay going strong or will it fade along with DataBinding?

an...@gmail.com <an...@gmail.com> #13Jun 8, 2018 10:54AM

ViewBinding is only a build tool and does not run an annotation processor, hence it is not impacted by KAPT / KSP.

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 :)

il...@google.com <il...@google.com> #14Jun 8, 2018 02:33PM

Kotlin K2 compiler doesn't support kapt anymore, which means the data-binding library can be dead soon.

https://github.com/JetBrains/kotlin/blob/master/plugins/kapt3/kapt3-compiler/src/org/jetbrains/kotlin/kapt3/Kapt3Plugin.kt#L71-L76

al...@gmail.com <al...@gmail.com> #15Jun 15, 2018 09:18PM

Here is the tracking bug on YouTrack: https://youtrack.jetbrains.com/issue/KT-51982/K2-Support-Kapt

al...@gmail.com <al...@gmail.com> #16Jun 15, 2018 09:21PM

#14 Kapt will be supported on K2, there are no plans to stop supporting it in Kotlin

lb...@gmail.com <lb...@gmail.com> #17Jun 15, 2018 09:26PM

gooooogle, gradle and kotlin are a perfect match ☺️

al...@gmail.com <al...@gmail.com> #18Jun 16, 2018 04:43PM

deleted

m....@gmail.com <m....@gmail.com> #19Dec 27, 2018 08:16PM

https://drive.google.com/file/d/1zBwQSAHyw8aoyggjjYoG6Bo4NQz3l45T/view?usp=drive_web (-Docs--1.docx)

3g...@gmail.com <3g...@gmail.com> #20Mar 27, 2021 06:55AM

file sdcard encrypt....

[Deleted User] <[Deleted User]> #21Mar 2, 2022 06:20AM

Common