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
|