{"id":14277,"url":"\/distributions\/14277\/click?bit=1&hash=17ce698c744183890278e5e72fb5473eaa8dd0a28fac1d357bd91d8537b18c22","title":"\u041e\u0446\u0438\u0444\u0440\u043e\u0432\u0430\u0442\u044c \u043b\u0438\u0442\u0440\u044b \u0431\u0435\u043d\u0437\u0438\u043d\u0430 \u0438\u043b\u0438 \u0437\u043e\u043b\u043e\u0442\u044b\u0435 \u0443\u043a\u0440\u0430\u0448\u0435\u043d\u0438\u044f","buttonText":"\u041a\u0430\u043a?","imageUuid":"771ad34a-9f50-5b0b-bc84-204d36a20025"}

Разработка гибридных мобильных приложений

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

Еще пожалуй опишу свой опыт, чтобы был очевиднее ход моих мыслей. Я ранее 5 лет в роли ведущего программиста разрабатывал мобильные приложений под заказ на iOS и воспитал 8 программистов на iOS, которые также программировали мобильные приложения.

Учить разрабатывать мобильные приложения на iOS крайне долго, чтобы выйти на достойный уровень уходит 4-6 месяцев. Само собой кандидатов достойных к обучению крайне мало.

Если говорить о своем опыте разработки, то это:

  • тесная работа с программистом серверной части, которая порой выливается в твое тестирование и обсуждение API
  • свои баги независимо от Android, самый выбешивающий комментарий к багу «а на Android вот так-то работает, а в iOS нет»
  • необходимость адаптации дизайна под iOS на свое усмотрение, к сожалению в наших проектах это был один вид дизайна или для Android или для iOS в зависимости от того к чему заказчик отдавал сам предпочтение
  • реализация всевозможных костылей, вроде а сделайте в заголовке посередине логотип, хотя по гайдам этого делать не рекомендуется

И основное что долгое время держало именно в разработке нативных приложений: «приложение работает быстро». За счет обмена с сервером посредством API, эти данные кэшируются и используются повторно.

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

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

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

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

Давайте разберем варианты реализации гибридных мобильных приложений.

Xamarin (ксамарин) от Microsoft

Пишется на языке C # с использованием .NET, реализованы компоненты вызова нативных элементов, таким образом скомпилированное приложение работает по сути как нативное. Минус очевидный, нужно изучать C #. Само собой превращается в плюс для тех кто этим языком уже владеет.

React Native

Смысл тот же что и в Xamarin, только создание элементов экрана происходит в процессе его открытия на мобильном телефоне, интерпретируя скрипты на JS. Идея в том чтобы посредством языка JavaScript используя биндинги вызывать любые нативные компоненты, тем самым реализовывать нативное приложение, с соответсвующим быстродействием. Минусы: нужно изучать JS классы и методы для реализации мобильного приложения.

Cordova/Phonegap (кордова, фонегап)

Реализация на языке html + js вызовы плагинов нативных функций. Что важно наиболее простая адаптация для вебщиков, т.к. по сути создается мобильный сайт. Из минусов: грамоздкость оболочки, за счет совместимости с древними версиями iOS и Android. Адаптирован на работу с сервером по API, файлы верстки лежат в ресурсах приложения.

WebView + JS функции

Можно сказать что это тот же Phonegap, только если срезать с него 90% древних наростов и хранить файлы не в ресурсах приложения, а на сервере. Одно из главных преимуществ, любой нативщик добавит те или иные функции на ваш вкус. Например вам нужно в фоновом режиме GPS обрабатывать особым образом, а результат отправлять на сервер. Плюсы: все просто, любой веб разработчик пишет на php/html мобильный сайт, дополнительно нужно по итогу расставить несколько js функций, например, нативные переходы между экранами, получение gps или считывание QR кода с камеры телефона.

Важнейший ньюанс

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

Но это и порождает серьезные минусу на мой взгляд:

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

Наш вариант

Мы выбрали вариант с читым webView, добавили необходимые нам JS функции, которые работают с нативными функциями. В верстке мы используем Bootstrap, а в роли серверной части и админки используем 1С-Битрикс. Тем самым у нас есть унифицированная выборка и запись данных от bitrix framework, которую программист в комплексе с остальными тонкостями может освоить за неделю. Понятное управление данными для админа сервиса буквально с небольшими настройками уже после установки. Один программист управляет всеми процессами создания приложения. Использование компонент и разделение визуальной части и работу с данными позволяет распараллелить разработку над одним проектом до 5-и программистов, для ускорения производства.

Итоги

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

0
1 комментарий
Лёха Вованыч

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

Ответить
Развернуть ветку
-2 комментариев
Раскрывать всегда