Управление ориентацией меняет себя

Question

Из документации, касающейся атрибута android:configChanges='orientation' тега активности в манифесте:

Примечание. Следует избегать использования этого атрибута и использовать его только в качестве крайней меры. Пожалуйста, прочитайте Обработка изменений времени выполнения для получения дополнительной информации о том, как правильно обрабатывать перезапуск из-за изменения конфигурации.

Почему это говорит это?

В случае потоков и сетевых запросов через библиотеку API службы запрос может быть сделан со ссылкой на исходное действие, а затем может произойти изменение ориентации, при этом поток будет указывать на старое действие.

Хотя это можно исправить, это утомительно и безобразно по сравнению с простой обработкой изменений конфигурации.

Почему этого следует избегать?

Редактировать: Думаю, мне следует также спросить: будет ли это приемлемой причиной для изменения конфигурации ориентации самостоятельно?

Answer 1

Почему так сказано?

Потому что они хотят, чтобы вы прочитали раздел «Обработка изменений времени выполнения» в документации. : -)

В случае потоков и сетей запросы через сервис API библиотеки, запрос может быть сделан со ссылкой к исходному действию, а затем может произойти изменение ориентации, оставляя нить, указывающую на старую Активность.

Для случаев, когда вам небезразличны ротации, не используйте неявные ссылки на Activity (например, обычный внутренний класс), а скорее явные (например, статический внутренний класс). Вот совершенно новый пример проекта , который демонстрирует, что я имею в виду.

Хотя это можно исправить, это утомительно и некрасиво по сравнению с просто обработкой Конфигурация меняется самостоятельно.

Рекомендация есть, я подозреваю, потому что они боятся, что новички в Android могут испортить «обработку изменений конфигурации самостоятельно». Например, они решили использовать несколько разных строк для ландшафта (где у вас больше горизонтального пространства) и забыли перезагрузить их. Или, они решили иметь несколько разных изображений для ландшафта и забыли перезагрузить их. И так далее.

Большинство действий в большинстве приложений не будут иметь фоновых потоков или сокетов или чего-либо собственного, либо потому, что они им просто не нужны, либо потому, что ими управляет что-то другое (например, Service). Их стандартная реализация уничтожения и воссоздания обычно «просто работает», особенно со встроенной поддержкой для сохранения состояния виджета EditTexts и тому подобного.

Кроме того, вы не можете сэкономить так много, «обрабатывая это самостоятельно», потому что вам все же все равно необходимо реализовать onSaveInstanceState(), чтобы обрабатывать сценарии, отличные от изменений конфигурации (например, ваша активность отбрасывается недостаточно оперативной памяти для освобождения места).

Теперь, их фразы немного резкие? Наверное. Опытные разработчики Android могут самостоятельно принимать решение о том, какую стратегию обработки ротации использовать. Я подозреваю, что их тон состоит в том, чтобы напугать новичков, чтобы они дважды подумали, прежде чем идти по этому пути.

Answer 2

Согласен, в некоторых случаях кажется чрезмерным необходимость сохранять состояние и перерисовывать мои взгляды. Я могу понять, хотите ли вы настроить другой макет при изменении ориентации, но в противном случае намного проще добавить это в мою деятельность.

@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);
 }
}