Я думаю о реализации одного экрана с Activity
другими экранами с помощью Fragments
и managing all the fragments thru the activity
.
Это хорошая идея? и мой ответ НЕТ, но все же я хочу знать более четко об этой мысли.
Каковы плюсы и минусы идеи?
Примечание:
Пожалуйста, не дайте мне ссылку на фрагмент и активность.
РЕДАКТИРОВАТЬ:
Вот кое-что над Фрагментами и деятельностью:
Плюсы:
- Фрагменты предназначены для использования с действиями в качестве вспомогательного действия.
- Фрагменты не являются заменой деятельности.
- Фрагменты предназначены для повторного использования (необходимо знать, каким образом можно обеспечить повторное использование.).
- Фрагменты - лучший способ написать код для поддержки планшетов и телефонов.
Минусы:
- Нам нужно реализовать интерфейс для получения данных из фрагментов.
- Для диалога мы должны пройти долгий путь, чтобы показать это.
Зачем нам использовать фрагменты, если мы не рассматриваем планшеты? Какая разница во времени между активностью и фрагментом?
Ответы:
Это зависит от приложения, которое вы создаете. Я создал несколько приложений, используя оба подхода, и не могу сказать, что один способ всегда лучше другого. В последнем приложении, которое я создал, я использовал единый
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
источник
settargetfragment
и вы могли бы обрабатывать действия какstartforresult
процедуры.Я собираюсь закончить проект (5 месяцев в разработке), который имеет 1 действие и 17 фрагментов, все на весь экран. Это мой второй проект на основе фрагментов (предыдущий был 4 месяца).
Pros
finish()
все невидимые действия и выполнять ту же логику управления для навигации, что и для фрагментов. Можно сделать это с фрагментами только из-за этого.Cons
источник
Во-первых, что бы вы ни делали, убедитесь, что у вас есть модульная конструкция с использованием модели, представления, презентатора, которая не сильно зависит от действия или фрагмента.
Что на самом деле обеспечивают действия и фрагменты?
Поэтому используйте их ТОЛЬКО для этого . У них достаточно ответственности, не усложняйте их. Я бы сказал, что даже создание TextView в Activity или Fragment является плохой практикой. Есть причина, по которой методы типа public View findViewById (int id) являются PUBLIC .
Теперь вопрос становится проще: нужно ли мне несколько независимых событий жизненного цикла и backstacks? Если вы думаете, что да, возможно, используйте фрагменты. Если вы никогда не думаете, не используйте фрагменты.
В конце концов, вы можете сделать свой собственный backstack и жизненные циклы. Но зачем воссоздавать колесо?
РЕДАКТИРОВАТЬ: Зачем голосовать против? Одноразовые занятия людей! Каждое действие или фрагмент должны иметь возможность создавать презентатора, который создает представление. Презентатор и представление являются модулем, который можно взаимозаменять. Почему за действия или фрагменты отвечает ведущий?
источник
Pros
Вы можете контролировать свои фрагменты из одного действия, потому что все фрагменты независимы друг от друга. Фрагменты имеют жизненный цикл (
onPause
,onCreate
,onStart
...) свои собственные. Имея жизненный цикл, фрагменты могут независимо реагировать на события, сохранять их состояниеonSaveInstanceState
и возвращаться (например, при возобновлении после входящего вызова или когда пользователь нажимает кнопку возврата).Cons
Тем не менее, это довольно хорошая идея, как будто вам нужно создать приложение, в котором вы хотите показать несколько просмотров. По этой идее вы сможете просматривать несколько фрагментов в одном представлении.
источник
Это зависит от дизайна вашего приложения. Предположим, если вы используете вкладки в ActionBar в макете дизайна, то в Single Activity приложения можно изменить фрагменты при нажатии Tab. Итак, теперь у вас есть Activity и, скажем, предположим, что в ActionBar есть три вкладки, и представление для вкладок, предоставляемых фрагментами, облегчает управление плюсом. Итак, все зависит от схемы дизайна вашего приложения и от того, как вы принимаете решение о его создании.
источник
Плюсы:
Минусы:
Я считаю, что это хорошая идея, потому что использование различных макетов xml, основанных на текущем размере экрана и ориентации, может сделать приложение более удобным и снизить необходимость выпуска нескольких версий приложения, если вы планируете выпустить приложение как для телефонов, так и для планшетов. Если ваше приложение никогда не будет использоваться как на планшетах, так и на телефонах, оно, вероятно, не стоит того.
источник
Я сторонник того, чтобы отложить все виды инфляции на фрагменты, чтобы обеспечить большую гибкость. Например, наличие одной операции посадки для планшета, которая объединяет несколько фрагментов, и повторное использование одних и тех же фрагментов в телефоне для отображения одного экрана на фрагмент. Однако в реализации телефона у меня было бы отдельное действие для каждого экрана. Действия не будут иметь слишком много кода, поскольку они сразу же передадут свой фрагмент фрагмент для просмотра инфляции.
Я думаю, что для реализации телефона плохой идеей является переход к одной операции приземления при появлении вкладок или выдвижного меню, поскольку навигация по вкладкам или меню просто приводит к появлению совершенно нового экрана.
источник
Самая важная причина, по которой я бы не использовал подход с одним действием, заключается в том, чтобы использовать жизненный цикл действия. Действия содержат контекстное поведение определенной части приложения, а фрагменты дополняют это поведение. Возможность воспользоваться преимуществами переопределяемых шагов в жизненном цикле действия помогает отделить поведение одного действия от другого с помощью таких методов, как
onPause
иonResume
. Этот жизненный цикл также позволяет вам вернуться к предыдущему контексту. При подходе с одним действием, когда вы оставляете фрагмент, вы должны создать механизм, чтобы вернуться к нему.источник