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

Ответ 1

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

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

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

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

- EDIT -

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

Ответ 2

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

Pros

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

против

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

Ответ 3

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

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

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

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

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

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

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

Ответ 4

Pros

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

Против

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

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

Ответ 5

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

Ответ 6

Плюсы:

• Может использоваться для создания единого интерфейса, используемого несколькими размерами экрана и ориентациями с помощью макетов xml.

Минусы:

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

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

Ответ 7

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

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

Ответ 8

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