Obsolete
Status Update
Comments
dn...@gmail.com <dn...@gmail.com> #2
Having a similar problem, are we missing something? :)
ed...@gmail.com <ed...@gmail.com> #3
Did anyone find a solution for this?
(except calling forceLoad())
(except calling forceLoad())
ha...@gmail.com <ha...@gmail.com> #4
[Comment deleted]
ha...@android.com <ha...@android.com> #5
Loaders are used extensively in Android 3.0, so I doubt there is such a problem. Please look at the fragment static library, it also includes an implementation of loaders for pre-HC platforms. In there you can look at the CursorLoader to see how it is implemented on top of AsyncTaskLoader. Do the same thing as it.
ed...@gmail.com <ed...@gmail.com> #6
I just checked the CursorLoader from the static library.
It seems we have to implements some methods, one of them being onStartLoading(), that actually calls forceLoad() the first time:
protected void onStartLoading() {
if (mCursor != null) {
deliverResult(mCursor);
}
if (takeContentChanged() || mCursor == null) {
forceLoad();
}
}
Thanks.
It seems we have to implements some methods, one of them being onStartLoading(), that actually calls forceLoad() the first time:
protected void onStartLoading() {
if (mCursor != null) {
deliverResult(mCursor);
}
if (takeContentChanged() || mCursor == null) {
forceLoad();
}
}
Thanks.
al...@gmail.com <al...@gmail.com> #7
Here is a nice little class that basically does what CursorLoader does but in a generic way.
Dianne: Can the docs får AsyncTaskLoader be clearer about how to handle this?
Dianne: Can the docs får AsyncTaskLoader be clearer about how to handle this?
di...@gmail.com <di...@gmail.com> #8
onStartLoading() is called in two places:
1. LoaderManagerImpl.doStart()->LoaderInfo.start(), which will happen when the hosting fragment is started.
2. LoaderManagerImpl.installLoader(LoaderInfo)->if the hosting fragment is started, call LoaderInfo.start().
So basically, your custom class extending AsyncTaskLoader will have to override onStartLoading(), and call forceLoad() within when necessary.
Loader::startLoading() will be called when the hosting fragment is started, and your onStartLoading() will be called as consequence.
1. LoaderManagerImpl.doStart()->LoaderInfo.start(), which will happen when the hosting fragment is started.
2. LoaderManagerImpl.installLoader(LoaderInfo)->if the hosting fragment is started, call LoaderInfo.start().
So basically, your custom class extending AsyncTaskLoader will have to override onStartLoading(), and call forceLoad() within when necessary.
Loader::startLoading() will be called when the hosting fragment is started, and your onStartLoading() will be called as consequence.
jb...@android.com <jb...@android.com>
jb...@android.com <jb...@android.com>
sa...@google.com <sa...@google.com> #9
Thank you for your feedback. We assure you that we are doing our best to address the issue reported, however our product team has shifted work priority that doesn't include this issue. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with latest bug report here https://goo.gl/TbMiIO .
Description
Doing forceLoad() on the returned Loader kicks of the loading like so: getLoaderManager().initLoader(0, null, this).forceLoad();
When doing it the "correct" way with CursorLoader everything works as expected, and the examples only use CursorLoader so there may be something missing when implementing a Loader that I'm missing.