Flutter: прокачиваем AppBar & SliverAppBar
Во Flutter для создания панели инструментов используется хорошо всем известный AppBar, ну а когда нам нужна динамическая панель инструментов, которая покажет контент при свайпе, мы используем отличный виджет SliverAppBar.
Оба виджета позволяют сделать приложение чуточку красивее, что во Flutter, без сомнений, весьма просто.
Я видел много вопросов на StackOverflow и в группах Facebook о том, как можно изменить AppBar и SliverAppBar с точки зрения поведения или дизайна.
Давайте рассмотрим две задачи.
Задача 1
Мы хотим создать, не привинченный к верху экрана AppBar, но не так как делаем это обычно. Мы хотим добавить Drawer (боковое меню), на открытие которого AppBar будет реагировать. Вот и всё: наш собственный AppBar с нужными нам размерами.
Проблема в том что, как мы знаем, у AppBar есть размер по умолчанию, и изменить его мы не можем. Заглянув в исходный код, мы видим параметр appBar в Scaffold, видим, что он принимает виджет типа PreferredSizeWidget, теперь просматриваем исходный код AppBar и узнаём, что это только StatefulWidget, который реализует PreferredSizeWidget.
Дело за малым: просто создать наш собственный виджет, который реализует PreferredSizeWidget.
Как бы так сделать, чтобы при нажатии кнопки меню нашего AppBar открывалось боковое меню.
Мы можем сделать это двумя способами:
Используя `AppBar`
Вот так AppBar сможет контролировать открытие бокового меню внутри Scaffold.
Используя кастомный виджет
Здесь у нас больше гибкости и можно использовать GlobalKey типа ScaffoldState или InheritedWidget от Scaffold, получив таким образом доступ к методам состояния для открытия Drawer.
Результат
Просто, не так ли? Давайте рассмотрим вторую задачу для SliverAppBar.
Задача 2
Как мы знаем, SliverAppBar работает следующим образом:
Что мы хотим, так это поместить Card, встроенную в наш SliverAppBar, как показано на следующем рисунке.
Подождите, но содержимое внутри SliverAppBar обрезается, поэтому не может выйти за рамки, что же делать?
Без паники, давайте посмотрим исходный код SliverAppBar и, о сюрприз, это StatefulWidget, использующий внутри SliverPersistentHeader, вот и весь секрет.
Мы создадим свой собственный SliverPersistentHeaderDelegate, чтобы использовать SliverPersistentHeader.
Результат
Готово, обе задачи решены.
Вывод
Часто мы отчаиваемся, когда не находим каких-нибудь свойств у виджета, но надо лишь посмотреть его исходный код, чтобы понять как он реализован во Flutter, открыв для себя таким образом варианты реализации собственных виджетов.
День шестой. Application Bar
Вступление
Коснувшись значка, вы можете перейти на нужную страницу. При этом сами значки остаются на месте. По сути это схоже с полоской меню в обычных настольных приложениях.
Добавляем Application Bar (XAML)
Если вы создаете новый проект, то там уже есть заготовка для добавления Application Bar в приложение. Вам нужно снять комментарии с кода в файле MainPage.xaml file. Вернемся к нашему примеру и уберем комментарии:
Если вы создаете проект с нуля, то кроме указанного выше кода необходимо добавить пространства имен в (не забудьте установить также ссылки):
После того, как вы уберете комментарии, в программе появятся два значка на панели приложения. Запустите проект, чтобы убедиться в этом. Всего в Application Bar может содержаться от 1 до 4 значков. Высота панели равна 72 пикселам.
Кстати обратите внимание, что в коде для значков указаны пути к изображениям (напр. /Images/appbar_button1.png), которые не являются частью проекта. Если вы запустите проект, то в Application Bar будут выводиться значки X для ApplicationBarIconButtons. Безусловно, вы можете создать собственные значки, добавить их в проект и использовать их в своей программе. Но можно пойти другим путем и использовать уже готовые значки для этих целей. Откроем проект в Expression Blend и найдем объекты ApplicationBarIconButton в дереве объектов Objects and Timeline.
Щелкните на одном из них и изучите вкладку Properties.
Щелкнув по выпадающему списку IconUri, вы можете выбрать из множества предопределенных значков. Также вы можете задать текст для кнопок панели приложения.
Пусть вас не пугает, что стандартные значки имеют белый цвет на черном фоне. Если в телефоне будет использоваться светлая тема (о темах говорилось в прошлом занятии), то значки поменяют свой цвет на противоположный автоматически.
Вам нужно взять это на заметку, если собираетесь использовать собственные значки. О том, как создавать подобные значки, мы поговорим в одной из наших статей.
События для Application Bar
Теперь неплохо бы заставить кнопки-значки реагировать на наши действия. Добавим событие Click и его обработчик в коде.
Кроме значков на Application Bar вы можете видеть три точки (. ). Если коснуться в этом месте, то откроется дополнительная выдвижная панель с текстовым меню. Повторное касание троеточия закроет панель. Сейчас там мы видим команды menuutem 1 и menuitem 2. Поступаем с ними аналогичным образом:
В отличие от значков на панели, текстовых команд может быть больше и при этом поддерживается прокрутка.
Управляем прозрачностью Application Bar
Можно использовать свойство Opacity для изменения прозрачности панели. Если значение Opacity равно 1, то панель непрозрачна, если установить значение «0.5», то панель станет полупрозрачной.
Системная область
Дополнительные сведения
Есть несколько значков панели приложения, которые устанавливаются вместе с Windows Phone Developer Tools. Вы можете найти эти значки в одном из следующих мест:
Если вам необходимо создать собственный значок панеди приложения, то он должен соответствовать следующим требованиям:
Vuetify — создаем свое простое приложение
Хоть UI библиотек или фреймворков для Vue.js не так уж и много, но Vuetify как раз здесь больше всего выделяется и по функционалу просто впереди других. Сегодня в этой небольшой статье я расскажу об данном UI фреймворке, его особенности, его структура и вообще к чему его можно применять. И честно в интернете не так уж и много русскоязычных материалов под данной теме, поэтому я решил что-то написать по Vuetify.
P.S. Вот сыллка на GitHub с кодом приложения.
Введение/Установка
Окей, представим что вы решили все таки начать пользоваться Vuetify и написать какое-то своё первое приложение используя его. И начинается все конечно же с установки, для начала давайте создадим новое Vue CLI приложение с помощью npm:
Важно, надо чтобы приложение имело версию Vue 2.0, поскольку на время написания этой статьи в Vuetify поддержка идёт только для Vue 2.0 приложений. После того как нового приложение было создано — следующим шагом будет установить UI фреймворк как плагин:
Нас попросит в дальнейшем выбрать какой-то пресет, и поскольку мы не собираемся пробовать версию V3 (которая нестабильна), то мы выбираем пресет “Default”:
Когда процесс установки Vuetify завершиться, то можно будет запустить локальный сервер приложения:
И открыв https://localhost:8080 мы увидим по-умолчанию созданную страницу от Vuetify с полезными сыллками:
Как мы видим то все работает и самое время начать уже писать наше приложение.
Так о чем же будет наше приложение?
Хороший вопрос, ведь мы создали уже Vue CLI приложение и установили Vuetify, но я так и не сказал что же будет делать именно наше приложение. Мой любимый пример, это мобильное приложение по доставке еды — поэтому давайте это будет тема нашего приложения.
Но перед этим давайте также установим Vue Router:
Как обычно при добавлении нового плагина к приложению, терминал может сказать что есть изменения которые не были добавлены в commit, мы здесь пишем “y” (т.е. yes) и двигаемся дальше:
Дальше при установке нас спросит хотим ли использовать режим истории в маршутизации, и здесь мы также тыкаем “y”:
Вот теперь Vue Router установлен, и самое время убрать код примеров в src/router/index.js чтобы когда мы сейчас запустили снова локальный сервер — не было ошибок:
Файл маршутизации теперь настроен и не содержит в себе каких-то несуществующих маршрутов, ну а теперь нужно также почистить файл App.vue:
Хорошо, теперь мы настроили наши два файла и при запуске не будет никаких ошибок — а самое лучшее это то — что мы можем начинать разрабатывать наше приложение.
Layout
В Vuetify уже есть своя придуманная гибкая система построения сетки в приложении. И давайте сейчас с ней ознакомимся. Для начала нам нужно будет воспользоваться двумя компонентами, это v-app и v-main. Открываем App.vue и добавляем их:
С компонента v-app и начинается наше приложение, этот компонент является псевдонимом тега
Окей, список у нас есть, а с помощью каких компонентов от Vuetify будем его выводить? Сейчас воспользуемся компонентом v-card, который позволяет удобно в карточках выводить подобную информацию. Но при этом мы также воспользуемся Bootstrap Vue чтобы элементы красиво располагались на странице.
Многие могут заметить что в row’e где мы уже выводим сами карточки заведения с помощью v-for в компоненте v-col я добавляю атрибут md=”4«. Те кто учили Bootstrap уже должны догадаться для чего нужен этот атрибут и как именно он задает размеры колонок. С помощью этого атрибута я указал чтобы каждая колонка имела размеры 4/12 и благодаря этому на странице карточки будут выводиться по 3 штуки в один ряд. Окей, компонент вывода заведений готов, надо теперь добавить его маршрут в файл src/router/index.js:
А теперь давайте перейдем на локальный сервер и посмотрим на результат вывода:
На декстоп и на мобайл выглядит нормально, можем двигаться дальше
Супер У нас есть вывод заведений на главной странице. А теперь я думаю самое время добавить отдельную страницу заведения, которая будет открываться при клике на заголовок карточки. Поскольку у нас нету базы данных с которой мы могли бы брать определенное заведение через API — то сама страница будет статичной.
Страница просмотра заведения
Для начала создаём компонент src/components/CafeView.vue и первое что в нем будет выводиться это изображение с заведением, его заголовок и описание. Для этой базовой информации мы создадим отдельный компонент с названием CafeInfo.vue, но перед этим заполним уже чем-то компонент CafeView.vue:
Хорошо, а теперь создаём компонент CafeInfo.vue:
Для удобства я специально поместил данные в data функцию. Теперь когда наш компонент готов — самое время сделать маршрут для компонента CafeView.vue в src/routes/index.js:
Окей, а теперь давайте посмотрим как это выглядит вместе на локальном сервере на url http://localhost:8080/cafe/view:
Вид можно было б ещё больше кастомизировать чтобы выглядело намного красивее. Но пусть будет так с стилями Vuetify по-умолчанию. Теперь давайте также пропишем сыллку на переход на эту страницу в List.vue:
В массив объектов заведений можно было бы ещё добавить отдельное поле url, которое хранило в себе линки на страницу заведения — но поскольку само приложение у нас статичное, то мы сделали именно так. Вывода такой информации на странице заведения — недостаточно. Нужно ещё реализовать компонент вывода меню товаров (еды) заведения. Поэтому для этого мы сейчас создадим отдельный компонент CafeMenu.vue.
Компонент меню заведения
Сначала создайте компонент src/components/Cafe/CafeMenu.vue, и внутри него сначала создаем переменную с массивом внутри которого будут объекты с информацией об товарах:
Рекомендую также добавить другие товары в список. А теперь самое время вывести их в отдельной колонке:
С помощью компонента v-list-item-group мы создали список, внутри которого с помощью v-for в v-list-item вывели список всех товаров. Компонент v-list-item-content используется для того чтобы выводить контент самого элемента списка, в нашем случае мы выводим заголовок (v-list-item-title) и цену (с помощью v-list-item-subtitle). А с помощью v-list-item-action, внутри мы добавили кнопку покупки товара (v-btn), атрибут icon мы добавили чтобы указать что внутри кнопки выводиться только иконка.
Внутри v-icon мы указали иконку от Material Design. Окей, теперь когда я объяснил что к чему — можем подключить данный компонент:
Открываем локальный сервер и смотрим на результат:
Круто, но нашему приложению не хватает менюшки в хедере очень сильно. Поэтому давайте её сейчас добавим.
Создание навигации
Сейчас нам нужно перейти в компонент App.vue и добавить новый компонент v-navigation-drawer:
Этот компонент позволяет создавать меню навигации, я специально прописал атрибут left чтобы пустое меню навигации появилось с левой стороны:
Выглядит немного страшновато, но сейчас мы это пофиксим. Добавлю также что v-navigation-drawer является одним из компонентов layout системы Vuetify, и именно он отвечает за меню навигации. Давайте добавим следующий код чтобы это меню срабатывало при клике на иконку в хедере:
Зачем я добавил атрибуты absolute, temporary и v-model в v-navigation-drawer? Во-первых, absolute задает CSS свойство position: absolute; а это позволит сделать так чтобы эта менюшка и на мобайл хорошо отображалась. Во-вторых, temporary задает z-index для навигации — чтобы другие элементы не залазили на неё.
И во-третьих, v-model имеет в себе переменную drawer, которая в зависимости от значения true или false будет показывать меню. К примеру, если переменная drawer равняется в текущую момент значению true — то менюшка будет показываться. Если false, то менюшка будет спрятана. Если вы сейчас перейдете на локальный сервер — то увидите в хедере иконку и при клике на неё будет вылазить наше меню:
Вот здесь мы и можем увидеть иконку в хедере А при клике на саму иконку вылазит пустое меню с левой стороны
Теперь нужно чем-то заполнить меню, для этого создадим сейчас отдельную переменную с пунктами для меню:
А теперь выведем все это внутри v-navigation-drawer:
Готово, теперь если мы откроем меню то увидим следующее:
И вот у нас есть менюшка которая выглядет не прям красиво, но она работает и позволяет уже переходить на страницы. Окей, и что у нас получается? У нас есть простое приложение с выводом заведений, и просмотром этих заведений. Все это довольно таки примитивно — то мы смогли уже сделать что-то с Vuetify.
32 отличия дизайна мобильного приложения под iOS и Android
Железный дизайнер из Redmadrobot Design Lab Артур Абраров делится наблюдениями.
Адаптировать дизайн под другую платформу — неотъемлемая часть работы дизайнера мобильных приложений. Цель этой работы — органично вписать дизайн в паттерны взаимодействия пользователя. К тому же, проработанная адаптация упрощает разработку за счёт использования нативных компонентов платформы.
Чтобы адаптировать дизайн правильно, нужно соблюдать гайдлайны платформ: Human Interface Guidelines (HIG) у iOS и Material Design у Android. И общаться с разработчиками, в идеале подключать их к дизайну как можно раньше, чтобы они могли сразу задать технические ограничения.
Но в чём именно отличается дизайн под iOS от дизайна под Android? В этой статье я разберу 32 конкретных отличия дизайна под iOS и Android. Они поделены на четыре группы:
Базовые отличия
Human Interface Guidelines vs Material Design
Почти все отличия этой статьи взяты из анализа этих гайдлайнов. Их суть на идейном уровне следующая. HIG — это про плоский, лёгкий, дружелюбный дизайн, пришёл он из постепенного отказа от скевоморфизма.
Material же имеет несколько основополагающих принципов: материал как метафора; смелый, графический, сознательный; осмысленная анимация; гибкая основа и кроссплатформенность. Если вы не знакомы с гайдлайнами, лучше их прочесть до того, как ознакомитесь со статьёй.
2. Единицы измерения: pt vs dp
Дизайн iOS-приложения создаётся в pt, а Android-приложения — в dp. Мы, как правило, создаём дизайн в 1x (или mdpi) и выгружаем в Zeplin. Zeplin отображает для iOS дизайн в pt и генерирует иконки и иллюстрации в 2х и 3х. Под Android отображает дизайн в dp и генерирует графику в hdpi, xhpdi, xxhdpi и xxxhdpi.
3. Размер экрана: 320 pt x 568 pt vs 360 dp x 640 dp
Предпочитаю проектировать iOS-приложение под наименьший размер — iPhone 5 с размером экрана 320pt х 568pt. Делаю это, чтобы избежать некорректного отображения контента на маленьких экранах. Некоторые предпочитают проектировать под iPhone 8.
Под Android есть общепринятый размер экрана — 360dp х 640dp.
При дизайне под iOS иногда создаю дизайн и под iPhone X (375pt х 812 pt). Это нужно, чтобы разработчик понимал, как правильно расставить отступы у экрана этого размера. Ещё при дизайне под iPhone X нужно помнить про Safe area — зону, вне которой не стоит размещать контент.
4. Системный шрифт: San Francisco vs Roboto
5. Android Navigation Bar
В отличие от iOS, у Android есть встроенный инструмент навигации назад. Это Android Navigation Bar.
Он либо физически встроен в смартфон, либо является частью интерфейса. С помощью стрелки пользователь перемещается на один шаг назад в хронологической последовательности (reverse chronological navigation). Навигация происходит как внутри приложения, так и между ними.
В начале профессионального пути в качестве дизайнера мобильных приложений я долго мучил Android-разработчиков вопросом: зачем нужны две кнопки назад? Одна есть внизу в Navigation Bar, вторая появляется в Top App Bar при переходе на дочернюю страницу.
Ответ такой. Есть два вида навигации назад: reverse chronological navigation (её осуществляем с помощью стрелки назад в Navigation Bar, зовем её Back).
И upward navigation (её осуществляем с помощью верхней стрелки, зовем её Up).
Представим, что у нас есть путь A-B-C, где A — это материнская страница, а B и С — дочерние. Представим, что пользователь попал напрямую из A в С. Если он нажмёт на кнопку Back, то вернётся на A. Но если нажмёт Up, то сначала попадёт на B — и уже по второму нажатию попадёт на A.
Это сложно реализовать и путанно для пользователя, поэтому сейчас эти две кнопки назад осуществляют одинаковое действие back, как в iOS. То есть если пришли из A в С, то из С вернёмся обратно в А.
6. Важность Elevation в Material
В iOS принципиально нет теней. Как исключение, тени можно обнаружить на главном экране App Store и в Health. Но в целом HIG никак не прописывает использование теней.
В Material тени играют большую роль. Они добавляют интерфейсу третье пространство (ось Z), за счёт чего у каждого компонента появляется своё строгое место на этой оси (от 0 dp до 24 dp). Причём эта ось Z существует не просто на идейном уровне: у разработчиков есть параметр elevation, в котором они задают положение компонента по этой оси.
Навигация и смена состояний сопровождается изменением elevation компонентов. Поэтому при дизайне под Android нам стоит осознанно подходить к созданию теней.
7. Отличия в нейминге
Отличий в нейминге много. Предлагаю рассмотреть эти пять.
a. Tab Bar vs Bottom Navigation Bar
| |
b. Navigation Bar vs Top App Bar
Этот bar у обеих платформ выполняет примерно одинаковые задачи: сообщает пользователю его текущее местоположение в приложении, даёт возможность вернуться на предыдущий экран и предлагает одно или несколько контекстных действий. Подробнее об отличиях — ниже в статье.
c. Segmented Controls vs Tabs
| |
d. Alerts vs Dialogs
Интересно, что в iOS описан только один инструмент предупреждения пользователя — Alerts. В Android их три: Snackbars, Banners и Dialogs.
Snackbar предназначен для сообщений низкой приоритетности и не требует действий. Dialogs блокирует взаимодействие с интерфейсом и требует совершить действие. Banners находятся между ними: не блокирует взаимодействие, но требует совершить действие.
| |
e. Touch ID vs Android Fingerprint
 | |
Отличия в навигации и паттернах (UX)
8. Способы верхнеуровневой навигации
Начнём с самого верха. iOS рекомендует только один способ верхнеуровневой навигации — через Tab bar. У Android в ответ есть три способа: Navigation Drawer, Bottom Navigation Bar и Tabs.
Если количество верхнеуровневых страниц больше пяти, используем Navigation Drawer. Если меньше — Bottom Navigation Bar. Tabs нечасто применяют для этой навигации, но способ нам доступен. Однако Material рекомендует не совмещать Tabs и Bottom Navigation Bar, так как взаимодействие с данными компонентами влияет на контент страницы и пользователь может запутаться.
9. Отличия в поведении Tab Bar и Bottom Navigation Bar
Это отличие предлагает Material.
Если вы в iOS перейдёте от материнской страницы к дочерней, потом через Tab Bar переключитесь на другую материнскую страницу, то по возвращении на первую материнскую страницу вы всё также будете находиться на дочерней.
В Android всё строже — при переключении через Bottom Navigation Bar вы всегда переключаетесь между материнскими страницами. Если до этого вы были на дочерней, она сбросится.
Наши разработчики Android уверены, что такое поведение системы неверное. В случае переключения по Bottom Navigation стоит сохранять открытые дочерние страницы, как на iOS.
10. Особое поведение Tabs у Android
| |
Это потому, что страницы табов находятся на одной высоте (elevation).
Это важно знать потому, что при использовании табов в Android нам не стоит добавлять в дизайн элементы с похожими жестами. Например, карусель картинок или взаимодействие с карточками с помощью свайпов.
| |
В целом эти два компонента не заменяют друг друга полностью. Segmented control — это control, который управляет контентом страницы. А Tabs — инструмент навигации.
Поэтому стоит советоваться с разработчиками перед тем, как при адаптации рассматривать их как равноценные компоненты. Иногда корректнее заменять андроидовские Tabs на Page Control. Всё зависит от контекста.
11. Отличия в появлении дочернего экрана
В iOS появление дочернего экрана (не считая модалок) происходит только одним образом: дочерняя страница появляется справа поверх материнской с эффектом slide in. Возвращение на материнский экран происходит с эффектом slide out.
Material рекомендует показывать пользователю иерархическую взаимосвязь материнской и дочерней страницы с помощью осмысленной анимации.
Компонент, при взаимодействии с которым пользователь переходит к дочерней странице, раскрывается и покрывает собой материнскую страницу. Так пользователь понимает, откуда и куда он перешёл, почему это произошло и куда он вернётся при нажатии на кнопку «Назад».
Переход происходит с помощью Standard Easing.
| |
12. Особый паттерн вызова Navigation Drawer
При проектировании приложения с Navigation Drawer важно помнить, что этот компонент «забирает» себе жест edge swipe слева вправо. Поэтому не стоит добавлять этому жесту другую логику.
В iOS у этого жеста есть устоявшийся паттерн перехода с дочерней на материнскую страницу. Этот паттерн постепенно перекочевал и во многие андроидовские приложения.
13. Поведение контента при скролле
По HIG контент в iOS при скролле ведёт себя так: Navigation Bar уменьшается в ширине, исчезает Tool Bar. Но в целом iOS-разработчики могут настроить любое поведение контента и баров при скролле.
Material предлагает больше вариантов поведения при скролле. Например, Bottom Navigation Bar, Search и Bottom App Bar при скролле могут исчезать.
| |
Top App Bar может либо исчезать, либо подниматься выше основного контента.
Разное поведение поиска
Интересно, что HIG относит поиск к барам и называет его Search Bar. В Material мы находим поиск в разделе Navigation, не в Components. То есть для Material поиск — это ещё один способ навигации.
Как в iOS, так и в Android поиск может статично присутствовать на экране и, как правило, прибит к Navigation Bar или Top App Bar.
| |
На обеих платформах поиск может быть в виде иконки, только в iOS иконка раскрывается в самостоятельный компонент Search Bar, а в Android поиск раскрывается внутри Top App Bar.
| |
Особенность поиска в iOS — его можно «спрятать» под Navigation Bar и вызывать по жесту Swipe down. Такой же жест типичен и для рефреша (pull to refresh), поэтому не стоит вызывать поиск и рефреш по этому одному действию.
Отличия в компонентах (UI)
15. Каких компонентов нет в iOS
В iOS нет многих нативных компонентов Android. Пробежимся по ним.
a. Navigation Drawer
iOS в принципе не признаёт бургер-меню. Как говорили раньше, в iOS верхнеуровневая навигация только по Tab Bar.
b. Backdrop
Backdrop — самый удивительный для меня компонент в Material. На момент написания статьи Android ещё только планирует реализовать его как нативный. В целом при изучении компонентов Material стоит проверять, доступны ли они уже для использования.
Сам Material любит этот компонент. Посмотрите, например, на победителей Material Design Award 2019.
c. Banner
Banner не найти среди нативных компонентов iOS. С помощью Banner мы сообщаем пользователю важную информацию и предлагаем связанные с ней действия.
d. Snackbar
Как и Banner, Snackbar — не нативный для iOS. Snackbar применяют, чтобы донести до пользователя короткое сообщение о результате его действия.
e. Chips
Chips также отсутствует среди нативных компонентов iOS. Они используются для ввода информации, описания и действия.
f. Bottom App Bar
Тут можно поспорить, что у iOS есть похожий компонент — Tool Bar. Но они разные, вот почему: Toolbar — это бар для контекстных действий. Например, при редактировании списка сообщений в Messages появляется Tool Bar с действиями Read All и Delete.
Bottom App Bar — это перемещение Top App Bar вниз с теми же действиями верхнего уровня: открытие Navigation Drawer, вызов поиска и так далее. Ещё в Bottom App Bar мы размещаем FAB.
g. FAB
Да, FAB тоже нет в iOS. FAB — это кнопка для совершения основного действия на экране. Например, в почтовом приложении FAB будет создавать новое письмо.
Если вы используете в Android FAB для основного действия на экране, то в iOS это основное действие стоит разместить наверху в Navigation Bar справа (смотри пример: iMessages).
h. Bottom Navigation Drawer
Разновидность Navigation Drawer, типичная только для Android. Вызывается нажатием кнопки бургер-меню в Bottom App Bar.
i. Side Sheet
Хоть Material и разрешает использовать этот компонент в мобильном приложении, я бы рекомендовал заменить его на более привычный Bottom Sheet.
j. Expanding Bottom Sheet
Этот очень красивый компонент Android не найти среди нативных для iOS. Expanding Bottom Sheet — это поверхность, которая прибита к низу страницы. При нажатии поверхность расширяется до полноценной страницы.
k. Standard Bottom Sheet
Standard Bottom Sheet — разновидность Bottom Sheet, и его нет среди компонентов iOS.
16. Каких компонентов нет в Android
Теперь рассмотрим, каких компонентов не найти в библиотеке Android.
a. Page Controls
Page Control показывает, на какой из страниц находится пользователь. Его нет среди нативных компонентов Android.
b. Toolbar
Toolbar привычен только для iOS.
c. Steppers
Steppers — стандартный control iOS, не описан в Material. Используем его для ввода небольших значений. Пример: количество копий при печати.
d. Popover
Popover — всплывающая панель, которая в основном используется на iPad.
В iOS есть одно стандартное применение Popover — настройка текста в ридерах или браузерах.
17. Разные Status Bar
| |
Ещё у Status Bar Android есть такая особенность, когда приходит уведомление из приложения, в Status Bar появляется иконка этого приложения. В iOS такого нет.
18. Refresh Content Controls vs Swipe to refresh
Рефрешеры вызываются одним и тем же жестом swipe down на обеих платформах. Но в iOS Refresh Content Control «толкает» остальной контент вниз, в то время как Swipe to refresh у Android появляется поверх контента. Кроме того, рефреш iOS при скроле контента исчезает, а у Android остаётся видимым.
19. Разные Control
| |
Ещё Material предлагает использовать родительский чекбокс, когда нужно дать пользователю возможность быстро выбрать все варианты.
20. Разный вид стрелки «Назад» и положение заголовка
| |
21. Разный вид иконки трёх точек
| |
22. Разный вид Picker
В iOS выбор даты происходит с помощью барабана. Барабан iOS можно использовать для ввода любых других данных. В Android Picker даты имитирует вид физического календаря.
Material также рекомендует давать пользователям возможность вводить дату с помощью Input Field-а.
23. Разные Text Fields
HIG куда менее требователен к Text Fields, по сравнению с Material.
Отличия
В iOS Label находится внутри поля ввода и исчезает во время ввода текста. Material рекомендует поднимать Label при вводе текста.
Схожее
Обе платформы советуют при необходимости добавлять Clear Button.
Что ещё просит Material
Material также рекомендует выделять Label и полосу под Text Field основным цветом — это помогает понять, что поле выделено. Material описывает поведение поля при ошибке ввода. В Material на выбор есть две формы: Filled и Outlined.
24. Context Menus vs Menus
Context Menus появился в iOS 13. Этот контрол предлагает пользователю нескольких контекстных действий, связанных с выбранным элементом. В Android есть частично похожий на него элемент — Menus.
Menus Android применяется в большем числе кейсов: оно предлагает контекстные действия как для выбранного элемента, так и для всей страницы в целом; используется как инпут с несколькими вариантами на выбор (дропдаун меню); применяется для редактирования текста. Context Menus — компонент только iOS. А Menus Android можно использовать как в мобильном приложении, так и на десктопе.
25. Action View/Activity View vs Modal Bottom Sheet
| |
| |
26. Edit Menus vs Text Selection Tool Bar
Помимо визуального отличия Edit Menus и Text Selection Tool Bar отличаются следующим: при долгом нажатии в Android пользователь может продолжить выделение текста. В iOS после долго нажатия возникает лупа для точного выбора места в слове.
Также Android отличается от iOS тем, что при вызове дополнительных действий Text Selection Tool Bar принимает форму Menus.
27. Разный размер divider
В iOS это 0,5 pt, в Android — 1 dp.
Прочие отличия
28. Разные требования к размеру зоны нажатия
По гайдлайнам минимальная зона нажатия в iOS — 44 x 44 pt, а в Android — 48 x 48 dp.
29. App Store vs Google Play
Ваше приложение для iOS будут скачивать из App Store. Приложение для Android — из Google Play. Чтобы разместить приложение в сторах правильно, нужно соблюдать их требования. Требования App Store стоит прочесть здесь, а Google Play — здесь. Там много особенностей, поэтому рекомендую изучить перед публикацией.
30. Особый паттерн в iOS — Undo and Redo
Это особый паттерн iOS: если потрясти смартфон, приложение предложит пользователю отменить или повторить последнее совершенное действие. Как правило, этот жест используется для удаления введённого текста.
31. Отношение к Branded Launch
| |
32. Дополнительные темы Material Design
На сайте Material раскрыты ещё и такие темы, как: Data Formats (разные форматы данных), Data Visualization (правильная инфографика), Empty States (дизайн пустых состояний), Offline States (интерфейс при отсутствии интернета), Accessibility (доступный дизайн) и Bidirectionality (дизайн для читающих справа налево).
Заключение
Знание гайдлайнов повышает наш уровень осознанности. Мы понимаем сложившиеся пользовательские паттерны и создаём приложение, которое органично вписывается в привычки пользователей.
Гайдлайны побуждают нас уважать нативные решения платформ. При адаптации дизайна под другую платформу всегда есть соблазн продублировать дизайн без изменений. Это вредит пользовательскому опыту и усложняет разработку. Но когда мы видим различия в нативных решениях, мы адаптируем дизайн правильно.
А если мы хотим внедрить новое, кастомное решение, знание гайдлайнов помогает аргументировать это нововведение.
Итого: знание гайдлайнов и их отличий — важный навык дизайнера мобильных приложений.
Какие ещё отличия вы знаете? Поделитесь ими в комментариях.
