是否必须从 onConfigurationChanged() 调用 setContentView() ？

发布于 2024-11-24 09:26:09 字数 598 浏览 1 评论 0原文

我已经为我的活动设置了清单条目，以便它自行处理方向更改。

在我的 onConfigurationChanged() 中，我得到了这个：

@Override
public void onConfigurationChanged(Configuration newConfig) {
    super.onConfigurationChanged(newConfig);

    findViewById(R.id.header).post(new Runnable() {
        @Override
        public void run() {
        }
    });
}

经过几个月的正常工作后，我在 findViewById() 上遇到了 NullPointerException代码>行。我的结论是，由于省略了 setContentView()，因此尚未创建相关的 View。

setContentView() 这里真的有必要吗？如果是这样，为什么它一直工作而没有发生任何事故？

原文

I've set the manifest entry for my Activity so that it handles orientation changes by itself.

In my onConfigurationChanged(), I've got this:

@Override
public void onConfigurationChanged(Configuration newConfig) {
    super.onConfigurationChanged(newConfig);

    findViewById(R.id.header).post(new Runnable() {
        @Override
        public void run() {
        }
    });
}

After months of working without problems, I've just had a NullPointerException on the findViewById() line. My conclusion is that the View in question hasn't been created yet, due to the omission of setContentView().

Is setContentView() really necessary here? If so, why has it been working all this time without incident?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

茶底世界 2024-12-01 09:26:09

不，在这种情况下没有必要调用 setContentView。代码中的其他内容导致 findVieWById 返回 null。

回复收藏 0 原文

扬花落满肩 2024-12-01 09:26:09

来自 Android Activity 文档：

如果设备的配置（由
Resources.Configuration 类）发生变化，然后任何显示
用户界面需要更新以匹配该配置。
因为 Activity 是与应用程序交互的主要机制
用户，它包括对处理配置更改的特殊支持。
除非您另外指定，否则配置更改（例如更改
屏幕方向、语言、输入设备等）将导致您
当前活动将被销毁，进行正常活动
onPause()、onStop()、onDestroy()的生命周期过程如下
合适的。如果该 Activity 位于前台或可见
用户，一旦在该实例中调用 onDestroy()，就会产生一个新的
将创建活动的实例，无论是什么
前一个实例已从其生成的 savingInstanceState
onSaveInstanceState(Bundle)。
这样做是因为任何应用程序资源，包括布局文件，
可以根据任何配置值进行更改。因此唯一安全的方法是
处理配置更改就是重新检索所有资源，
包括布局、绘图和字符串。因为活动必须
已经知道如何保存自己的状态并从中重新创建自己
那种状态，这是重新启动活动的便捷方法
本身具有新的配置。
在某些特殊情况下，您可能希望绕过重新启动您的
基于一种或多种类型的配置更改的活动。这是
使用清单中的 android:configChanges 属性完成。对于任何
您说您在那里处理的配置更改类型，您将
接到关于您当前活动的电话
onConfigurationChanged(Configuration) 方法而不是
重新启动。如果配置更改涉及任何您不涉及的内容
但是，该活动仍将重新启动并且
onConfigurationChanged(Configuration) 不会被调用

基本上，您需要确保保存实例状态，并在 onConfigurationChanged() 之后获取信息

希望这有帮助！

From the Android Activity Docs:

If the configuration of the device (as defined by the
Resources.Configuration class) changes, then anything displaying a
user interface will need to update to match that configuration.
Because Activity is the primary mechanism for interacting with the
user, it includes special support for handling configuration changes.
Unless you specify otherwise, a configuration change (such as a change
in screen orientation, language, input devices, etc) will cause your
current activity to be destroyed, going through the normal activity
lifecycle process of onPause(), onStop(), and onDestroy() as
appropriate. If the activity had been in the foreground or visible to
the user, once onDestroy() is called in that instance then a new
instance of the activity will be created, with whatever
savedInstanceState the previous instance had generated from
onSaveInstanceState(Bundle).
This is done because any application resource, including layout files,
can change based on any configuration value. Thus the only safe way to
handle a configuration change is to re-retrieve all resources,
including layouts, drawables, and strings. Because activities must
already know how to save their state and re-create themselves from
that state, this is a convenient way to have an activity restart
itself with a new configuration.
In some special cases, you may want to bypass restarting of your
activity based on one or more types of configuration changes. This is
done with the android:configChanges attribute in its manifest. For any
types of configuration changes you say that you handle there, you will
receive a call to your current activity's
onConfigurationChanged(Configuration) method instead of being
restarted. If a configuration change involves any that you do not
handle, however, the activity will still be restarted and
onConfigurationChanged(Configuration) will not be called