| e6f7daeb469ee4242416270b803e06909436d90e |
|
02-Mar-2017 |
George Mount <mount@google.com> |
Fix Loader bugs
Bug 32758881
Bug 34264461
When destroying the LoaderManager, the host was not being cleared.
The host was being leaked and this leaked the Activity.
When a LoaderManager is reused, for example with an orientation
change, the host was updated, but it wasn't started. This
adds a test for that case to ensure that when a reused
LoaderManager is loaded that it is properly started.
Test: Ib90f14e16083916a21a25ce87a4dd29ab9a33878
Change-Id: Id4c8afab5db0a78bbff376d597be294a6e3dbcba
/frameworks/base/core/java/android/app/LoaderManager.java
|
| 180202f2211d8c6bbb7a7057e61dafc90fe31930 |
|
22-Sep-2016 |
Adam Powell <adamp@google.com> |
Don't hold old host callback for fragments on the back stack
LoaderManagers configure their host callback lazily as their
associated fragment is brought up through its lifecycle states. In the
case of fragments on the fragment back stack this could happen very
late, if at all. As a LoaderManager's host callback references the
host Activity, this means that a LoaderManager could keep a destroyed
Activity reference alive.
Update the host callbacks of all LoaderManagers eagerly during the
restore non-configuration instance phase.
Bug: 30653222
Test: core/tests/coretests/src/android/app/LoaderLifecycleTest.java
Change-Id: I5d2b81daae5e7cae429fcf4934e64b3ce281140c
/frameworks/base/core/java/android/app/LoaderManager.java
|
| e5552be22a016dd8b79026f56b071ab128d5a904 |
|
27-Apr-2016 |
Adam Powell <adamp@google.com> |
Fix a bug where restartLoader would result in a stuck loader
Framework edition
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: Ia4e276fc8e63d43b9c52c6155cea827b194d8b19
/frameworks/base/core/java/android/app/LoaderManager.java
|
| eba13dd07f2e9070b2017f8defddd5bb719939a1 |
|
11-Apr-2016 |
Adam Powell <adamp@google.com> |
Prevent duplicate loader onLoadFinished calls on config change
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: I85b848f7d7b239c8fac5aec8f0c91e4eea6bcebf
/frameworks/base/core/java/android/app/LoaderManager.java
|
| a5fc6f006f67867417b7a427de6e7394c4312dec |
|
15-Apr-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: 19569654
Change-Id: I6816a5c1815122d206062b9f4584ad460b3d41dd
/frameworks/base/core/java/android/app/LoaderManager.java
|
| f4bf0ae2a7c2d9d92c5c8abdb82baa53b4c9ccda |
|
21-May-2013 |
Dianne Hackborn <hackbod@google.com> |
New ArrayMap class.
This is a new kind of key/value mapping that stores its data
as an array, so it doesn't need to create an extra Entry object
for every mapping placed in to it. It is also optimized to reduce
memory overhead in other ways, by keeping the base object small,
being fairly aggressive about keeping the array data structures
small, etc.
There are some unit and performance tests dropped in to some
random places; they will need to be put somewhere else once I
decided what we are going to do with this for the next release
(for example if we make it public the unit tests should go in
to CTS).
Switch IntentResolver to using ArrayMap instead of HashMap.
Also get rid of a bunch of duplicate implementations of binarySearch,
and add an optimization to the various sparse arrays where you can
supply an explicit 0 capacity to prevent it from doing an initial
array allocation; use this new optimization in a few places where it
makes sense.
Change-Id: I01ef2764680f8ae49938e2a2ed40dc01606a056b
/frameworks/base/core/java/android/app/LoaderManager.java
|
| 1da8e8ce8912b79a5ed7cd3865a3913ee9bfb1d9 |
|
13-Dec-2012 |
Roman Mazur <mazur.roman@gmail.com> |
Clear loaders array after they are destroyed.
See change Ia577caecbacb226a3ce525a01a66283efb6ba754 for details.
Change-Id: I9f07eeceaa3829f71008e6f6a38ab849095bd69c
Signed-off-by: Roman Mazur <mazur.roman@gmail.com>
/frameworks/base/core/java/android/app/LoaderManager.java
|
| 62bea2f1710be0d1a42c07109fd4307ded660d3b |
|
05-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Nested fragments.
Change-Id: I79acc19b391352c16b06afee2ca543223c38e364
/frameworks/base/core/java/android/app/LoaderManager.java
|
| b19a71a20adb48c084e87d06a1e6b0dcb49170f5 |
|
31-Jan-2012 |
Jeff Brown <jeffbrown@google.com> |
Support automatic cancellation of Loaders.
Change-Id: I18d3f49e413f48fcdd519d15e99c238ad54d35b9
/frameworks/base/core/java/android/app/LoaderManager.java
|
| 7871badd5d4d29d80207e9cc09a0681f26a151d0 |
|
13-Dec-2011 |
Dianne Hackborn <hackbod@google.com> |
SDK only: now that support lib is in SDK, we can link to it.
Update some of the platform documentation to directly link to
relevent support lib docs. Yay!
Also improve BroadcastReceiver documentation to more clearly
discussion security around receivers, and how the support
lib's LocalBroadcastManager can help.
Change-Id: I563c7516d5fbf91ab884c86bc411aff726249e42
/frameworks/base/core/java/android/app/LoaderManager.java
|
| 37510908a7b570accb2c4829842790b3d9d3a102 |
|
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: Ia17a902c579c09d7ac01079c7c1da137635aa08b
/frameworks/base/core/java/android/app/LoaderManager.java
|
| 635c60af623c73d2409f5729c0953638b5d6c497 |
|
26-Oct-2011 |
Adam Powell <adamp@google.com> |
Add API for deferring fragment start.
Fragments now have the setDeferStart method to signal that a fragment
has lower priority than others. Deferred start fragments will not
always be started immediately; they will be started once any loaders
have finished servicing any outstanding requests. This is useful if
any attached fragments are not immediately visible and can wait to
start until later.
Disabling deferStart on a fragment that is waiting for a deferred
start will start it immediately. Start.
Change-Id: Ia1f004877ca5e88d4f10147d21c7e2e97f141c34
/frameworks/base/core/java/android/app/LoaderManager.java
|
| b54e7a3d9f60ac605f404f9eb3c5e92ca51bbd23 |
|
04-Oct-2011 |
Joe Fernandez <joefernandez@google.com> |
docs: add developer guide cross-references, Project ACRE
Change-Id: I5df1c4e13af67ff4c4a5b22f3cb1247bf0103b09
/frameworks/base/core/java/android/app/LoaderManager.java
|
| afc4b283fdaedec9bf32492a019b43cc33edc9b6 |
|
11-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix some problems with moving in and out of detached state.
Loaders were not being re-initialized correctly when coming back
(this would also impact the back stack). The ListView also wasn't
working correctly, and there were also problems with simply
re-using a Fragment instance after it had been removed.
Change-Id: I534b091ae09c0ef7ffffe9d68049e6840e8926b3
/frameworks/base/core/java/android/app/LoaderManager.java
|
| f9dd34f4d3203fd50363b3b0247c5d0db6fe2c8f |
|
20-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
DO NOT MERGE: Integrate from main - Deprecate a bunch of APIs.
And clean up some documentation.
Change-Id: I8f06e2fc3bb6c552581b64657e82ba690d524232
/frameworks/base/core/java/android/app/LoaderManager.java
|
| 260c3c77d9b340164e055f87002c64d78da6e836 |
|
31-Jan-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #3381489: IllegalStateException: attempt to re-open...
...an already-closed object: android.database.sqlite.SQLiteQuery
It turns out there is a state we are missing -- the loader is
still needed, but in the inactive list. In this case the loader
needs to continue holding on to its current data, and not deliver
any new data (which would result in it releasing its old data).
This introduces the new state to Loader, and uses it in
AsyncTaskLoader so all subclasses of that should get the new
correct behavior.
A further improvement would be to unregister CursorLoader's
content listener when going in to this state, but that can
wait for later.
Change-Id: I6d30173b94f8e30b5be31d018accd328cc3388ec
/frameworks/base/core/java/android/app/LoaderManager.java
|
| ec541e1787b39605200584042fa1e144923eeb4f |
|
22-Jan-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix some error messages, turn off logging.
Change-Id: Ifcd2c0f0ad137485896144d2248361aeb0a05600
/frameworks/base/core/java/android/app/LoaderManager.java
|
| 6e1bf6a3054674281bafd270165c99cb2423666d |
|
20-Jan-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #3352125: Crash after clearing search query
Don't deliver data arriving from a Loader after the application
has moved on to a new Loader.
Also throttle the number of Loaders will have actively running
for a particular ID.
Oh, and documentation. Documentation is good.
Change-Id: I5a5cfdbb8c9bfb320ffc014f99e37fe7e3001382
/frameworks/base/core/java/android/app/LoaderManager.java
|
| 327fbd2c8fa294b919475feb4c74a74ee1981e02 |
|
17-Jan-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix a bunch of API review bugs.
3362464 API REVIEW: android.content potpourri
3362445 API REVIEW: Fragment transaction stuff
3362428 API REVIEW: Fragment stuff
3362418 API REVIEW: Loader stuff
3362414 API REVIEW: android.content.pm.ActivityInfo
Change-Id: I6475421a4735759b458acb67df4380cc6234f147
/frameworks/base/core/java/android/app/LoaderManager.java
|
| db7f38673c33ba55801019007ff18fa4c57f75e0 |
|
17-Jan-2011 |
Dianne Hackborn <hackbod@google.com> |
Merge "Start renaming FragmentTransaction.openTransaction() to beginTransaction()." into honeycomb
|
| 48e7b458694acdf3a4fc58e62437f1dbc4f29d83 |
|
17-Jan-2011 |
Dianne Hackborn <hackbod@google.com> |
Start renaming FragmentTransaction.openTransaction() to beginTransaction().
Change-Id: Ib4a6d824b33cca699b7b25159c491fb610d5f5da
/frameworks/base/core/java/android/app/LoaderManager.java
|
| fd119e986d531345c2df3022ea9d968bb7fd3858 |
|
17-Jan-2011 |
Dmitri Plotnikov <dplotnikov@google.com> |
Delivering null cursor to loader callbacks.
ContentProviders are allowed to return null and both
of our contact directories (Focus and Exchange) actually
do when they find no data to return.
The problem is that when LoaderManager receives a result
from a loader, it checks if the result is the same as
previously received. That's fine, as long as the loader
always returns a different result. Now consider a loader
that returns null when it cannot produce the result.
What we are seeing is that if the loader is rapidly restared
and returns null twice in a row, the null is never
delivered to the callbacks.
In the case of the reported bug, the scenario is this:
1. We look for "foo"
2. Data for "foo" comes from a directory and we display it
3. We hit backspace twice in rapid succession. Each time
we hit backspace, the loader is restared, but since we do
this very fast, the second restart overrides the first. So
far so good.
4. The directories are programmed to return null if the
query string is less than 3 characters long, so the loader
returns null twice.
5. Loader manager looks at the final result, compares it
to the previous result and since they are the same (both null)
concludes that it does not need to deliver either of them.
6. The UI attempts to show the stale data and blows up
Bug: 3352125
Change-Id: I3e5bc505faa03f72ebe5cb010377a740f5c7d5b6
/frameworks/base/core/java/android/app/LoaderManager.java
|
| 0e3b8f421dfcc5363f234eb1b76479cb2fb2e8ee |
|
21-Dec-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #3301572: onCreateLoader must not be a member class: VolumeMetadataLoader
Also some various cleanup.
Change-Id: I8e8616a86c50c86817f7ec9bb02a5954c1ccd84f
/frameworks/base/core/java/android/app/LoaderManager.java
|
| a2ea747faaf5fcd437afbaaf4085cfc29e7c16b8 |
|
20-Dec-2010 |
Dianne Hackborn <hackbod@google.com> |
More cleanup of Loader APIs.
- Remove old method names.
- Introduce onXxx() hooks to Loader.
- Improve debugging.
Change-Id: I3fba072a05c7023aa7d2c3eb4e126feb514ab6d8
/frameworks/base/core/java/android/app/LoaderManager.java
|
| f73c75ca20fcaaee1b0eeaaf756252c33e3099c6 |
|
18-Dec-2010 |
Dianne Hackborn <hackbod@google.com> |
Some fixes to the new loader management.
Change-Id: Ib882be5762b0ebeed9b027754159f401232718e9
/frameworks/base/core/java/android/app/LoaderManager.java
|
| 540d3d26623f44caaa82a5c973cda818cb11f946 |
|
17-Dec-2010 |
Dianne Hackborn <hackbod@google.com> |
Fixes for when onLoaderReset() is called.
Change-Id: Iab479926f11fa579757904032ada46c41686d560
/frameworks/base/core/java/android/app/LoaderManager.java
|
| c91893511dc1b9e634648406c9ae61b15476e65d |
|
15-Dec-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #3272082: Contacts: when going back from edit view,
list UI is not ready yet
This involves some reworking of Loaders.
Loaders, in particular CursorLoader, are now expected to retain
their current data after being stopped. This allows applications
to keep that data across onStop() -> onStart(), so when the user
returns to the app it doesn't have to wait for the data to reload
and thus cause flicker.
This includes various API changes to better reflect the new
semantics, plus a new LoaderCallbacks method to tell the application
when it is actually time to stop their use of a loader's data.
Note this is somewhat half-done, to help checking in the extensive
application changes that are required without causing build breakage.
Change-Id: Ib4b3bf8185a6da46e7f06ca125521d65e2e380a1
/frameworks/base/core/java/android/app/LoaderManager.java
|
| 30d7189067524000c738c188c4ff91f84f474d25 |
|
11-Dec-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #3274841: Orientation change problem with a paused activity
Plus a bunch of debug output improvements.
And some new Intent helpers for dealing with restarting an app.
Change-Id: I50ec56bca6a86c562156b13fe8a6fdf68038a12e
/frameworks/base/core/java/android/app/LoaderManager.java
|
| ab36acb39941ce981dddda9f9cf4d2d23a56fd26 |
|
05-Nov-2010 |
Dianne Hackborn <hackbod@google.com> |
Fixe some stuff.
Addresses these bugs:
3061847 - With no headers, PreferenceActivity crashes
2888426 - minor typo in DevicePolicyManagerService.ActiveAdmin.writeToXml()
3159155 - IllegalStateException:"Can not perform this action after
onSaveInstanceState" while dismissing a DialogFragment
3155995 - PopupWindow.showAtLocation does not respect LayoutParams
Also tweak the new fragment APIs to use abstract classes instead of
interfaces as base classes.
Change-Id: I9c0b4337fe0e304b737b5f7c2762762372bb3020
/frameworks/base/core/java/android/app/LoaderManager.java
|
| fb3cffeb35368da22f99b85d45039c4e6e471c06 |
|
26-Oct-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #3130426: Finsky crash in switching from window carousel
Need to note that we no longer have saved state before delivering
results or new intents to an activity.
Also do some work on loaders to prevent apps from making fragment
changes as a result of receiving loader data. This makes apps
consistent crash in a case that they would previously sometimes
crash (if they got the loader data after onPause).
Change-Id: I46e9e46d0aa05d9d7d6a275a2a488a18a20a5747
/frameworks/base/core/java/android/app/LoaderManager.java
|
| debb2e25b3ce2f0f5195a2895dd1882fc172d4d8 |
|
10-Aug-2010 |
Dianne Hackborn <hackbod@google.com> |
This may fix LoaderManager bug where a closed cursor could be used.
Change-Id: I362d5f86dcbdbede921ef9d29c849ed6401850ea
/frameworks/base/core/java/android/app/LoaderManager.java
|
| 5e0d59547c4042037e23a42ba4e2521721e9c7d3 |
|
05-Aug-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix some Loader bugs.
- Weren't re-attaching to the current loader manager after retaining
instance state.
- Ensure loaders are being destroyed.
- Fix a bug if you call restartLoader() inside of onLoadFinished().
Change-Id: I89df53db49d8e09047bf55216ebeb0f133c059e7
/frameworks/base/core/java/android/app/LoaderManager.java
|
| f5100a7823a60f369a6c0014b1b80ca945128e4a |
|
21-Jul-2010 |
Ben Komalo <benkomalo@google.com> |
Relay stopLoading() on the loader from LoaderInfo.stop()
Change-Id: Ie48b303cef4fe1b284d4ed6a1b310f3dcef20c91
/frameworks/base/core/java/android/app/LoaderManager.java
|
| 4911b783aa9f4af5ac919db861751d350471f5ef |
|
15-Jul-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix bug where loader listener would be registered twice.
Also change LoaderManager to an interface.
Change-Id: Ife6d123e56cc6f63b6fe902afac35b2673761e60
/frameworks/base/core/java/android/app/LoaderManager.java
|
| 622b3dc4a902bdc9262981c0a566a70b9a4490b3 |
|
12-Jul-2010 |
Kenny Root <kroot@google.com> |
Change Javadoc to get around brokenness
Apparently the Javadoc we're using can't handle generic method
arguments, so remove the argument specification to let the compiler
match the right one since we're not overloading that method anyway.
Change-Id: Ie1a1a28c6e3c5fe5d2d434ecc66519e514bc692c
/frameworks/base/core/java/android/app/LoaderManager.java
|
| 2707d6026240bcca6f0e35e2e1138958882e90ce |
|
10-Jul-2010 |
Dianne Hackborn <hackbod@google.com> |
Implement instance passing in LoaderManager.
Activity now propagates loaders across instances when retaining
state. Adjusted APIs to make it better for apps to deal with this.
Change-Id: I8a6448cff1132e66207f9223eb29ccfc0decf2ca
/frameworks/base/core/java/android/app/LoaderManager.java
|
| 53c67c8dfd4fe089bae2ab28cf6eae02ab1066c1 |
|
09-Jul-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix build.
Change-Id: I60185df6150d13d704a28933bc919527da173307
/frameworks/base/core/java/android/app/LoaderManager.java
|
| c801768e4d29667a2608695449ebc2833ba0f200 |
|
06-Jul-2010 |
Dianne Hackborn <hackbod@google.com> |
Integrate Loader support in to Activity/Fragment.
Introduces a new LoaderManager class that takes care of
most of what LoaderManagingFragment does. Every Fragment
and Activity can have one instance of this class. In the
future, the instance will be retained across config changes.
Also various other cleanups and improvement.
Change-Id: I3dfb406dca46bda7f5acb3c722efcbfb8d0aa9ba
/frameworks/base/core/java/android/app/LoaderManager.java
|