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
|