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

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

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

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

Примечание:

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

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

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

Плюсы:

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

Минусы:

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

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

Это зависит от приложения, которое вы создаете. Я создал несколько приложений, используя оба подхода, и не могу сказать, что один способ всегда лучше другого. В последнем приложении, которое я создал, я использовал единый 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

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

Pros

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

Cons

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

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

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

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

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

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

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

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

Pros

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

Cons

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

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

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

Плюсы:

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

Минусы:

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

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

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

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

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