Выбор между дыбой и колесованием — HTML5 и нативной средой программирования — рано или поздно встает перед любым мобильным разработчиком, которому важно присутствовать на разных платформах. Нас в UBANK он тоже не обошел стороной.
В 2011 году мы начинали именно с html-версии, которая работала на Android. Готовились портировать ее на другие платформы, несмотря на трудности, с которыми пришлось столкнуться. Но в итоге через два года свернули этот проект и заменили проект на нативные приложения.
В этой заметке ведущий разработчик UBANK Александр Путилин постарается рассказать о нашем опыте создания кросс-платформенного приложения, а также поделится кое-какими идеями о том, зачем все же нужен HTML5 и как его можно победить. Заинтересованные в практических вопросах приглашаются в комментарии.
Бета на Bada
Александр Путилин:
— В HTML нас, разумеется, привлекала мультиплатформенность. Перед UBANK стояла задача присутствовать на всех популярных устройствах. Казалось, что создать один раз веб-приложение и потом портировать его на все платформы будет намного проще, чем писать для каждой нативное.
Разработка началась в 2011 году. Мы решили начать с платформы Bada. Samsung для нашего стартапа был стратегическим партнером. А это была его родная платформа, на ней корейцы выпустили порядка 200 моделей телефонов. В 2010-2011 годах она занимала около 10% российского мобильного рынка и казалась перспективной.
Я начал писать приложение, использовав фреймворк PhoneGap. С задачей удалось управиться за пару месяцев. К концу 2011 года наша версия приложения вышла на уровень достаточно стабильной беты.
Но тут случилась небольшая неприятность: Samsung неожиданно для всех решил свернуть Bada. Корейцы начали разрабатывать операционную систему Tizen, планируя в будущем объединить ее с Bada. Выпускать наше приложение на Bada уже не имело смысла, хотя она и была готова.
Мы, впрочем, не очень расстроились. Ведь ненативная версия позволяла нам легко портировать приложение на любое устройство, ведь так? Вот и ладно. Мы занялись тем, что стали портировать нашу разработку на Android, так и не выпустив UBANK на Bada в свет.
Но тут все оказалось сложнее, чем мы думали.
Реслинг с Android
Первой проблемой стало шифрование. Изначально ведь фреймворк предназначен просто для создания приложений — формочки, тексты, вывод данных, в общем, ничего сложного. А для нашего платежного приложения требовалось шифрование. При этом математика в java-script работает откровенно слабо — на порядки медленнее, чем в нативном коде.
Чтобы реализовать шифрование и не заставлять пользователя ждать окончания операции пару минут, нам пришлось написать куски нативного кода, которые взаимодействовали бы с html-интерфейсом. Таким образом нативный код в приложении составил около 10%. И это было бы, наверное, неплохо, если б остальная часть кода работала как надо. Но нет.
У Android, как известно, слишком много модификаций, которые сильно отличаются друг от друга. На iOs в новых версиях добавляются новые возможности, но обычно старые не отваливаются. На Android же то, что отлично работает на 2.2, уже почему-то не работает на 4.
Анимация из Android 2.2, в четверке шла серыми полосами. А та, которую мы сделали под четверку, на втором тупо тормозила. А ведь еще бы и третий Android, и на нем не работало ни то, ни другое.
Много проблем доставила и клавиатура. В браузере на Android она вела себя как ей хотелось: могла закрыться на входе в поле, могла при переходе на новое поле остаться на старом. C этим приходилось бороться — и снова нативным кодом.
С решением подобных мелких проблем мне пришлось изрядно повозиться. Причем по нативной разработке хотя бы есть документация, а тут приходилось до всего доходить экспериментальным путем, то есть методом научного тыка. Эксперименты, впрочем, завершились довольно благополучно: первая версия UBANK была именно HTML-приложением, портированным на Android. Однако на этом славная история этого проекта и закончилась.
Работа в стол
Разумеется, перед UBANK как мобильным платежным сервисом стояла задача присутствия на всех основных смартфонах. Поэтому параллельно мы запилили версии под iOS и Windows Phone.
Тут мы повторяли уже проделанный путь. В каждом случае около 10% кода приходилось переписывать, чтобы обеспечивать нативное шифрование. А также бороться с разными огрехами, которые появлялись при портировании.
Эта прекрасная работа так никогда и не увидела свет. Когда ее посмотрели наши маркетологи, они сразу ее зарубили без лишних сантиментов. И, в общем-то, совершенно правильно сделали.
Как известно, iOS — сильно унифицированная среда. Пользователи айфонов уже привыкли к стандартным элементам дизайна. А переработать внешний вид нашего веб-приложения так, чтобы оно адекватно смотрелось на iOS, оказалось практически невозможно. Хотя мы старались. Но все равно было видно, что-то тут не то. Про Windows Phone с его плиточным интерфейсом и говорить нечего.
Мы еще предприняли попытку выпустить приложение под Simbian — Nokia тогда была актуальна. Но оказалось, что Simbian не давал возможности шифрования в нативном коде. Мы просто не смогли бы обеспечить на нем должную степень безопасности.
В итоге мы в UBANK пришли к неизбежному решению: серьезная кросс-платформенная разработка в HTML для мобильных платформ — полная утопия. Портирование оказывается не таким безболезненным и легким, как того хотелось бы, если перед вашим приложением стоят действительно серьезные задачи. А особенности дизайна каждой платформы не позволяют сделать так, что продукт выглядел на пять на всех устройствах, имея один и тот же внешний вид интерфейса.
Один в поле воин
Теперь все наши сервисы, которые мы выкатили полгода назад, — это полностью нативные приложения. Значит ли это, что HTML5 надо отправить на свалку истории?
Не думаю. Мне кажется, у каждого инструмента есть свои преимущества — нужно только правильно его использовать. На основании своего опыта я бы сказал, что HTML прекрасен для прототипирования. Он дает возможность практически молниеносно увидеть, как все будет работать.
Сравните: первую, вполне работоспособную HTML-версию, я сделал в одиночку за два месяца. Разработка нативных приложений под iOS, Android и Windows Phone заняла около года работы целой команды программистов, численность которой за это время на разных этапах менялась от двух до семи человек.
Для быстрого старта HTML — инструмент неплохой. Но закладывать его как основную технологию компании не стоит, потому что портированное приложение всегда будет хуже нативного — и работать, и выглядеть.
Если вы прямо сейчас занимаетесь разработкой мобильного приложения на HTML и столкнулись с какой-то проблемой, пишите в комментариях. Возможно, я смогу вам помочь, поскольку уже искал способ решения такой же задачи. В интернете мне тогда не удалось найти подсказок — до всего доходил сам. И теперь буду рад ими поделиться.
Автор: marinaler
