Когда сохранить состояние заявки на надгробие?

Question

Мне было интересно, когда более уместно сохранить модель представления отдельных страниц.

Я вижу две возможности:

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

Как правильно обращаться с ним?

Thx Simone

Answer 1

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

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

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

Answer 2

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

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

Примеры сохраняемой мной конкретной информации: введенные, но несохраненные данные; и прокрутите позиции.

Answer 3

Я тоже об этом подумал.

Я обобщил свой взгляд на это.

Сохраните как можно раньше.

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

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

Причины, которые могут мотивировать вас отложить сохранение, могут включать

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

Answer 4

Я не могу проголосовать за предыдущий ответ, потому что у меня недостаточно «репутации», но да, любая информация о переходном состоянии должна быть сохранена в событии Application.Deactivation, а затем восстановлена ​​в событии Application.Activation для поддержки захоронения.

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