it-swarm.com.ru

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

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

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

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

На ранней стадии Fragments предполагалось, что они будут использоваться в приложениях для удобной поддержки Tablets и Smartphones одновременно. 

Так, например, у вас есть ListView, который может открыть деталь View при нажатии на элемент. На смартфоне мы заменили бы ListView и вместо этого отобразили бы подробную View. Принимая во внимание, что Tablet вместо замены List на подробное представление может отображать оба Views одновременно.


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

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

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

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


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


Вопросы:

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

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

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

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


Из Udacity: 

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

  1. Увеличение сложности
  2. Сложнее обработка намерений
  3. Трудно читать, поддерживать и тестировать
  4. Риск жесткой связи
  5. Проблемы безопасности
70
Frame91

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

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

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

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

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

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

95
Steven

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

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

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

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

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

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

2
Sherif elKhatib

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

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

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

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

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

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

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

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

Это некоторые случаи,

Спасибо,

2
Huy Tower

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

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

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

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

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

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

1
phemt.latd

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

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

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

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

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

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

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

0
Penguin Blues