Как разработчики, иногда мы склонны настраиваться на нашем пути. Мобильный телефон, вероятно, является одним из самых быстро меняющихся ландшафтов в сфере ИТ, поэтому с технической точки зрения можно простить за то, что он придерживается старых, надежных способов решения тех же проблем, вместо того, чтобы прыгать на подножку для каждой новой библиотеки, архитектуры или прославленного эксперимент.
Однако, несмотря на то, что пользователи не имеют возможности узнать, как устарели некоторые решения, они должны заметить, насколько современен внешний вид программного обеспечения и насколько хорошо работает наше приложение. С системой, на которой он работает. Позвольте мне поболтать о некоторых пользовательских функциях Android, которые, на мой взгляд, все еще постыдно недоиспользуются или не используются нами, разработчиками приложений. Принятие новых UX-трендов является важным шагом в эволюции платформы, и мы должны коллективно постараться добиться большего, чтобы мы могли предложить новый и более последовательный опыт нашим пользователям в 2020 году.
Обладая более чем десятилетним опытом поддержки экранов с любым возможным соотношением сторон, мультиокно произвольной формы не должно быть чем-то новым для Android. Тем не менее, большинство приложений не справляются с этим должным образом.
В настоящее время у нас есть Chromebook с приложениями для Android в окнах с изменяемыми размерами. Samsung DEX делает то же самое (точнее, один пользовательский интерфейс имеет функцию «всплывающего окна», которая даже не требует внешнего монитора). Даже редактор макетов Android Studio позволяет нам перетащить угол окна предварительного просмотра и проверить, как будет выглядеть макет для любого возможного соотношения сторон. В общем, время для android: screenOrientation = ”Portrait” и android: resizableActivity = ”false” прошло , так как связывать руки пользователям просто нельзя. Нам нужны интерфейсы, которые могут быстро и изящно адаптироваться к любому размеру в любой момент времени без потери состояния.
Изменение размера окна всегда должно сохранять состояние экрана, но компоновка может перестраиваться, чтобы лучше использовать преимущества нового размера.
Многие из библиотек Jetpack облегчают эту задачу. Оставить слой данных полностью отделенным от представления - безусловно, самый простой способ сделать это, и ViewModel был специально создан для этой цели. Если уделить дополнительное внимание тщательной обработке событий жизненного цикла, это также поможет устранить потенциальные проблемы. Еще одна вещь, которая может нарушить восстановление состояния, - неправильный backstack фрагмента, то, что компонент Navigation может абстрагировать.
При реализации реального пользовательского интерфейса ConstraintLayout должен быть нашим лучшим другом вместе с квалификаторами ресурсов для более экстремальных случаев. На экранах, отображающих списки, еще одним полезным инструментом может быть GridLayoutManager с динамическим счетчиком диапазонов.
Учитывая все вышесказанное, поддержка многооконного режима произвольной формы является более сложной задачей для команды разработчиков, чем для нас, поскольку продуманная архитектура имеет побочный эффект правильного сохранения и восстановления состояния экрана после изменений конфигурации.
Отображение надрезов и пробивных камер, занимающих ценные области экрана, является новой проблемой, о которой мы действительно не просили… Но опять же, отказ от ощущения, будто мы убегаем от этой проблемы, и мы лучше этого! Последние API-интерфейсы позволяют нам рисовать любой контент под системными панелями, дополняя важные части информации, в зависимости от вставок экрана, с удивительно малой работой.
Хотя содержимое отображается на всей поверхности дисплея, 3D-камера фокусируется на центре используемой области (отмеченной пересечением двух белых диагоналей), динамически определяемой вставками окна.
Библиотека Insetter от Chris Banes инкапсулирует сложность переопределения метода dispatchApplyWindowInsets () пользовательской корневой ViewGroup или написания нашего собственного OnApplyWindowInsetsListener . Мы не должны забывать, что, поскольку мы не хотим блокировать приложение в портретной ориентации (см. Предыдущий раздел), нам приходится иметь дело не только с верхней и нижней вставками окна, но и со всеми четырьмя из них.
Давайте также рассмотрим установку атрибута android: windowLayoutInDisplayCutoutMode темы приложения в shortEdges : это будет способствовать распространению пользовательского интерфейса под вырезом экрана и в альбомном режиме (в отличие от поведения по умолчанию, которое делает это только в портретном режиме и возвращается к почтовому ящику в ландшафтном режиме). ). Более подробную информацию об этом можно найти здесь .
Результатом минимальных усилий по получению этого права станет захватывающее приложение, которое в полной мере использует всю доступную площадь экрана, а не окружено уродливыми черными полосами.
Если ваш драгоценный брендинг работает только на ослепительном белом фоне, я не собираюсь открывать ваше приложение после заката. Поскольку все больше и больше дизайнов охватывают темную сторону Материала , те, кто отказывается это делать, торчат, как больной большой палец. То же самое можно сказать и наоборот: некоторые пользователи предпочитают дневную тему (на которую, несмотря на все недавние темные шумихи, было бы удобнее смотреть, особенно под прямыми солнечными лучами). Решение ясное: пользователям нужны варианты, поэтому мы могли бы также поддерживать оба предпочтения темы на ранней стадии разработки.
Приложение с поддержкой темных и светлых тем
Лучше поздно, чем никогда: ночной режим больше не скрывается в настройках разработчика. Теперь любой желающий может в любое время переключить свои предпочтения между светлыми и темными темами, но результаты, к сожалению, не соответствуют ожидаемым (даже в случае приложений Google). iOS здесь далеко впереди: один главный переключатель влияет на каждое приложение, в то время как в нашем случае отдельные реализации очень противоречивы.
Мы попали в ту же ловушку, что и при написании кода, который взламывает настройки языка пользователя на уровне системы: кажется, что каждое приложение начало использовать свои собственные пользовательские средства выбора тем. Являются ли это проблема является спорной, но давайте по крайней мере согласиться, чтобы добавить опцию по умолчанию, чтобы следовать глобальным настройкам системы.
Реальная реализация поддержки двойных тем, опять же, не очень сложна для совершенно нового проекта, но может быть довольно большим усилием для унаследованного. В ночь и notnight отборочных ресурсов, вероятно, лучшие места , чтобы начать на, при использовании пользовательских атрибутов вместо прямых ссылок цвета является также то , чтобы рассмотреть.
Заставка вообще не является новой концепцией, но будет первой вещью, которую пользователи видят в наших приложениях, а не просто правильно их реализовывать, до боли очевидна.
У вас может быть красивая 5-секундная вступительная анимация, которую вы хотели бы запихивать в лица пользователей каждый раз, когда они запускают ваше приложение. Или вам может потребоваться загрузить некоторые данные, прежде чем вы сможете отобразить что-либо значимое. Если вы когда-либо добавляли экран с единственной целью - заблокировать пользователю быстрый доступ к основному экрану, я прошу вас взглянуть на календарь и пересмотреть, так как есть более эффективные способы решения этих проблем.
Заставка не должна задерживать запуск приложения.
Приложения Android загружаются некоторое время, прежде чем вызывается метод onCreate () первого действия. В это время на экране рисуется фон окна приложения. Лучший экран-заставка - это просто настраиваемый фоновый рисунок (возможно, список слоев) для темы, который переопределяется в момент создания первого действия (путем вызова setTheme () перед super.onCreate ( )). Вы можете найти очень простой пример здесь: Activity , Manifest , файл темы , всплывающее окно .
Хотя есть много других аспектов успешного современного приложения, я чувствую, что вышеперечисленные четыре, вероятно, применимы к любому виду проектов Android (даже к играм - передумайте!). Можно рассматривать их как основные требования для плавной интеграции опыта, который обеспечивает их приложение, в общий внешний вид Android.
Хотя реализация некоторых из этих вещей требует дополнительных усилий по планированию и проектированию, я бы хотел сказать, что это не то, к чему мы должны быть консервативны. Результатом создания приложений, которые кажутся естественной частью ОС, станет более зрелая экосистема, к которой мы все должны стремиться.