Одно задание и все остальные фрагменты [закрыто]


158

Я думаю о реализации одного экрана с Activityдругими экранами с помощью Fragmentsи managing all the fragments thru the activity.

Это хорошая идея? и мой ответ НЕТ, но все же я хочу знать более четко об этой мысли.

Каковы плюсы и минусы идеи?

Примечание:

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

РЕДАКТИРОВАТЬ:

Вот кое-что над Фрагментами и деятельностью:

Плюсы:

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

Минусы:

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

Зачем нам использовать фрагменты, если мы не рассматриваем планшеты? Какая разница во времени между активностью и фрагментом?


Можете ли вы уточнить, почему вы считаете, что ответ отрицательный? Я не согласен, но легче решить проблемы, которые могут возникнуть у вас по поводу этого подхода, если мы знаем, что это за проблемы.
Александр Лукас

1
@AlexanderLucas Ответ, который я не дал, потому что это делает ваш код менее модульным, увеличивает сложность.
Vineet Shukla

@Ski Вы больше концентрируетесь на получении ответа, пожалуйста, сконцентрируйтесь на том, что спрашивают, и какой ответ должен быть лучшим, который вы можете предоставить.
Vineet Shukla

3
Для тех, кто находит это, я остановил рефакторинг, потому что все очень быстро усложнилось.
theblang

18
Это хороший вопрос, и его не следовало закрывать.
Джим в Техасе

Ответы:


94

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

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

То, что Аравинд говорит о привязанности к одному Activityтипу, также верно, но на самом деле это не ограничение. Ваша деятельность будет FragmentActivity, и пока вы не нуждаетесь в MapViewней, реальных ограничений нет. Однако если вы хотите отображать карты, это можно сделать, но вам нужно либо изменить библиотеку совместимости Android, чтобы она FragmentActivityрасширялась, MapActivityлибо использовать общедоступные android-support-v4-googlemaps .

В конечном счете большинство разработчиков, которых я знаю, пошли одним Activityпутем и вернулись к множеству Деятельностей, чтобы упростить их код. UI мудро, на планшете, вы несколько раз застряли, используя один Activityтолько для того, чтобы добиться какого-то безумного взаимодействия, которое придут ваши дизайнеры :)

-- РЕДАКТИРОВАТЬ --

Google наконец-то выпустил MapFragmentбиблиотеку совместимости, так что вам больше не нужно использовать хак с android-support-v4-googlemaps. Об обновлении читайте здесь: Google Maps Android API v2

- РЕДАКТИРОВАТЬ 2 -

Я только что прочитал этот замечательный пост о современном (2017) состоянии фрагментов и вспомнил этот старый ответ. Думал, что поделюсь: Фрагменты: решение всех проблем Android


6
Там settargetfragmentи вы могли бы обрабатывать действия как startforresultпроцедуры.
Лалит Б

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

1
Подводя итог минусы фрагментов - только вы даете, на самом деле их нет. У startActivityForResult, как говорит Лалит Б, есть аналог, и с картами это тоже не проблема. Кроме того, все (сохранение состояния и т. Д.) Может быть обработано методами жизненного цикла фрагмента.
Ixx

85

Я собираюсь закончить проект (5 месяцев в разработке), который имеет 1 действие и 17 фрагментов, все на весь экран. Это мой второй проект на основе фрагментов (предыдущий был 4 месяца).

Pros

  • Основным видом деятельности является 700 строк кода, просто красиво управляя порядком навигации по фрагментам.
  • Каждый фрагмент красиво разделен на собственный класс и относительно небольшой (пара сотен строк пользовательского интерфейса).
  • Менеджмент может сказать: «Эй, как насчет того, чтобы мы изменили порядок этих экранов», и я могу сделать это очень легко, поскольку эти фрагменты не зависят друг от друга, все они общаются через действие. Мне не нужно копаться в отдельных действиях, чтобы найти, где они называют друг друга.
  • мое приложение очень сильно загружено графикой и никогда не будет работать как 1 экран 1 действие. Все эти вспомогательные действия в памяти приводят к тому, что приложению все время не хватает памяти, поэтому мне придется выполнять finish()все невидимые действия и выполнять ту же логику управления для навигации, что и для фрагментов. Можно сделать это с фрагментами только из-за этого.
  • если мы когда-нибудь сделаем приложение для планшета, у нас будет время перефакторинга, потому что все уже хорошо разделено.

Cons

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

1
Я не был уверен в том, что у нас слишком много фрагментов и только сейчас в работе ... какие-то проблемы на производстве, и вина на тебе !! :)
Шахар

1
@Dinash не позволяйте ОС возобновить вашу деятельность. справиться с изменением ориентации самостоятельно. читайте больше здесь: stackoverflow.com/questions/5913130/…
Тамас

1
@Tamas У вас были какие-нибудь многофрагментные экраны (например, master-detail), и если да, то как вы справились с этим?
theblang

7
@ Тамас Этот подход сильно анти-Android. Вы в конечном итоге с классом БОГА. Система Android предназначена для работы с действиями - например, у вас нет хорошего способа работать с панелями инструментов в нескольких фрагментах. У вас нет стартового фрагмента для результата, и многие другие не имеют. Это означает, что вы должны переписать всю логику, которая уже есть. Как насчет местных вещательных приемников, услуг и других компонентов Android. Чтобы запустить сервис, вы должны сделать следующее: getActivity ()! = Null ... это действительно ужасно. Также связь между фрагментами очень странная, если у вас много фр.
Теодор

9
700 строк !!!! "приятно"???? Занятия бесплатные.
beplaya

16

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

Что на самом деле обеспечивают действия и фрагменты?

  1. События жизненного цикла и backstack
  2. Контекст и ресурсы

Поэтому используйте их ТОЛЬКО для этого . У них достаточно ответственности, не усложняйте их. Я бы сказал, что даже создание TextView в Activity или Fragment является плохой практикой. Есть причина, по которой методы типа public View findViewById (int id) являются PUBLIC .

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

В конце концов, вы можете сделать свой собственный backstack и жизненные циклы. Но зачем воссоздавать колесо?

РЕДАКТИРОВАТЬ: Зачем голосовать против? Одноразовые занятия людей! Каждое действие или фрагмент должны иметь возможность создавать презентатора, который создает представление. Презентатор и представление являются модулем, который можно взаимозаменять. Почему за действия или фрагменты отвечает ведущий?


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

ИМХО: если вы передадите actvity своему представителю и докладчику (назвав 2 вместе «модулем»), вы включите повторное использование этого модуля с другими активностями. Если это помогает, лучше всего передать эту деятельность в качестве объекта, который подвергается воздействию только необходимых вещей. Если вам не нравится находить взгляды за пределами действия, то вы можете внедрить все взгляды через этот интерфейс в pres./view. Суть в том, что я верю, что Android-кодирование должно быть сделано вне концепции Actvities и Frags, так что переключение между двумя - это легко. Затем становится ясно, что самое лучшее, и вы не застряли ни с тем, ни с другим внутри сети код.
beplaya

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

12

Pros

Вы можете контролировать свои фрагменты из одного действия, потому что все фрагменты независимы друг от друга. Фрагменты имеют жизненный цикл ( onPause, onCreate, onStart...) свои собственные. Имея жизненный цикл, фрагменты могут независимо реагировать на события, сохранять их состояние onSaveInstanceStateи возвращаться (например, при возобновлении после входящего вызова или когда пользователь нажимает кнопку возврата).

Cons

  1. Создайте сложность в вашем коде деятельности.
  2. Вы должны управлять порядком фрагментов.

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


2

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


1

Плюсы:

  • Может использоваться для создания единого интерфейса, пригодного для использования с несколькими размерами экрана и ориентациями через макеты XML.

Минусы:

  • Требуется более сложный код в вашей деятельности.

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


Для ориентации не обязательно использовать разные макеты на основе XML.
Vineet Shukla

@VineetShukla true, но это вариант, так же, как использовать различные макеты XML в зависимости от размера экрана. Например, домашний экран моего телефона Android имеет разную компоновку, когда я смотрю на него в горизонтальной или вертикальной ориентации.
Ски

0

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

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


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

-1

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


4
Я не верю, что это правда. Из документации по жизненному циклу фрагмента ( developer.android.com/guide/components/fragments.html#Lifecycle ): «Жизненный цикл действия, в котором находится фрагмент, напрямую влияет на жизненный цикл фрагмента, так что каждый обратный вызов жизненного цикла для действия приводит к аналогичному обратному вызову для каждого фрагмента. Например, когда действие получает onPause (), каждый фрагмент в действии получает onPause (). "
Ski
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.