Android: Що краще - кілька заходів або перемикання поглядів вручну?

Я розробив кілька додатків для Android, і це питання залишається завжди:

Як я повинен структурувати інтерфейс користувача? Чи слід запускати активність після активності та залишати телефон для створення кнопки «назад», або я повинен вибрати більш оптимізований, але більш складний у застосуванні спосіб перемикання вручну вручну, а потім вручну виконувати функцію «Назад»?

Як ви думаєте (чи знаєте), що є кращою практикою?

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

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

Крім того, я вважаю, що це говорить про те, що в інструкціях для Android щодо діяльності та дизайну завдань взагалі не згадується про переключення переглядів; він зосереджений навколо дизайну "Огляд діяльності".

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

• Якщо екрани програм щільно з'єднані та мають спільний об'єкт, над яким вони працюють. У цьому випадку для проходження навколо Об'єкта може знадобитися пакет і може бути схильний до помилок, оскільки його копії будуть. Хорошим прикладом може бути майстер . Так, ви можете використовувати static для доступу до загального об'єкта, але статичний може бути небезпечним для Android (думаю, що зміни конфігурації!)

• Якщо ви хочете по-справжньому круті анімації між екранами. Можливо, ви хочете, щоб птах злетів в один екран і приземлився в інший екран. Спробуйте зробити це, коли кожен екран - це діяльність!

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

ОНОВЛЕННЯ Березень 2014 року:

На даний момент питання тепер має включати вибір фрагментів. Я думаю, що Перегляди, мабуть, найменш вірогідний вибір із 3: Діяльність, Фрагмент, Вид. Якщо ви хочете реалізувати екрани, на яких використовується кнопка "Назад", тоді це повинні бути "Активісти" або "Фрагменти", оскільки обидва спрацьовують із кнопкою "Назад". Фрагменти потрібно буде додати до заднього стека FragmentManager, щоб кнопка "Назад" працювала. Управління фрагментами, діалогами та зворотним стеком може дещо роздратувати!

ОНОВЛЕННЯ вересня 2018 року:

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

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

На відміну від інших, я використовую суміш обох, наприклад,
1. Є головне меню, коли програма запускається.
2. Ви натискаєте на пошук,
переходить до пошукової діяльності 3. Потім є кнопка фільтра, яка просто перемикає погляд і показує ви фільтруєте параметри
4. У кінці подання фільтра є дві кнопки, ви натискаєте "Пошук" або "Скасувати", і ви знову повертаєтесь до перегляду пошуку (без переключення активності)
5. Тепер, якщо користувач поверне телефон назад кнопку він повертається до головного меню замість опцій фільтра пошуку. Я думаю, що це правильна поведінка.

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

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

Просто моя думка.

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

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

Недолік декількох видів діяльності

Використовуючи численні дії, важко переробити код рефактора для повернення даних від активності.

Якщо ви називаєте "суб-активність", то основна діяльність може бути знищена. Але ви ніколи не відчуваєте, що під час налагодження на гідному пристрої, значить, вам потрібно обробляти завжди збережений стан і правильно відновити стан. Це біль. Уявіть, що викличте метод у бібліотеці (тобто іншу діяльність), і вам слід переконатися, що при поверненні цього методу додаток повинен мати змогу повністю відтворити його стан з усіма полями на всіх об'єктах VM (тобто діяльність. RestoIntance). Це божевільно.

Також навпаки, коли ви відкриваєте субактивність, VM, можливо, був убитий з моменту появи першої підозрілості, наприклад, коли програма мінімізована під час відображення субактивності.

Це набагато чистіше, щоб просто було одне місце для зберігання відповідного стану додатків, і в моєму випадку, найчастіше, якщо VM вбита, я хочу повернути користувача на головний екран, і дозволити їм робити свої речі знову, тому що я не хочу не витрачаю 30-50 годин на кодування функцій збереження / відновлення, які коли-небудь відчують 0,1% користувачів.

Альтернатива

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

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

Можливо, це стосується: Reddit: Офіційно: Google офіційно рекомендує архітектуру додатків для однієї активності