как самому сделать приложение для андроид для такси
Как сделать приложение для Android самостоятельно
Платформа Android открытая, поэтому каждый может написать своё приложение и распространять его через каталоги программ. Все инструменты бесплатны.
Язык программирования для мобильной разработки на Android очень простой — это Java. Сейчас Google активно продвигает Kotlin как язык, который сможет заменить Java. Приложения пишут и на C++.
Создание простейшего приложения состоит из нескольких этапов:
А пока мы описываем азы, студенты курса «Профессия Мобильный разработчик» уже получают деньги за свои приложения.
Пишет про разработку в Skillbox. Работал главным редактором сайта «Хабрахабр», ведет корпоративные блоги.
Необходимые инструменты
Первым делом установите программу Android Studio. Это официальная среда разработки (IDE) для Android, она работает на Windows, macOS и Linux. Хотя при разработке программ для Android можно использовать и другие среды, кроме Android Studio.
Если на компьютере не установлены Android SDK и другие компоненты, то Android Studio автоматически скачает их. Android SDK — это среда программирования, в которую входят библиотеки, исполняемые файлы, скрипты, документация и т.д.
Полезно установить и эмулятор Android, чтобы запускать и тестировать приложения. Эмулятор поставляется в комплекте с Android Studio.
Когда все инструменты установлены, можно создать первый проект. Но сначала нужно разобраться с основными понятиями.
Из чего состоит приложение
на Android
Android-приложение состоит из четырёх компонентов. Каждый компонент — это точка входа, через которую система или пользователь может получить доступ.
Теперь попробуем сделать своё приложение для Android.
Создаём Android-приложение
в Android Studio
Шаг 1
Выбираем название приложения, домен компании, путь к проекту и название пакета. Указываем, включить ли поддержку опциональных языков программирования C++ и Kotlin.
Шаг 2
Задаём одну или несколько целевых платформ для сборки. Для этого используется SDK и AVD, менеджер виртуальных устройств Android. Инструмент позволяет устанавливать в SDK пакеты, которые поддерживают несколько версий ОС Android и несколько уровней API (интерфейсов программирования приложений).
Чем ниже версия Android, тем больше устройств, на которых приложение запустится. Чем выше версия, тем богаче функциональность API.
Шаг 3
Выбираем основную активность, которая будет запускаться при нажатии на иконку приложения, и даём ей имя.
Шаг 4
После нескольких минут сборки Android Studio открывает интерфейс IDE. Здесь три основных момента.
Что нужно для того, чтобы разработать приложение по заказу такси
Но, вообще-то нет, это не совсем так. Если присмотреться, то простенькое приложение не такое уж простое. А конкурентоспособное приложение – это гораздо большее. Это сложная система, мощный целевой маркетинг и продажный механизм, оснащенная серверной системой, где мобильное приложение является лишь малой частью, которая напрямую взаимодействует с клиентами. И чем проще приложение выглядит на первый взгляд, тем больше вероятность того, что уйма времени была потрачена на то, чтобы оно выглядело подобным образом, увеличивая при создании серверную часть, чтобы компенсировать тем самым простоту плоского дизайна.
Давайте взглянем на наше пассажирское приложение на iOS «Saytaxi». Выглядит довольно-таки просто, не правда ли?
Ниже представлена упрощенная схема пользовательского интерфейса:
Оно все еще кажется вам простым?
И это всего лишь часть пользовательского интерфейса, а представьте себе, что происходит на стадии серверной разработки.
Довольно часто наши потенциальные клиенты утверждают, что они отдают свое предпочтение созданию приложения для бронирования с нуля, и что стоимость такого приложения будет не на много больше, но зато оно будет их собственностью и они сделают его так, как захотят.
Обычно я даже не отговариваю их от этой затеи, так как наверняка знаю, что они в любом случае вернутся, потому, что зайдут в тупик, и вот по каким причинам:
1. Нужно по крайней мере 2 версии Вашего приложения для бронирования
Для двух основных систем – Android и IOS, и конечно, на это уйдет, по меньшей мере, в два раза больше времени и средств.
2. Нужно приложение для водителей
Ну, или какой-то другой способ автоматического распределения заказов для водителей. Даже, подогнав все аппаратные и программные решения, как Вам удобно, существует вероятность неправильной интеграции с приложением для бронирования, которое само по себе:
— ненадежно- дорогое в разработке и обслуживании
— тяжело поддается настройкам
В то время, правильно разработанное приложение для водителей:
— создано для той же системы, что и Ваше приложение для бронирования
— может быть установлено непосредственно самими водителями
— является интуитивно понятным и простым в использовании.
3. Вы должны поддерживать и постоянно обновлять эти приложения
Вы должны внедрять новые возможности, новые способы оплаты, новые способы оповещения клиента, улучшать пользовательский интерфейс, отражать любые изменения во внешних системах (например, Google Maps), и многое другое. На самом деле все эти действия необходимы. Если приложение постоянно не обновляется, то за полгода оно попросту умрет.
Большинство людей не понимают, что приложение – это всего лишь верхушка айсберга, с которой клиент сталкивается непосредственно.
4. Вам нужна серверная система
Как упоминалось ранее, большинство людей даже не понимают, что приложение – это всего лишь верхушка айсберга, с которой клиент сталкивается непосредственно.
Существует целая система, оснащенная несколькими серверами в центрах обработки данных, распределяющими базы данных, постоянно выполняющими ряд процессов с целью оптимизации времени отклика приложения, и выполняющие множество различных действий в зависимости от того, какие инструменты, Вам могут понадобиться. Создать само приложение легко, а вот создать и обслуживать серверные системы на самом деле трудно и дорого.
Кроме того у диспетчерских служб такси уже есть свои IT-системы и тогда встает вопрос интеграции/переноса всего массива данных.
5. «Получаю то, что хочу» – не всегда верная тактика
Вы должны проанализировать массу информации, чтобы выяснить, что работает, а что нет, что следует изменить на каждом шагу Вашего пути, как Вы сможете залатать, возникающие «дыры», а затем постепенно внедрять и реализовывать новые возможности. А потом сделать шаг назад и проверить все еще раз, так как все Ваши «улучшения» могут в действительности сделать только хуже.
Мы проанализировали данные, полученные от тысяч первых клиентов, изучили сотни сообщений обратной связи и прошли через несколько циклов улучшений. И угадайте что? Мы все еще продолжаем делать то же самое. Постоянно, без остановок, даже в планах не имея, что мы должны остановиться в ближайшее время.
6. Да, право собственности остается за клиентом
Но это также означает, что у клиента «сохраняется право собственности» на поддержку системы и также все приложения, это не только дорого, но и отнимает уйму времени, требует определенного опыта и гарантированно доставит много проблем.
Приложения служб такси – это довольно-таки молодое направление, именно поэтому я так тщательно все объясняю. Вам же не стоит объяснять, почему Вы не должны разрабатывать собственную систему учета или собственный сервис электронной почты, не так ли? То же самое должно касаться и приложений по бронированию, но, к сожалению, в данной отрасли еще не пришли к общему пониманию основных направлений.
Поэтому, прежде чем погрузиться в ад разработки, я предлагаю Вам поупражняться и для начала посчитать, сколько же будет стоить разработать лишь ОДНО приложение, а затем оставить свои результаты в комментариях ниже. Давайте сравним.
И еще несколько слов о нас:- Работаем 5 лет в 35 странах мира;- Лидирующие позиции в других странах мира (Франция, Бахрейн, Коста-Рика, Перу)- Whitelabel мобильное приложение под Android/iOS и интеллектуальная диспетчерская система
Создание макетов приложения такси «Ситимобил» для айфона и андроида
Заказчик просит сделать приложение заказа такси, не оглядываясь ни на кого.
Знакомимся с предметной областью. Изучаем статьи, отзывы и тематические ресурсы.
Анализируем статистику, самые популярные опции и наиболее распространенные жалобы.
Проводим в студии соцопрос об опыте использования такси. Вне конкуренции опция мечты «молчаливый водитель». Еще узнаем, что во многих приложениях невозможно указать несколько детских кресел, и для многодетных родителей это боль.
Начитавшись и наслушавшись всякого, фантазируем. Какое оно, идеальное такси, что оно умеет? Скажем, хочется самостоятельно выбирать водителя из нескольких вариантов или учитывать при ранжировании водителей оценки от друзей. Или вообще постоянно ездить с одним и тем же водителем. А что, если я хочу кататься на такси по расписанию, чтобы каждый день в одно время тот же водитель возил меня из дома на работу?
Или удобная оплата рабочей поездки с корпоративного счета. Администратор аккаунта компании добавляет по телефонному номеру сотрудников в список, и при заказе у пассажира появляется возможность выбрать оплату за счет компании, чтобы не возиться потом с этими чеками.
Ну и, конечно же, возможность через приложение поделить стоимость поездки со знакомыми или отправить другим предложение оплатить поездку.
А еще возможность «шарить» поездку, чтобы отследить на карте приближение опаздывающего товарища или убедиться в том, что таксист не увез жену в Котельники.
Или возможность указать не время прибытия машины к пассажиру, а время ее прибытия к точке назначения. Если надо успеть на поезд к 16:00, то пусть такси рассчитывает, какие там пробки, сколько времени займет дорога, это не забота пассажира.
Или, например, если пассажир молчит, это не значит, что ему все нравится — плохая музыка, болтливый водитель и прочие дорожные «прелести». А водитель и не знает, что что-то не так, а потом злится на оценки. Поэтому в личном профиле хорошо бы указывать предпочтения: радиостанция, стиль вождения, болтливость водителя, аромат освежителя и все такое. Водитель вправе и проигнорировать эти пожелания, но в погоне за хорошей оценкой он, скорее всего, будет стараться следовать подсказкам, оставленным пассажиром через приложение.
Анализируем существующее приложение заказчика.
Расспрашиваем его о механизмах работы такси и таксопарка, планах развития и конкурентных преимуществах. Обсуждаем все утопические предложения и их реализуемость. От чего-то отказываемся сразу, что-то еще зафлексим в процессе работы.
Собираем у коллег промо-коды и отправляемся в поездки, тщательно делая скриншоты всех экранов.
Изучаем лучшие образцы мобильных приложений, тенденции и применяемые ходы.
Устанавливаем приложения такси, пока «ай-ОС» не треснет.
Изучаем каждое из них, сравниваем ходы и способы решения однотипных задач.
Выявляем три подхода к интерфейсу заказа такси, существующих на рынке.
— Опрос или «мастер заказа». Такой у «Яндекс-такси». Поочередно запрашивает выбор каждой из основных опций заказа. Плюсы: нет расфокуса внимания, один экран — один параметр, игра в минимализм. Минус: при каждом заказе надо продираться через этот опросник, даже если всегда указываешь одинаковые параметры.
— Центр управления. Таких приложений большинство. Показывается список выбранных параметров заказа, при нажатии на каждый из них открывается экран с вариантами. Плюсы: заказ такси в один тап, не требуется каждый раз подтверждать все опции. Минусы: для смены любого параметра необходимо отправляться на отдельный экран, что утомляет и нарушает бесшовность интерфейса.
— Комбинации вариантов 1 и 2. Это «Убер» и «Гетт». Начинает с короткого опроса, обычно спрашивая адрес, потом переходит в центр управления. Плюсы и минусы наследуются.
Ставим перед собой ограничение: найти решение, позволяющее заказать такси в один тап, но при смене параметров не гоняющее по вспомогательным экранам.
Собираем все мысли и тезисы в один документ, чтобы ничего не забыть.
Сразу складываем примерную карту экранов.
Тут же цепляемся за идею представлять маршруты и адреса в виде точек и линий на мини-карте. Адреса сложные и плохо запоминаются, а так одного взгляда достаточно, чтобы прикинуть, откуда и куда предстоит ехать.
Далеко не все прошли курс распознавания марки машины по эмблеме, для многих «Мицубиси лансер эволюшен икс 2.0» — это «красненькая машинка с ромбиками такими», и нельзя их за это заставлять страдать при заказе такси. Поэтому сопровождаем марку такси эмблемой, которую легко сопоставить со значком на машине. Ну и пиктограмма машины, которая не перекрашивается в свой настоящий цвет, — в наше время уже позор.
Размышляем о поездке как о смысловой единице приложения, пытаемся представить ее в виде карточки.
Слишком мелко, вебно и вообще не похоже на мобильный интерфейс. Исправляемся. Пробуем использовать цветовое кодирование статусов поездки.
Примеряем к макету экрана.
Ну, типа, так. Для начала сойдет. После разминки переходим к основной программе выступления — экрану заказа.
Для начала собираем список полей и возможных действий, определяем их актуальность на каждом этапе поездки.
Все эти порции информации раскидываем пока что по экранам и помешиваем, смотря, что при этом выходит.
Не хватает четкой сквозной структуры, охватывающей все данные, чтобы не бегали глаза и не надо было угадывать, как работает каждый элемент.
В качестве самого перспективного выбираем вариант интерфейса «Аппстора»: вертикальный скроллинг с вложенным построчным горизонтальным скроллингом позволяет уложить в экран все варианты всех параметров заказа.
По-прежнему мусорно, акцентов нет, все вперемешку.
При нажатии на поля ввода адреса появляется карта и возможные варианты.
Или вот еще фильтры сделать, а к вариантам добавить точки на карте — при скролле весело будет.
Ладно, для демонстрации принципа работы пока хватит. Собираем прототип для презентации заказчику.
В последний момент перед демонстрацией рука дрогнула: все же указание точки «откуда забрать» на карте надо не прятать за меню. Решаемся разделить заказ на два этапа: выбор места, а потом — параметров заказа.
Показываем заказчику. Идея сквозного постраничного меню ему нравится, но возникают сомнения относительно общего внешнего вида, выглядит слишком сложно. Ну и еще он просит все же найти способ заказа такси в один тап.
Понимаем, что сейчас сложно отделить идею работы экрана заказа от чернового оформления. Собираем еще три варианта реализации единого принципа постраничного скролла, чтобы показать, что предлагаемый нами механизм способен менять оформление и что процесс его выбора еще впереди.
Заказчик соглашается, настает время поиска стиля.
Ловим дзен: радикально очищаем экран, избавляемся от всех пиктограмм, суперъярких пятен, полосок, картинок, фотографий, разделителей и обводок.
Совмещение пиктограмм с текстом не работает, выглядит как мусор. Оставляем просто текст, карту и параметры совмещаем на одном экране, варианты выводим сразу все.
Получается суперпростой и бронебойный стартовый экран: карта, шторка с построчным выбором параметров и кнопка заказа.
Только цвета притушить надо.
Вместо информации о тарифах рассчитываем стоимость поездки на кнопках. Если знаем точку назначения — сразу прикидываем маршрут и стоимость. Если нет — ограничиваемся информацией о тарифе.
Получается удобная скроллилка. Вводим принципы оформления элементов меню: названия параметров, которые вместо выбора приводят к уточняющим экранам, заканчиваются многоточием; те, которые подразумевают ввод текста, дополнительно подчеркиваются.
Заказчику не нравится тонирование карт, пробуем другие варианты.
С этим экраном примерно определились, переходим к остальным.
Беремся за боковое меню. Карточки поездок в меню не выжили, ограничиваемся списком. При отсутствии заказов разворачиваем его на всю высоту.
Еще когда карточки поездок пристраивались к меню, возникла идея использовать в качестве фона не просто абстрактную фотографию, а привязанную к конкретному времени, погоде и месту. Вечерний дождь на эстакаде или солнечное снежное утро у Кремля. Так мы задаем настроение и устанавливаем эмоциональную связь с пассажиром. Это не просто интерфейс заказа такси, а проводник по улицам города. Делаем привязку к рекламной кампании.
Сперва идея развивается до зацикленного видео вместо фотографий, а потом рождается мысль — снять и вступительный видеоролик, который показывался бы при первом запуске приложения. Собираем референсы, прикидываем содержимое — хочется показать, как машина проезжает через разную Москву.
Когда-нибудь да, а пока флексим. Переходим к остальным экранам. На очереди — чат с техподдержкой. Просматриваем все существующие в мире мессенджеры, делаем выводы. Чатик должен быть умным, с интерактивными элементами и возможностью прикрепить фото либо геолокацию. Чтобы на типичные вопросы человек отвечал текстом или выбирал подходящий вариант из списка. Самые частые причины обращений к специалистам службы поддержки выносим в список возле поля ввода. Ввод текста — это боль мобильных интерфейсов, его надо минимизировать.
Теперь профиль водителя. Прикидываем его содержимое.
Делаем первые попытки.
Решаем, что нужно больше ачивок.
Отображаем разные состояния поездок.
Все не то. Глядя на экран, нельзя понять главное сообщение. Вспоминаем про цветовое кодирование, пробуем использовать большие яркие плашки.
Комки перемешались. Чтобы стало аккуратней, меняем местами панель кнопок и плашку водителя.
Подбираем цвета более тщательно. Градации фирменного оранжевого или полный разброс по hue?
Разноцветные побеждают. Сразу прикидываем анимацию перехода между состояниями.
Техдизайнер приносит машинки разного класса с видом сверху — для карты и сбоку — для всего остального. Они легко перекрашиваются в любой цвет.
Пришло время навести везде порядок и собрать полноценную карту приложения с настоящими макетами.
Проводим инвентаризацию типографики: собираем все текстовые стили, использовавшиеся при сумбурном макетостроении на всех экранах, и перетряхиваем. Тридцать четыре стиля схлопываются в тринадцать.
Когда внешний вид приложения для «ай-ОС» устоялся, беремся за андроид. Работа начинается с изучения свежих гайдлайнов операционной системы и рекомендаций «Гугла» по разработке материального дизайна. Делаем первый пристрелочный набросок.
Нет, нужно просто адаптировать уже имеющийся дизайн под андроид.
Постепенно приложение обрастает дополнительными экранами.
Приводим в соответствие карту приложения для «ай-ОС».
Худрук просит дополнить метку «Где я сейчас» адресом для уверенности и попробовать другие варианты размещения стоимости поездки и времени подачи такси.
В какой-то момент заказчик начинает переживать о том, что новый дизайн слишком радикально отличается от существующего приложения, и приносит свой вариант.
Понимаем тревогу заказчика, поэтому еще раз перебираем варианты, чтобы убедиться, что выбрали лучшее решение.
В итоге дополнительно делаем промежуточную версию для плавного внедрения нового дизайна.
И презентуем заказчику.
Но в итоге в разработку идет самый смелый вариант.
Собираем анимации для разработчиков.
Готовим анонс. Утверждаем у арт-директора набросок фотографий, разыскиваем подходящую локацию, долго дожидаемся нужной погоды, делаем пристрелочные кадры. Разочаровываемся в результате, еще раз ищем локацию и отправляемся на финальную съемку, на этот раз прихватив немного пиротехники для ощущения тумана.
Параллельно со сборкой анонса просматриваем тестовые сборки приложения, пишем замечания.