Каковы мои варианты хранения данных при использовании React Native? (iOS и Android)

Ответ 1

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

Асинхронное хранилище ("встроенное" в React Native)

Я использую AsyncStorage для производственного приложения. Хранилище остается локальным для устройства, не зашифровано (как упомянуто в другом ответе), удаляется, если вы удаляете приложение, но должно быть сохранено как часть резервных копий вашего устройства и сохраняется во время обновлений (как собственных обновлений ala TestFlight, так и обновлений кода через CodePush).

Вывод: локальное хранилище; Вы предоставляете свое собственное решение для синхронизации/резервного копирования.

SQLite

Другие проекты, над которыми я работал, использовали sqlite3 для хранения приложений. Это дает вам SQL-подобный опыт со сжимаемыми базами данных, которые также можно передавать на устройство и с него. У меня не было опыта синхронизации их с бэкэндом, но я думаю, что существуют различные библиотеки. Есть библиотеки RN для подключения к SQLite.

Данные хранятся в вашем традиционном формате базы данных с базами данных, таблицами, ключами, индексами и т.д. Все они сохраняются на диск в двоичном формате. Прямой доступ к данным доступен через командную строку или приложения, которые имеют драйверы SQLite.

Вывод: локальное хранилище; Вы предоставляете синхронизацию и резервное копирование.

Firebase

Firebase предлагает, помимо прочего, базу данных noSQL в реальном времени вместе с хранилищем документов JSON (например, MongoDB), предназначенным для синхронизации от 1 до n числа клиентов. В документах говорится о сохранении в автономном режиме, но только для собственного кода (Swift/Obj-C, Java). Собственная опция Google ("Web"), используемая React Native, не предоставляет опцию кэшированного хранилища (см. Обновление 2/18 ниже). Библиотека написана с предположением, что веб-браузер будет подключаться, и поэтому будет полупостоянное соединение. Возможно, вы могли бы написать механизм локального кэширования в дополнение к вызовам хранилища Firebase, или вы могли бы написать мост между нативными библиотеками и React Native.

[Обновление 2/2018] С тех пор я обнаружил React Native Firebase, который предоставляет совместимый интерфейс JavaScript для нативных библиотек iOS и Android (делая то, что, вероятно, мог/должен был сделать Google), предоставляя вам все преимущества нативных библиотек с бонусом поддержки React Native. С введением Google хранилища документов JSON рядом с базой данных в реальном времени, я даю Firebase хороший второй взгляд на некоторые приложения в реальном времени, которые я планирую создать.

База данных в реальном времени хранится в виде JSON-подобного дерева, которое вы можете редактировать на веб-сайте и довольно просто импортировать/экспортировать.

Вывод: с реактивной базой firebase RN получает те же преимущества, что и Swift и Java. [/update] Хорошо масштабируется для устройств, подключенных к сети. Низкая стоимость за низкое использование. Прекрасно сочетается с другими облачными предложениями Google. Данные легко видны и редактируются из их интерфейса.

область

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

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

В отличие от Firebase, все возможности Realm поддерживаются в React Native и Xamarin, так же как и в приложениях Swift/ObjC/Java (native).

Ваши данные привязаны к объектам в вашем коде. Поскольку они являются определенными объектами, у вас есть схема, а контроль версий является обязательным условием для кода. Прямой доступ доступен через инструменты GUI, предоставляемые Realm. Файлы данных на устройстве являются кросс-платформенными.

Вывод: сначала устройство, дополнительная синхронизация с платными и бесплатными тарифами. Все функции поддерживаются в React Native. Горизонтальное масштабирование дороже, чем Firebase.

ICloud

Честно говоря, я не очень много играл с этим, но буду играть в ближайшем будущем.

Если у вас есть нативное приложение, использующее CloudKit, вы можете использовать CloudKit JS для подключения к контейнерам вашего приложения из веб-приложения (или, в нашем случае, React Native). В этом случае у вас, вероятно, будет собственное приложение для iOS и приложение для React Native для Android.

Как и Realm, он хранит данные локально и по возможности синхронизирует их с iCloud. Существуют публичные магазины для вашего приложения и частные магазины для каждого покупателя. Клиенты могут даже поделиться некоторыми своими магазинами или объектами с другими пользователями.

Я не знаю, как легко получить доступ к необработанным данным; схемы можно настроить на сайте Apple.

Вывод: отлично подходит для приложений, ориентированных на Apple.

Couchbase

Большое имя, множество крупных компаний. Есть Community Edition и Enterprise Edition со стандартными расходами на поддержку.

На их сайте есть учебное пособие по ознакомлению с React Native. Я также не потратил много времени на это, но он выглядит жизнеспособной альтернативой Realm с точки зрения функциональности. Я не знаю, насколько легко получить доступ к вашим данным за пределами вашего приложения или любых создаваемых вами API.

[Изменение: Нашел более старую ссылку, в которой говорится о Couchbase и CouchDB, и CouchDB может быть еще одним вариантом для рассмотрения. Эти два исторически связаны, но в настоящее время совершенно разные продукты. Смотрите это сравнение.]

Вывод: похоже, имеет схожие возможности, как Realm. Может быть только для устройства или синхронизированы. Мне нужно попробовать это.

MongoDB

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

У данных нет жесткой структуры, как у схемы, поэтому каждый объект хранится в виде "документа", который легко найти, фильтровать и т.д. Подобные объекты JSON могут иметь дополнительные (но разные) атрибуты или дочерние объекты, что позволяет большая гибкость в том, как вы структурируете свои объекты/данные.

Я не пробовал какие-либо функции синхронизации между клиентом и сервером и не использовал их встроенными. Реактивный нативный код для MongoDB существует.

Вывод: только локальное решение NoSQL, нет очевидных вариантов синхронизации, таких как Realm или Firebase.

[Обновление 2/2019]

MongoDB имеет "продукт" (или услугу) под названием Stitch. Поскольку клиенты (в смысле веб-браузеров и телефонов) не должны напрямую общаться с MongoDB (это делается с помощью кода на вашем сервере), они создали серверный интерфейс, с которым ваши приложения могут взаимодействовать, если вы решите использовать их Размещенное решение (Атлас). Их документация дает понять, что существует возможная опция синхронизации.

В этой статье, опубликованной в декабре 2018 года, обсуждается использование React Native, Stitch и MongoDB в примере приложения, а другие примеры связаны в документе (https://www.mongodb.com/blog/post/building-ios-and-android-apps -with-mongodb-stitch-реакции-native-sdk).

Twilio Sync

Еще одна опция NoSQL для синхронизации - Twilio Sync. С их сайта: "Синхронизация позволяет вам управлять состоянием на любом количестве устройств в реальном времени в масштабе, не обращаясь к какой-либо серверной инфраструктуре".

Я рассматривал это как альтернативу Firebase для одного из вышеупомянутых проектов, особенно после общения с обеими командами. Мне также нравятся их другие инструменты коммуникации, и я использовал их для обновления текстовых сообщений из простого веб-приложения.

[/Обновить]

[Править] Я провел некоторое время с Царством, так как я первоначально написал это. Мне нравится, что мне не нужно писать API для синхронизации данных между приложением и сервером, как в Firebase. Бессерверные функции также выглядят очень полезными, ограничивая объем внутреннего кода, который я должен написать.

Мне нравится гибкость хранилища данных MongoDB, поэтому он становится моим выбором для серверной части веб-приложений и других приложений, требующих подключения.

Я нашел RESTHeart, который создает очень простой, масштабируемый RESTful API для MongoDB. Не должно быть слишком сложно создать компонент React (Native), который читает и записывает объекты JSON в RESTHeart, который, в свою очередь, передает их в/из MongoDB.

[Редактировать] Я добавил информацию о том, как хранятся данные. Иногда важно знать, сколько работы вы можете выполнить во время разработки и тестирования, если вам нужно настроить и протестировать данные.

[Обновление 2/2019] Я экспериментировал с несколькими из этих вариантов при разработке проекта с высоким уровнем параллелизма в прошлом году (2018). Некоторые из них упоминают жесткие и мягкие ограничения параллелизма в своей документации (я полагаю, что у Firebase было жесткое ограничение на 10 000 соединений, в то время как Twilio был мягким пределом, который можно было увеличить, согласно обсуждениям с обеими командами в AltConf).

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

Ответ 2

Быстро и грязно: просто используйте Redux + реакция-редукция + redux-persist + AsyncStorage для реагирования-родной.

Он идеально подходит для реагирования на родной мир и работает как шарм для android и ios. Кроме того, вокруг него есть сплошная община и много информации.

Для рабочего примера см. F8App от Facebook.

Каковы различные параметры сохранения данных?

С реакцией native вы, вероятно, захотите использовать redux и redux-persist. Он может использовать несколько модулей хранения. AsyncStorage и redux-persist-filesystem-storage - это опции для RN.

Существуют и другие варианты, такие как Firebase или Realm, но я никогда не использовал их в проекте RN.

Для каждого, каковы пределы этого персистентности (т.е. когда данные больше не доступны)? Например: при закрытии приложения перезагрузка телефона и т.д.

Используя redux + redux-persist, вы можете определить, что сохраняется, а что нет. Когда они не сохраняются, данные существуют во время работы приложения. При сохранении данные сохраняются между выполнением приложений (закрытие, открытие, перезапуск телефона и т.д.).

AsyncStorage имеет ограничение по умолчанию на 6 МБ на Android. Можно сконфигурировать больший предел (на Java-код) или использовать в качестве механизма хранения для Android версию storage-persist-filesystem-storage.

Для каждого существуют различия (кроме общей настройки) между реализацией в iOS и Android?

Использование redux + redux-persist + AsyncStorage, настройка точно такая же на Android и iOS.

Как сравнить параметры для доступа к данным в автономном режиме? (или как обычно доступен доступ к автономному доступу?)

Используя сокращение, доступ к оффлайну почти автоматически благодаря своим конструктивным частям (создателям действий и редукторам).

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

То же самое относится и в другом направлении. Вы можете хранить данные, которые вы отправляете на сервер, и которые все еще находятся на рассмотрении и обрабатывают его соответствующим образом.

Есть ли какие-либо другие соображения, о которых я должен помнить?

React способствует реактивному способу создания приложений, и Redux очень хорошо подходит для него. Вы должны попробовать, прежде чем использовать опцию, которую вы будете использовать в своем обычном приложении Android или iOS. Кроме того, вы найдете гораздо больше документов и помощь для них.

Ответ 3

Люди выше выбирают нужные заметки для хранения, хотя, если вам также необходимо учесть любые данные PII, которые необходимо сохранить, вы также можете зайти в цепочку ключей, используя что-то вроде https://github.com/oblador/react-native-keychain поскольку ASyncStorage не зашифрован. Это может быть применено как часть конфигурации persist в чем-то вроде redux-persist.

Ответ 4

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

Хранилище только для устройств

Параметры:

• AsyncStorage (Redux-persist in Native использует AsyncStorage, если вы не указали собственный механизм хранения)
• Realm
• Firebase (или это как устройство, так и внешнее?)

Вопросы:

• Данные сохраняются после закрытия приложения или перезапуска устройства.
• Данные удаляются, когда приложение удаляется с устройства (для всех параметров или просто для AsyncStorage и iOS?) Что касается iCloud и аналогичных соображений Android?)

Хранилище с несколькими устройствами

Обычно это делается с внешней БД (и учетными записями пользователей), а данные, сохраненные на устройстве, гидратируются и синхронизируются с внешними данными БД. (здесь нужна лучшая информация)

Ответ 5

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

response-redux + AsyncStorage = redux-persist

поэтому внутри файла createotre просто добавьте эти строки

store.subscribe(async()=> await AsyncStorage.setItem("store", JSON.stringify(store.getState())))

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

Затем загрузите преобразованный магазин JSON. когда приложение загружается. и снова установите магазин.

Потому что redux-persist создает проблемы при использовании wix response-native-navigation. Если это так, то я предпочитаю использовать простой Redux с вышеуказанной функцией подписчика.

Ответ 6

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

import SyncStorage from 'sync-storage';

SyncStorage.set('foo', 'bar');
const result = SyncStorage.get('foo');
console.log(result); // 'bar'

Ответ 7

Вы можете использовать Realm или Sqlite, если хотите управлять сложным типом данных.

В противном случае пойти со встроенным реагировать родной asynstorage