| 47ab4c24dac8eff1adbe4cc216cbf9c6318993a3 |
|
27-Apr-2016 |
Adam Powell <adamp@google.com> |
Fix a bug where restartLoader would result in a stuck loader
In some cases restartLoader calls that happen in quick succession
could cause the new loader to become stuck and never run. Treat loader
restarts for loaders that have not yet started the same as starting a
brand new loader.
Bug 27437287
https://code.google.com/p/android/issues/detail?id=56464
Change-Id: I787616e1a2e8892c4db6f7952794104a304e0422
/frameworks/support/v4/java/android/support/v4/app/LoaderManager.java
|
| b3f99a77c492ae252bac148540bcd6e8fa7c18b1 |
|
11-Apr-2016 |
Adam Powell <adamp@google.com> |
Prevent duplicate loader onLoadFinished calls on config change
Support edition
Loaders report entering the started state in two places, once from
their host callbacks and once when moving into their host fragment's
starting state. In the former, we will also deliver load results if
we're finishing a retained cycle.
In practice, the individual fragment start happens first which clears
the report-next-start flag, then the finishRetain step sees that flag
is cleared and dispatches the finished load results again. Change
reportStart to only call onLoadFinished if we are not finishing up a
retain step.
Bug 28074512
Change-Id: I5300573a9f0efbc8cf5b45280cad5b23c70acd79
/frameworks/support/v4/java/android/support/v4/app/LoaderManager.java
|
| 8491eb62f621cd5de4b4caed839be09c77011f53 |
|
30-Apr-2015 |
Todd Kennedy <toddke@google.com> |
Sync API with platform
While going through the main platform review, there were several
changes to class and method names. Apply those changes to the
support library to maintain parity with the platform.
Bug: 19569096
Change-Id: Ibe36a664c40379665e3482f792220d975974abca
/frameworks/support/v4/java/android/support/v4/app/LoaderManager.java
|
| d608cf6e08769bf320c1b595cbbd9a7664160449 |
|
26-Mar-2015 |
Todd Kennedy <toddke@google.com> |
Remove dependency upon FragmentActivity
The FragmentManagerImpl is intimately tied with a FragmentActivity. In
many cases, we want to be able to create / manage Fragments outside of
a FragmentManager. This defines a FragmentController interface that can
be used by any class to host Fragments.
Bug: 19569096
Change-Id: I62dee733a70577d0d3c8f96a89e4b05a3d5e18b0
/frameworks/support/v4/java/android/support/v4/app/LoaderManager.java
|
| 220dc21ab5a2a5b3f8b6532105121750770a69f4 |
|
10-Oct-2013 |
Jeff Brown <jeffbrown@google.com> |
Add loader cancellation to support library.
This change brings the support library loader API in sync with the
current framework API.
Adds CancellationSignal and OperationCanceledException.
Adds support for canceling queries in progress on JB+.
Bug: 11070452
Change-Id: I67b858897539caad815b8dd28e828abdb1646534
/frameworks/support/v4/java/android/support/v4/app/LoaderManager.java
|
| edb2ce86c2d08e3381dc62f0ffc95bc115afba5a |
|
07-Feb-2013 |
Jeffrey Brown <jeffbrown@android.com> |
Merge "Clear loaders array after they are destroyed."
|
| b83c02f94b45868aa3f14016747639bbd2ced185 |
|
15-Sep-2012 |
Roman Mazur <mazur.roman@gmail.com> |
Clear loaders array after they are destroyed.
Here is the story.
There is a bug. Decision about retaining state is made when
onRetainNonConfigurationInstance is called after onStop. I mean
doRetain() method is called in this case only. But it's possible that
activity is recreated because of a configuration change happening much
further after it was stopped. E. g. start an activity, navigate to
another from it (stopping the current), rotate the screen, press back.
In this case loaders are destroyed, not retained despite the
configuration change nature of activity recreation.
Well, let it be... But loaders are destroyed (reset), and at the same
time their instances are still in that sparse array. As a result,
instance of the destroyed loader is used again when new activity
starts. The loader reloads its data (since it was previously reset)
but cannot deliver it to a callback since LoaderInfo.mDestroyed is
true.
So, I do not see any reason mLoaders array is not cleared after all
the loaders are destroyed. If it is cleared, everything should work
well. A new loader will be created, it will load data and deliver to
a callback.
Btw, retain logic should be reconsidered to avoid the situation when
loaders are reset in case of the navigation described above.
Change-Id: Ia577caecbacb226a3ce525a01a66283efb6ba754
/frameworks/support/v4/java/android/support/v4/app/LoaderManager.java
|
| 0adacc1aa313d757ae1c517152cef838e0f35c13 |
|
09-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Nested fragments.
Change-Id: I2cfd30fda55320796c8eec738f5b9b592ea2c29c
/frameworks/support/v4/java/android/support/v4/app/LoaderManager.java
|
| 346e2f2390f0d743fd10e7d01a015df6b32292cd |
|
28-Feb-2012 |
Adam Powell <adamp@google.com> |
StaggeredGridView and supporting functionality
Stable IDs are not yet supported.
Move/rename HCSparseArray => SparseArrayCompat; make it public.
Add some new features to ViewCompat.
Add ScrollerCompat; leave it package-private for now as it needs
a reasonable fallback implementation for new methods.
Change-Id: I87d6952ef2c7748a40558759372a2525d6a52cf0
/frameworks/support/v4/java/android/support/v4/app/LoaderManager.java
|
| 1199ae7067cdf8cf3eb30c057a61ae71a0aea1e5 |
|
31-Oct-2011 |
Adam Powell <adamp@google.com> |
Bug 5535639 - Monkeys mad at FragmentManager
Also check for starting deferred start fragments when a loader is
destroyed.
Change-Id: I58c80708f96afa2943ca1e2cae077f7ac52a064d
/frameworks/support/v4/java/android/support/v4/app/LoaderManager.java
|
| abc968f1eba800c34a4008deb43b015da5d23a5f |
|
26-Oct-2011 |
Adam Powell <adamp@google.com> |
Defer starting fragments in FragmentPagerAdapter for offscreen pages.
Add FragmentCompatICSMR1 to work with deferring fragment starts.
Fix some slightly dodgy layout behavior in ViewPager when extra child
views are present.
Add deferred start feature to support library fragment/loader
framework.
Change-Id: Ied454a6f3e11024eafc970ed9d091788c2d80bab
/frameworks/support/v4/java/android/support/v4/app/LoaderManager.java
|
| 9c53b844bd525e6a04e17291efc38713893074cd |
|
13-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
Update to follow fixes from platform.
Change-Id: I9918b084426c62a60581e3ac6e69a48e51b7cc9b
/frameworks/support/v4/java/android/support/v4/app/LoaderManager.java
|
| cba2e2c881e8e16ea5025b564c94320174d65f01 |
|
08-Feb-2011 |
Dianne Hackborn <hackbod@google.com> |
First checkin!
Change-Id: Ib09737c48a144dd778efe4750452d74ac8265a29
/frameworks/support/v4/java/android/support/v4/app/LoaderManager.java
|