Фрагментировать или не фрагментировать - вложенные фрагменты против действий. Почему я должен использовать более одного вида деятельности?

есть много дискуссий о том, следует ли использовать Activities или Fragments. Например:

большинство дискуссий, которые я нашел, были выпущены раньше Android 4.2.
С Android 4.2 Google изобрела вложенные фрагменты.

поэтому я на самом деле не вижу причин больше использовать более одного Activity.

на первом этапе Fragments они должны были использоваться в приложениях для поддержки таблетки и смартфонов в удобном виде в то же время.

так, например, у вас есть ListView, который может открыть деталь View on click on пункт. На смартфоне мы бы заменили ListView и показать детальное View вместо. В то время как планшет вместо замены списка с подробным представлением можно показать оба Views в то же время.

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

кроме этого, Fragments кто вложил Fragments, также хранить информацию для своих детей Fragments.

С Fragments Я могу легко использовать Views, Я могу показать больше, чем один Fragment в то же время и я могу легко сформировать диалог из Fragment. Все это займет у меня, вероятно, не больше, чем просто некоторые действия копирования и вставки.

если я использую Activities вместо этого я серьезно должен многое изменить, чтобы сделать это.

я недавно реализовал приложение где я легко мог бы использовать два Fragment-ViewPager чтобы получить вещи действительно красивые и динамичные (какой - то: сегодняшняя информация-вчерашняя информация). По-моему Fragments сделать нашу жизнь намного легче :)

вопросы:

  • почему я должен использовать более одного Activity?

не могли бы вы привести хороший пример, в котором использование нескольких Activities больше смысла вместо того, чтобы использовать Fragments?

  • есть ли хорошие примеры, когда у вас нет выбора, кроме как использовать Activities?

я думаю, что большинство больших рамок, как карты,YouTube и co уже поддерживают Fragments. Так что нам не придется полагаться на Activities. Также это довольно легко иметь дело с NavigationBar,TabHosts,ViewPager,ActionBar в случае, если вы используете Fragments.

от Udacity:

почему бы не всегда создавать одно действие с большим количеством фрагментов?

  1. Повышенной Сложности
  2. более жесткая обработка намерений
  3. трудно читать, поддерживать и испытаний
  4. риск плотного сцепления
  5. проблемы безопасности
5 70
android android-fragments android-activity

5 ответов:

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

Если у меня есть виджет, который можно повторно использовать в других приложениях, я делаю это фрагмент. Например, мое приложение имеет кнопку" Синхронизация с сервером", и я создал пользовательский фрагмент, который использует индикаторы выполнения для визуального отображения процесса синхронизации. Легко представить себе другое приложение, способное использовать этот виджет, поэтому я разработал его как фрагмент.

Если я переключаю задачи в своем приложении, так что новая задача концептуально независима от предыдущей задачи, то я использую новое действие. Например, на первой странице моего приложения предлагается выбрать пользователя. Как только вы щелкнув по пользователю, я отправляю вас в Главное меню для этого пользователя. Это главное меню для пользователя отображается в новом действии.

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

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

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

94

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

например, вот ситуация, когда несколько видов деятельности имеют смысл. Наши приложения имеют определенную функциональность, которая может быть расширена, если пользователь входит в систему. Однако, пользователь может по-прежнему используйте эту ограниченную функциональность перед входом в систему. Скажем, вы не можете комментировать элементы, за исключением тех случаев, когда вы вошли в систему. В этом случае наша MainActivity может показать всю функциональность. Если пользователь хочет прокомментировать, мы просим его войти в систему, сохранив его запрос и запустив действие LoginActivity, которое обрабатывает вход/регистрацию и устанавливает правильный результат, когда он закончит. В нашем вызывающем фрагменте или действии мы проверяем, является ли результат LOGIN_SUCCESS или если пользователь в настоящее время вошел в систему и служит ожидающий запрос. Я пытаюсь сказать, что поток действий входа в систему должен быть отдельным действием. В противном случае обработка, вероятно, будет перепутано. Таким образом, любое действие, требующее входа в систему, может вызвать startActivityForResult(LOGIN) и сохранить себя как pendingAction. Тогда после установки результата мы могли бы реализовать обработку в супер.onActivityResult. Это все теоретические конечно, можно было бы реализовать логин во фрагменте без проблем. Тем не менее, код будет определенно подвернется под обстрел.

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

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

однако вся ваша "Единая активность хоста" с данными там довольно слабая защита. Действия и близкие фрагменты имеют весь жизненный цикл, который включает экземпляр save/restore через пакеты. Одно действие хоста может быть длительным и содержать несколько фрагментов, которые могут быть повторно использованы несколько раз в течение одного времени жизни их активности. Поэтому весьма вероятно, что деятельность проведение всех этих инстанций со временем превысит свой бюджет ресурсов. Разработчик несет ответственность за сохранение данных в общем контексте, когда они действительно разделяются между несколькими объектами. Это является недостатком такого подхода. В нашем примере не имеет смысла, чтобы MainActivity потреблял дополнительный байт данных, потому что он размещал фрагменты входа, когда он мог спать и освобождал свою память, если это необходимо.

в конце концов, хороший программист может сделать то же самое задача аналогично.

2

вы совершенно правы!

Почему я должен использовать более одного вида деятельности?

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

есть ли хорошие примеры, когда у вас нет выбора, кроме как использовать действия?

Я думаю, что большинство больших фреймворков, таких как Maps, YouTube и co, уже поддерживают фрагменты. Поэтому нам не нужно полагаться на деятельность. Также довольно легко иметь дело с NavigationBar, TabHosts, ViewPager, ActionBar в случае, если вы используете фрагменты.

всегда использовать фрагменты не очень хорошо для раздувания данных в UI, особенно в случае

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

  • или для использования метода onActivityResult для более гибкого, используя деятельность также лучше чем. Ex. Вы можете позвонить FileDialogChooser в вашем приложении.

то есть в некоторых случаях,

спасибо,

2

по вашим вопросам я могу только сказать, что иногда, со сложным пользовательским опытом или сложным приложением, которое должно использовать другой аппаратный компонент, вам нужно использовать activity вместо fragment.

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

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

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

iMeal -https://play.google.com/store/apps/details?id=it.fullsix.chiccopappe

GGRugby - https://play.google.com/store/apps/details?id=it.f6.template

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

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

1

Я знаю, что слишком поздно для этого, но у квадрата есть мнение о фрагментах. Вот суть статьи:

фрагменты: уроки

несмотря на свои недостатки, фрагменты преподали нам бесценные уроки, которые мы теперь можем применить при написании приложений:

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

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

вы можете прочитать его здесь:https://corner.squareup.com/2014/10/advocating-against-android-fragments.html.

вы также можете найти библиотеку минометов площади здесь:https://github.com/square/mortar

0