Что такое react native android

React Native с точки зрения мобильного разработчика

Статья ориентирована на iOS и android разработчиков, которые уже достаточно хорошо разбираются в своей области и поглядывают в сторону React Native.

Впервые узнав про React Native, я воспринял его как повод для веб-разработчиков вторгнуться на мою территорию (нипазволю!) и заодно испортить хорошо работающий crash-free-60-fps продукт. Так оно и произошло. Конец. Реальная история оказалась длиннее.

Отрицание

JavaScript в мобильном приложении? В голову приходило всего пара библиотек с использованием JavaScriptCore на iOS (эти же библиотеки были причиной 90% падений приложений, в которых использовались) и гибридные приложения “старого образца” (ну это вообще атас).

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

Вспоминая неудачные потуги в освоении Xamarin 3 года назад я быстро отказался от идеи использовать React Native.

Стоит отметить что я всегда с радостью воспринимал новые способы написания нативных приложений (от ObjC к Swift, от Java к Kotlin, от Eclipse к Android Studio). Уже много лет занимаюсь iOS и android разработкой в качестве хобби и профессионально. После перехода на новый язык (внутри одной ОС) или IDE я редко возвращался к предыдущему. Казалось бы React Native — логичный следующий шаг, ещё одна новая ступень вверх. Или это шаг назад?

К чему мне учить упрощённый вариант, когда я уже знаю как делать это “по-настоящему”?!
На этот вопрос мне ещё предстояло найти ответ когда компания поставила задачу полного редизайна одного из приложений (в тот момент доступного только на iOS) и выпуска его на android.

Как сделать сразу два дела и написать меньше кода? Напрашивались решения вроде: тонкий клиент, библиотеки на C с вызовом из Swift / Kotlin кода, React Native?

React Native выглядел довольно перспективно из-за возможности сделать библиотеки и затем использовать их сразу на трёх платформах (iOS / android / web).

Торги

Перспективно для кого угодно, но только не для меня. Я точно не был счастлив такому повороту. Чувствовал что нахожусь на пике способности к развитию iOS и android и тут меня попросили выбросить все эти знания, как будто я свежий выпускник и опыта у меня 0. Ещё больше я сомневался в том что с React Native можно создать качественный продукт.

Депрессия

Сомнение были обоснованными. Главные проблемы:

• приличное количество падений в ядре React Native;
• методы, которые работают только на одной платформе (в доках указано что работают везде);
• неполное описание. Вы только взгляните на доки сборщика React Native.

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

Принятие

И конечно React Native — это не только минусы. Есть много хорошего, пишется это намного проще и работает из коробки лучше чем тоже самое на конкретных платформах.

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

JavaScript

Ничего удивительного. Это первое с чем придётся идти рука об руку через кровь, пот и слёзы.
Когда я начал вспоминать свой предыдущий опыт frontend-разработчика (до мобильных приложений занимался сайтами), у меня начался вьетнамский синдром: Джонни, JavaScript нас окружает!

Если решите писать приложения на React Native, то рекомендую пройти один из свежих курсов по JS. Необязательно чтобы они были по React или React Native.

В последние несколько лет с выходом стандартов ES6, ES7 и ES8 способ написания кода сильно изменился.

И он стал очень даже ничего.

Статическая проверка

В первые месяцы очень недостаёт статического анализатора, который есть во всех нативных мобильных языках.

Есть разные утилиты, которые сглаживают его отсутствие, выполняя часть функций

Вёрстка элементов

Самым большой вызов здесь будет для начинающих iOS разработчиков.

Этот вызов — отсутствие визуального редактора интерфейса.

Всё делается в коде с помощью JSX-разметки. Технически, эта разметка не обязательна, она помогает увидеть иерархию компонентов. Android-разработчики будут в своей тарелке, заметив сходство с XML.

Одновременно есть понятный вид вьюшек и потенциал для переиспользования.

В iOS нет либо одного либо другого, зависит от того какой метод выбрать (вёрстка в коде или в Interface builder). Да, обе эти проблемы решаемы, но приходится писать приличное количество кода.

В React Native нет этой проблемы.
В Android, кстати, её тоже нет.
Зато Android-специалисты оценят способ передачи параметров из внешних компонентов во внутренние прямо в разметке.

Базовые View здесь — аналог LinearLayout (android) и UIStackView (iOS) с примесью констрейнтов одновременно. Довольно простой способ (по сравнению с констрейнтами) позиционирования элементов.

UIViewController и Activity

В React Native нет ни того ни другого.
Конечно они есть под капотом. Напрямую взаимодействовать с ними не получится. Да это и не нужно.

Жизненный цикл всех React Native компонентов полностью отличается от iOS и android, сложно провести какие-то параллели. Если сосредоточиться на отличиях от нативных систем, то:

• UI-элементы сами меняют состояние / вид при изменении входных параметров;
• на android нет необходимости жонглировать onSaveInstantState. React Native всё это делает за нас;
• на iOS нет методов, которые напрямую явно сообщают момент появления / скрытия экранов приложения.

Время сборки / Live Reload / Hot Reload

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

Все изменения в JS-коде видны сразу видны в симуляторе. Колоссально ускоряет разработку!

Отсутствие нативного функционала в JS

В JS-части React Native из коробки доступно не всё что нужно.

Можно написать нативную часть на обе платформы, сделать JS-обёртку и вызывать её как остальной код. Ничего сложного нет.

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

Все модули подключаются через npm (аналог CocoaPods для iOS и Gradle для android), в которых есть нативный код с нужным функционалом.

Универсальные и глубокие ссылки

Функционал реализован силами Facebook.
Работает хорошо и консистентно.

Обработка сторонних Intent’ов

Как частный случай предыдущего пункта.

Самая большая проблема на android — обработать Intent, отличный от диплинка в приложение.
Зависит, конечно, от Intent’а и что необходимо сделать при его получении.

На эту тему можно написать отдельную статью. Стартовая точка — добавить метод createReactActivityDelegate в MainActivity.

Производительность

Довольно просто получить 60 FPS при прокрутке длинных списков со сложными ячейками.
Производительность всего остального (например — нажатие на кнопку, печать текста в поле) ниже. Заметно при анимированной смене состояния у большого количества элементов. С этим можно легко бороться. Хороший раздел в документации Using Native Driver for Animated.

А ещё из коробки нельзя получить нормальное управление жестами и их связывание с анимацией.

Нестабильность

Часто проект просто прекращает собираться, например после:

• обновления ядра React Native (в том числе при обновлении минорной версии);
• обновления npm-модулей;
• обновления XCode;
• обновления CocoaPods (с этим вообще постоянные проблемы);
• просто так. Да, такое тоже бывает.

К счастью большинство этих проблем довольно быстро исправляются. Можно добавить скрипт, который чистит все кеши везде, и запускать его когда что-то идёт не так. Помогает решить 98% странных проблем, возникших из ниоткуда. За исключением CocoaPods, тут всё печально.

Нестабильность сторонних зависимостей

Самой большой проблемой на iOS было и есть повсеместное желание npm-модулей использовать method swizzling.

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

Сборка происходит в несколько этапов и на каждом из них может что-нибудь пойти не так.

Нестабильность при обновлении сторонних зависимостей

Одни npm-модули зависят от других npm-модулей и так далее. Если два модуля завязаны на разные версии третьего модуля, то мы сразу получаем warning при установке, в лучшем случае. А в худшем случае warning’a нет, но ничего не работает.

Аналогичная проблема, если npm-модули полагаются на нативные Android-модули с разными версиями.

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

Unit и UI-тестирование

Очень лёгкий механизм тестирования через библиотеку Jest, идёт в комплекте к React Native. Удобный анализ покрытия тестами — показывает какие строки в тестируемой функции не вызывались ни разу.

Есть библиотеки для UI-тестирования. Пока на деле не пришлось использовать.

Заключение

Спустя 13 месяцев работы с React Native могу с уверенностью сказать:

• он подходит для большинства приложений, в которых надо просто получить с сервера список, показать список, показать подробный вид элемента списка, отправить на сервер изменения;
• всё перечисленное выше достигается меньшим количеством кода;
• теперь это мой выбор “по умолчанию” для новых проектов, с которыми ко мне обращаются, потому что см. предыдущий пункт;
• не подходит для проектов, выходящих за границу “отправил запрос — получил ответ”, немного примеров: фоторедактор, плеер, работа с Bluetooth, AI, ML, соц. сеть, мессенджер;
• advanced-проекты можно сделать на React Native, но всё равно придётся писать много нативного кода, поэтому смысл отпадает;
• React Native пришёл и никуда не денется, с этим надо считаться;
• спрос на нативных мобильных разработчиков несколько снизится, приток новых нативных мобильных разработчиков снизится намного больше. Почему? см. ниже;
• человек как правило идёт по самому простому пути, и незачем стараться, если 95% приложений можно сделать, потратив 20% усилий (по сравнению с нативной разработкой) на изучение;
• как следствие из предыдущих трёх пунктов: разрыв между спросом и предложением нативных мобильных разработчиков станет ещё больше. Тем, кто действительно не может без них обойтись, будет ещё труднее их найти. И это печально.

Заключительное слово для того, кто сразу начал писать на React Native и по каким-то причинам решил прочесть эту статью, ещё и до самого конца.

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

Источник

React Native с колокольни Android-разработки часть 1

Зачем?

Я понимаю, что основная аудитория react native это как раз таки веб разработчки, которые захотели потыкать в мобильные устройства. Но зачем мобильному разработчику смотреть в сторону react native? Я опущу момент как я вообще наткнулся на react native, скажу лишь то, что я уже несколько месяцев на него посматриваю и вот последние 4-5 дней активно изучаю. Я понял, что реакт уже готов что бы создавать простые приложения, которые принимают и отправляют данные. А потом я начал вспоминать все свои проекты и понял, что большая часть из них как раз принимает и отправляет данные, за редким исключением. Получается, что большую часть приложений я мог сделать реакте? Ага, а плюсом шло бы еще приложения на iOS.

Конечно, нативная разработка лучше по всем параметрам, но есть пару НО:

Во-первых, нативная разработка под андроид сложна и полна кучей мелочей, самый банальный пример — это поворот экрана, есть куча разных решений и библиотек, даже я сам нагородил свои костыли. А в реакте все просто, сделал экран, а про повороты можно забыть из коробки, все работает (как я понял) не в основном потоке, в основном только перерисовывается вью, поворот экрана жизненный цикл компонентов реакта никак не затрагивает и это прекрасно.

Смысл в том, что я занимаюсь нативной разработкой под android уже довольно долго и до сих пор приходится сталкиваться с новыми странными (но, порой, и интересными) проблемами. А если мне нужно приложения и под iOS, сколько уйдет времени что бы я научился нативно писать под iOS? Я уже изучал iOS и столкнулся с проблемой подходов: а как писать приложения? Паттерны, библиотеки, best practices и прочее. И для каждой платформы свои заморочки. В случае с реактом тоже свои проблемы, но они общие на обе платформы. Так что я свой выбор сделал: для простых приложений сил реакта хватает, когда начинаются трудности можно прибегнуть к главному козырю — написать модуль нативно под нужную платформу. Ну а вишенкой на торте становится то, что фраза: «Ну, это такой же React как в вебе, только на мобилках» работает и в обратную сторону, изучая react native я использую те же инструменты и подходы что и на вебе, можно будет намного легче сменить направление разработки на веб.

Инструменты

Непосредственно про установку можно почитать тут. Далее я буду считать, что вы прочитали тот мини-туториал.

Конечно, после Android studio все будет не так удобно, придется много работать с консолью (если не запускать студию вообще), но привыкнуть можно. Лично я использую:

возымела эффект необходимо, чтобы виртуальный девайс уже был запущен. Android studio все делает за нас после нажатия на волшебную зеленую кнопочку, а тут придется все делать вручную. Чтобы каждый раз не запускать студию ради запуска виртуального девайса просто открываем меню Android Virtual Device:

Запускаем нужный нам девайс и смотрим в консоль в студии, там будет что-то вроде:

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

Сразу добавлю полезную команду:

Для того что бы видеть логи в терминале.

Компоненты

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

Компонент является основой основ. Для начала стоит воспринимать компонент как Activity или Fragment (но фрагмент ближе). Хотя, компонентом может быть и 1 единственная кнопка. Но позже разберемся.

Самый простой компонент:

Этот компонент сделает нечто подобное:

Любой компонент имеет свой lifecycle, капитально почитать про это можно тут. Нас же интересует, в основном, только эти:

• constructor() — сам говорит за себя, это конструктор компонента, это не обязательный метод, но позже я к нему вернусь;
• render() — это метод почти аналог setContentView(R.layout.activity) из Android
• componentDidMount() — это что-то вроде метода onCreate(), но немного по-другому, вызывается сразу после метода render()

componentDidMount() — это как раз то место, где нужно делать запросы к серверу, чтобы получить данные, которые необходимо отобразить. Он так же не является обязательным методом.

И все тут просто, но мы же захотим работать с данными? У компонента есть 2 источника данных:

• Props
• State

Props можно воспринимать как Intent, который мы передаем когда открываем другую активити. Это данные, которые передаются ВкомпонентИЗвне.
А теперь наглядно:

Давайте разбираться. Props вызывается внутри компонента конструкцией:

в этом примере параметр называется «name». Ну а в фигурных скобках нужно вызывать вообще все параметры, не только props.

Далее, нам необходимо передать props:

Greeting — это имя нашего компонента что мы вызываем, а затем, через пробел мы передаем все props, в нашем случае это «name».

Да, необычно то, что мы явно не указываем в компоненте какие нам нужны props (или я что-то не до конца понял), а сразу же вызываем их в коде как будто они уже есть. Важно заметить, что props мы можем вызывать в любом месте компонента, не только в методе render(), а так же то, что props нельзя изменить, какие пришли, такие и останутся. Типичное применение — это передать id какого-то элемента из списка, на который мы тыкнули, чтобы загрузить какую-то информацию.

Теперь про state. State — это изменяемые параметры самого компонента. Их нельзя куда-то передать напрямую, так же нельзя получить из вне. С точки зрения Android это что-то вроде private параметров без сеттеров и геттеров. State инициализируются внутри конструктора компонента:

Вся прелесть в том, что изменение любого параметра state приводит к вызову метода render(). Т.е. этого кода достаточно чтобы мы получили реальный секундомер, счетчик будет обновляться самостоятельно.

Ну, собственно, про компоненты все. Как же работает само приложение? Все достаточно просто, есть две точки входа: index.is.js и index.android.js, понятно для кого которая. И вот эта строка является настоящей точкой входа:

«folderName» — это название корневой папки проекта, менять нельзя. App — это название компонента, который мы хотим использовать как главный. Своего рода это что-то вроде Main Activity.

Идеалогия написания кода

Когда я только начинал писать на реакт нейтив я стопорился на самых простых вопросах. Допустим, самый простой экран логина: 2 EditText и 1 кнопка. Вот уж не знаю почему, но я на уровне инстинкта пытался реализовать это как в ванильном Android, т.е. MVC без всяких библиотек: по нажатию кнопки берем значения этих EditText и отправляем куда надо, предварительно провалидировав их. Даже не пытайтесь мыслить таким образом.

Через некоторое время у меня в голове щелкнул какой-то тумблер и меня осенило — react native и data binding в Android — это почти одно и тоже (ну, не совсем). Однако, подход практически 1 в 1. Уже во второй своей статье я крайне рекомендую ознакомиться с data binding для андроида, если еще не. Иначе, эта статья вообще вам не поможет.

Для начала, посмотрим как выглядит xml на Android при использовании data binding:

А вот так это будет выглядеть на react native:

Ну и как вам такое? Лично у меня после этого отпали все вопросы по поводу того как писать под react native, тут мы пишем не в императивном стиле, а в реактивном. Сразу оговорюсь, что у компонента TextInput есть метод onChangeText, но у меня он почему-то не возвращал введенный текст.

Что дальше?

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

Источник