在Android中实现弃用的API而不过度抑制警告的最佳方法是什么?这实际上是一个更一般的Java问题,但它在Android上下文中不断出现。
在Android(java)代码中,一个特性或API被弃用并替换为另一个选项或实现是很常见的。IDE和/或编译器(正确地)用警告标记此错误。例如,getParcelableExtra(String) API从API 33起就被弃用,我们鼓励使用 getParcelabelExtra(String,Class)。
所以,如果我们有一些代码
someMethod(someTypeSomeArgs) {
...
someObj = intent.getParcelableExtra(EXTRA_STRING_PARAMETER)
...
}
它将生成弃用警告。
由于我们正在为各种目标构建,并且新的API通常在旧平台上不可用,因此我们可以遵循文档建议并使用SDK版本检查:
someMethod(someTypeSomeArgs) {
...
if (Build.VERSION.SDK_INT >= 33) {
someObj =intent.getParcelableExtra(EXTRA_STRING_PARAMETER,someClass);
} else {
someObj = intent.getParcelableExtra(EXTRA_STRING_PARAMETER);
}
...
}
这似乎是运行时推荐的最佳实践,但编译器警告仍然存在。我们可以抑制编译器警告,但只能在方法范围内,这是有效的,但完全消除了在方法中其他位置跟踪弃用或在维护代码时跟踪未来弃用的能力。
那么...有没有一个公认的最佳做法来处理这个问题?
1条答案
按热度按时间iqih9akk1#
最好创建一个像
ParcelableExt.kt
这样的扩展函数例如,您可以在resultLauncher中使用它,如下所示