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

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

Преимущество:

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

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

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

Ответ 6

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