Tab bar что это
Tab Bar контроллеры
Анатомия Tab Bar интерфейса
Интерфейс панели вкладок полезен в ситуациях, когда требуется обеспечить различные аспекты видов на один и тот же набор данных или в ситуациях, когда требуется организовать ваше приложение по функциональному принципу. Ключевым компонентом интерфейса с панелью вкладок является наличие панели вкладок вдоль нижней части экрана. Этот вид используется для инициирования навигации между различными видами вашего приложения, а также может передавать информацию о состоянии каждого режима.
Виды Tab Bar интерфейса.
Объекты Tab Bar интерфейса
Стандартный интерфейс панели вкладок состоит из следующих объектов:
Создание интерфейса панели вкладок
Перед созданием интерфейса панели вкладок, вы должны решить, как вы собираетесь использовать интерфейс панели вкладок. Поскольку это влияет на всеобъемлющую организацию ваших данных, вы должны использовать один только из приведенных способов:
Установка интерфейса панели вкладок в главном окне вашего приложения на сегодняшний день является наиболее распространенным способом его использовать. В таком случае, интерфейс панели вкладок обеспечивает фундаментально организующий принцип для данных вашего приложения, ведущий пользователя от каждой вкладки к отдельной части приложения. Поскольку он обеспечивает доступ ко всему вашему приложению, он должен быть кореневым контроллером вид окна.
Кроме того, можно представить контроллер панели вкладок модально если существует специфическая потребность в этом. Например, вы могли бы представить контроллер панели вкладок модально для редактирования некоторого сложного набора данных, который имеет несколько различных наборов с параметрами. Поскольку модальный вид заполняет всю или большую часть экрана (в зависимости от устройства), наличие панели вкладок просто отражает выбор, доступный для отображения или редактирования модального представления данных. Избегайте использования панели вкладок таким образом, если доступен дизайн попроще.
Назначение контроллеров видов интерфейсу панели вкладок
Поскольку каждый режим интерфейса панели вкладок отделен от всех остальных режимов, контроллер вида для каждой вкладки определяет содержимое этой вкладки. Таким образом, контроллер вида, который вы выбираете для каждой вкладки должен отражать потребности этого конкретного режима работы. Если вам нужно представить относительно богатый набор данных, можно установить контроллер навигации для управления навигацией сквозь эти данные. Если данные, представленные попроще, вы можете установить контроллер вида и довольствоваться одним представлением вида.
Создание Tab Bar интерфейса, используя Storyboard
Если вы создаете новый проект Xcode, используя шаблон Tabbed Application, он создает контроллер панели вкладок в storyboard, установленный в качестве первой сцены.
Чтобы создать контроллер панели вкладок в storyboard, выполните следующие действия:
Создание Tab Bar интерфейса программно
Создание контроллера панели вкладок с нуля.
Создание элемента панели вкладок программно
Для каждого контроллера вида контента в интерфейсе панели вкладок, необходимо предоставить объект UITabBarItem с изображением и текстом, который будет отображаться в соответствующей закладке. Можно связать элементы панели вкладок с вашим контроллером вида в любое время до отображения своего интерфейса панели вкладок. Это можно сделать путем присвоения элемента вкладки свойству tabBarItem соответствующего контроллера вида. Рекомендуемое время для создания элемента вкладки является время инициализации самого контроллера вида, но это, как правило, возможно только для контроллера пользовательского вида. Вы также можете создать и инициализировать объект контроллера вида, создать элемент панели вкладки, а затем сделать объединение.
Пример создания элемента вкладки для контроллера пользовательского вида.
Управление вкладками в момент выполнения
После создания интерфейса панели вкладок, есть несколько способов, чтобы изменить его и реагировать на изменения в вашем приложении. Вы можете добавлять и удалять вкладки или использовать объект делегата, чтобы предотвратить выбор закладок на основе динамических условий. Вы также можете добавить значки в отдельные вкладки, чтобы привлечь внимание пользователя к этим вкладкам.
Добавление и удаление вкладок
Следующий листинг показывает метод, который удаляет выбранную вкладку в ответ на нажатие определенной кнопки в той же вкладке. Данный метод реализуется с помощью контроллера вида для вкладки. Вы можете использовать что-то подобное в собственном коде, если вы хотите удалить вкладку, которая больше не нужна. Например, вы можете использовать его, чтобы удалить вкладку, содержащую некоторые пользовательские данные, которые должны быть введены только один раз.
Предотвращение выбора вкладок
Если вам нужно запретить пользователю выбор вкладки, вы можете сделать это путем предоставления объекта-делегата и реализации метода tabBarController:shouldSelectViewController: для этого объекта. Предотвращение выбор закладок должно быть сделано только на временной основе, например, когда вкладка не имеют никакого контента. Например, если ваше приложение требует от пользователя предоставить определенную информацию, например, имя пользователя и пароль, вы можете отключить все вкладки кроме той, что запрашивает у пользователя необходимую информацию. Листинг ниже показывает пример того, как такой способ может выглядеть. Метод hasValidLogin обычный метод, который вы реализуете для проверки предоставленной информации.
Контроль инициированной пользователем смены вкладки
Есть два типа инициированных пользователем изменений, которые могут произойти на панели вкладок:
Предотвращение настройки вкладок
More контроллер вида обеспечивает встроенную поддержку по изменению предоставленных пользователю, отображаемых элементов в панели вкладок. Для приложений с большим количеством вкладок, эта поддержка позволяет пользователю выбирать, какие экраны должны были быстро доступны, а какие требуют дополнительной навигации.
Изменение бейджика вкладки
Внешний вид вкладки в интерфейсе панели вкладок обычно не меняется, кроме случаев, когда она выбрана. Чтобы привлечь внимание к конкретной вкладке, возможно потому, что в ней есть новое содержимое для пользователя, вы можете использовать бейджик.
Бейджик представляет собой небольшой красный маркер отображаемый в углу вкладки. Внутри он содержит некоторый произвольный текст, который вы предоставляете. Как правило, бейджики содержат числовые значения, отражающие количество новых элементов, доступных во вкладке, но вы также можете указать очень короткие строки из символов.
Чтобы назначить бейджик вкладке присвойте не-нулевое значение свойству badgeValue соответствующему элементу набора вкладок. Листинг ниже показывает пример того, как контроллер вида, который отображает количество новых элементов в своем бейджике может установить значение бейджика.
Контроллеры панели вкладок и вращение вида
Tab Bar контроллеры поддерживает книжную ориентацию по умолчанию и не вращаются в горизонтальную ориентацию, если все содержащиеся контроллеры видов не поддерживает такую ориентацию. При возникновении изменение ориентации устройства, контроллер панели вкладок запрашивает свой массив контроллеров видов. Если хотя бы один из них не поддерживает ориентацию, контроллер панели вкладок не изменяет свою ориентацию.
Мобильные паттерны навигации
Как делать правильно и удобно
Подумал я о следующем: на чем же больше всего народу ломается в попытке сделать что-то хорошее? Вариантов, конечно же, тонна и маленькая тележка, но один из них самый страшный и ужасный — Навигация.
Начинающие свой путь в гуях и уиксах дизайнеры натыкаются на нее родимую сразу, а читать гайдлайны (где тоже про навигацию отведено где-то около 1/50 всего объема) никогда не было модно. Как и инструкцию от бытовой техники… Ну да Бог с ними, с гайдами, все равно потом прочтете и не один раз.
Какие паттерны бывают?
Как таковых, паттернов навигации не то чтобы вон как много. Давайте их перечислим:
Но прежде чем рассмотреть каждый из них, давайте разберемся с понятием “Погружение”.
Иерархия
Пользователь путешествует по аппу при помощи погружения внутрь (вниз по иерархии). Также этот термин зовут Pushin, drill down. Суть название не меняет ибо в 99.9% случаев в мобильных аппах навигация погружная.
На практике погружение означает следующее: Вася ткнул палец в какую-то ячейку (строчку, кнопку, иконку, картинку), и вдруг он буквально проваливается внутрь этого объекта и оказывается на другой экран. Этот другой экран обычно хранит информацию о верхнем объекте в развернутом виде.
Схематично выглядит это примерно так:
А теперь обратите внимание: слева на страницах “ООО “Рога и копыта” и “Профиль” есть стрелочка-кнопочка “Назад”! Тапнув по ней наш герой “поднимается” на уровень выше.
И самое главное! Кто заметил, что на главной странице “Контрагенты” нет кнопочки-стрелочки “Назад”?
Молодец, дорогой читатель, ее там просто НЕ МОЖЕТ БЫТЬ потому что подняться на уровень выше мы не сможем ибо некуда уже.
Это было просто. Но не все это понимают, к сожалению. Кстати, уровней иерархии может быть бесконечно много, но все же стоит спроектировать систему так, чтобы пользователь не мог гулять на 20 уровней иерархии вглубь аппа. 5–6 уровней вложенности будет за глаза иначе пользователь в какой-то момент гарантированно потеряется и будет страдать.
Базовые модели мобильной навигации
Навигация в приложении должна быть интуитивной и предсказуемой. Разобраться, как по нему перемещаться, должно быть легко как для тех, кто уже пользовался приложением, так и для тех, кто открывает его впервые. Но на мобильных устройствах сделать навигацию доступной и легкой для обнаружения непросто из-за ограничений, которые накладывает маленький размер экрана, и необходимости отдавать приоритет над UI элементами контенту. Разные модели навигации пытаются разрешить это проблему по-разному, но каждая из них страдает от ряда проблем, связанных с юзабилити.
В своей статье Ник Бабич, специалист по разработке мобильных приложений и UX дизайну, рассматривает три базовых модели навигации — меню-гамбургер, Tab bar и управление жестами — и описывает их сильные и слабые стороны.
Меню-гамбургер
Пространство на экране мобильного устройства — ценность на вес золота, а меню-гамбургер — одна из самых популярных моделей навигации, помогающих вам его сберечь. Выдвижная панель позволяет спрятать навигацию за левой границей экрана и показывать ее только когда пользователь совершит определенное действие. Такое решение особенно полезно, если вы хотите, чтобы пользователь сосредоточился на контенте главного экрана.
Как видите, собственно меню скрыто за иконкой.
Большое количество вариантов навигации. Главное преимущество навигационного меню в том, что с его помощью можно уместить большое количество вариантов на маленьком участке.
Аккуратный дизайн. Освободите место на экране, перенеся все варианты с него на боковое меню.
Скрытую навигацию сложнее найти. С глаз долой — из сердца вон. Если навигация спрятана, пользователи с меньшей вероятностью будут ей пользоваться. Несмотря на то, что эта схема становится стандартной и многие владельцы мобильных с ней знакомы, большое количество людей просто не додумается открыть меню.
Противоречие с правилами навигации платформы. Для Android меню-гамбургер стало практически стандартом, но на iOS устройствах его просто невозможно внедрить, не затрагивая основные элементы навигации. В результате панель может оказаться перегруженной.
С меню-гамбургером контекст оказывается скрыт. Меню-гамбургер не отображает текущую позицию пользователя; эту информацию сложнее извлечь, так как она становится видимой только при нажатии на иконку меню.
Для того, чтобы попасть на искомую страницу, требуется дополнительное действие. Для перехода на ту или иную страницу нужно не меньше двух кликов (один — на иконку меню, второй — на интересующую пользователя страницу).
Варианты должны быть в приоритете. Если у вас сложная навигация, вы не облегчите жизнь пользователю тем, что ее спрячете. Есть много примеров из жизни, которые показывают: когда варианты из меню представлены в более визуально доступном виде, вовлеченность растет, а пользовательский опыт улучшается. Спросите у себя: «Какие элементы настолько важны, чтобы сделать их видимыми на мобильном устройстве?». Чтобы ответить на этот вопрос, необходимо сначала разобраться, что же имеет значение для ваших пользователей.
Если у вас небольшое количество пунктов меню с высоким приоритетом, подумайте о том, чтобы перенести их во вкладки или на Tab bar.
Посмотрите, как у вас структурирована информация. У хороших приложений очень узкий фокус. Если структура сложная, возможно, имеет смысл разделить функции между двумя или несколькими приложениями попроще. Facebook выпустил свой Messenger именно для того, чтобы решить проблему излишней сложности. Если урезать функционал, сократится и количество вариантов в меню, а значит, отпадет необходимость внедрять меню-гамбургер.
Tab bar
Модель с использованием панели вкладок, — наследие дизайна десктопных приложений. Обычно на панели представлено относительно небольшое количество вариантов равной значимости, которые должны быть доступны для прямого перехода с любого экрана в приложении.
В Твиттере Tab bar позволяет пользователю переходить непосредственно на экран, связанный с выбранным объектом.
Tab bar легко передает информацию о местонахождении пользователя. При правильном применении визуальных подсказок (иконки, подписи, цвета) она становится самоочевидной и не требует дополнительных пояснений.
Tab bar обеспечивает постоянство. Варианты навигации все время представлены на экране, так что пользователи видят, какие основные окна имеются в приложении, и могут перейти на любое из них по клику.
Число вариантов навигации ограничено. Если в вашем приложении их больше пяти, уместить все на Tab bar, сохраняя при этом оптимальный для тачскрина размер иконок, будет сложно.
Логика и расположение панели вкладок у iOS и Android отличаются. У каждой из этих платформ свои правила и рекомендации, касающиеся UI и юзабилити; их следует принимать во внимание, создавая Tab bar для того или иного устройства. Панель может находиться в верхней (преимущественно на Android) или нижней (преимущественно на iOS) части страницы. Кроме того, на iOS нижняя панель часто используется, чтобы переключаться между экранами приложения. На Android же, напротив, принято отображать вкладки для визуального управления сверху. К тому же на нижнюю панель иногда выводятся действия.
Не делайте иконки слишком маленькими. Они должны быть достаточно крупными, чтобы на них легко было нажимать. Чтобы рассчитать размер каждой иконки действия на нижней панели, разделите ширину экрана на количество действий. Или же подгоните размер всех иконок под самую большую из них.
Иконки должны быть протестированы на юзабилити. Применяйте правило пяти секунд: если вам понадобилось больше пяти секунд, чтобы придумать иконку для чего бы то ни было, скорее всего она не сможет эффективно передать нужное значение.
Всегда добавляйте к иконкам подписи. Из-за того, что у большинства иконок отсутствует стандарт применения, поясняющий текст необходим, чтобы передать нужную информацию и снизить градус неопределенности. Пользователям должно быть понятно, что именно произойдет, если они кликнут на элемент.
Управление жестами
29 июня 2007 года наступил поворотный момент. Как только компания Apple выпустила на рынок первый смартфон с полностью сенсорным экраном, взаимодействие с тачскрином стало доминирующим типом управления для мобильных устройств.
Жесты быстро приобрели популярность среди дизайнеров; появилось множество приложений, которые экспериментировали с управлением жестами.
Сегодня успех мобильного приложения может в большой степени зависеть от того, насколько продуманно жесты встроены в пользовательский опыт.
Tinder совершил переворот в своей индустрии при помощи жеста swipe, который стал практически визитной карточкой продукта. У людей это приложение ассоциируется с «проведите вправо» и «проведите влево».
Убирает лишние элементы из интерфейса. Выстраивая дизайн на базе управления жестами, вы получаете возможность делать интерфейс более лаконичным, тем самым экономя место для ценного контента.
«Естественный интерфейс». Люк Вроблевски в своей статье приводит данные из исследования, в ходе которого сорок человек из девяти разных стран попросили придумать жесты для различных действий (удаление, пролистывание, приближение и т. д.). Важно отметить следующую тенденцию: выбранные жесты оказались схожими, несмотря на различия в культурах и опыте участников эксперимента. К примеру, когда им предлагали «удалить», большинство людей, к какой бы национальности они ни относились, пытались перетащить объект на пределы экрана.
Невидимая навигация. Видимость — важный принцип дизайна UI. Посредством меню можно сделать так, чтобы все возможные действия были видимыми и, как следствие, чтобы их можно было легко найти. Невидимый интерфейс может выглядеть заманчиво красивым, но сама его невидимость вызывает массу проблем с юзабилити. Управление жестами по природе своей существует в скрытом виде, пользователю нужно сначала его обнаружить. Здесь работает та же закономерность, что и в случае с меню-гамбургером: если возможность спрятана, ей воспользуется меньше людей.
Больше усилий со стороны пользователя. Большая часть жестов не отличается ни естественностью, ни простотой для освоения и запоминания. Разрабатывая навигацию, основанную на жестах, имейте в виду: по мере того, как вы убираете объекты из интерфейса, пользователю становится все сложнее учиться работать с вашим приложением. Без визуальных подсказок он может растеряться, не зная, как взаимодействовать с интерфейсом.
Удостоверьтесь, что вы не пытаетесь научить людей радикально новой схеме взаимодействия с приложением. Воссоздайте опыт, с которым они уже знакомы. Чтобы создать хорошую навигацию, основанную на жестах, для начала нужно посмотреть, как обстоят с ними дела в мире мобильных приложений в целом. Например, если вы разрабатываете почтовое приложение, использовать swipe для пролистывания писем можно спокойно — этот жест будет знаком многим пользователям.
Предоставляйте информацию по мере необходимости и используйте визуальные инструкции, чтобы научить людей работать с вашим приложением. Помните: нужно показывать только данные, необходимые пользователю для действия, которое он осуществляет в данный момент — почти как в играх, где механика раскрывается по мере прохождения.
Как реализовать таб-бар с нестандартной кнопкой: CAShapeLayer и UIResponderChain
Дизайн играет важную роль в мобильном приложении, напрямую влияя на его успех. На этапе проектирования интерфейса часто отдается предпочтение нестандартным, иногда даже интерактивным, элементам, которые будут притягивать взгляд, способствуя повышению показателя user retention (удержание пользователей).
В данной статье рассмотрим один из таких случаев: таб-бар с круглой кнопкой в центре, которая будет изменять свой цвет при нажатии с условного красного на зеленый.
Представленный способ ориентирован на начинающих iOS-разработчиков.
Стандартная реализация
Подготовка
Отнаследуемся от UITabBarController вместо UIViewController :
В файле Main.storyboard у TabBarController укажем класс MainTabBarController :
В классе MainTabBarController создадим константу диаметра средней кнопки (по дизайну он равен 42), константы для цветов, с которыми предстоит работать, и свойство самой кнопки:
Создадим UIImageView для отображения иконки сердца внутри кнопки.
Объявим метод makeUI() для построения интерфейса:
Рассмотрим подробнее, что происходит в данном методе:
2. Активируем констрейнты для middleButton :
2.1. Фиксируем высоту и ширину в соответствии с дизайном;
2.2. Фиксируем центр по оси x и отступ от верхней границы: по дизайну кнопка выступаем над таб-баром на 10 пикселей.
3. Активируем констрейнты для heartImageView :
3.1. Фиксируем высоту и ширину в соответствии с дизайном;
Вызовем метод makeUI() в методе viewDidLoad() класса MainTabBarController :
Скомпилируем и запустим проект. У нас должно получиться следующее:
Работа с CAShapeLayer
В файле Main.storyboard выберем таб-бар на MainTabBarController и укажем, что он будет реализован классом CustomTabBar :
Внутри класса CustomTabBar объявим вычисляемые свойства для работы с таб-баром, а также константу для радиуса полукруга обводки:
Объявим метод для вычисления границ обводки таб-бара, который будет возвращать CGPath – буквально путь, по которому мы будем двигаться, рисуя обводку:
Рассмотрим подробнее, что происходит в данном методе:
Перемещаемся в точку начала системы координат, которая всегда находится в левом верхнем углу.
Добавляем линию в точку, которая соответствует правому верхнему углу таб-бара.
Добавляем линию в точку, которая соответствует правому нижнему углу таб-бара.
Добавляем линию в точку, которая соответствует левому нижнему углу таб-бара.
Закрываем путь, по сути перемещаясь из точки левого нижнего угла в начальную точку, то есть в верхний левый угол.
Аналогичным способом получим CGPath для обводки полукруга:
Рассмотрим подробнее, что происходит в данном методе:
Указываем радиус полукруга.
Указываем начальный угол.
Указываем конечный угол.
Указываем направление отрисовки полукруга – по часовой стрелке.
Объявляем константу shapeLayer типа CAShapeLayer для создания слоя обводки по периметру таб-бара. У нее указываем путь, цвет обводки, цвет заливки и ширину линии.
Сохраняем созданные слои в соответствующие свойства класса.
Данный метод будем вызывать в переопределяемом методе draw(_:) нашего класса:
Для тестирования вернемся в класс MainTabBarController и добавим следующий код в метод makeUI() :
Скомпилируем и запустим проект. У нас получилось воспроизвести задуманный дизайн:
Здесь можно увидеть довольно простую логику:
Фиксируем позицию нажатой кнопки.
Если да, меняем цвет кнопки на зеленый.
Если нет, меняем цвет кнопки на красный.
UIResponderChain
На данном этапе кажется, что цель достигнута, но мы можем заметить два интересных момента:
Если нажать на круглую кнопку чуть выше границы таб-бара, ничего не произойдет (а мы хотим, чтобы был выбран соответствующий tabBarItem и поменялся ViewController ).
Почему же так происходит?
Что же делать с нажатием на область кнопки, которая выступает за границу таб-бара?
Проход по иерархии view реализован с помощью метода hitTest(_:with:)
UIKit uses view-based hit-testing to determine where touch events occur. Specifically, UIKit compares the touch location to the bounds of view objects in the view hierarchy. The hitTest(_:with:) method of UIView traverses the view hierarchy, looking for the deepest subview that contains the specified touch, which becomes the first responder for the touch event.
Returns a Boolean value indicating whether the receiver contains the specified point.
При этом официальная документация Apple гласит:
If a touch location is outside of a view’s bounds, the hitTest(_:with:) method ignores that view and all of its subviews.
То есть проход мы начнем не с subview таб-бара (круглая кнопка), а с корневой UIView ViewController ‘a, которая, естественно, никак не обработает касание, как и остальные объекты UIResponder в иерархии.
Чтобы обработать касание на части круглой кнопки, которая находится за пределами таб-бара, нам необходимо переопределить метод point(inside:with:) в классе CustomTabBar :
Здесь происходит следующее:
1. Проверяем, находится ли точка касания в границах ( bounds ) таб-бара (в нашем случае получаем false ).
2. Если касание произошло вне bounds таб-бара:
2.1. Проходимся по всем subview таб-бара.
2.3. Если касание произошло внутри subview :
2.3.1. Возвращаем true – subview может обработать касание.
Чтобы наша кнопка выполнила некое действие при обработке касания, вернемся в класс MainTabBarController и добавим следующую строку в замыкание, возвращающее middleButton :
Рассмотрим входные параметры метода addTarget(_:action:for:) :
target – в рамках этого объекта произведем поиск метода, который будет вызван при нажатии на кнопку;
action – selector метода, который будет вызван;
controlEvents – событие, при котором произойдет вызов метода.
Готово, мы получили полноценно функционирующую круглую кнопку в центре таб-бара.