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

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

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

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

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

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

Ответ 1

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

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

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

Специализация фрагмента называется DialogFragment позволяет легко показать Диалог, который управляется как часть Жизненный цикл деятельности. Это заменяет Управляет API-интерфейсами с управляемым диалоговым окном.

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

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

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

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

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