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