Лучший способ справиться с ориентацией экрана Изменение при работе с динамически создаваемыми видами? - PullRequest
3 голосов
/ 30 ноября 2010

При запуске определенного действия моего приложения, пользователь "приветствуется" с диалоговым окном, которое он должен заполнить некоторыми данными, чтобы продолжить.Затем в задании как таковом у пользователя есть 2 кнопки, которые позволяют ему динамически создавать и удалять бесконечное количество полей (составленных из нескольких представлений)

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

Чтобы справиться с ориентацией экрана, документация для Android советует разработчикам использовать onRetainNonConfigurationInstance () .Единственная проблема заключается в том, что если вы используете его для сохранения объектов в контексте, все связанные представления будут утечками.Это еще более проблематично в моем случае, так как данные в этом действии по своей сути связаны с его представлением, которое, в свою очередь, связано с его контекстом.

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

Я могу легко обойти начальный диалог, создав логическое значение hasBeenShown и установив его, например, в true,Я даже могу обойти проблему «динамически создаваемых представлений», сохранив их метаданные: в этом случае количество сгенерированных полей, их тип, их взаимное расположение, их текст или выделение и т. Д. (С некоторыми незначительнымиошибки, но ничего серьезного).

Но поскольку поля (представления) генерируются динамически с layoutInflate (и, таким образом, мы можем иметь бесконечное количество просмотров), при повторной генерации тех же полей после изменения ориентации экрана,приложение работает очень медленно даже на эмуляторе.С 20 полями (примерно 120 видов) на реальном устройстве (Samsung Galaxy S) для завершения потребовалась почти 1 минута.

Странно, но когда я передавал виды напрямую (и, таким образом, пропускал все эти вещи), это занималомоя Samsumg Galaxy S меньше чем за 10 секунд до завершения.

С этой информацией, какой, по вашему мнению, наилучший подход?

(1) - Разрешить сброс полей?(на самом деле не вариант, могу поспорить, что кто-нибудь разозлится, если они непреднамеренно наклонят свой экран = P)

(2) - Добавить загрузочный экран, пока Android заботится об изменении ориентации экрана?

(3) - Блокировать изменение ориентации экрана

(4) - Управлять изменением ориентации экрана самостоятельно, и надеюсь, что мешающие разговоры о документах Doom для Android никогда не придут.

PS: Немного оффтоп, но когдамоя деятельность заканчивается, вся память освобождается, верно?

1 Ответ

6 голосов
/ 30 ноября 2010

Ваша ситуация отличается от моей, но аналогичное решение может быть в порядке.

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

Чтобы сэкономить на использовании сети и головных болях, я просто «справляюсь» с изменением ориентации самостоятельно. Поместив этот код в свой AndroidManifest.xml

<activity android:name=".whatever" android:configChanges="keyboardHidden|orientation"/>

вы разрешаете Android сохранять текущий контекст с представлениями, переменными и т. Д. Что происходит, так это то, что макеты изменят свой размер, но если вы спроектировали правильно, то все будет в порядке.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...