Зарплаты: мобильный разработчик, россия

Базовые требования к профессионалу

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

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

• Android: знание Android SDK, Java, Kotlin, Scala (в меньшей степени), Rest/SOAP, различные API, SQLite и т.д.
• iOS: Objective-C, С#, Swift, знание Apple Development Guidelines

Для обеих платформ:

• знание структур и алгоритмов
• знание принципов ООП (к которому и относится Java, Objective-C, Swift)
• понимание принципов дизайна и проектирования мобильных приложений
• знание сетевых протоколов
• знание SQL
• навыки работы с App Store и Google Play
• навыки работы с многопоточностью (всё чаще)
• Flutter (бешено растёт популярность)

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

Топ-5 востребованных технологий у специалистов по данным «Хабр Карьеры», 2 полугодие 2019 года

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

UI

Одна из главных особенностей Android-разработки – обилие девайсов разного размера и с разным разрешением экрана. В Wear OS, ещё и разная форма экрана: круглый, квадратный и круглый с обрезанным краем.
Если мы попробуем сверстать какой-либо лейаут и отобразить его на разных экранах, скорее всего, увидим примерно такой вот кошмар:

Во второй версии системы Google любезно решила часть UI-проблем, включив в Support wearable library новые адаптивные view-компоненты. Пробежимся по самым любопытным из них.

BoxInsetLayout

BoxInsetLayout – это FrameLayout, который умеет адаптировать дочерние элементы под круглый дисплей. Он помещает их в прямоугольную область, вписанную в окружность экрана. Для квадратных дисплеев подобные преобразования, само собой, игнорируются.

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

Выглядит лучше, не правда ли?

WearableRecyclerView

Списки – удобный паттерн, который активно используется в мобильном (и не только) UX. Wear-интерфейсы исключением не стали. Но из-за закругления углов дисплея верхние View у списка могут обрезаться. WearableRecyclerView помогает исправить такие недоразумения.
Например, есть параметр isEdgeItemsCenteringEnabled, который позволяет задать компоновку элементов по изгибу экрана и расширять центральный элемент, делает список более удобным для чтения на маленьком экране.
Есть WearableLinearLayoutManager, который позволяет прокручивать список механическим колесиком на часах и доскроливать крайние элементы до середины экрана, что очень удобно на круглых интерфейсах.

Сейчас библиотека поддержки Wear включает пару десятков адаптивных View. Они все разные, и обо всех можно подробно почитать в документации.

Рисовать данные на экране – весело, но эти данные нужно откуда-то получать. В случае мобильного клиента, мы чаще используем REST API поверх привычных всем сетевых протоколов (HTTP/TCP). В Wear OS подобный подход тоже допустим, но Google его не рекомендует.
В носимой электронике большую роль играет энергоэффективность. А активное интернет-соединение будет быстро сажать батарею, и могут регулярно происходить разрывы связи. Ещё носимые устройства предполагают активную синхронизацию, которую тоже нужно реализовывать.
Все эти проблемы за нас любезно решает механизм обмена данными в Google Services под названием «Data Layer». Классы для работы с ним нашли свое место в пакете com.google.android.gms.wearable.

Техническое задание в процессе создания мобильного приложения

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

Обычно в нем прописываются:

• Цели проекта.
• Пользовательские истории и карта путешествия человека — описывают, какие задачи будут решать люди с помощью сервиса, и как они будут это делать.
• Обязательные функции.
• Технические требования к интерфейсу, производительности, роли пользователей, безопасности.
• Реализация функциональности: UX и UI дизайн.
• Этапы разработки.
• Время, необходимое, для всех работ.
• Бюджет.

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

Чаще всего студии разработки помогают с подготовкой ТЗ. Например, в AppCraft мы всегда проверяем ТЗ на соответствие требованиям платформ и разрабатываем его с нуля, если у вас не хватает на него времени или возникли какие-то сложности. 

Экраны, данные и логика

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

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

Хорошим выбором станет разделение приложения на относительно короткие сценарии не более 10 шагов каждый.

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

Группировка экранов и сквозное именование

Итак, у нас на руках есть схемы экранов от проектировщиков/дизайнеров и последовательность переходов между ними.

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

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

Если вы опытный программист, то легко справитесь с разделением списка экранов на связанные разделы. В любом случае, потребуется немного практики.

Итак, у нас могут получиться следующие разделы:

1. Account
2. Help
3. Checkout
4. Catalog

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

Например, слой работы с данными (группы методов для различных серверных API) в этом случае разделится на разделы (репозитории, если вам так привычнее), каждый из которых будет обслуживать свой набор экранов:

DAL\DataServices (Repositories)

AccountDataService.cs (или AccountRepository.cs)

HelpDataService.cs

CheckoutDataService.cs

CatalogDataService.cs

В дальнейшем каждый из репозиториев может полностью скрывать всю работу с сервером, дисковым кешем и локальной СУБД. Это позволит на уровне бизнес-логики работать с репозиториями как с черными ящиками.

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

Имена экранов будут использоваться у нас в названиях классов для соответствующих страниц (Page) и ViewModel (или Controller для MVС):

1.1 Profile

ProfilePage

ProfileViewModel

В первую очередь это важно для разработчиков, которые фактически получают готовую структуру проекта:

• Слой доступа к данным разбивается на разделы приложения — создаем структуру Data Access Layer (DAL)
• Добавляем нужные Pages и ViewModels — это создает структуру слоев работы с пользовательским интерфейсом (UI) и бизнес-логикой (BL).

Как видим, уже вырисовывается скелет проект. Слой DAL можно легко выделить в отдельную библиотеку. Если же у вас используется типовая архитектура или шаблон проекта (Base-классы, NavigationService, и т.д.), то считайте, что костяк приложения у вас уже имеется.

Пример структуры проекта представлен ниже.

UI (User Interface, пользовательский интерфейс)

    \Pages

        \Account

            ProfilePage.xaml

            …

BL (Business Logic, бизнес-логика)

    \ViewModels

        \Account

            ProfileViewModel.cs

            …

DAL (Data Access Layer, доступ к данным)

    \DataObjects (Models)

        ProfileObject.cs (ProfileModel.cs)

        ProductObject.cs

        …

    \DataServices (Repositories)

        AccountDataService.cs

        …

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

Как выбрать курс и нужно ли учиться в университете

Насколько хорошо учат программистов в университете?

Мое отношение к университетскому образованию айтишников — среднее. Это не бесполезно, но после университета вы еще не готовы быть разработчиком. 

За те 5 лет, которые вы будете учиться в университете, уже 2–3 раза изменятся технологии. Поэтому университет надо рассматривать, как базу, которая учит мыслить и дает фундамент. Потом надо будет доучиваться на курсах.

На что стоит смотреть при выборе курсов?

Я бы смотрел в первую очередь на программу. Второе — познакомился бы с человеком, который будет меня обучать, посмотрел, нравится он мне или нет.

На бренд я бы не рекомендовал смотреть. Есть крупные школы, которые ругают, есть маленькие — которые хвалят. 

Что должно быть в курсе, чтобы человек вышел хорошим специалистом?

Должна быть основа, базовая теория, чтобы люди научились программировать в целом. Но обязательно должно быть много практики. Хорошо, если на курсе вы напишете конкретные программы, которые можно положить в портфолио.

Плюсы и минусы профессии

Плюсы

Минусы

Высокие зарплаты. Например, iOS-разработчик может получать до 200-250 тыс. рублей в месяц.

Востребованность и растущий спрос на рынке труда.

Наличие четких стандартов и гайдлайнов значительно облегает работу.

Можно освоить профессию самостоятельно или на курсах.

Видимый результат работы.

При найме работодатели смотрят на реальные знания и навыки, а не диплом.

Сидячая работа.

Новичкам сложнее найти работу, поскольку работодатели чаще ищут людей с опытом.

Желательно знать английский язык, так как документация часто написана на нем.

Необходимо постоянно учиться и осваивать новое, т.к

в сфере программирования все быстро меняется.

Важно быть самостоятельным, искать решение проблем своими силами, не отвлекая коллег.

ASO

Зачем нужно

ASO (App Store Optimization) — аналог SEO, только для приложений, когда пользователь ищет что-то в поиске в App Store/Google Play. С помощью ASO можно:

• Отслеживать ранжирование по ключевым словам

• Отслеживать конкурентов

• Прокачивать ранкинг, в том числе для локализации

И другие смежные задачи.

Есть гайдлайны Apple для улучшения ранкинга. В целом, оптимизация ASO и SEO — это похожие вещи, которыми надо заниматься постоянно. Можно найти гайды и рекомендации, они есть в открытом доступе.

Кого выбирать

Я даже близко не эксперт в ASO, но знаю хорошие отзывы про AppFollow и AsoDesk. Как вариант, можно написать самописное решение – на GitHub много библиотек, которые помогут с этим, например, здесь.

Как стать разработчиком мобильных приложений

На эту профессию можно выучиться разными способами: пройти обучение в ВУЗе, разобраться самостоятельно, закончить курсы, заниматься с репетитором.

1. Самостоятельные занятия подойдут тем, кто уже хоть немного знаком с принципами разработки и решил по какой-либо причине попытаться создать собственную программу. Это реально сделать с помощью книг и обучающих видео в Интернете. Не стоит писать код ради интереса и без практического применения: когда есть свой проект, идея и требования к нему, самообучение будет иметь конкретную цель. Она будет мотивировать, а также заставит выбирать материалы более осознанно, не даст захлебнуться в массиве информации, будет служить своеобразной путеводной звездой, придаст обучению структуру. Также на собственном приложении будут сразу отрабатываться полученные знания, совершаться и исправляться ошибки, а в программировании практика – основа всего.
2. Курсы гарантируют системный подход к обучению, причем записаться на них можно с 0. Первые несколько занятий обычно посвящают базовым моментам в разработке, а потом переходят к более сложному материалу. Однако нужно понимать, что мало посещать занятия, слушать и читать материалы, нужно работать, пытаться создать что-то свое. На многих онлайн-курсах предусмотрены домашние задания и обратная связь с куратором, эту возможность нужно использовать с пользой и максимально отработать еще во время курсов непонятные и сложные моменты. Некоторые онлайн-университеты помогаю своим лучшим выпускникам с трудоустройством, это отличный старт для начала карьеры.
3. Занятия с наставником – наименее популярный вариант. Больше распространен как вариант наставничества на работе. Однако нет ничего плохого в том, чтобы позаниматься с репетиром и освоить новую профессию. Есть опасность получить однобокие знания, т. е. наставник научит только тому, чем пользуется сам. Однако для старта этого хватит.
4. Обучение в ВУЗе тоже проблематичный вариант: ВУЗов, обучающих мобильной разработке, немного. Это НИИ ВШЭ, РГУ, МИЭТ. Обучение здесь дорогое, долгое, однако для выпускников школ это вполне подходящий вариант. Знания будут широкими и разнообразными. В основном в институтах представлены общие программы по прикладной информатике и вычислительной технике, где выделен блок и на разработку приложений для мобильных устройств. Если в старшей школе уже есть интерес к программированию, можно попытаться поступить в один из ВУЗов.

Реализация: интерактивный Web Container

в первой версии

Решение

▍2. Двустороннее взаимодействие приложения и веб-контейнера

1. Воздействие Jasonette на веб-контейнер. А именно, невозможно было вызывать JavaScript-функции, расположенные в контейнере, из Jasonette-приложения.
2. Воздействие контейнера на Jasonette. Невозможно было вызывать нативные API из кода, расположенного в контейнере.

Решение

JSON-RPCДо использования JSON-RPC Jasonette и веб-контейнер взаимодействовать не могли. После внедрения JSON-RPC стала возможна двусторонняя коммуникация основного приложения и контейнера

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

документации

Пример

Приложение для создания QR-кодов

1. для ввода текста в нижней части окна на 100% нативен.
2. QR-код генерируется веб-приложением, размещённым в веб-контейнере.
3. Когда пользователь вводит некий текст в поле и нажимает кнопку , осуществляется вызов действия агента веб-контейнера, что приводит к JS-функции .

здесь

Решение

Внедрение JS-кода в страницу, загруженную в веб-контейнер

▍4. Обработка переходов по URL

1. В режиме «только чтение» веб-контейнер рассматривается как элемент только для чтения, при этом все события, такие, как касание или прокрутка, игнорируются. Все веб-контейнеры находятся в состоянии только для чтения до тех пор, пока их не переключат в режим обычного браузера, так, как описано ниже.
2. В режиме «обычный браузер» веб-контейнер может взаимодействовать со страницей так, как будто мы работаем с обычным браузером. Включить этот режим можно, записав в атрибут значение .

Решение

Действие для обработки взаимодействий со ссылками

1. Если URL содержит , открывается нативное окно для входа в систему.
2. Если URL этой строки не содержит, выполняется действие, задаваемое параметром , в результате наша программа ведёт себя как обычный браузер.

Как начать путь в mobile development

Прежде всего необходимо ознакомиться с азами ООП, т.е. объектно-ориентированного программирования. В интернете можно найти массу бесплатных статей и видео-руководства по теме.

Самые популярные ЯП в данном случае – Objective_C и, конечно же, Java. Последний настоятельно рекомендуется всем без исключения, потому что это не только главный язык в программировании под ОС Android, но и такая же главная платформа для разработки ПО.

Как только будут усвоены азы Java-программирования, нужно практиковаться, практиковаться и еще раз практиковаться – в штате офиса, на удаленной основе, на фрилансе или как частный специалист. Освоив Java, можно смело приступать к разработке Android- и  iOS-ориентированных платформ.

Где можно освоить профессию разработчика

Как и обещал, ниже я перечислю лучшие курсы по созданию мобильных приложений:

• «Разработчик мобильных приложений» от университета онлайн-профессий Skillbox (страница — skillbox.ru/course/profession-mobdev). Здесь вас научат создавать приложения на Android или iOS и окажут помощь в трудоустройстве. По окончании обучения вручается диплом.
• «Профессия Android-разработчик» — еще один курс от Skillbox (сайт — skillbox.ru/course/profession-android-developer). Обучение длится 20 месяцев. Все бонусы с дипломом, практикой и трудоустройством те же.
• «Android разработка — с нуля до профессионала» от Udemy (сайт — udemy.com/course/android-kak-po-notam-a). Здесь вы получите основы Java, Kotlin, а также создадите 21 приложение, включая чат и приложение для заказа такси. Курс состоит из 40 часов видео и заданий.
• «React Native 2020. Мобильные приложения на JavaScript» — другой курс от площадки Udemy (udemy.com/course/react-native-complete-guide). В программе создание мобильных приложений для Android и iOS на JavaScript + React JS. Это 13 часов видео, 2 статьи, 84 ресурса для скачивания и сертификат по окончании программы.
• «Android-разработчик с нуля» от Нетологии (netology.ru/programs/android-app#). За 10 месяцев обучения вы научитесь программировать на Java и Kotlin. Вас ждут вечерние онлайн-вебинары и практические задания, портфолио и диплом о профессиональной переподготовке.
• Программист Android» от Geekbrains (geekbrains.ru/professions/android_developer). Курс длится 7 месяцев и предусматривает живое общение с экспертами-практиками, вебинары, выполнение задач и стажировку.
• «Быстрый старт в разработке Android-приложений» от Coursera (сайт — coursera.org/learn/quick-start-to-android). Бесплатный 20-часовой курс для новичков. По окончании можно получить электронный сертификат, ссылкой на который можно делиться в сети.

На сегодня это все. Желаю Вам успехов в реализации задуманных идей.

Не забудьте подписаться на обновления блога, чтобы не пропустить новые полезные публикации.

До скорого!

Автоматическое разрешение конфликтов при синхронизации

В ходе синхронизации мобильного приложения, работающего в offline-режиме, могут возникать ситуации, когда переданные в Creatio данные не могут быть сохранены по ряду причин. К таким причинам могут относиться следующие:

• Запись была слита в Creatio с другой дублирующейся записью, поэтому ее не существует.
• Запись была удалена из Creatio.

Каждая из приведенных выше ситуаций обрабатывается мобильным приложением автоматически.

Слияние дублей

Алгоритм разрешения конфликта, возникающего по причине использования данных, которые в Creatio были удалены в ходе процедуры слияния дублей:

Как видно на схеме, в ходе синхронизации приложение сначала забирает на сервере информацию о том, по каким записям с момента последней синхронизации производилось слияние дублей. А именно какие записи были удалены и какие записи их заменили. Если в ходе экспорта не было никаких ошибок, то далее выполняется импорт. Если же произошла ошибка, связанная с исключением внешнего ключа (Foreign Key Exception), или ошибка, связанная с тем, что на сервере не была найдена какая-то из записей (Item Not Found Exception), то выполняется процедура разрешения этого конфликта со следующими этапами:

• В экспортируемых данных ищутся колонки, содержащие “старую” запись.
• В найденных колонках “старая” запись заменяется новой, в которой данные объединялись.

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

Запись не найдена

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

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

Мифы профессии

• Мобильные разработчики говнокодеры создают плохой код, не оптимизируют приложения и вообще дилетанты. Здесь речь идёт примерно о такой же ситуации, как с PHP: язык огребает горы хейта из-за того, что в него легко войти и горе-вебмастера написали на нём ну очень много плохих приложений. В мобильной разработке действительно много дилетантов и любителей, что немного портит общую картину. Но распространять выводы на каждого программиста точно не стоит.
• Мобильные разработчики мало зарабатывают. Всё зависит от вашего опыта, квалификации и способности решать задачи вашей компании.
• Мобильная разработка — это недопрограммирование, не труъ. С каких это пор Java, Swift, Kotlin и т.д. — это не труъ?! А если серьёзно, корни этого мифа уходят к готовым конструкторам и универсальным крутым средствам типа Flutter, которые здорово облегчают и ускоряют работу и портируемость приложения. Это так не работает: хорошее приложение без кода и глубокой разработки не получится.
• В мобильной разработке часто возникают конфликты между разработчиком и заказчиком. Чистая правда, так оно и есть. Решается с помощью сбора требований, чётко прописанного технического задания и поэтапной разработки с тестированием и согласованием в конце каждого спринта.

Плюсы и минусы профессии

Плюсы

1. Высокооплачиваемая, востребованная профессия.
2. Чёткость стандартов и гайдлайнов значительно облегчают дизайнерскую часть работы мобильного разработчика. Гайдлайн — это подробные описания элементов в мобильных приложениях, причём для каждой платформы они свои.
3. Вложение ресурсов для мобильной разработки невелико.

Минусы

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

Кто такой разработчик мобильных приложений

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

Задачи мобильного разработчика:

• создание ТЗ по разработке приложений;
• работа с клиентами, обсуждение функционала программы, внешнего вида, согласование этапов;
• разработка архитектуры, программирование самого приложения;
• работа с дизайнером;
• публикация готовой программы в магазинах приложений, например, Google Play, AppStore и др.

Готовая программа должна не только выполнять свои функции, но и быть удобной для пользователей, интуитивно понятной. Тогда им будут пользоваться миллионы людей по всему миру. Кстати, желательно, чтобы приложение поддерживало хотя бы несколько базовых языков.

Зарплата разработчика мобильных приложений

Минимальные зарплаты по вакансии mobile developer составляют 60-65 тыс. руб. Однако почти все работодатели требуют, чтобы у специалиста был хотя бы минимальный опыт работы и наличие базовых навыков: умение писать программы для Android и работать с Java.

Как только у работника появляется опыт и реальные проекты за плечами, его зарплата начинает расти. Специалистам с опытом от 2 лет предлагают зарплаты в районе 100 тыс. руб. Однако и требования к навыкам повышаются.

Опытные разработчики, владеющие различными инструментами, умеющие работать в команде, править чужие ошибки, активно занятые в сфере разработки минимум 3-5 лет, могут получать свыше 150 тыс. руб. Также возможно сотрудничество с зарубежными компаниями, тогда доход будет составлять более 200-300 тыс. руб. в месяц.