Closed noxonsu closed 5 years ago
это быстро, мы делали за пару вечеров приложение для радио (нативное). на андроид, кстати, было сложнее сделать
Если главная цель переиспользовать большую часть наработанной логики то лучшим решением будет использовать React Native. SounCloud утверждают, что их команда разработчиков, смогла переиспользовать 85 процентов кода при написании мобильного приложения, используя ReactNative.
Вещи, которые придется изменить:
Верстка. React Native использует Yoga layout для позиционирования элементов и стилей. Никакого CSS. Подробнее. Так что всю верстку элементов придется переписать. Плюс в том, что yoga использует в основе flexbox, который используется в swap.react, что упростит переписывание.
Ряд методов, которые недоступны в React Native. Например localStorage придется заменить на AsyncStorage. А все анимации реализуются, используя Animated API.
Дизайн. Его нужно адаптировать под малые экраны. С другой стороны, возможно для каждой из платформ стоит сделать его вид более нативным. То есть так, чтобы приложение соответствовало гайдлайнам Apple / Google соответственно (не обязательно).
Что будет круто настроить:
С учетом закона Мерфи, моя оценка трудозатрат: 30-40 часов.
Интересные ссылки:
Проверил библиотеку bitcoinjs-lib. Работает. Вернее не сама она, а ее форк react-native-bitcoinjs-lib. Проверяю web3 и ipfs pub sub
Проверил web3, удалось подключить согласно инструкции.
Проверяю ipfs pub sub
Мне удалось запустить ipfs js внутри React Native используя nodejs-mobile. То есть обращение к либе ipfs происходит не напрямую, а через мост в асинхронном режиме, который связывает React Native код и NodeJS код.
Подводя итог: получилось запустить все три испытуемые библиотеки с некоторыми особенностями, которые указал в этом треде выше. В итоге, чтобы запустить swap.core/swap.react на мобильные платформы используя React Native, необходимо будет сделать, что то вроде react-native-swap.core, react-native-swap.react, где будут внесены изменения в работе касательно этих библиотек и другого функционала, который нельзя использовать напрямую в окружении React Native.
Касательно WebView решений, таких как Apache Cordova / PhoneGap. Новость, что Apple планирует удалять гибридные приложения, использующие WebView, оказалось уткой.
Вот примеры гибридных приложений, использующих WebView и допущенных в сторы. С другой стороны, Apple может не пустить в стор приложения, которые являются чистыми портами веб сайтов.
2.12 Apps that are not very useful, are simply web sites bundled as apps, or do not provide any lasting entertainment value may be rejected
Подробнее тут.
Проблемы таких решений:
Производительность: приложения, использующие WebView кажутся тормознутыми, задержка отклика на действия заметна. Судя по отзывам к опубликованным приложениям они падают довольно часто.
Различие между движками WebView на андроиде и IoS.
The JavaScript code included in our Hybrid app runs in a WebView, which is essentially a native browser bundled with app. On Android, our code runs in a modern Chromium-based WebView that for the most part works exactly as it should. On iOS, we have the choice of running our code in one of two WebViews: UIWebView or WKWebView.
Подробнее, вместе с тем, к чему это приводит можно прочитать тут.
Google начнет блокировать OAuth requests, исполняемые из WebView. Это может коснуться и Firebase Cloud Messaging. Вряд ли это приговор, но головной боли может добавить. Подробнее.
Непонятная ситуация насчет ipfs. Runtime Support: Cordova #834
Лично я бы использовал React Native, из за производительности, большей прозрачности насчет допуска в сторы и комьюнити. Там все равно большую часть уже написанного кода можно будет переиспользовать.
ресерч, сколько будет стоить сделать приложение (которое пройдет в сторы). делает @Eljoy