Я разработал некоторые приложения для Android, и эти вопросы всегда остаются:
Как мне настроить свой интерфейс? Должен ли я запускать активность после операции и оставлять телефон для создания кнопки "назад", или я должен выбрать более оптимизированный, но более сложный для реализации, способ с переключением вручную "Представления", а затем вручную использовать функциональные возможности "Назад"?
Что вы думаете (или знаете) лучше?
Я бы сказал, что несколько видов деятельности почти всегда имеют больше смысла. Я просто не думаю, что Android предназначен для постоянного переключения своих собственных взглядов - вы так много упускаете. Вы должны реализовать Назад, вы не получаете переходов между активностями, вам нужно реализовать много внутренней логики, чтобы возобновить приложение в правильном состоянии. Если вы не разделяете свое приложение на "Деятельность", это значительно усложняет процесс изменения потока вашего приложения. Это также приводит к одной мега-активности, которая может быть сложнее обрабатывать, чем много меньших фрагментов кода.
Мне трудно представить, что скорость действительно проблема; если это то, что-то не так с тем, как вы инициализируете каждую активность. Например, я использовал попытку передать Serializable объекты между Activity, и это оказалось невероятно медленным; когда я переключился на более быстрый способ передачи объектов, скорость запуска Activities значительно увеличилась.
Кроме того, я думаю, что это говорит о том, что рекомендации Android для Activity and Task Design вообще не упоминают переключения Views; он был сосредоточен вокруг проекта Activity-as-View.
Я хотел бы указать на некоторые случаи, когда отдельное действие может быть лучше разработано для приложения Android, имеющего более одного полноэкранного просмотра.
Если экраны приложения тесно связаны и имеют общий объект, над которым они все работают. В этом случае обход объекта может потребовать пакет и может быть подвержен ошибкам, так как будут его копии. Хорошим примером может быть волшебник. Да, вы можете использовать static для доступа к общему объекту, но static может быть опасным в Android (подумайте об изменениях конфигурации!)
Если вам нужны действительно крутые анимации между экранами. Может быть, вы хотите, чтобы птица взлетела на одном экране и приземлилась на другом экране. Попробуйте сделать это, когда каждый экран - это занятие!
С другой стороны, если один из ваших экранов предназначен для показа любым количеством других приложений, тогда этот экран должен быть его собственной деятельностью.
ОБНОВЛЕНИЕ март 2014:
На данный момент вопрос должен теперь включать выбор фрагментов. Я думаю, что Виды - это, вероятно, наименее вероятный выбор из 3: Активность, Фрагмент, Вид. Если вы хотите реализовать экраны, в которых используется кнопка "Назад", то это должны быть либо "Активности", либо "Фрагменты", поскольку обе кнопки обрабатывают кнопку "назад" изначально. Для работы кнопки "Назад" необходимо добавить фрагменты в стек стека FragmentManager. Управление фрагментами, диалогами и задним стеком может быть немного раздражающим, хотя!
ОБНОВЛЕНИЕ Сентябрь 2018:
Некоторые разработчики в Google рекомендуют отдельные приложения, использующие новый компонент архитектуры навигации.
Также имейте в виду, что реализация вашего приложения с несколькими Activities даст пользователю более последовательный опыт работы с платформой в целом. Часть опыта будет определяться с помощью встроенных приложений Google, поэтому пользователям, вероятно, будет проще использовать приложение, если оно ведет себя так же, как те, которые уже установлены на телефоне.
В отличие от других, я использую смесь обоих, например,
1. При запуске приложения появляется главное меню
2. Вы нажимаете на поиск, вы можете искать активность
3. Затем есть кнопка фильтра, которая просто переключает вид и показывает параметры фильтра.
4. В конце просмотра фильтра есть две кнопки. Вы нажимаете "Поиск" или "Отмена", и вы снова возвращаетесь к поисковому представлению (без активности переключения)
5. Теперь, если пользователь нажимает кнопку "Назад", он возвращается в главное меню вместо параметров фильтра поиска. Я думаю, это правильное поведение.
Используйте его так, как пользователь будет чувствовать себя естественным. И сохранение всего в одном действии сделает его сложным.
Все зависит от приложения, что вы пытаетесь достичь лучшей производительности, более плавного интерфейса. ИМХО. Я предпочитаю второй подход к управлению действиями вручную, даже если он более сложный, как вы заявили. Это подход, который я использовал в своем проекте вкладки Android, также вы можете взглянуть на класс ActivityGroup (не уверен, что пакет), он позволяет вам иметь несколько видов деятельности, которые вы можете переключаться между ними, хорошая вещь об этом классе заключается в том, что ваши действия не выгружаются при переключении, но это плохо, так как загрузка основного приложения занимает больше времени.
Просто мое мнение.
Проблема с переключением просмотров, на которые я наткнулся, также вызвана сборщиком мусора. Кажется, что GC запускается, когда вы оставляете активность, а не вид. Таким образом, изменение вкладок с довольно сложными детскими представлениями, например, почти неизбежно приведет к исключению.
У меня было так много проблем с несколькими макетами активности, что я категорически не одобряю их, если только нет веских причин для их выбора.
Недостаток нескольких видов деятельности
Используя многократные действия, очень трудно реорганизовать код для возврата данных из активности.
Если вы называете "sub" -activity, то основное действие может быть убито. Но вы никогда не испытываете этого при отладке на подходящем устройстве, поэтому вам нужно всегда обрабатывать сохранение состояния и правильное восстановление состояния. Это боль. Представьте, что вы вызываете метод в библиотеке (т.е. Другое действие), и вы должны быть уверены, что когда этот метод возвратит, ваше приложение должно иметь возможность полностью воссоздать свое состояние со всеми полями всех объектов в ВМ (т.е. Активность). restoreIntance). Это безумие.
Также наоборот, когда вы открываете субактивность, виртуальная машина могла быть убита с момента ее появления, например, когда приложение свернуто, когда отображается субактивность.
Намного чище иметь только одно место для хранения соответствующего состояния приложения, и в моем случае, чаще всего, если виртуальная машина убита, я хочу вернуть пользователя на главный экран и позволить ему снова делать свое дело, потому что я не не тратьте 30-50 часов на программирование функций сохранения/возобновления, которые когда-либо испытывали 0,1% пользователей.
альтернатива
Фрагменты или просто управляйте своей деятельностью просматриваете сами. Управление представлениями вручную требует кодирования некоторой альтернативы переключения видов для действий/фрагментов с переходами, если это необходимо.
И нет, это не означает одно мега -activity, как предлагается в принятом ответе, каким-либо иным образом, чем одно мега-приложение. Для этого просто требуется немного больше разработки кодовой базы для подгонки частей, потому что там немного больше работы по управлению представлениями, но гораздо меньше работы по управлению состояниями активности и прочими странностями.
Я работаю над приложением, которое имеет только одно действие. Но я столкнулся с множеством проблем, особенно с map fragment.may, я не обрабатываю фрагмент правильным образом, но я бы предложил несколько действий по активности лучше.