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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

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

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

В некоторых случаях

Спасибо,

Ответ 4

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

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

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

Наиболее вероятной ситуацией, которая требует использования большей активности и фрагмента, является пользовательский опыт приложения. Если вам нужен правильный ящик, который содержит меню, и каждый фрагмент меню содержит 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

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

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

Ответ 5

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

Фрагменты: извлеченные уроки

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

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

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

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

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