IssueTracker

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?

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.

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

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.

Thanks I can also confirm the same thing in my case.

Removing the call to getLoaderManager().restartLoader(id, null, this); from onResume of the fragment then allows proper resuming of all fragments. (In my case all loaders Id are different).

This give a clue at how to reproduce, will see if I can tonight.

A sample app is here: https://github.com/calvarez-ov/android-HorizontalPaging

If you build it as-is, you see three onResume() logs at once, when the app is launched:

02-28 14:03:43.534 15309 15309 V MainActivity/DummySectionFragment: onResume 1
02-28 14:03:43.682 15309 15309 V MainActivity/DummySectionFragment: onResume 2
02-28 14:03:43.682 15309 15309 V MainActivity/DummySectionFragment: onResume 3


If you change it to use support library 27.1.0 (Application/build.gradle), you only see the first onResume(). You see the other ones after you manually click on the tabs:

02-28 14:07:15.491 15443 15443 V MainActivity/DummySectionFragment: onResume 1
...
02-28 14:07:21.504 15443 15443 V MainActivity/DummySectionFragment: onResume 3
...
02-28 14:07:25.119 15443 15443 V MainActivity/DummySectionFragment: onResume 2


Note, this sample app doesn't look anything like the real app which has the same problem :)  It's just the smallest example I could make to reproduce the issue.  There's no ListView or RecyclerView and no adapter to display the loader data. I explicitly call forceLoad() to make the loader's loadInBackground() be called.  If I don't do this, I have the bug even with support lib 27.0.2.

In case this helps troubleshooting: if you post the restartLoader() (or initLoader()) call to a Handler, the bug goes away:

         @Override
         public void onActivityCreated(@Nullable Bundle savedInstanceState) {
             super.onActivityCreated(savedInstanceState);
-            getLoaderManager().restartLoader(1337, null, this);
+            new Handler().post(new Runnable() {
+                @Override
+                public void run() {
+                    getLoaderManager().restartLoader(1337, null, FragmentWithLoader.this);
+                }
+            });
         }

Actually from Ian Lake: https://plus.google.com/u/0/+IanLake/posts/UNXxBrsBUzJ?cfem=1 This is a normal behavior from before that seems more visible now.

What you can test in the loaderinbackground is a long thread sleep the issue should be back even when running from the handler.

I guess the root issue is that before the loader was marked activated for a very very short amount of time (the actual loading so a few ms for most) and now it's marked active for a way longer time leading to the issue. Or maybe for the same amount of time but the loading occurs exactly at the time the fragment manager check for it before loading the others.

Won't be something easy to change I fear :(

There was pre-existing coupling between Loaders and FragmentManager:
1. FragmentManager wouldn't start new Fragments with userVisibleHint=false if current Fragments had running Loaders
2. LoaderManager would directly contact FragmentManager upon Loader completion to start any of those pending Fragments

With 27.1.0, #2 was removed, but #1 remained. This mismatch causes the issue.

While both removing #1 and re-instating #2 are options, we are going to proceed with removing #1 as that continues the goal to separate Loaders from the other APIs (it is not intuitive that adding Loaders affects the Fragment's lifecycle) and bring Loaders more in line with other APIs (such as ViewModels+LiveData).

Thanks. Do you think it might worth extending the API to allow anyone who want that behavior for performance reasons to continue?

Like a way to query if there's active loaders for visible fragments and a listener for their end? With that and the already existing isVisibleToUser this would allow anyone to keep that.

Or maybe even better, to be more generic a busy indicator for visible fragments, with a listener when nothing busy. To handle that even with normal viewmodels. (Then it would be up to the user to manually toggle that in oncreate / onfinished)
I know one can use a viewmodel + livedata tied to activity to handle that, but native support for that, to allow anyone to easily priorise the visible fragment with an easy way to do something when the visible fragment have done it's delayed init would be really a nice addition.
It's tons of boiler plate code to achieve that currently and prone to mistakes.