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

Я все еще новичок в мире React Native, и в целом в мобильном / родном мире, и мне кажется, что документации не хватает, когда речь заходит о сохранности данных.

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

Я специально хочу знать:

• Какие существуют варианты сохранения данных?
• Для каждого из них, каковы пределы этой стойкости (т. Е. Когда данные больше не доступны)? Например: при закрытии приложения, перезагрузке телефона и т. Д.
• Для каждого из них есть различия (кроме общей настройки) между реализацией в iOS против Android?
• Как сравнить параметры для доступа к данным в автономном режиме? (или как обычно обрабатывается автономный доступ?)
• Есть ли другие соображения, которые я должен иметь в виду?

Спасибо за вашу помощь!

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

Асинхронное хранилище («встроенное» в 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. Родная поддержка. С введением Google хранилища документов JSON рядом с базой данных в реальном времени, я даю Firebase хороший второй взгляд на некоторые приложения в реальном времени, которые я планирую создать.

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

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

область

Обновление 4/2020 MongoDB приобрела Realm и планирует объединить его с MongoDB Stitch (обсуждается ниже). Это выглядит очень захватывающе .

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

Они предлагают бесплатную версию хранилища объектов, которое вы размещаете на своих собственных серверах или в облачном решении, таком как 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

Обновление 4/2020

Mongo приобрела Realm и планирует объединить MongoDB Stitch (обсуждается ниже) с Realm (обсуждается выше).

Я использую эту часть сервера для части приложения, которое использует 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's Sync. С их сайта: «Синхронизация позволяет вам управлять состоянием на любом количестве устройств в реальном времени в масштабе, не обращаясь к какой-либо серверной инфраструктуре».

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

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

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

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

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

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

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

Быстро и грязно: просто используйте Redux + реагировать-редукс + избыточно-персистировать + 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) или использовать redux-persist-filesystem-storage в качестве механизма хранения для Android.

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

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

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

Благодаря избыточному доступу в автономном режиме практически все автоматически благодаря элементам дизайна (создатели действий и редукторы).

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

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

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

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

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

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

import SyncStorage from 'sync-storage';

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

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

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

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

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 с вышеуказанной функцией подписчика