Зачем использовать фрагменты?

В чем преимущество использования Fragment с использованием пользовательских View , которые повторно используются в разных макетах?

В оригинальном блоге, представляющем фрагменты , Диана Хакборн говорит, что

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

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

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

Жизненный цикл Fragment :

onAttach() , onCreate() , onCreateView() , onActivityCreated() , onStart() , onResume() , onPause() , onStop() , onDestroyView() , onDestroy() , onDetatch() .

Жизненный цикл View :

ctor , onFinishInflate() , onAttachedToWindow() , onMeasure() , onLayout() , onDetatchedFromWindow()

Я хотел бы услышать от разработчиков, имеющих опыт написания больших приложений о том, какие преимущества (если они есть) они видели при использовании Fragments vs custom Views для разделения пользовательского интерфейса на многоразовые фрагменты.

Solutions Collecting From Web of "Зачем использовать фрагменты?"

Основная причина заключается в том, что фрагменты более многоразовые, чем пользовательские.

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

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

Обратите внимание, что пользовательский пользовательский интерфейс не может полностью инкапсулировать эту функциональность, потому что ему придется полагаться на запуск startActivityForResult Activity, поскольку представления не принимают результаты деятельности (они могут косвенно запускать намерение через контекст).

Теперь, если вы хотите повторно использовать свой пользовательский компонент интерфейса в разных действиях, вы будете повторять код для Activity.startActivityForResult.

Фракция, с другой стороны, решительно решает эту проблему.

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

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

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

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

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

Обновление Feb 2016 : Хотя выше все еще верно, есть сложности с фрагментами, которые заставили многих людей полностью избежать их использования. Более новые шаблоны, такие как использование подходов MVC и более мощные представления, предоставляют альтернативы. Как говорится … YMMV.

Некоторое описание:

Представьте себе активность как тарелку, в которой есть один большой торт. Фрагмент будет контейнером, который нарезает один и тот же пирог на кусочки. Каждый фрагмент содержит свои собственные логики (слушатели и т. Д.). И в целом они почти не отличаются от одного большого пирога.

Выгода:

  1. Когда вы не можете держать большой торт. (Экран невелик) Вы можете легко использовать несколько пластинок (Activity) для хранения каждого из них БЕЗ необходимости переместить свои логики в новую активность.

  2. Лучшее повторное использование. У меня есть некоторые случаи, когда я могу полностью использовать фрагмент в другом приложении. Вы можете утверждать, что это может сделать и пользовательский вид. Но обратитесь к пункту 1, я мог бы использовать его только с несколькими строками изменений макета, но для пользовательского представления он должен найти способ подключить его как к макету, так и к коду.

  3. Это, в некотором смысле, более OO способ организации логики пользовательского интерфейса в Android-программировании. Когда у вас есть функция (например, новый раздел на экране), вы создаете новый класс фрагментов с незначительной модификацией существующего класса активности. Однако, если вы программируете только с активностью, вам нужно будет добавить логику и внести большую модификацию в тестируемый класс.

Только мои 2 цента. 🙂

Методы жизненного цикла, вероятно, являются вашим самым большим намеком. Если вы думаете об этом, они тесно связаны с жизненным циклом деятельности (с некоторыми крючками в активности и представлениях). Фактически, в статье, которую вы связали, Хакборн говорит:

В некотором смысле вы можете представить фрагмент как мини-активность

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

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

Использование фрагментов также позволяет вам разделить компоненты на свои классы (фрагменты), а не иметь слишком много логики в одном действии. Позвольте мне обосновать это на примере:

Скажите, что вы применяете приложение для чтения журналов. Используя фрагменты, вы можете создать фрагмент: ArticleList, который отображает список статей и другой фрагмент: ArticleDisplay, который обрабатывает логику отображения содержимого. Вы можете указать, каким образом эти фрагменты должны взаимодействовать с помощью инструментов фрагментов, так что на телефоне вы можете использовать полноэкранную недвижимость для ArticleDisplay, а на планшете вы можете отображать фрагменты бок о бок.

Если бы вы попытались сделать это с помощью Activity / custom view, у вас была бы логика для обоих фрагментов в вашей монолитной деятельности, вам пришлось бы написать собственное представление, и вам пришлось бы отлаживать этого громоздкого монстра.

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

Однажды я коснулся фрагментов и нашел их не очень полезными (см. Этот пост ). Из того, что я прочитал, A Fragment – действительно причудливое слово для объекта с доступом к Контексту активности . Мне нравится игнорировать фрагменты в моей работе и просто создавать эти объекты самостоятельно. Я создал очень большие, очень требовательные приложения, передав Activity вместо конструктора вместо Context . Одно из основных преимуществ использования Fragments заключается в том, что они поддерживаются системой макета View, поэтому вы можете легко добавить их в Android xml (если вы используете его для своих макетов).