Навіщо використовувати фрагменти Android?


15

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

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

Фрагменти створюються для того, щоб:

  1. дозволяють Activityвикористовувати багато фрагментів, змінювати між ними, повторно використовувати ці одиниці ... ==> the Fragmentповністю залежить Contextвід діяльності, тому якщо мені потрібно щось загальне, що я можу повторно використовувати і обробляти в багатьох видах діяльності, я можу створити власні власні макети або перегляди ... Мені не буде байдуже цей додатковий рівень розробки складності, який додавали б фрагменти.

  2. краще обробляти з різною роздільною здатністю ==> ОК для планшетів / телефонів у разі тривалого процесу, що ми можемо показати два (або більше) фрагментів в одній і тій же діяльності в таблетках і по одному в телефонах. Але навіщо я завжди використовував фрагменти ?

  3. обробка зворотних викликів для навігації між фрагментами (тобто: якщо користувач увійшов у систему, я показую ще фрагмент, я показую інший фрагмент). ===> Просто спробуйте побачити, скільки помилок у Facebook через SDK увійшов через це, щоб зрозуміти, що це насправді (?) ...

  4. враховуючи, що додаток для Android базується на видах діяльності ... Додавання ще одного життєвого циклу в Активність було б краще розробити додаток ... Я маю на увазі модулі, сценарії, управління даними та підключення, було б краще розроблено, шлях. ===> Це відповідь того, хто звик бачити Android SDK та Android Framework із баченням фрагментів. Я не думаю, що це неправильно, але я не впевнений, що це дасть хороші результати ... І це справді абстрактно ...

====> Чому я ускладнюю своє життя, кодуючи більше, використовуючи їх завжди? інше, чому це найкраща практика, якщо це лише інструмент для деяких випадків? що це за випадки?


1
Незрозуміло, що ви запитуєте, чи не могли б ви підсумувати це питання, можливо, нижче перерахування передбачуваних переваг та вашої критики щодо кожного?
logc

Я додав детальне запитання.
ahmed_khan_89

Я загубився, як @logc. Як би ви вирішили ці випадки без Фрагментів?
neontapir

Я дав те, що можу зробити без фрагментів: (1) створення спеціальних загальних елементів керування та повторне використання їх там, де мені хочеться (2) за допомогою 2-х видів діяльності та навігації за допомогою startActivityForResult, або просто переходу між переглядами (показ / приховування, надув / видалення ...) без кодування так багато ... (3) ви можете використовувати зворотний дзвінок навіть у заходах із переглядами (4) Це абстрактна відповідь, яку я завжди отримую, коли обговорюю цю тему ... що потребує додаткового пояснення ...
ahmed_khan_89

1
Хм. Це питання показує обмеження дизайну stackexchange, коли оригінальний плакат вибирає "найкращу" відповідь. (На відміну від slant.co, де всі голосують.) Не ідеально для такого широкого питання. Тут неясне запитання отримує прийняту відповідь, яка, очевидно, погоджується з тим, що запитувач хотів почути. Якщо ви не бачите причин використовувати фрагмент у своїй ситуації, тоді не робіть цього. Кращим питанням було б запитати плюси / мінуси фрагмента проти активності . І на цю точну тему є багато тем.
ToolmakerSteve

Відповіді:


5

Фрагмент - це модульний розділ діяльності, який має власний життєвий цикл, отримує власні події введення, які ви можете додавати або видаляти під час виконання діяльності (на кшталт "додаткової активності", яку ви можете повторно використовувати в різних видах діяльності)

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

Тепер ...

====> Навіщо мені ускладнювати своє життя, кодуючи більше ... ??

Нехай це не рекомендується, якщо ви не плануєте контролювати життєвий цикл окремих елементів та / або використовувати стан стека або історію попередніх переглядів.


5

Якщо для скептиків фрагментів є варіант використання "шлюзу", ймовірно, це діалоги. Довгохвильовий застарілі методи showDialog(...), onCreateDialog(...)і т.д., були гарні в тому , що рамки будуть називати їх автоматично знищувати і відтворювати діалоги , коли хостинг активність була зруйнована і відновлена. Якщо ви створюєте власні діалоги безпосередньо, вам доведеться самостійно керувати цим вмістом. Але якщо ви використовуєте a DialogFragment, ви можете ще раз дозволити фреймворку керувати ними. У цьому випадку фрагменти можуть значно спростити ваше кодування.


1

Я задавав це питання більше року тому.

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

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

Переваги:

1 / це допомагає модулювати код, де ви можете мати повний потік в одній діяльності, в окремих фрагментах. Приклад: + список / сітка та деталі, + вхід та реєстрація & забути пароль, і т. Д. Це приголомшливо отримати код багаторазового використання, який ви завжди можете скопіювати та пропустити в різних проектах.

2 / у вас новий життєвий цикл, повний клопоту, що правда, але і з перевагами. Приклад: фрагмент збереженого екземпляра є приголомшливим, оскільки він вирішує проблему орієнтації.

3 / ви можете керувати потоком ваших фрагментів за подіями та слухачами з діяльності.

4 / стопка фрагментів вашої діяльності.

5 / використовувати ту саму панель дій на багатьох екранах.

І багато інших ...

Я як і раніше інколи використовую активність як контейнер, особливо це стосується випадку Camera. Деякі API-програми Android та бібліотеки сторонніх виробників непросто реалізувати у фрагментах.

Що ж, це як будь-який інструмент, ви повинні його врахувати і самостійно судити, чи краще його використовувати у тому чи іншому випадку.

Я сподіваюся, що це може допомогти !!!

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.