什么是已弃用的 getSupportLoaderManager() 的适当替换?
Posted
技术标签:
【中文标题】什么是已弃用的 getSupportLoaderManager() 的适当替换?【英文标题】:What is the appropriate replacement of deprecated getSupportLoaderManager()? 【发布时间】:2018-12-26 17:35:08 【问题描述】:我知道 getSupportLoaderManager 已被弃用。但我想打电话:
getSupportLoaderManager().initLoader(0, null, mRecipeLoaderManager);
该调用的替代方法是什么? 或者我还能不用担心地使用 getSupportLoaderManager 吗?
【问题讨论】:
在 API 28 中不仅不推荐使用此调用,而且通常不推荐使用加载程序。建议的替换是ViewModel
和 LiveData
。
您不应该继续使用加载器,除非有充分的理由这样做(即大量依赖于使用它们的遗留代码)。对于新代码,正确的做法是不要使用已弃用的代码,这就是弃用存在于首位的原因。
有时在某些设备上抛出“从 oncreateloader 返回的对象不能为空”
【参考方案1】:
我也遇到了这个问题,这段代码为我解决了这个问题LoaderManager.getInstance(this).initLoader(0,null,mRecipeLoaderManager);
希望对你有帮助
【讨论】:
有时在某些设备上抛出“从 oncreateloader 返回的对象不能为空”【参考方案2】:不推荐使用此方法的原因是因为 Loaders 已从其历史的 Fragment
和 FragmentActivity
实现中解绑,以便存在于他们自己的库中,该库很快将成为可选依赖项,并且它们的实现已被重写架构组件的顶部。
获取LoaderManager
实例的非捆绑方式是使用静态工厂方法:
LoaderManager.getInstance(T)
其中T
是LifecycleOwner
和ViewModelStoreOwner
的一个实例(主要实现是FragmentActivity
和Fragment
)。
【讨论】:
所以,在我的AppCompatActivity
(即implements LoaderManager.LoaderCallbacks<Cursor>
)中,我需要做的就是将getSupportLoaderManager()
替换为LoaderManager.getInstance(this)
,然后我可以留下我的@987654335 @、onLoadFinished()
和 onLoaderReset()
方法不变?
是的。您现在也可以在 onLoadFinished() 中安全地执行 FragmentTransactions。【参考方案3】:
如此处所述:Loaders
“自 android P (API 28) 起,加载器已被弃用。在处理 Activity 和 Fragment 生命周期时处理加载数据的推荐选项是结合使用 ViewModel 和 LiveData。”
当您看到 deprecated
时,直接转到 developer api reference site 并查看您正在寻找的类或函数,以及是否有等效的替代方案。
【讨论】:
对不起,我只是给了一个错误的链接。请再次检查!我已经更新了链接。 @fabi 请看本页开头的蓝色大字。此调用没有一对一的替代品,通常不推荐使用加载器。 我怎么能错过...好的,谢谢!对我来说,接缝是弃用 Loaders 并使用 ViewModel 和 LiveData 处理这些情况的好举措。 框架加载器已被弃用,但根据文档,支持库/AndroidX 中的加载器尚未被弃用。不推荐使用的是从Activity
或 Fragment
实例中检索 LoaderManager
的方法,因为您现在需要使用静态工厂方法。【参考方案4】:
如果您需要,您仍然可以使用getSupportLoaderManager
:
android.support.v4.app.LoaderManager.getInstance(this).initLoader(0, null, this).forceLoad();
【讨论】:
这似乎消除了弃用警告,但这是正确的方法吗? @Amrut 它删除了折旧,因为它使用了支持库 v4。如果您仍想使用 Loader,这是正确的方法。否则,您应该使用 ModelView 而不是 Loader。 如果你想使用加载器,你不需要这样做:你只需使用它。如果你想抑制弃用消息,那么正确的方法是在语句之前使用@SuppressWarnings("deprecation") 注释。 @FranMarzoa 支持包的整个前提是保持跨版本的支持,特别是对于以后删除或以前不可用的项目。简单地抑制警告是导致问题的最快方法。【参考方案5】:这里有一个关于如何用 ViewModel 替换 Loaders 的简要说明:
https://developer.android.com/jetpack/arch/viewmodel#loaders
我认为那里的图形是不言自明的:
如需更详尽的解释,您可以阅读这篇博文:
https://medium.com/google-developers/lifecycle-aware-data-loading-with-android-architecture-components-f95484159de4
【讨论】:
【参考方案6】:我也遇到了同样的问题!
getSupportLoaderManger()
可以替换为LoaderManager.getInstance(this)
并且进一步的代码保持不变。所以,最后你的代码会变成:
LoaderManager.getInstance(this).initLoader(0, null, mRecipeLoaderManager);
可以参考Android官方文档: https://developer.android.com/reference/androidx/fragment/app/FragmentActivity#getSupportLoaderManager()
【讨论】:
以上是关于什么是已弃用的 getSupportLoaderManager() 的适当替换?的主要内容,如果未能解决你的问题,请参考以下文章
channel 或 mutablesharedflow ,哪个是已弃用的 localbroadcastmanager 的更好替代品