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

Я думаю про реалізацію одного екрана з Activityта всіх інших sreens з 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маршрутом, повернулися до кількох заходів, щоб спростити свій код. Інтерфейс, розумний, на планшеті ви кілька разів зациклюєтесь на використанні єдиного, Activityщоб досягти того, що коли-небудь шалена взаємодія ваших дизайнерів придумала :)

- EDIT -

Нарешті, Google вийшов MapFragmentу бібліотеку сумісності, тому вам більше не доведеться використовувати хак для android-support-v4-googlemaps. Про оновлення читайте тут: API Google Maps Android v2

- EDIT 2 -

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

Я збираюся закінчити проект (5 місяців у розробці), який має 1 активність та 17 фрагментів, весь на весь екран. Це мій другий фрагментний проект (попередній - 4 місяці).

Плюси

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

Мінуси

• ви повинні навчитися використовувати фрагменти

По-перше, що б ви не робили, переконайтеся, що у вас є модульний дизайн, використовуючи модель, перегляд, презентатор, який не сильно залежить від діяльності чи фрагмента.

Що насправді забезпечують діяльність та фрагменти?

1. Події з життєвого циклу та backstack
2. Контекст і ресурси

Тому використовуйте їх для цього, ТІЛЬКИ . Вони несуть достатню відповідальність, не надто ускладнюйте їх. Я можу стверджувати, що навіть інтанізація TextView у діяльності чи фрагменті є поганою практикою. Існує причина такої методи, як public View findViewById (int id) - ПУБЛІЧНІ .

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

Врешті-решт, ви могли б скласти власний задник та життєві цикли. Але, навіщо відтворювати колесо?

EDIT: Чому за це голосують? Люди з єдиною ціллю! Кожна активність або фрагмент повинен мати можливість створювати презентацію, який створює подання. Презентатор і перегляд - це модуль, який можна змінювати. Чому за діяльність або фрагмент повинен відповідати ведучий ??

Плюси

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

Мінуси

1. Створіть складність у своєму коді діяльності.
2. Ви повинні керувати порядком фрагментів.

Тим більше, що це дуже гарна ідея, як якщо б вам потрібно створити додаток, де ви хочете показати кілька переглядів. За допомогою цієї ідеї ви зможете переглянути кілька фрагментів в одному огляді.

Це залежить від дизайнерського макета вашої програми. Припустимо, якщо ви використовуєте Tabs у ActionBar у дизайнерському макеті, то в Single Activity додатку можна змінити фрагменти, що змінюються при натисканні Tab. Отже, тепер у вас є активність і скажіть, припустимо, три вкладки в панелі ActionBar і вигляд вкладок, які надаються фрагментами, що дозволяє легко керувати плюсом, також можливо. Отже, все залежить від схеми дизайну вашого додатка і того, як ви приймаєте рішення для його створення.

Плюси:

• Може використовуватися для створення єдиного інтерфейсу, який може бути використаний у кількох розмірах та орієнтаціях екрана через макети xml.

Мінуси:

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

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

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

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

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