Нативная разработка для android

Руководство по React Native для начинающих Android-разработчиков (с примером приложения)

Представляем вам перевод статьи Nikhil Sachdeva, опубликованной на hackernoon.com. Автор делится опытом разработки мобильных приложений с помощью React Native и предлагает создать свое приложение, используя этот фреймворк.

Я был Android-разработчиком и довольно длительное время использовал в работе Java. Лишь недавно я попробовал свои силы в создании мобильных приложений с помощью React Native. Это заставило меня взглянуть на процесс разработки по-новому, если не сказать больше. Цель моей статьи — показать, какие различия я заметил, используя эти два фреймворка в разработке приложений.

Что такое React Native

«React Native позволяет создавать мобильные приложения, используя при этом только JavaScript с такой же структурой, что и у React. Это дает возможность составлять многофункциональный мобильный UI с применением декларативных компонентов».

«Приложения, которые вы создаете с помощью React Native, не являются мобильными веб-приложениями, потому что React Native использует те же компоненты, что и обычные приложения для iOS и Android. Вместо того чтобы использовать язык Swift, Kotlin или Java, вы собираете эти компоненты с помощью JavaScript и React».

Итак, получается, что React Native — это фреймворк, в основе которого лежит React.js, что позволяет разрабатывать кроссплатформенные приложения как для Android, так и для iOS.

Вы спросите, зачем уходить от привычного Java и осваивать JavaScript и React.js? Вот несколько плюсов использования этих языков.

Плюсы: в чем вы выиграете

1. Кроссплатформенная разработка

Основная цель разработчиков — предоставить клиентам сервисы. Никто не хотел бы, чтобы его пользователи были ограничены лишь одной какой-то платформой только потому, что разработчик не может создавать приложения для других платформ. Следовательно, и сам разработчик не должен ограничивать свои способности только потому, что ему или ей комфортно работать с конкретным инструментом разработки.

Фреймворк React Native является портативным, то есть его единая кодовая база, написанная в JavaScript, создаст модули как для Android, так и для iOS.

2. Освоение React

Освоив React Native и JavaScript, вы откроете для себя новый мир front-end разработки применительно, например, к веб-сайтам. Фреймворк React Native основан на тех же компонентах, что и React, поэтому полученные здесь навыки не ограничиваются только разработкой мобильных приложений.

3. Время сборки быстрее, чем в Android Studio

Вы когда-нибудь тратили больше 2–3 минут на сборку, чтобы протестировать/пофиксить базовую функцию, и при этом багфикс растягивался на долгие часы? Решением проблемы станет React Native. С ним на сборку уходит значительно меньше времени. С такой функцией, как «Горячая перезагрузка» (Hot Reloading), разработка и тестирование пользовательского интерфейса — это легко. Благодаря этой функции приложение перезагружается каждый раз, когда JS-файл сохраняется!

4. JavaScript удобен для передачи данных по сети

В React Native вызов API, рендеринг изображений по URL и другие процессы очень просты. Больше не нужно использовать Retrofit, OkHttp, Picasso и т. д. Намного меньше времени тратится на настройку. Когда данные поступают из API на платформе Android, они сначала преобразуются в POJO-модель и лишь затем используются в элементах UI. А вот данные JSON, полученные в React Native, удобны для JavaScript и могут напрямую использоваться для предпросмотра UI. Это позволяет облегчить веб-интерфейс для GET или POST-запросов от REST API.

5. Разработка UI

В React Native в качестве разметки UI выступает модуль flexbox, серьезный конкурент XML-разметки на Android. Flexbox очень популярен в сообществе веб-разработчиков. В React Native UI-элементы в основном должны разрабатываться с нуля, тогда как в нативной разработке для Android библиотека поддержки Google Design Support Library уже подключена. Это дает разработчику свободу в плане интерактивного и адаптивного дизайна.

Минусы: в чем вы, быть может, проиграете

1. Возможно, вы ненавидите JavaScript

Многие люди не любят JavaScript просто за то, что этот язык не похож на традиционные языки, такие как Java, C++ и другие. Подробные негативные отзывы вы можете найти здесь и здесь.

2. Не так уж много сторонних библиотек

Сообщество React Native по-прежнему находится в стадии становления и поддерживает сторонние библиотеки, не такие популярные, как нативная библиотека Android (кстати, оцените слайд-шоу моей библиотеки для Android ).

Пример приложения

Для начала давайте попробуем разработать приложение для извлечения данных из API, чтобы понять, насколько просто работает React Native. Очевидно, что первым шагом является установка React Native. Для этого перейдите на официальный сайт. Также вы найдете там замечательную инструкцию для начинающих — прочтите ее. Мы будем использовать фиктивный API https://jsonplaceholder.typicode.com/photos, который содержит следующие данные:

Обратите внимание, что для Android работа с API с использованием таких библиотек, как Retrofit/OkHttp, — это сложная задача. Однако мы видим, что динамический и итеративный язык JavaScript упрощает эту работу.

Перейдем к созданию проекта MockApp:

react-native init MockApp
cd MockApp

Далее запустите его на вашем виртуальном/локальном устройстве, используя:

На экране появится такое изображение:

Стартовый экран приложения

Приложение для работы с API, которое мы создадим, будет выглядеть вот так:

Так в результате выглядит приложение

Теперь откройте проект в текстовом редакторе и скорректируйте App.js, как показано ниже:

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

1. componentDidMount. Это часть React Native в жизненном цикле приложения. componentDidMount() запускается сразу после того, как компонент был добавлен в дерево компонентов.

2. fetch. Чтобы работать с сетевыми запросами, в React Native существует API-интерфейс Fetch.

3. Переменные состояния (isLoading, dataSource). isLoading — это переменная типа bool, которая показывает, загружены данные API или нет. dataSource — переменная, которая сохраняет ответ JSON от команды fetch.

4. FlatList. Это эквивалент RecyclerView в React Native, только намного проще. Компонент FlatList отображает скролящийся лист данных, которые могут изменятся, хотя и имеют общую структуру. FlatList отлично подходит для работы с длинными списками, в которых количество элементов может меняться с течением времени.

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

Как мы видим, стили каждого компонента уже определены. Нам нужно задать значения переменных. Это можно сделать следующим способом:

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

Источник

Мобильная разработка: Cross-platform или Native

Всем привет! Я Игорь Веденеев, руководитель мобильной разработки в AGIMA. Поговорим немного о нативной и кроссплатформенной разработке. Раньше я по большей части скептически относился ко второй: не устраивало качество конечных приложений в первую очередь. Однако за последний год темпы развития кроссплатформенных фреймворков уже не в первый раз заставляют пересмотреть свое мнение насчет такого подхода. Поэтому давайте еще раз сравним самые популярные кроссплатформенные решения и нативную разработку.

На всякий случай

Если вы не знаете, что такое нативная и кроссплатформенная разработка:

нативная разработка (2 независимых приложения на языках Swift и Kotlin);

кроссплатформенная разработка — общая кодовая база для iOS и Android (с применением фреймворков Flutter или React Native (далее RN)).

У каждого способа есть свои особенности, плюсы и минусы. Соответственно, под каждый конкретный проект и каждую конкретную цель подходит какой-то один из них. Сейчас объясню, как выбрать и на что обращать внимание.

Нативная разработка

Нативная разработка — это классический способ создания приложения для iOS и Android. Ведется она с использованием инструментов и языков программирования, предложенных вендорами — Apple и Google. Языки в данном случае — Swift (iOS) и Kotlin (Android), а инструментов для профилирования и отладки в нативной разработке очень много.

Однако мы должны понимать, что в данном случае мы делаем два независимых приложения. Разрабатываются они параллельно. Каждое приложение может реализовать фичу по-своему, и у каждого могут быть свои баги. И самое главное, нативная разработка никуда не денется: пока существуют iOS и Android, Apple и Google будут предоставлять инструментарий для создания приложений.

Нативная разработка позволяет создать самое качественное и функциональное приложение, но взамен придется разрабатывать и отлаживать всё 2 раза и следить, чтобы приложения соответствовали друг другу функционально.

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

Плюсы и минусы нативной разработки

2 независимых приложения

Стоимость разработки и отладки

Меньше потребляемых ресурсов*

Богатый инструментарий для разработки

Широкий рынок разработчиков

Кроссплатформенная разработка

Кроссплатформенная разработка подразумевает, что мы используем один и тот же код и на iOS, и на Android. Вообще говоря, это всё такое же нативное приложение, но, запустив его, мы сразу проваливаемся в мир Flutter или RN, и всё происходит уже там. Стоит отметить, что разработка на Flutter/RN идет быстрее. Причем не только за счет того, что мы делаем 1 приложение вместо 2-х, а еще и за счет концепций создания приложений, в частности UI.

Но, увы, не всё так хорошо: кроссплатформа имеет ряд проблем, на которые стоит обратить внимание, прежде чем выбирать этот подход для своего приложения. React Native и Flutter всё же сторонние Open Source-решения. В них могут встречаться баги. Новые фишки iOS и Android там будут появляться не так быстро, как при нативных решениях. Может прекратиться поддержка, в конце концов.

Также, довольно часто придется полагаться на сторонние Open Source-библиотеки, что тоже несет в себе риски потенциальных проблем: например, совместимость версии Flutter/RN. Не исключен вариант, что нужной библиотеки не существует в природе, и тогда придется реализовывать всё с нуля самому. Также нельзя добавить расширения для iOS-приложений или, например, приложение на часы. Это касается и Flutter, и RN.

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

Если в приложении много логики и есть необходимость сделать ее многопоточной, это тоже будет проблемой и во Flutter, и в RN. Это возможно, но, скажем, это не то, для чего были предназначены эти фреймворки. Также каждый из фреймворков имеет достаточно тяжелую исполнительную среду, что делает кроссплатформенные приложения более ресурсоемкими и требовательными к процессору/оперативке телефона.

Если приложение подразумевает обширное использование аппаратных возможностей телефона, взаимодействия с ОС, то я бы тоже не рекомендовал использовать кроссплатформу — есть риск, что в какой-то момент или код станет очень запутанным, или мы упремся в ограничения одной из платформ или самого фреймворка. Еще стоит учесть, что нам стоит использовать платформенно нейтральный UI, чтобы не создавать потенциальных проблем с различным поведением на платформах и в принципе не снижать на этом скорость разработки.

На картинке ниже представлены результаты теста с простым списком с изображениями: видим, что нативное приложение выигрывает вчистую. Да, на более новых моделях телефонов разница будет не такой значительной, но тенденцию можно видеть. Результаты остальных тестов тут.

Если проще, то кроссплатформа позволяет разработать приложение в кратчайшие сроки. Лучше всего подходит для приложений-витрин услуг или товаров среднего/малого объема без обширного использования платформенных возможностей. То есть снять фотку на аватар или отсканировать QR-код не составит больших проблем, но, если вы делаете приложение вокруг камеры, лучше рассмотреть нативную разработку.

Плюсы и минусы кроссплатформенной разработки

Источник

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 и по каким-то причинам решил прочесть эту статью, ещё и до самого конца.

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

Источник