Verified
Status Update
No update yet.
Comments
ad...@google.com
Thank you for reporting this issue. For us to further investigate this issue, please provide the following additional information:
Steps to reproduce
Please provide source code or apk of a sample application to reproduce the issue.
Also kindly mention the steps to be followed for reproducing the issue with the given sample application.
Expected output
What is the expected output?
Current output
What is the current output?
Steps to reproduce
Please provide source code or apk of a sample application to reproduce the issue.
Also kindly mention the steps to be followed for reproducing the issue with the given sample application.
Expected output
What is the expected output?
Current output
What is the current output?
cc...@google.com
Seeing this with a FragmentPagerAdapter as well. Our app has three static tabs, and opens by default on tab 1. Previously, the fragments for tab 2 and tab 3 would have their onResume() called when the activity's onResume() was called, even though those tabs weren't visible yet.
Now, since 27.1.0, onResume() on those tabs' fragments is only called when the user navigates to them.
Now, since 27.1.0, onResume() on those tabs' fragments is only called when the user navigates to them.
rh...@abc.net.au
#3 can you try to provide a repro app? I've lost 4 hours already and can't find the root cause, the basic AS sample does not produce that :(
Maybe it's easier from your code.
Maybe it's easier from your code.
cc...@google.com
I also tried with the sample app (https://github.com/googlesamples/android-HorizontalPaging ) which doesn't have the issue.
I did find a clue in my app though: the first tab's fragment does getLoaderManager().initLoader() in its onActivityCreated(). If I comment this out, the onResume() methods of all the fragments are called at once as with support lib 27.0.2.
This might be related to this change in the support lib release notes:
> The underlying implementation of Loaders has been rewritten to use Lifecycle.
It's going to be quite a bit of work to get this into a small sample app though. I can't share my own app.
I did find a clue in my app though: the first tab's fragment does getLoaderManager().initLoader() in its onActivityCreated(). If I comment this out, the onResume() methods of all the fragments are called at once as with support lib 27.0.2.
This might be related to this change in the support lib release notes:
> The underlying implementation of Loaders has been rewritten to use Lifecycle.
It's going to be quite a bit of work to get this into a small sample app though. I can't share my own app.
Description
Version used: 27.1.1
Theme used: N/A
Devices/Android versions reproduced on: Any
Regarding the check at the top of `submitList` here:
```
if (newList == mList) {
// nothing to do
return;
}
```
There's a race condition -- suppose we have lists A and B, and the differ's `mList` before starting is list A.
1. Submit list B - async diff generation N kicks off
2. Submit list A - `newList` matches `mList` since diff gen N hasn't completed yet, but `mMaxScheduledGeneration` is not incremented and this returns early
3. Async diff gen N is accepted, despite list A being submitted after list B.
Seems this could be fixed by incrementing `mMaxScheduledGeneration`. As a workaround, I am wrapping my lists in a new identity before submitting them to the differ.