Я хотел бы пролить свет на инструмент, который открыл недавно. Дамы и господа, с большим удовольствием представляю вам - NativeScript.
Что в этом такого особенного?
У нас уже много лет есть гибридные приложения. Вы (разработчик) пишете HTML / CSS, приправленный некоторым JS-кодом, на основе фреймворка, который развертывает все наши ресурсы на устройстве, и вуаля - приложение оживает. Для этого все взаимодействия с пользователем проходят через компонент WebView, который на практике является встроенным браузером устройства. Распространенной практикой является использование Apache Cordova в качестве моста между JS-кодом, работающим в «браузере», и собственными драйверами устройств.
AppBuilder, Intel XDK и Ionic могут показаться совершенно разными вещами, но на самом деле все они полагаются на элементы DOM в WebView для создания пользовательского интерфейса и на Cordova для доступа к оборудованию. Такой подход, безусловно, продуктивен, но имеет несколько неприятных побочных эффектов. Конечный продукт по-прежнему больше похож на сайт на маленьком экране, чем на мобильное приложение. Ionic поставляется с множеством предварительно созданных элементов, которые имитируют естественный внешний вид, но все же есть некоторые тонкие различия, очевидные для натренированного глаза. Другая серьезная проблема возникает, когда все становится нетривиальным, например, если мы хотим вставить базу данных в наше приложение или отрендерить какой-нибудь причудливый переход пользовательского интерфейса. Скорее всего, мы достигли предела производительности, хотя за последний год в этом направлении были сделаны некоторые серьезные улучшения.
Подход NativeScript помещает его на другую сторону спектра, ближе к React Native или Xamarin (хотя C # здесь является предпочтительным языком). Он не использует WebView, поэтому никаких манипуляций с DOM не происходит. Он по-прежнему использует JS, но в совершенно другой среде. Все элементы пользовательского интерфейса описываются представлениями XML, которые в процессе сборки преобразуются в собственные объекты пользовательского интерфейса. Также NativeScript является бесплатным и open-source, поддерживается компанией Telerik.
Как это работает.
И iOS, и Android поставляются с движками JS (Nitro и V8 соответственно), которые выполняют код JS внутри своих сборок в браузерах. Эти программы на C ++ могут взаимодействовать с внешним кодом C ++ (так называемые ловушки в случае V8). На практике, добавляя функциональные возможности в движок JS, мы добавляем вещи в сам язык JS, которые не являются частью спецификации языка. Если вы использовали NodeJS, вы, вероятно, уже знакомы с этой концепцией, потому что именно так она работает. Используя V8 на стероидах, JS узла может работать с файловой системой, перехватывать сетевые запросы, передавать двоичные данные и т. Д. В этом смысле мы можем рассматривать NativeScript как NodeJS для мобильных устройств, который работает внутри виртуальной машины (хотя это это немного упрощение). Стандартный JS упакован с объектами, которые отображают собственные объекты Java / Objective-C / Swift на соответствующем устройстве. Конечным результатом является JS-доступ ко всем нативным компонентам. Сюда входят элементы пользовательского интерфейса (которые мы обычно описываем с помощью XML в Android, но после сборки превращаются в код Java). По словам создателей, код NativeScript примерно на 10% медленнее по сравнению с чисто нативным кодом. Даже если мы скептически относимся к этим данным, они все равно выглядят чертовски хорошо. Более подробную информацию по теме вы можете найти здесь.
Впечатления.
Начиная с хороших:
1. Документация. Если вы видели их руководство по началу работы, возможно, вы заметили его объем. Сотрудники Telerik постарались описать все, что нам нужно знать об их изобретении. Сюда входят не только особенности API, но и некоторые общие обзорные статьи.
2. Структура проекта: Файлы в проектах NativeScript хорошо организованы. Существует соглашение об именах, которое помогает инструментам CLI понять, как их создавать. В качестве бонуса вы можете использовать TypeScript, чтобы код вашего приложения был хорошо организован и масштабируем, поскольку это главный аргумент в пользу TypeScript.
3. Поддержка Angular: По мере того, как фреймворк Angular набирал обороты, он практически стал стандартным способом создания приложений NativeScript. Конечно, можно использовать что-то еще, использовать только TypeScript или даже простой JavaScript. Существует модуль привязки данных с синтаксисом, аналогичным тому, который KnockoutJS использует для привязки разметки пользовательского интерфейса к объектам данных. Я бы рекомендовал придерживаться стека Angular / TypeScript, поскольку большинство примеров кода, которые вы найдете в Интернете, также используют его.
4. Отладка. Отладчик похож на тот, который использует NodeJS. Он поставляется с функцией автоматической перезагрузки, поэтому нам не нужно часто перестраивать приложение. Его также легко интегрировать с текстовым редактором, таким как Visual Studio Code.
5. Поддержка собственных библиотек: поскольку мы получаем доступ ко всем встроенным функциям, это также включает в себя все внешние библиотеки, с которыми мы выбираем для сборки проекта.
Не очень хорошие:
1. Возможно, вам придется написать много собственного кода доступа самостоятельно. Существуют плагины для наиболее распространенных задач, но может потребоваться время, чтобы привыкнуть к вызову собственных API-интерфейсов Java / Objective C с помощью JS. синтаксис. Чтобы ускорить процесс, вы можете включить в проект любой модуль npm, который вам нравится, если он не требует внутри себя специфических для NodeJS вещей. Это немного сокращает список, но есть несколько часто используемых модулей, которые подойдут.
2. Кривая обучения: нужно время, чтобы привыкнуть ко всем особенностям, которые разработчик должен учитывать. Тем не менее, если вы хорошо разбираетесь в JS, вы сможете быстро достичь продуктивного уровня.
3. Отладка макета: NativeScript использует подмножество CSS для стилизации своих XML-представлений, что неплохо. Как веб-разработчик, у меня всегда были проблемы с запоминанием атрибутов стиля / позиционирования Android. Плохо то, что я не нашел места, где я мог бы изучить свои представления и разбить макет. Сделать это на глаз не так уж и важно, поскольку живая перезагрузка работает хорошо, но я думаю, что это может быть пугающим в более сложных макетах. Тем не менее, существует дискуссия, посвященная этой проблеме.
Это резюмирует мои мысли, основанные на использовании платформы для пары небольших проектов. Вы можете ознакомиться с этими примерами приложений, чтобы понять, что еще можно сделать с помощью NativeScript.
В целом, я очень рад видеть будущее разработки гибридных приложений, особенно сейчас, когда на сцене стали появляться и Progressive Web Apps.
