Connect with us

Разработка

Замахнуться на малое: как писать приложения для Apple Watch

Артемий Соболев, разработчик в Parallels, рассказал о трудностях, с которыми неизбежно столкнется разработчик приложения (причем приложения для любых умных часов, а не только именно «яблочных»).

AppTractor

Опубликовано

/

     
     

«Умные часы» от Apple буквально ворвались на рынок этой весной: уже в первый день начала предзаказа их продажи превысили количество проданных Android Wear, а с момента официального старта продаж вообще заняли второе место на рынке носимой электроники (сразу после фитнесс-браслетов Fitbit). Благодаря такой популярности (и официальному разрешению Apple) часы заинтересовали не только производителей ремешков, но и разработчиков приложений. Ведь это не только возможность дать пользователю несколько новых полезных функций, но и новая, экспериментальная среда, со своими новыми правилами. Артемий Соболев, разработчик в Parallels (недавно компания как раз анонсировала поддержку Apple Watch в своем мобильном приложении удаленного доступа Parallels Access), рассказал о трудностях, с которыми неизбежно столкнется разработчик такого приложения (причем приложения для любых умных часов, а не только именно «яблочных»).

Очень маленькие

Главная особенность Apple Watch в том, что они не просто маленькие, а крохотные – причем во всех отношениях: относительно слабенький процессор, небольшая память по меркам современных смартфонов, совсем крохотная батарейка и маленький экран. Это нестандартно для разработчиков мобильных приложений, которые привыкли к уже сравнительно большим экранам и высокой производительности смартфонов, позволяющими и обрабатывать приличные объемы данных (включая графические) и «развернуться» с точки зрения интерфейса. Но помнить об истинных размерах Apple Watch нужно с самого начала – это станет краеугольным камнем при разработке функциональности приложения и определении его полезности для пользователя.

Очень мало времени

Еще одна вещь, о которой разработчик должен позаботиться с самого начала (с момента проектирования приложения), – это время взаимодействия с этим приложением, и оно предполагается достаточно коротким. Пользователь проводит в нем всего несколько секунд, что серьезно ограничивает сценарий использования: человек не должен нажать 10 кнопок, чтобы получить желаемое. Иначе в процессе достижения он обязательно либо отвлечется, либо потеряет терпение, либо попросту запутается и не справится.

Без авторизации

К сожалению, в этом отношении умные часы не могут быть на 100% самостоятельным инструментом. Дело в том, что для подавляющего большинства сервисов необходима авторизация пользователя, а ее практически невозможно пройти на часах (нет клавиатуры, а ввести пароль голосом не получится). Поэтому часы покрывают максимально простые случаи использования телефона и об этой стороне процесса необходимо помнить с самого начала.

Volkswagen-own-Apple-Watch-app

В необычных местах

Нужно помнить, что пользователь возьмет часы туда, куда обычно не берет даже телефон. Поэтому сценарии использования часов могут быть самыми неожиданными: на остановке, по пути домой, в пробке и даже в душе. И это гораздо шире, чем сценарии использования смартфона. Некоторые даже спят в часах, что может определять для вас поведенческие мотивы и, соответственно, возможности применения приложения.

Это не телефон на ремешке

Приложения для умных часов не заменяют собой ни телефон, ни планшет, ни компьютер. Не нужно писать приложения, держа в голове картину мира, где все эти девайсы равнозначны, нужно подумать, какая функция будет проста и возможна именно для часиков, и при этом учитывала, что у человека есть и другие устройства. Например, приложение для заказа Uber-такси в Apple Watch – пример такого идеального сценария: человек выходит из аэропорта, заходит в приложение и нажимает одну кнопку вызова такси. В самом приложении он проводит максимум пару секунд. Но при этом вся информация для того, чтобы вызвать такси, есть на телефоне (при условии, что человек хоть раз пользовался приложением ранее).

Netflix-Watch

Без дубляжа

Приложение на часах не должно полностью дублировать приложение на телефоне. Если ваше приложение позволяет заказывать пиццу, и у вас огромный ассортимент, то показывать все наименования одним списком будет большой ошибкой. Представьте, что у вас 100 товаров, а пользователь должен будет крутить этот список на малюсеньком экране! Это не значит, что сервисы доставки пицц не должны делать приложения для Apple Watch. Просто им нужно продумать, какое действие пользователь совершает чаще всего. Примером тут может быть доставка самой любимой пиццы. Вместо того, чтобы показывать весь список, приложение, допустим, показывает две наиболее часто заказываемые пользователем пиццы и одну новую популярную.

По этому же сценарию разработки мы и пошли, когда создавали свое собственное приложение для Apple Watch: сейчас пользователь мобильного приложения удаленного доступа Parallels Access может видеть прямо на экране «умных часов» список своих удаленных компьютеров, может с часов в один клик инициировать подключение к ним или «разбудить» удаленный компьютер, если он находится в спящем режиме.

А вдруг оно не нужно?

При проектировании и выборе сценариев разработчик должен сразу ответить за пользователя на один простой вопрос: а не быстрее ли будет достать телефон и сделать ровно то же самое? Если снова взять пример с доставкой пицц (или любых других товаров), то логично, что полное меню все-таки нужно демонстрировать на большом экране телефона: тогда будут доступны большие красивые картинки и разборчивый шрифт. Ответ на этот вопрос может коренным образом поменять сценарий использования.

«Усложнялки»

В умных часах присутствуют программные надстройки для циферблатов, которые называют «усложнялками» (complications). Среди них — будильники, погодные виджеты, хронографы, напоминания о встречах, интерактивные анимации и многое-многое другое. Этот список каждой пользователь определяет для себя самостоятельно в зависимости от важности и приоритетности информации «усложнялки». Нажав на нее, пользователь открывает соответствующее приложение. Для каждого варианта оформления предлагаются дополнительные опции настройки виджетов-«усложнялок». При разработке своего приложения вы можете сделать «усложнялку» частью приложения и завоевать свою аудиторию через простое и понятное дополнение к циферблату.

apple-watch-configure-complications-e1440075950266

Glances

Эти экраны используются для того, чтобы показать более актуальную информацию, предоставляемую приложением, на одном экране. Например, это может быть график акций за неделю или песня, которая сейчас проигрывается, вместе с кнопками play/pause. Пользователь может выбирать, какие приложения будут показаны в Glances. Это тоже поле для творчества и момент, на который нужно обратить внимание при планировании своего приложения.

Уведомления

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

Digital Crown

Размер пальца сопоставим по размерам с экраном часов, поэтому при прокрутке пальцем закрывается значительная часть экрана. Вообще в целом при разработке приложения факт соотношения пальца и экрана нужно постоянно иметь в виду. Мы с этим столкнулись, еще когда делали самую первую версию Parallels Access (для iPhone), и это выросло в большую серьезную функциональность, позволяющую более точно кликнуть пальцем в нужный мелкий элемент интерфейса (так, например, появились «увеличительное стекло», видоизменяющийся курсор и многое другое). А в вопросах прокрутки стоит помнить, что для замены пальца есть колесико digital crown.

apple-watch-digital-crown

Приложения для рынка носимых гаджетов считаются одним из самых перспективных направлений мобильной разработки. Но все-таки всегда стоит помнить главное: «умные» часы – это продолжение вашего смартфона и адаптированная с учетом вышесказанного функциональность его приложений.

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Мероприятия

ВКонтакте открывает регистрацию на чемпионат по программированию VK Cup 2018

ВКонтакте анонсировал ежегодный чемпионат по программированию VK Cup 2018. К участию приглашаются программисты от 14 до 23 лет. В одной команде может быть один или два человека.

AppTractor

Опубликовано

/

Автор:

Призовой фонд VK Cup 2018 составляет 2,5 млн руб.:

  • 1 место – 1 048 576 руб.
  • 2 местo – 524 288 руб.
  • 3 местo – 262 144 руб.
  • 4-8 места – 131 072 руб.

Соревнование пройдёт в несколько этапов на площадке Codeforces. Начать свой путь к чемпионскому кубку можно с одного из квалификационных раундов 24 февраля или 2 марта.

В финале VK Cup 2018, который состоится в августе в Санкт-Петербурге, сразятся 20 команд, прошедших все этапы предварительных отборов. ВКонтакте покроет расходы на проезд и проживание финалистов.

Комментарии
Продолжить чтение

Разработка

Почему структура команды разработки может вас замедлять

Выход новой функции опять затянулся? Дело может быть в неэффективной структуре команды разработки. В этой статье собраны признаки того, что вам пора задуматься об изменении распределения ответственности.

Анна Гуляева

Опубликовано

/

“Почему мы так медленно выпускаем новые функции так медленно?” — думал я спустя год после присоединения к быстро растущему стартапу. Релиз каждой новой функции был болезненно долгим. Это не то, чего я ожидал — стартапы должны двигаться быстро. Особенно, если вы ещё не нашли свою нишу. В начале моей работы у нас было три команды разработки. Спустя год и несколько миллионов инвестиций у нас в распоряжении было девять команд разработки. Наша способность к разработке утроилась, но новые функции выходили с той же скоростью. В чем же дело? Я думаю, что дело было в законе Брукса, который утверждает, что добавление новых разработчиков в проект на поздней стадии, приводит к ещё большему замедлению проекта. Мы наняли многих отличных разработчиков, но им нужно было понять что замедляло остальных сотрудников.

Наш мотивирующий постер для разработчиков

Спустя полгода мы по-прежнему выпускали новые функции медленно. Поэтому, очевидно, закон Брукса был уже не при чем. Должна была существовать ещё одна причина, но какая? Потом мы столкнулись с проблемой в производстве, которая указала мне на возможного виновника.

Проблема и урок

Мы только выпустили новую функцию фильтрации по тегам. Поддержка получала жалобы о том, что функция не работает. Первым делом я попытался загрузить картинку и отметить её как “Не хот-дог”. Потом я попробовал отфильтровать картинки по этому тегу и убедился, что фильтрация не работает. Я составил список команд, которые участвовали в создании функции. Каждая команда была ответственна за свой компонент:

  1. Загрузка и обработка изображений.
  2. Elasticsearch.
  3. Фронтенд фотоальбома.
  4. Команда DevOps, ответственная за инфраструктуру и развертывание новых функций в облаке.

Я решил сначала поговорить с командой по загрузке изображений. Я спросил руководителя команды, почему их функция не работала. Он посмотрел, что теги были сохранены и предположил, что они не были проиндексированы, что привело меня к команде Elasticsearch. Разработчик из следующей команды заглянул в Elasticsearch. Тег был проиндексирован, все выглядело отлично. Поэтому он отправил меня к команде фронтенда альбома. Они обнаружили, что фронтенд-библиотека была развернута в более старой версии. Функция фильтрации зависит от этой библиотеки, поэтому это, вероятно, было причиной проблемы. Фронтенд-команда посоветовала мне поговорить с командой DevOps, чтобы они развернули нужную библиотеку. Я устал ходить от одной команды к другой и сказал им, чтобы они сразу исправили эту проблему. Наконец проблема была решена. Я понял, что командам не хватало ответственности за то, что они создавали. Команды были разбиты по компонентам, и никто из них не чувствовал ответственности за функции – каждый работал только над маленьким кусочком пазла. Разбитие команд по компонентам сделала быстрый выпуск новых функций сложным. Все их усилия были тесно связаны. Если одна из четырех команд не работала или задерживалась, это влияло на выпуск всего функционала.

Почему компании начали разбивать команды по компонентам?

В начале разработки продукта команды часто самостоятельно разбиваются по компонентам. Если сам продукт пока не имеет структуры, то технические компоненты для его работы понятны. Поэтому команды проще организовать по этим компонентам. Эта идея довольно проста — каждая команда ответственна за один или более компонентов. Такая структура помогает увеличить продуктивность разработчиков, которые работают над конкретными частями системы. Создание чего-то нового на Amazon RedShift? Только одна команда должна беспокоиться об изучении RedShift. Недостаток таких команд заключается в том, что менеджеры должны беспокоиться о выпуске функций. Границы между командами создают зависимости, которые требуют активного управления. Это возможно, если у вас не так много компонентов или функции не распределены между множеством команд. Представьте, что вы владелец продукта и хотите внедрить Feature 2,  как на картинке ниже. Она зависит от двух компонентов, за которые отвечают разные команды. Функция выйдет, только если обе команды завершат необходимую работу над своими компонентами. Вернемся к примеру с фильтрацией тегов. Так как даже причину неисправности было сложно установить, представьте, как неэффективно было заставлять все эти команды координироваться ради одной маленькой функции. Любая задержка в любом компоненте вызывала задержку релиза функции. Чем больше компонентов и команд вовлекалось в дело, тем больше возникало проблем с координацией и вынужденного ожидания. Если один спринт одной команды проваливается, функция не может быть выпущена.

Альтернатива: команды по функциям

Вместо того чтобы делать команы ответственными за компоненты, вы можете сделать команды ответственными за функции. Представьте, что одна команда была бы ответственна за фильтрование и поиск, а другая — за метаданные к изображениям. При выпуске фильтрации по тегам вам нужно было скоординировать усилия всего двух команд. При этом ответственность за компоненты делится, и несколько команд могут работать над изменениями в одних и тех же компонентах. Усилия по координации смещаются с уровня функции на уровень компонентов. Управлять на уровне функции сложно, но это проще, чем управлять на уровне компонентов. Вам нужно убеждаться, что изменениями в компонентах занимаются люди, которые больше других в компании знают об этих компонентах, а также все команды должны разбираться в одних и тех же технических вопросах.

Переход к командам по функциям

Многие команды начинают с команд по компонентам, потому что структура продукта неясна в начале существования проекта. Но в какой-то точке команды по компонентам могут начать вас тормозить. Вот симптомы, которые подскажут вам, что ваша структура вас замедляет:

  1. Разработка небольших функций занимает больше времени, чем вы ожидали, потому что они находятся в зонах ответственности разных команд.
  2. При возникновении проблем все показывают пальцем друг на друга. Никто не несет ответственность за функцию.

Если это происходит, вам стоит рассмотреть переход на команды по функциям. Такая работа имеет свои сложности: вам нужно будет придумать лучшее распределение компонентов между командами и подстроить свою архитектуру, чтобы разъединить как можно больше компонентов. Переход к командам по функциям — это самая сложная часть работы с подобной структурой. Как структурировать команды? Как передавать знания? Как убедиться, что организация разрешит вам изменить структуру? Этому будет посвящена уже другая статья.    https://apptractor.ru/develop/myi-uvolili-nashego-luchshego-razrabotchika.html https://apptractor.ru/info/articles/vyi-uvolili-luchshego-razrabotchika-nadeyus-vyi-dovolnyi.html  

Комментарии
Продолжить чтение

Новости

Интересные материалы: 21.02

В новой подборке ASCII-арт, карты развития, практики и ловушки.

Леонид Боголюбов

Опубликовано

/

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

Комментарии
Продолжить чтение

Программирование

Создание анимации в 7 строк кода

Android-разработчик Леонардо Пирро рассказывает, как создать простую анимацию при помощи ConstraintLayout и ConstraintSet.

Анна Гуляева

Опубликовано

/

Заниматься анимацией всегда весело, но это довольно сложно, так как вам нужно будет сделать много вычислений, измерений и другой работы с интерфейсом. По той причине создание анимации занимает много времени и усилий.

ConstraintLayout + ConstraintSet

Я хочу поделиться с вами новым способом создания анимаций в приложении при помощи всего семи строк кода, используя Keyframe Animations, ConstraintLayout и ConstraintSet. Эта концепция заключается в создании двух разных макетов: одного для начальной точки и одного для конечной точки анимации. Давайте посмотрим, что мы хотим создать: наша цель — создать плавную анимацию детали, которая будет появляться при нажатии пользователем на экран.

Анимация создается при помощи двух файлов макета: circuit.xml and circuit_detail.xml. Эти макеты очень похожи и различаются только тем, что на первом элементы вынесены за экран, а на втором — находятся в нужной позиции.

Поэтому давайте создадим анимацию и увидим, как просто создавать анимацию при помощи ConstraintLayout и ConstraintSet.

Пусть магия произойдет

Сначала создадим отдельный ConstraintSet, куда мы скопируем ограничения второго макета, вызвав метод clone():

val constraintSet = ConstraintSet()
constraintSet.clone(this, R.layout.circuit_detail)

Теперь создадим объект перехода, используемый для установки интерполятора и продолжительности анимации:

val transition = ChangeBounds()
transition.interpolator = AnticipateOvershootInterpolator(1.0f)
transition.duration = 1200

Сейчас вызовем TransitionManager.beginDelayedTransition(), который используется для осуществления перехода на следующий кадр рендеринга. Затем мы вызываем applyTo(), чтобы начать анимацию.

TransitionManager.beginDelayedTransition(constraint, transition)

constraintSet.applyTo(constraint)

Это действительно семь строк кода. Вот и все! Вы можете посмотреть полный пример в моем репозитории GitHub по этой ссылке.

Комментарии
Продолжить чтение

Постеры для разработчиков

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.