Cordova. Опыт Enterprise-проекта +7


AliExpress RU&CIS

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

Немного истории

Четыре года назад для нужд нашей организации было принято решение написать мобильное приложение для двух платформ (iOS и Android). Программист был один, а опыта работы с нативными языками на тот момент не было. Для этих целей мы решили попробовать кроссплатформенную схему разработки от Cordova.

Выбор фреймворка

Оказалось, что реализовать проект в основе которого лежит один подход, можно по-разному. Выбрав Phonegap можно было получить платформу Cordova, плюс несколько полезных инструментов для отладки и демонстрации приложения, а главное, облачную сборку для разных платформ (не бесплатно). Для тех кто не в курсе, приложения для iOS собираются только на macOS, а для Android, можно собирать как на macOS, так и на Windows. Судя по всему идея заработать на облачной сборке у Phonegap провалилась, так как Adobe прекратила инвестиции в проект. Другой путь это Ionic, команда этой группы предлагает набор инструментов охватывающий все этапы разработки гибридного приложения от А до Я. Здесь к платформе Cordova вы получите возможность интеграции с популярными фреймворками (Angular, React, Vue), инструменты для бесплатной и платной разработки, подробную документацию и многое другое. Мы пошли по пути наименьшей зависимости от кого бы то ни было. Взяли Cordova, а в качестве фреймворка для single page application выбрали менее хайповый, но довольно симпатичный Framework 7 (так же были доступны Angular, React, Vue и другие). В реальном проекте трудности обычно возникают либо с плагинами, либо с особенностями самих платформ. Так как команда Ionic предлагает готовые решения известных проблем, многим, будет легче поддерживать проект присоединившись к ним.

Плюсы и минусы

После нескольких лет работы с платформой могу выделить некоторые значимые плюсы и минусы. Далее в данной статье буду говорить о некоторых пунктах подробнее.

Плюсы:

  • не нужен программист для каждой платформы на начальном этапе

  • лёгкая интеграция с приложениями имеющими веб интерфейс

  • разнообразие фреймворков для разработки одностраничных приложений

  • возможность обновлять код без выпуска новых сборок

  • возможность использования большого количества бесплатных веб компонентов

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

Минусы

  • поддержка существующих плагинов

  • особенности браузерных компонентов webview

  • неудобная работа с файловой системой 

  • многозвенная схема отладки приложения

  • вечно-зеленый компонент webview у Android

Программисты и плагины

На начальном этапе можно действительно обойтись без навыков нативной разработки, но по мере увеличения количества плагинов в вашем проекте, это будет неизбежно. Дело в том, что код плагинов быстро устаревает и часть функционала либо перестает работать, либо будет работать неправильно в определенных версиях ОС той или иной платформы. Бывают ситуации и хуже. Так обновленный Xcode поддерживающий последнюю версию платформы iOS, может отказаться собирать ваш проект, обнаружив в нем плагин написанный на предыдущей версии swift. Пример конечно экзотичен, потому как 99% плагинов под iOS написаны на Objective C, тем не менее, с этим приходилось сталкиваться. Немалое количество плагинов сообщество энтузиастов-разработчиков забросило, а те что поддерживаются, порой ждут обновлений довольно долго. Так же, нужного плагина может и не быть вовсе. В итоге, чтобы иметь актуальный и работающий проект, вам необходимо будет вносить изменения в нативный код плагинов, писать их с нуля или просто редактировать главные модули приложения (на Objective C и Java соответственно).

Интеграции

Интегрировать в проект отдельные элементы веб приложений или полноценные  приложения довольно удобно. Ваш проект работает в браузере, а это значит, что вы сможете загружать в него веб страницы, делать запросы к веб сервисам, использовать возможности WebDAV и многое другое. При HTTP запросах из вашего приложения к другим веб ресурсам, вы наверняка столкнётесь с проблемами аутентификации, CORS ограничениями, нюансами работы с сертификатами итд. Полноценные веб приложения лучше загружать в отдельный браузерный компонент с помощью плагина. Если потребуется, вы даже сможете настроить обмен данными между вашим основным браузерным компонентом (webview) и внешним. При этом, пользователь не будет покидать окна мобильного приложения. Как показала практика, многие десктопные приложения уже имеют веб интерфейсы, а некоторые из них, даже адаптированы к мобильным телефонам и планшетам. Так, например, мне удалось интегрировать веб версии клиентов MS Outlook, 1С, Redmine. Конечно, там не все гладко, неоднородность интерфейсов, отсутствие поддержки touch экранов, ограничения при работе с файловой системой и другие нюансы. Но спектр возможностей от таких интеграции, по-моему, перевешивает все недостатки.

WebView

Несмотря на хорошую поддержку стандартов со стороны браузерных компонентов двух платформ, сами webview имеют серьезные отличия. WKWebView - так называется актуальный компонент для iOS, имеет кучу ограничительных политик безопасности, в том числе и дурацких, среди которых невозможность загрузки контента по протоколу File. При этом, является намного более производительным и быстрым чем webview у Android. Ниже таблица с некоторыми показателями двух компонентов, которые были важны в реализации моего проекта.

iOS

Android

Поддержка стандартов

хорошо

отлично

Поддержка touch

отлично

удовлетворительно

Рендеринг анимаций

отлично

хорошо

Поддержка WebRTC

нет

есть

Встроенный вьювер файлов

основные форматы Microsoft Office, OpenOffice, PDF, изображения

изображения

Отладка приложения

хорошо

отлично

VPN

При работе с корпоративными удаленными ресурсами (веб приложения, сервисы, базы данных), которые не являются публичными, возможно, придётся использовать VPN. Такой подход является довольно логичным, но затея не является безобидной. В реальности это накладные расходы на разработку и обслуживание, плюс негативный опыт ваших пользователей. Идеальным решением будет интеграция VPN клиента в приложение, что тоже не просто. Так, например, библиотеку с открытым кодом Open VPN можно интегрировать в проект с помощью нативного кода и предварительно скомпилированных библиотек. Плагина для Cordova нет, возможно, появится позже. Здесь так же придется немного помучиться с приложениями и сервисами работающими по протоколу HTTPS. Дело в том, что последние в корпоративной среде используют либо самоподписанные сертификаты, либо сертификаты выданные локальным центром сертификации, что для ваших webview не являются доверенными. Этот вопрос решается для двух платформ, но универсального и однозначного подхода здесь нет. Кто-то считает, что доступ к ресурсам внутри сети может быть осуществлен по-обычному HTTP. В этом есть логика, но не надо забывать, что весь трафик в данном случае будет передан без шифрования. Можно научить приложения для iOS и Android работать по HTTPS с ресурсами внутри сети и такой вариант считаю предпочтительным.

Провайдер сервер за прокси

Реализация такого сервера задача необходимая, если конечно, ваше приложение собирается получать push-уведомления. Для работы с APNS (служба Push-уведомлений Apple), потребуется установка соединения только по протоколу HTTP v.2 + TLS. Библиотеки и API популярных серверов научились работать с HTTP2, но не все они умеют работать с прокси серверами и здесь, возможно, будут сложности. Я какое-то время для этих целей использовал Apache, позже перешёл на собственный сервер, который был написан на Nodejs. Это оказалось невероятно просто и удобно. FCM для Android в этом смысле не такой требовательный (работает на HTTP v.1), при работе с ним проблем не наблюдалось.

Распространение приложений

Для iOS приложений придется оплачивать ежегодную enterprise лицензию, для Android это бесплатно. Плюсом enterprise лицензии для iOS является отсутствие модерации кода и возможность свободного распространения приложения без App Store. Достаточно иметь публичный сервер на котором у вас будут файл приложения и файл манифеста. Ссылку на манифест в специальном формате вы и будете распространять среди новых пользователей вашей организации. У Android приложений ограничений в распространении нет изначально. Последние рекомендую распространять через стандартные магазины приложений, так как APK загруженные не из магазина, по умолчанию, не являются доверенными для ОС Android.

Заключение

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




Комментарии (8):

  1. Imbecile
    /#22912266

    Решал эти проблемы, путём их избегания — использовал Xamarin. Помимо отсутствия несколько раз упомянутых проблем с файлами и web view, он решает и проблему нативного кода — там всё равно пишешь на C#. Правда в Xamarin другие проблемы и их есть достаточно.

    Но за статью спасибо. Интересно было узнать про жизнь в других мирах.

    • GMK82
      /#22912306

      Пожалуйста. По всей видимости универсальные решения без ложки (или половника) дегтя не обходятся:)

      • Imbecile
        /#22912346

        Думаю, что с нативными тоже не всё так гладко.

        • AlexWoodblock
          /#22920014

          Как человек, работающий с нативными приложениями уже 8 лет — нет, там все как раз-таки на порядки более гладко :)

    • Kromeshnaja
      /#22912624

      Можно пример проблем? Спасибо

      • GMK82
        /#22913194

        Вы про Cordova, Xamarin или натив?

        • Kromeshnaja
          /#22914932

          Xamarin

          • Imbecile
            /#22915012

            Стабильность работы. Вылеты на ровном месте с причинами где-то в глубине кода Xamarin. Мой app center забит отчётами. Спасает, что часть вылетов можно поймать внутри приложения и заглушить. Но не все.

            Скорость работы. Для enterprise приложений вполне хватает. Но иногда какой-то компонент начинает жутко тупить. И приходиться несколько дней ковырять исходники, чтобы понять, почему?

            Глюки компонентов Xamarin Forms. Как человек уже больше трёх лет работающий с Xamarin и постоянно ковыряющий его исходники — там такое периодически говно, что кровь из глаз. Сейчас сильно лучше стало. Но всё равно встречается. И из-за этого сами компоненты ведут себя непредсказуемым образом.

            Заключение. Xamarin Forms — хорошая платформа, но у неё есть проблемы, которые не решаются годами. И, похоже, не будут решены, поскольку впереди MAUI.