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

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

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

Как вы думаете (или знаете) что лучше?

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

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

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

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

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

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

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

ОБНОВЛЕНИЕ март 2014 г .:

На этом этапе вопрос должен включать выбор фрагментов. Я думаю, что представления, вероятно, являются наименее вероятным выбором из 3: Activity, Fragment, View. Если вы хотите реализовать экраны, которые используют кнопку «Назад», тогда это должны быть Activties или Fragments, потому что оба изначально обрабатывают кнопку «Назад». Чтобы кнопка возврата работала, необходимо добавить фрагменты в задний стек FragmentManager. Однако управление фрагментами, диалогами и задним стеком может быть немного неприятным!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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