Состояние сохранения IOS для сложных приложений

Question

Я создаю довольно сложное бизнес-приложение на iPad IOS 4.2: 4 вкладки с потенциально глубокими навигационными путями на каждой вкладке.

По мнению некоторых из ваших более опытных разработчиков IOS, каковы будут общие ожидания пользователя в отношении сохранения состояния приложения между запусками (т.е. после того, как приложение будет полностью завершено и впоследствии перезапущено)? Я использую Базовые Данные и имею все проблемы с данными, но меня беспокоит навигационное дерево приложения. Если пользователь покинул 1-ю вкладку на экране 3, 2-ю вкладку на экране 4, третью на экране 2, где он оставил запись новой записи наполовину завершенной, и был, когда приложение входило в фоновый режим , работая над 4-й вкладкой на экране 3 ... как вы думаете, будет ли средний пользователь ожидать, что приложение запомнит все, что будет запущено в следующий раз? (Моя интуиция говорит да, хотя я не уверен, как долго.)

Если ответ «да», можете ли вы предложить общую стратегию для решения этой проблемы (и, опять же, я говорю здесь о дереве навигации, а не о базовых данных)? Например, если бы навигационные контроллеры использовались в качестве корневого контроллера представления для каждой вкладки, было бы достаточно просто записать достаточно информации об их навигационных стеках, чтобы иметь возможность восстановить их позже. Но как насчет таких вещей, как всплывающие окна, листы предупреждений / действий или модальные ВК, созданные на лету? Должен ли каждый контроллер представления записывать состояние своих объектов пользовательского интерфейса и, если да, каков рекомендуемый способ сделать это?

Я знаю, что многое зависит от пользователя, но я прошу общую точку зрения на эти вопросы, то есть голос опыта.

Answer 1

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

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

Answer 2

По мнению некоторых из ваших более опытных разработчиков IOS, каковы общие ожидания пользователя в отношении сохранения состояния приложения между запусками?

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

Это полностью зависит от типа вашего приложения и продолжительности времени с момента последнего открытия. Похоже, у вас довольно сложное детализированное приложение, так что я думаю, что лучше всего помнить стек навигации в заранее определенный период времени. Я использую фреймворк Three20, который делает это автоматически для меня, но если бы вы реализовали его, это было бы примерно так:

1. Если пользователь открылся за последние 24 часа, откройте точное место, где остановился
2. Если пользователь открывается в течение недели, откройте основной «раздел» или область приложения, в котором он находился
3. Если пользователь открывается через неделю, откройте корневой экран.

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

Что касается реализации, то это всего лишь данные. Вам не нужно сериализовать живые объекты для хранения стека, просто реализуйте данные, необходимые для воссоздания состояния при следующем запуске. То, что вам нужно хранить, сильно зависит от вашей собственной настройки ... пробег будет варьироваться. Я использую NSUserDefaults для хранения всех экземпляров vars и стека навигации через Three20. Проверьте TTNavigator для отличной реализации.

Answer 3

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

Как вы сказали, достаточно легко запомнить, на какой вкладке вы находитесь ».и на какой контроллер вы переходите в каждой вкладке.Больше не нужно.

Звучит так, будто вы управляете им, но для других: 1) при смене вкладок сохраняйте «активную вкладку», 2) при навигации внутрисохранить вкладку «активный контроллер на вкладке», 3) при запуске приложения установить «активную вкладку», 4) при изменении вкладок установить / подтвердить «активный контроллер на вкладке».

Причина 4) заключается в том, что представление / контроллеры для вкладок будут задерживаться при их загрузке или, возможно, никогда не будут загружены.Вы не хотите устанавливать «активный контроллер на вкладке» для вкладки, которая не видна и, возможно, никогда не будет загружена в приложение, это просто приведет к ненужной загрузке.Часто (после загрузки приложения) вам не нужно менять его, потому что оно уже в правильном состоянии.

Answer 4

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

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