Android: бывают ли случаи, когда Activity создается заново, даже если для android: configChanges = установлено значение all?

1

Во-первых, краткое описание проблемы:

У меня возникли проблемы с обработкой жизненных циклов рабочих кадров в соответствии с жизненным циклом деятельности. Первая проблема заключается в том, что новый экземпляр активности создается всякий раз, когда изменяется конфигурация (включая ориентацию экрана), поэтому мне пришлось вытащить моих работников из старого экземпляра в новый. Во-вторых, это осложняется тем фактом, что иногда рабочие отображают диалоговое окно прогресса, а также, иногда, они отображают диалоговое окно с ошибкой, с которым пользователь должен взаимодействовать. Обработка всего этого материала - рабочих, диалогов и т.д. - через экземпляры активности стала настолько сложной, что теперь я ясно вижу, что это был неправильный путь.

Правильный способ, я полагаю, состоял в том, чтобы устранить эту re- копию. Если это было предоставлено, то у меня были действия с очень простым и быстрым жизненным циклом straight-, и нет необходимости отслеживать сотрудников и диалогов. Этого можно добиться, положив android:configChanges="..." в манифест.

Теперь вопрос:

Учитывая, что у этой активности есть android:configChanges="...", которая включает в себя все возможное (ориентация, клавиатура и все остальное) - есть гарантия того, что действие создается экземпляр ровно один раз, пока он жив, а не убит /re- созданный даже в фоновом режиме? Документация неясна об этой точке.

Если кто-то знает случаи, когда такая гарантия не задерживается - сообщите мне. И самое главное - как имитировать эти случаи, чтобы протестировать их?

Я очень ценю ваши ответы.

PS: В какой документации говорится, что "система может удалить вашу деятельность в любой момент, если она захочет", - но мы ее здесь не рассматриваем, потому что это будет новая история для нового экземпляра, когда пользователь назад к экрану, действие которого было удалено таким образом. В этом случае мы просто начнем с нуля, как если бы пользователь только открыл этот экран.

  • 0
    «Правильный путь, я полагаю, состоял в том, чтобы устранить это восстановление в первую очередь». -- возможно нет. Избавьтесь от диалоговых окон. Используйте onRetainNonConfigurationInstance() для передачи объектов AsyncTask и т. П. Между экземплярами AsyncTask которые уничтожаются / воссоздаются из-за изменений конфигурации, или setRetainInstance() таких «работников» во фрагментах с помощью setRetainInstance() .
  • 0
    @CommonsWare - Спасибо за ваш ответ! Я уже использую onRetainNonConfigurationInstance() для передачи рабочих, но, к сожалению, с диалогами не все так просто. Диалог создается рабочим, и действие только показывает его; он не знает, как создать копию этого диалога, когда ему нужно показать ее в новом экземпляре. Или что вы имели в виду, говоря "избавиться от диалоговых окон"?
Показать ещё 1 комментарий
Теги:
android-activity
android-asynctask
dialog

2 ответа

1
Лучший ответ

Если вы спрашиваете об этом, ваше приложение, вероятно, сломано.

Итак, почему вас это волнует? Если вы не можете обработать свою активность, которая будет перезапущена, тогда вы будете нарушать ситуацию, когда ваш процесс приложения должен быть убит для памяти в фоновом режиме, и пользователь позже возвращается к нему.

Если вы можете справиться с перезапуском, почему вам небезразлично, что может быть какой-то случай, когда необходимо перезапустить действие?

В любом случае ответ заключается в том, что нет способа гарантировать, что активность никогда не перезапускается, поэтому не следует злоупотреблять android: configChanges, чтобы попытаться избежать этого. Вы не можете предотвратить это, вы просто сделаете менее понятным для себя, что ваше приложение сломано, но пользователи все равно будут сталкиваться с имеющимися у вас ошибками.

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

Также невозможно установить множество возможных причин, по которым приложение может быть перезапущено. Новые изменения могут и будут добавляться в будущем, и вы не можете их учитывать.

Поделиться
  • 0
    the situation where your app's process needs to be killed for memory while in the background and the user later returns to it - я был бы очень признателен, если бы вы сказали мне, как пользователь может вернуться к завершенному процессу, не запустив его с нуля?
  • 0
    Я посмотрел на загрузчики, и было сказано, что они обрабатывают изменение конфигурации автоматически - очень хорошо, но есть одна проблема: загрузчики доступны начиная с API 11, и я должен поддерживать API 3+. Есть ли способ добиться того же, используя средства API 3? Я очень ценю ваш ответ.
Показать ещё 1 комментарий
0

Обычно, когда вы хотите, чтобы некоторые объекты оставались при активном отдыхе, вы должны зависеть не от активности, а от контекста приложения. Если ваш объект приложения, как рекомендовано, является одноэлементным, тогда было бы намного проще сделать ваши предметы выжившими до жизненного цикла деятельности.

Вот пример того, как это сделать: Как объявить глобальные переменные в Android?

Поделиться
  • 0
    А что касается диалогов, я не знаю точно, как они могут быть обработаны, я ищу дополнительную информацию от других участников в этой теме.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню