Двухпанельный пользовательский интерфейс с фрагментами против отдельных действий
Я запускаю Honeycomb-приложение, которое будет иметь базовую двухпанельную компоновку: одну панель слева для меню и одну справа для основных функций каждого раздела.
В отличие от доступных примеров API фрагментов, содержимое, отображаемое на правой панели, состоит из совершенно другого пользовательского интерфейса для каждого из пунктов меню.
Заманчиво просто заменить нужный фрагмент в соответствии с выбранным разделом, но это будет означать использование только одного действия во всем приложении, и это не звучит хорошо. Более того, жизненный цикл фрагмента привязан к активности, поэтому никакие фрагменты не будут убиты до тех пор, пока активность не будет уничтожена, в результате чего многие фрагменты "оживают".
Однако наличие разных действий с двумя панелями для каждого параметра меню означает, что фрагмент, используемый для меню, должен быть добавлен в КАЖДОЕ действие и будет подвержен противоречивым макетам во всех разделах, которые должны иметь меню.
Каковы лучшие практики здесь?
1 ответ
В этом блоге кратко изложены причины выбора фрагментов вместо действий:
Встроенная активность через ActivityGroup была хорошей идеей, но с ней всегда было трудно иметь дело, поскольку Activity разработана как независимый автономный компонент, а не тесно взаимодействует с другими действиями. Fragment API - гораздо лучшее решение для этого, и его следует рассматривать как замену встроенных операций.
Сохранение данных в экземплярах Activity может быть выполнено с помощью Activity.onRetainNonConfigurationInstance(), но это довольно сложно и неочевидно. Fragment заменяет этот механизм, позволяя вам сохранить весь экземпляр Fragment, просто установив флаг.
Специализация Fragment, называемая DialogFragment, упрощает показ диалога, который управляется как часть жизненного цикла Activity. Это заменяет API "управляемого диалога" в Activity.
Другая специализация Fragment, называемая ListFragment, позволяет легко отображать список данных. Это похоже на существующий ListActivity (с несколькими дополнительными функциями), но должно уменьшить общий вопрос о том, как отображать> список с некоторыми другими данными.
Информация обо всех фрагментах, в настоящее время прикрепленных к действию, сохраняется для вас платформой в сохраненном состоянии экземпляра действия и восстанавливается для вас при перезапуске. Это может значительно уменьшить объем кода сохранения и восстановления состояния, который вам нужно написать самостоятельно.
Инфраструктура имеет встроенную поддержку для управления бэк-стеком объектов Fragment, что позволяет легко обеспечить поведение кнопки "Назад", которое интегрирует существующий бэк-стек активности. Это состояние также сохраняется и восстанавливается автоматически.
Фрагменты довольно новы, поэтому, помимо этой статьи, я не уверен, что вы найдете много для лучших практик. Я думаю, что решение, которое вам нужно принять, заключается в том, что мои взаимодействия тесно связаны и предназначены для обмена данными, или они представляют собой отдельные компоненты, которые не имеют большого взаимодействия.
редактирование, уточнение: я думаю, что использование одного действия для приложения не обязательно является плохим решением. Это действительно решение, которое вы должны принять на основе функциональности вашего приложения. Исходя из статьи, действие является отдельным, а фрагмент, как правило, имеет значение только в сочетании с другими фрагментами в области действия. Ситуация, которую вы описываете, с комбинациями различных действий, является одной из болевых точек, которые они разработали для решения фрагментов.