Fragment lifecycle change with ViewPager [73976255]

Fixed

Bug

Status Update

No update yet.

Description

to...@gmail.com

created issue #1

Feb 28, 2018 08:55AM

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

Since support library 27.1.0 when using a FragmentStatePagerAdapter in a viewPager the offscreen fragment lifecycle have changed.

Before onStart / onResume where called on those fragment and it's no more the case. The offscreen fragments have the lifecycle stopping at onActivityCreated.

After a screen rotation those lifecycle are called correctly. So it's more a bug on first creation of the fragments than a wanted API change it seems.

If it's a normal wanted API change please confirm.

Comments

ku...@google.com <ku...@google.com> Feb 28, 2018 09:06AM

Assigned to ku...@google.com.

ku...@google.com <ku...@google.com> #2Feb 28, 2018 11:35AM

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

ms...@gmail.com <ms...@gmail.com> #3Feb 28, 2018 04:11PM

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

to...@gmail.com <to...@gmail.com> #4Feb 28, 2018 04:25PM

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

ms...@gmail.com <ms...@gmail.com> #5Feb 28, 2018 05:51PM

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

to...@gmail.com <to...@gmail.com> #6Feb 28, 2018 06:39PM

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.

ms...@gmail.com <ms...@gmail.com> #7Feb 28, 2018 07:10PM

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?

ms...@gmail.com <ms...@gmail.com> #8Feb 28, 2018 07:43PM

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

to...@gmail.com <to...@gmail.com> #9Feb 28, 2018 07:47PM

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?

il...@google.com <il...@google.com> #10Mar 1, 2018 12:07AM

Reassigned to il...@google.com.

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.

to...@gmail.com <to...@gmail.com> #11Mar 1, 2018 08:05AM

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.

il...@google.com <il...@google.com> #12Mar 1, 2018 04:53PM

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?

il...@google.com <il...@google.com> #13Mar 1, 2018 04:58PM

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

to...@gmail.com <to...@gmail.com> #14Mar 1, 2018 05:00PM

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

to...@gmail.com <to...@gmail.com> #15Mar 1, 2018 05:04PM

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

il...@google.com <il...@google.com> #16Mar 1, 2018 05:08PM

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

to...@gmail.com <to...@gmail.com> #17Mar 1, 2018 05:08PM

gooooogle, gradle and kotlin are a perfect match ☺️

to...@gmail.com <to...@gmail.com> #18Mar 1, 2018 05:32PM

deleted

il...@google.com <il...@google.com> #19Mar 2, 2018 10:50PM

Marked as fixed.

This has been fixed for the next release, almost certainly as part of a fast .X release

to...@gmail.com <to...@gmail.com> #20Mar 3, 2018 05:19PM

So doing some more tests I see other differences in loaders behavior from before :(

Like onLoadFinished is being called when returning to fragment when it was not the case before (before any call to reload or init made)

And much more important a change in how onLoaderReset is now called.

The documentation of restartLoader Says: "If a loader with the same id has previously been started it will automatically be destroyed when the new loader completes its work. The callback will be delivered before the old loader is destroyed."

But new implementation does not that at all. It calls onLoaderReset then onCreateLoader then onLoadFinished. (Previous implementation was sometimes broken and never called onLoaderReset but at least there was no long duration where we have no data to display).

This is a major change because this means you can't keep the previous data during the load as it's invalidated but you have nothing to display since the new loader is not finished. Meaning empty screen on reload = quite bad UX.

ta...@gmail.com <ta...@gmail.com> #21Mar 3, 2018 08:16PM

The onLoaderReset problem described in #20 makes working with CursorLoader and CursorAdapter suddenly very cumbersome in 27.1.0.

In order to avoid the "empty data" period of time after onLoaderReset, my extremely hacky workaround is to create a second identical loader, with a separate Loader ID, and flip between the two Loaders with each call to restartLoader, so that the previous Cursor remains alive until the next onLoadFinished callback.

to...@gmail.com <to...@gmail.com> #22Mar 3, 2018 08:18PM

I've opened

https://issuetracker.google.com/issues/74135998 to follow that as per Ian request.

ja...@gmail.com <ja...@gmail.com> #23Mar 21, 2018 08:58PM

Before 27.1.0, loaders initialized with getSupportLoaderManager() used to receive a call to onStartLoading() while the activity was executing super.onStart(). This allowed synchronous loaders to initialize resources before the remaining body of onStart() executed. In 27.1.0, loaders no longer start loading until some time after onStart(). This change caused a few NPEs in our onStart() methods. Is this 27.1.0 behavior a violation of the "between onStart/onStop" contract?

I think

https://issuetracker.google.com/issues/73976255#comment13 is referencing this same guarantee which appears to be broken.

ja...@gmail.com <ja...@gmail.com> #24Mar 21, 2018 09:06PM

With a bit more digging I found

https://issuetracker.google.com/issues/74225064 which appears to reference and fix the exact issue that I mentioned in #23. Sorry for the noise.

sa...@gmail.com <sa...@gmail.com> #25Apr 8, 2018 01:07PM

please update your support libraries with 27.1.1

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

This bug has been fixed in Support Library 27.1.1.

sa...@gmail.com <sa...@gmail.com> #27Jul 31, 2018 07:12PM

(Program type already present: android.arch.lifecycle.LiveData$LifecycleBoundObserver Message{kind=ERROR, text=Program type already present: android.arch.lifecycle.LiveData$LifecycleBoundObserver, sources=[Unknown source file], tool name=Optional.of(D8)})

solv this problam