Кроссплатформенная разработка: как решить проблему зависимости от сторонних плагинов для нативной функциональности?

Question

Я начинаю новый проект, и это будет кроссплатформенное мобильное приложение. Я рассматриваю возможность использования ReactNative, NativeScript или Ioni c 4 с конденсатором.

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

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

1. Что если плагин iBeacon отсутствует
2. Что если плагин есть, но он не выполняет то, что вы нужно это сделать
3. Что делать, если есть плагин, но разработчик отказывается от плагина или не работает над решением проблем и т. д. c.

Это ваш единственный способ узнать, как создавать плагины?

Мы небольшая компания, и у нас не так много времени для плагинов, поскольку мы заняты основным продуктом.

Answer 1

В последние месяцы я разрабатывал приложение Ioni c и столкнулся с проблемами, о которых вы упомянули. В двух словах, если нет плагина или у плагина есть проблемы, вы облажались, что означает, что вы должны собрать (или исправить) плагин самостоятельно.

Хорошая вещь с Ioni c является то, что он построен на вершине Кордова, который принадлежит Apache. У них довольно хорошая коллекция плагинов, которые отлично работают в Ioni c и в хорошем состоянии. Они охватывают основные функции.

Ioni c self имеет список плагинов сообщества с краткими инструкциями, вы можете найти его здесь . Большинство из них работают нормально, некоторые глючат. У них также есть премиум-доступ (называемый Premier), который дает вам доступ к официальным плагинам и поддержке, но это очень дорого.

Хорошая новость: если вы знаете, как это сделать, нетрудно создайте свой собственный плагин (если вы знаете JavaScript и нативный код). Найти учебные материалы непросто, особенно если учесть, что версии Ioni c сильно отличаются друг от друга. Этот урок является хорошей отправной точкой (проверьте библиографию внизу).

Не говорю о нативных, но и о плагинах в Ioni c: иногда я также использую Angular плагины, в основном успешно. О библиотеках JS, некоторые работают из коробки (например, Hammer JS), другие я просто не мог заставить их работать (например, jQuery).

Answer 2

Здесь вы сравниваете совершенно разные фреймворки.

Ioni c просто собирается работать внутри WebView, он не дает собственного UX. Поэтому я бы не рекомендовал это лично.

ReactNative дает вам собственный UX, но для того, чтобы настроить плагин, вы должны знать Java / Objective C или Swift. Даже тогда со временем может быть сложно управлять настройками. У них есть большое количество плагинов для сообщества, но опять же, постоянная поддержка - это то, что никто не может гарантировать.

С другой стороны NativeScript дает вам 100% доступ к API устройств, используя всего JavaScript, вам не нужно знать нативные языки программирования, но все же вам потребуются некоторые базовые c знания по маршаллингу нативного кода в JS / TS, у них есть очень хорошая документация по этому вопросу.

По моему мнению, вы должны выбрать ReactNative, если вы полностью полагаетесь на плагины сообщества. Если вы хорошо настроены (или ваша команда), вы можете потратить некоторое время на создание плагинов, тогда вам понравится NativeScript. С настройками плагинов будет намного проще управлять, так как в большинстве случаев это JavaScript, вы всегда можете переопределить цепочку прототипов, и вам не нужно будет трогать исходный код плагина.

Answer 3

React-Native был там довольно давно и пользуется сильной поддержкой сообщества. Теперь ваш случай всецело зависит от дизайна.

1. Если вы разрабатываете продукт, то при проектировании было бы лучше взглянуть на реактивные плагины, чтобы вы могли достичь в разработке именно того, что вы разработали.

   2.Если вам даны дизайны и им подобные, вы можете модифицировать некоторые из дизайнов в соответствии с внешними / внутренними плагинами, предоставленными реагирующим. Было бы разумно следовать реактивному нативу, так как он содержит большинство компонентов.

2. ЕСЛИ вам даны проекты, и вас просят строго следовать дизайну, то будет большой проблемой, если предположить, что даже 1-компонентная альтернатива отсутствует в реагирующем. Так что здесь вы можете выбрать нативное кодирование и все.

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