Кому нужен этот HTML: «Как я за 2 месяца запилил платежный сервис — и отправил на свалку»

    Выбор между дыбой и колесованием — 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 и столкнулись с какой-то проблемой, пишите в комментариях. Возможно, я смогу вам помочь, поскольку уже искал способ решения такой же задачи. В интернете мне тогда не удалось найти подсказок — до всего доходил сам. И теперь буду рад ими поделиться.
    UBANK
    26,00
    Компания
    Поделиться публикацией

    Комментарии 12

      –3
      Для игр без шифрования и достаточно простых должно сгодиться. Но вот мы столкнулись с тем, что наш код, работающий нормально на iOS и Android на WinPhone вообще не запустился.
        0
        Странно, портирование на WinPhone у нас не вызвало особых проблем, кроме очень заковыристого решения для того что бы убрать серое выделение нажимаемых элементов
          0
          Да, я думаю и мы разберемся. Я написал комментарий к тому, что HTML5 — он тоже разнообразно работает на платформах. Т.е. не вот прям панацея. Решим проблему — могу отдельную статью накатать про разницу работы веб-гибридных приложений на ios-androd-wp-tizen
            0
            />
            и
            -ms-touch-action: none;
            ?
              0
              Судя по описанию это применимо к IE11, когда разрабатывалась версия под WInPhone был еще WP7, с IE9 на борту. В итоге проблема решилась отлавливанием клика на уровне нативного кода, определения координат, отмена действия и потом уже делегирования его в WebView
          +6
          Напишите отдельную статью с решениями проблем, с которыми вы столкнулись (по крайне мере те, которые вспомнятся). Ими тогда и гуглокодеры смогут воспользоваться. Ну и хабражители этому будет больше рады, чем просто статье частном опыте частной компании на частном приложении.
            –1
            >Сравните: первую, вполне работоспособную HTML-версию, я сделал в одиночку за два месяца. Разработка нативных приложений под iOS, Android и Windows Phone заняла около года работы целой команды программистов

            Нативная разработка не такая уж сложная. Видимо, сказывается разница в опыте по html и по нативным средствам.
              +2
              Если вы в одиночку за два месяца написали на html, то нативное, при должной сноровке, точно не год и точно не команда.
              Хотя есть такие «команды», которые и за два не напишут, что уж тут…
              Как приснопамятной «Формуле любви»:
              … — За день сделаю.
              — А за два?
              — Ну, сделаем и за два…
              — А за пять дней?
              — Ну-у, ежели постараться, можно и за пять.
              — А за десять?
              — Ну барин, ты задачи ставить! За десять дён одному не справиться. Тут помощник нужен…
                +2
                Я думаю тут дело не столько в различии сложности, а в бездне меджду «почти готовым протипом» и реально готовым приложением в продакшне.

                разрабатывал и на PhoneGap и на нативном ADT — не могу сказать что что-то откровенно быстрее.
                0
                На сколько мне, дилетанту, известно, шифрование и любой другой тяжёлый код можно подключить на PhoneGap обычными Java модулями и подружить их с JavaScript. Это работает по крайней мере под Android, полагаю что-то похожее и на других платформах. Не берусь утверждать, но что-то мне подсказывает, что ваши разработчики просто плохо изучили инструменты, которыми пользовались.
                  +1
                  Да, именно так и реализовывалось. Проблема в том что в итоге нативной логики достаточно много, и под каждую платформу она своя, что уменьшает преимущества портируемости
                    0
                    На сегодня столкнулся с той же проблемой в PhoneGap. Конечно, можно нативную сторону подключить и через мост вести общение с операционкой. Но в один прекрасный момент приходит понимание, что нативки уже больше, чем того же html и без пол литра не разобраться. На данный момент пришло понимание, что начинать надо было бы UI Based app разрабатывать исключительно нативно. А html оставить верстальщикам сайтов. Весь профит технологии уходит, когда приходят четкие требования использовать ту или иную возможность девайса.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое