有关清单中活动代码的android:configChanges='orientation'
属性的文档:
注意:应避免使用此属性,并仅将其用作最后的手段。有关如何通过配置更改正确处理重新启动的更多信息,请阅读处理运行时更改。
为什么会这样说?
对于通过服务API库的线程和网络请求,可以使用对原始Activity的引用进行请求,然后可以进行方向更改,使线程指向旧的Activity。
虽然可以解决这个问题,但与自己处理配置更改相比,这是单调乏味的。
为什么要避免?
编辑:我想我也应该问:这是否是您自己进行方向配置更改的可接受原因?
答案 0 :(得分:3)
为什么会这样说?
因为他们希望您阅读文档中的“处理运行时更改”部分。 : - )
在线程和网络的情况下 通过服务API库请求,a 请求可以参考 到原来的Activity,然后一个 方向改变可能发生, 让线程指向旧的 活性。
对于你关心旋转的情况,不要使用Activity
的隐式引用(例如,常规内部类),而是使用显式引用(例如,静态内部类)。 Here is a brand-spankin'-new sample project表明我的意思。
虽然可以修复,但这很乏味 和刚刚处理的丑陋相比 配置会改变自己。
我怀疑这个建议是存在的,因为他们害怕Android的新手会搞乱“自己处理配置更改”。例如,他们决定为横向设置一些不同的字符串(你有更多的横向空间)并忘记重新加载它们。或者,他们决定为景观制作一些不同的图像,忘记重新加载它们。等等。
大多数应用程序中的大多数活动都不会有后台线程或套接字或其他任何内容,或者因为它们不需要它们,或者因为其他东西正在管理它们(例如,Service
)。他们的破坏和重新创建的库存实现通常“正常工作”,特别是内置支持保存小部件状态EditTexts
等。
此外,你可能不会通过“自己处理”来节省那么多,因为仍然需要实现onSaveInstanceState()
,以处理配置更改以外的场景(例如,你的活动被拉出RAM以释放空间。)
现在,他们的措辞有点刺耳吗?大概。经验丰富的Android开发人员可以自行决定采用哪种轮换处理策略。我怀疑他们的语气是试图在走下这条路线之前吓唬新人思考两次。
答案 1 :(得分:1)
我同意,在某些情况下,必须保存状态并重新绘制我的观点似乎有些过分。我可以理解,如果您想在方向更改时配置不同的布局,但是将其添加到我的活动中会更容易。
@Override
public void onConfigurationChanged(Configuration newConfig) {
if(newConfig.equals(Configuration.ORIENTATION_LANDSCAPE)
|| newConfig.equals(Configuration.ORIENTATION_PORTRAIT)
|| newConfig.equals(Configuration.ORIENTATION_SQUARE)
|| newConfig.equals(Configuration.ORIENTATION_UNDEFINED)) {
} else {
super.onConfigurationChanged(newConfig);
}
}