Fixed
Status Update
No update yet.
Comments
ta...@gmail.com
Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:
- Android Studio Ladybug Feature Drop | 2024.2.2 Canary 2
- Android Gradle Plugin 8.8.0-alpha02
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
Thank you for taking the time to submit feedback — we really appreciate it!
il...@google.com
to...@gmail.com
Can you confirm this is unwanted change or not?
If it's wanted I'll probably have to priorize my migration to normal ViewModel/LiveData.
If it's wanted I'll probably have to priorize my migration to normal ViewModel/LiveData.
il...@google.com
Yes, this is an unintentional regression.
A better workaround is to:
1) Add a Loader field (say, mLoader) to your FragmentActivity/Fragment
2) Where you used to call restartLoader(), replace with:
mLoader = null;
mLoader = loaderManager.restartLoader(ID, bundle, callbacks);
3) For onLoaderReset(), use this pattern:
if (loader == mLoader) {
// Your existing reset logic
}
4) If you use initLoader(), make sure to assign its return value to mLoader
5) If you use destroyLoader(), make sure to null out mLoader after the call to destroyLoader()
A better workaround is to:
1) Add a Loader field (say, mLoader) to your FragmentActivity/Fragment
2) Where you used to call restartLoader(), replace with:
mLoader = null;
mLoader = loaderManager.restartLoader(ID, bundle, callbacks);
3) For onLoaderReset(), use this pattern:
if (loader == mLoader) {
// Your existing reset logic
}
4) If you use initLoader(), make sure to assign its return value to mLoader
5) If you use destroyLoader(), make sure to null out mLoader after the call to destroyLoader()
ta...@gmail.com
Re: #4: I don't think that's a perfect workaround. I had tried a similar workaround, setting a flag to skip a swapCursor() onLoaderReset the first time after restartLoader. This broke when calling restartLoader() multiple times quickly, for example in response to characters typed on a keyboard. I got StaleDataException from the CursorAdapter trying to use the old Cursor.
il...@google.com
Ah, yes that fixes the issue on the CursorAdapter side, but CursorLoader still closes the Cursor in onReset(), of which there's no good workaround for.
il...@google.com
This has been fixed and will be available in future Support Library releases. When a Loader is replaced with restartLoader(), the existing Loader won't be reset() until the replacement Loader returns data - this ensures that resources remain valid. When using restartLoader(), the previous LoaderCallbacks won't get a callback to onLoaderReset() - this ensures that your UI (such as a CursorAdapter) is not cleared.
vo...@gmail.com
Any ET on hotfix release date for 27.1x?
kk...@google.com
This bug has been fixed in Support Library 27.1.1.
ku...@gmail.com
Racave varjan
ku...@gmail.com
Racave varjan
ku...@gmail.com
Racave varjan
gs...@gmail.com
Mise a jour
Description
Callback order is changed when calling restartLoader.
The documentation of restartLoader Says: "If a loader with the same id has previously been started it will automatically be destroyed when the new loader completes its work. The callback will be delivered before the old loader is destroyed."
But new implementation does not that at all. It calls onLoaderReset then onCreateLoader then onLoadFinished. (Previous implementation was sometimes broken and never called onLoaderReset but at least there was no long duration where we have no data to display).
This is a major change because this means you can't keep the previous data during the load as it's invalidated but you have nothing to display since the new loader is not finished. Meaning empty screen on reload = quite bad UX.