Android: что лучше - несколько действий или переключение видов вручную?

Question

Я разработал несколько приложений для Android, и эти вопросы остаются всегда:

Как мне структурировать свой интерфейс? Должен ли я запускать активность после активности и оставить телефон, чтобы сделать кнопку «назад», или я должен выбрать более оптимизированный, но более сложный для реализации способ с переключением представлений вручную, а затем вручную выполнить функцию кнопки «Назад»?

Как вы думаете (или знаете), что является лучшей практикой?

Answer 1

Я бы сказал, что несколько видов деятельности почти всегда имеют больше смысла. Я просто не думаю, что Android предназначен для постоянного переключения своих собственных взглядов - вы упускаете так много. Вы должны реализовать Back самостоятельно, вы не получаете никаких переходов между действиями, вам нужно реализовать много внутренней логики, чтобы возобновить приложение в правильном состоянии. Если вы не разбиваете свое приложение на «Действия», в дальнейшем вам будет намного сложнее изменить поток вашего приложения. Это также приводит к одной мега-активности, с которой может быть гораздо сложнее справиться, чем с множеством небольших кусочков кода.

Мне трудно представить, что скорость действительно является проблемой; если это так, значит, что-то не так с инициализацией каждого действия. Например, я использовал попытку передать Сериализуемые объекты между Деятельностями, и это оказалось невероятно медленным; когда я переключился на более быстрый способ прохождения объектов, скорость запуска действий значительно возросла.

Кроме того, я думаю, что это говорит о том, что руководящие принципы Android для Activity и Task Design вообще не упоминают переключение видов; он сосредоточен вокруг дизайна «активность как вид».

Answer 2

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

• Если экраны приложений тесно связаны и имеют общий объект, над которым они все работают. В этом случае обход объекта может потребовать пакет и может быть подвержен ошибкам, так как будут его копии. Хорошим примером может быть волшебник . Да, вы можете использовать static для доступа к общему объекту, но static может быть опасным в Android (подумайте об изменениях конфигурации!)

• Если вам нужны действительно крутые анимации между экранами. Может быть, вы хотите, чтобы птица взлетела на одном экране и приземлилась на другом экране. Попробуйте сделать это, когда каждый экран - это занятие! ​​

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

ОБНОВЛЕНИЕ Март 2014:

На данный момент вопрос должен включать выбор фрагментов. Я думаю, что Представления, вероятно, являются наименее вероятным выбором из 3: активность, фрагмент, представление. Если вы хотите реализовать экраны, в которых используется кнопка «Назад», то это должны быть либо «Активности», либо «Фрагменты», потому что оба обрабатывают кнопку «Назад» изначально. Для работы кнопки «Назад» необходимо добавить фрагменты в стек стека FragmentManager. Управление фрагментами, диалогами и задним стеком может немного раздражать!

ОБНОВЛЕНИЕ Сентябрь 2018:

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

Answer 3

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

Answer 4

В отличие от других я использую смесь обоих, например,
1. При запуске приложения появляется главное меню
2. Вы нажимаете на поиск, принимает вас к поисковой деятельности
3. Затем есть кнопка фильтра, которая просто переключает вид и показывает опции фильтра
4. В конце представления фильтра находятся две кнопки. Вы нажимаете «Поиск» или «Отмена» и снова возвращаетесь к представлению поиска (без переключения активности)
5. Теперь, если пользователь нажимает кнопку возврата телефона, он возвращается в главное меню вместо параметров фильтра поиска. Что я думаю, это правильное поведение.

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

Answer 5

Все зависит от приложения, что вы пытаетесь добиться лучшей производительности, более плавного интерфейса. ИМХО, я предпочитаю второй подход управления действиями вручную, даже если он более сложный, как вы заявили. Это подход, который я использовал в своем проекте вкладок Android, также вы можете взглянуть на класс ActivityGroup (не уверен, что пакет), он позволяет вам иметь несколько действий, между которыми вы можете переключаться, что хорошо в этом классе в том, что ваши действия не выгружаются при переключении, но плохо, что загрузка основного приложения занимает больше времени.

Только мое мнение.

Answer 6

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

Answer 7

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

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

При использовании нескольких действий очень трудно реорганизовать код для возврата данных из действия.

Если вы называете «под-действием», то основное действие может быть убито. Но вы никогда не испытываете этого при отладке на приличном устройстве, поэтому вам нужно всегда обрабатывать сохранение состояния и правильное восстановление состояния. Это боль. Представьте, что вы вызываете метод в библиотеке (т. Е. Другое действие), и вы должны быть уверены, что когда этот метод возвратит, ваше приложение должно иметь возможность полностью воссоздать свое состояние со всеми полями всех объектов в ВМ (т. Е. Действия. restoreIntance). Это безумие.

Также наоборот, когда вы открываете субактивность, виртуальная машина могла быть убита с момента ее появления, например, когда приложение свернуто во время отображения субактивности.

Гораздо чище просто иметь одно место для хранения соответствующего состояния приложения, и в моем случае, чаще всего, если ВМ убита, я хочу вернуть пользователя на главный экран и позволить ему снова делать свои вещи, потому что я не трачу 30-50 часов на программирование функций сохранения / возобновления, с которыми когда-либо сталкивались 0,1% пользователей.

Alternative

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

И нет, это не означает одно мега-действие, как предлагается в принятом ответе, каким-либо иным образом, чем одно мега-приложение. Для этого просто требуется немного больше разбора кодовой базы на подгонки, потому что немного больше работы по управлению представлениями, но гораздо меньше работы по управлению состоянием активности и прочими странностями.

Возможно, актуально: Reddit: официально: Google официально рекомендует архитектуру приложения с одним действием