Два пользовательских интерфейса панели с фрагментами и отдельными действиями

Я запускаю приложение Honeycomb, которое будет иметь базовое расположение двух панелей, одну панель слева для меню и одну справа для основных функций каждого раздела.

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

Заманчиво просто заменить правый фрагмент в соответствии с выбранным разделом, но это будет означать использование всего одного действия во всем приложении, и это не очень хорошо. Более того, жизненный цикл фрагмента привязан к активности, поэтому никакие фрагменты не будут убиты до тех пор, пока активность не будет убита, что приведет к большому количеству фрагментов «живой».

Однако, имея различную активность с двумя панелями для каждого пункта меню, означает, что фрагмент, используемый для меню, должен быть добавлен в КАЖДОЙ активности и будет подвергаться несогласованным макетам во всех разделах, которые должны иметь меню.

Каковы лучшие практики здесь?

В этом блоге кратко излагаются причины выбора фрагментов над действиями:

Встроенная деятельность через ActivityGroup была хорошей идеей, но с ней всегда было трудно справиться, поскольку Activity была создана как самостоятельный автономный компонент, а не тесно взаимодействует с другими действиями. API-интерфейс Fragment – это гораздо лучшее решение для этого, и его следует рассматривать как замену встроенных действий.

Сохранение данных через экземпляры Activity может быть выполнено через Activity.onRetainNonConfigurationInstance (), но это довольно klunky и неочевидно. Фрагмент заменяет этот механизм, позволяя вам сохранить весь экземпляр фрагмента, установив флаг.

Специализация Фрагмента, называемого DialogFragment, позволяет легко показать диалог, который управляется как часть жизненного цикла Activity. Это заменяет API-интерфейсы «управляемого диалога».

Другая специализация Фрагмента, называемая ListFragment, позволяет легко отображать список данных. Это похоже на существующее ListActivity (с несколькими дополнительными функциями), но должно уменьшить общий вопрос о том, как показать список> с некоторыми другими данными.

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

Структура имеет встроенную поддержку для управления back-stack объектов Fragment, что позволяет легко обеспечить внутризадачное поведение кнопки «Назад», которое объединяет существующий стек предыдущей активности. Это состояние также автоматически сохраняется и восстанавливается.

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


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