React Nativeを使用するときにデータを保存するためのオプションは何ですか？（iOSおよびAndroid）[終了]

私はReact Nativeの世界、そして一般的にはモバイル/ネイティブの世界でもまだ新しいです。データの永続性に関しては、ドキュメントが少し不足しているようです。

React Nativeにデータを保存するためのオプションと、各タイプの意味は何ですか？たとえば、ローカルストレージと非同期ストレージがあることはわかりますが、レルムなども表示され、これらすべてが外部データベースでどのように機能するのか混乱しています。

特に知りたい：

• データの永続化にはどのようなオプションがありますか？
• それぞれについて、その永続性の制限は何ですか（つまり、いつデータが利用できなくなるか）？例：アプリケーションを閉じるとき、電話を再起動するときなど
• それぞれについて、iOSとAndroidでの実装には（一般的なセットアップ以外の）違いがありますか？
• オフラインでデータにアクセスするためのオプションはどのように比較されますか？（またはオフラインアクセスは通常どのように処理されますか？）
• 覚えておくべき他の考慮事項はありますか？

ご協力いただきありがとうございます！

現在のアプリプロジェクトをいくつか進めていくための最良の方法を決定するにあたり、私が学んだことは次のとおりです。

非同期ストレージ（React Nativeの「組み込み」）

私は、製品版アプリでAsyncStorageを使用しています。ストレージはデバイスに対してローカルのままであり、暗号化されていません（別の回答で述べたように）。アプリを削除すると消えますが、デバイスのバックアップの一部として保存され、アップグレード中も保持されます（TestFlightによるネイティブアップグレードとCodePushによるコードアップグレードの両方） ）。

結論：ローカルストレージ。独自の同期/バックアップソリューションを提供します。

SQLite

私が取り組んだ他のプロジェクトでは、アプリのストレージにsqlite3を使用しています。これにより、SQLのようなエクスペリエンスが提供されます。圧縮可能なデータベースは、デバイスとの間で送受信することもできます。それらをバックエンドに同期する経験はありませんが、さまざまなライブラリが存在すると思います。SQLiteに接続するためのRNライブラリがあります。

データは従来のデータベース形式で保存され、データベース、テーブル、キー、インデックスなどはすべてバイナリ形式でディスクに保存されます。データへの直接アクセスは、SQLiteドライバーを備えたコマンドラインまたはアプリを介して利用できます。

結論：ローカルストレージ。同期とバックアップを提供します。

Firebase

Firebaseは、とりわけ、1〜n個のクライアントの同期を維持するためのJSONドキュメントストア（MongoDBなど）とともに、リアルタイムのnoSQLデータベースを提供します。ドキュメントはオフラインの永続性について話しますが、ネイティブコード（Swift / Obj-C、Java）についてのみです。React Nativeで使用されるGoogle独自のJavaScriptオプション（「Web」）は、キャッシュされたストレージオプションを提供していません（以下の2/18の更新を参照）。ライブラリは、Webブラウザーが接続することを想定して記述されているため、半永続的な接続が存在します。おそらく、Firebaseストレージ呼び出しを補足するローカルキャッシュメカニズムを作成するか、ネイティブライブラリとReact Native間のブリッジを作成することができます。

アップデート2/2018 私はそれ以来、ネイティブのiOSおよびAndroidライブラリに互換性のあるJavaScriptインターフェースを提供する React Native Firebaseを見つけました（Googleがおそらくできる/すべきであったことを実行します）。ネイティブサポート。Googleがリアルタイムデータベースに加えてJSONドキュメントストアを導入したことで、私はFirebaseに、私が構築する予定のいくつかのリアルタイムアプリの見栄えをよくしています。

リアルタイムデータベースは、JSONのようなツリーとして保存され、Webサイトで編集して、簡単にインポート/エクスポートできます。

結論：react-native-firebaseを使用すると、RNはSwiftおよびJavaと同じ利点を得ます。[/更新]ネットワークに接続されたデバイスに適切にスケーリングします。低使用率のための低コスト。他のGoogleクラウドサービスとうまく結合します。インターフェースから容易に表示および編集可能なデータ。

レルム

更新4/2020 MongoDBはRealmを取得しており、MongoDB Stitch（後述）と組み合わせる予定です。これはとてもエキサイティングに見えます。

また、automagicネットワーク同期を備えたリアルタイムオブジェクトストア。彼らは自分たちを「デバイスファースト」と宣伝し、デモビデオはデバイスが散発的または損失の多いネットワーク接続をどのように処理するかを示しています。

独自のサーバーまたはAWSやAzureなどのクラウドソリューションでホストするオブジェクトストアの無料バ​​ージョンを提供します。また、デバイスと永続化しないメモリ内ストア、サーバーと同期しないデバイス専用ストア、読み取り専用サーバーストア、および1つ以上のデバイス間で同期するための完全な読み取り/書き込みオプションを作成することもできます。彼らには、Firebaseよりも前月あたりのコストが高い専門的およびエンタープライズオプションがあります。

Firebaseとは異なり、すべてのレルム機能は、Swift / ObjC / Java（ネイティブ）アプリと同様に、React NativeとXamarinでサポートされています。

データはコード内のオブジェクトに関連付けられています。それらは定義されたオブジェクトであるため、スキーマがあり、バージョン管理はコードの健全性にとって必須です。Realmが提供するGUIツールを介して直接アクセスできます。デバイス上のデータファイルは、プラットフォーム間で互換性があります。

結論：デバイス優先、無料および有料プランとのオプションの同期。React Nativeでサポートされるすべての機能。水平スケーリングはFirebaseよりも高価です。

iCloud

正直なところ、これについてはあまり遊んでいませんが、近いうちにそうする予定です。

CloudKitを使用するネイティブアプリがある場合は、CloudKit JSを使用して、ウェブアプリ（この場合はReact Native）からアプリのコンテナーに接続できます。このシナリオでは、おそらくネイティブiOSアプリとReactネイティブAndroidアプリがあります。

Realmと同様に、これはデータをローカルに保存し、可能であればiCloudに同期します。アプリのパブリックストアと各顧客のプライベートストアがあります。顧客は、一部のストアまたはオブジェクトを他のユーザーと共有することもできます。

生データにアクセスするのがどれほど簡単かわかりません。スキーマはAppleのサイトで設定できます。

結論：Appleを対象としたアプリに最適です。

カウチベース

ビッグネーム、その背後にある多くの大企業。標準サポートコストのCommunity EditionとEnterprise Editionがあります。

彼らのサイトには、React Nativeに接続するためのチュートリアルがあります。私もこれに多くの時間を費やしていませんが、機能の点ではRealmの実行可能な代替手段のようです。アプリや作成したAPIの外でデータにアクセスするのがどれほど簡単かわかりません。

[編集：CouchbaseとCouchDBについて語る古いリンクが見つかりました。CouchDBも検討すべきもう1つのオプションかもしれません。2つは歴史的に関連していますが、現在は完全に異なる製品です。この比較を参照してください。]

結論：レルムと同様の機能があるようです。デバイスのみまたは同期することができます。試してみる必要があります。

MongoDB

2020年4月更新

MongoはRealmを買収し、MongoDB Stitch（以下で説明）をRealm（上記で説明）と組み合わせる計画を立てています。

ローカルでAsyncStorageを使用するアプリの一部にこのサーバー側を使用しています。すべてがJSONオブジェクトとして保存され、クライアントデバイスへの転送が非常に簡単になるのが好きです。私の使用例では、TVガイドデータの上流プロバイダーとクライアントデバイス間のキャッシュとして使用されています。

スキーマのようにデータにハード構造はありません。そのため、すべてのオブジェクトは、簡単に検索、フィルタリングなどが可能な「ドキュメント」として保存されます。同様のJSONオブジェクトには、追加の（ただし異なる）属性または子オブジェクトがあり、オブジェクト/データを構造化する方法に多くの柔軟性があります。

クライアントからサーバーへの同期機能を試したことも、組み込みで使用したこともありません。MongoDBのReact Nativeコードは存在します。

結論：ローカルのみのNoSQLソリューション、RealmやFirebaseなどの明確な同期オプションはありません。

2019年2月更新

MongoDBには、Stitchと呼ばれる「製品」（またはサービス）があります。クライアント（Webブラウザーや電話の意味で）はMongoDBと直接通信する必要がない（サーバー上のコードによって行われる）必要がないため、クライアントは、アプリのインターフェイスとなるサーバーレスフロントエンドを作成しました。ホストされたソリューション（Atlas）。彼らのドキュメントでは、可能な同期オプションがあるように見えます。

2018年12月のこの記事では、サンプルアプリでのReact Native、Stitch、MongoDBの使用について説明し、他のサンプルはドキュメントにリンクされています（https://www.mongodb.com/blog/post/building-ios-and-android-apps -with-the-mongodb-stitch-react-native-sdk）。

Twilio Sync

同期のもう1つのNoSQLオプションは、Twilioの同期です。彼らのサイトから：「Syncを使用すると、バックエンドインフラストラクチャを処理する必要なく、任意の数のデバイスの状態をリアルタイムで大規模に管理できます。」

特に両方のチームと話し合った後、私はこれを前述のプロジェクトの1つでFirebaseの代替として見ました。私は彼らの他のコミュニケーションツールも気に入っており、シンプルなウェブアプリからのテキストメッセージの更新に使用しています。

[編集]私が最初にこれを書いて以来、私はRealmで少し時間を過ごしました。Firebaseのように、アプリとサーバーの間でデータを同期するためにAPIを作成する必要がない方法が気に入っています。サーバーレス関数もこれら2つで本当に役立つように見え、私が記述しなければならないバックエンドコードの量を制限しています。

MongoDBデータストアの柔軟性が気に入っているので、Webベースのアプリケーションやその他の接続が必要なアプリのサーバー側での選択肢になりつつあります。

私は、MongoDBに対して非常にシンプルでスケーラブルなRESTful APIを作成するRESTHeartを見つけました。JSONオブジェクトをRESTHeartに読み書きし、次にRESTHeartがそれらをMongoDBとの間でやり取りするReact（ネイティブ）コンポーネントを構築することはそれほど難しくありません。

[編集]データの保存方法に関する情報を追加しました。データを微調整してテストする必要がある場合、開発およびテスト中にどれだけの作業が必要になるかを知ることが重要な場合があります。

編集2/2019昨年（2018）に同時実行性の高いプロジェクトを設計するときに、これらのオプションのいくつかを試しました。それらのいくつかは、ドキュメントでハードとソフトの同時実行制限に言及しています（AltConfの両方のチームとの議論によると、Twilioはバンプできるソフト制限でしたが、Firebaseには10,000接続でハード制限がありました）。

数万から数十万のユーザー向けにアプリを設計している場合は、それに応じてデータバックエンドをスケーリングする準備をしてください。

迅速かつダーティ：反応ネイティブには、Redux + react-redux + redux-persist + AsyncStorageを使用するだけです。

それはほぼ完璧に反応するネイティブの世界に適合し、アンドロイドとiOSの両方の魅力のように機能します。また、その周りにはしっかりしたコミュニティがあり、たくさんの情報があります。

実際の例については、Facebook のF8Appを参照してください。

データの永続化にはどのようなオプションがありますか？

反応ネイティブでは、おそらくreduxとredux-persistを使用する必要があります。複数のストレージエンジンを使用できます。AsyncStorageとredux-persist-filesystem-storageは、RNのオプションです。

FirebaseやRealmなどの他のオプションがありますが、RNプロジェクトでは使用していません。

それぞれについて、その永続性の制限は何ですか（つまり、いつデータが利用できなくなるか）？例：アプリケーションを閉じるとき、電話を再起動するときなど

redux + redux-persistを使用すると、永続化するものと永続化しないものを定義できます。永続化されていない場合、データはアプリの実行中に存在します。永続化されると、データはアプリの実行（閉じる、開く、電話を再起動するなど）の間で永続化されます。

Androidでは、AsyncStorageのデフォルトの制限は6MBです。（Javaコードで）より大きな制限を設定するか、Androidのストレージエンジンとしてredux-persist-filesystem-storageを使用することが可能です。

それぞれについて、iOSとAndroidでの実装には（一般的なセットアップ以外の）違いがありますか？

redux + redux-persist + AsyncStorageを使用すると、セットアップはAndroidとiOSでまったく同じです。

オフラインでデータにアクセスするためのオプションはどのように比較されますか？（またはオフラインアクセスは通常どのように処理されますか？）

reduxを使用すると、そのデザインパーツ（アクションクリエーターとレデューサー）のおかげで、オフフィリンアクセスはほぼ自動的に行われます。

フェッチして保存したすべてのデータが利用可能です。状態（フェッチ、成功、エラー）とフェッチされた時刻を示す追加のデータを簡単に保存できます。通常、フェッチを要求しても古いデータは無効にならず、コンポーネントは新しいデータを受信したときに更新されるだけです。

同じことが他の方向にも当てはまります。サーバーに送信しているデータを保存して保留にすることができ、それに従って処理します。

覚えておくべき他の考慮事項はありますか？

Reactはアプリを作成する反応的な方法を促進し、Reduxはそれに非常によく適合します。通常のAndroidまたはiOSアプリで使用するオプションを使用する前に、それを試してみてください。また、それらのドキュメントやヘルプがはるかに多くなります。

上記の人々はストレージについて適切な注意を払いますが、保存する必要があるPIIデータも考慮する必要がある場合は、https：//github.com/oblador/react-native-keychainのようなものを使用してキーチェーンに隠しておくこともできます。 ASyncStorageは暗号化されていないためです。redux-persistなどの永続構成の一部として適用できます。

非同期ストレージよりも使いやすい同期ストレージを使用できます。このライブラリは、非同期ストレージを使用してデータを非同期で保存し、メモリを使用してデータを瞬時に同期して読み込み、保存するのに最適です。そのため、データを非同期でメモリに保存し、アプリの同期で使用します。これは素晴らしいことです。

import SyncStorage from 'sync-storage';

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

複雑なデータ型を管理する場合は、RealmまたはSqliteを使用できます。

それ以外の場合は、組み込みのネイティブの非同期ストレージを使用します

redux-persistは必要ありません。永続化にreduxを使用するだけです。

react-redux + AsyncStorage = redux-persist

だからcreatesotreファイルの中にこれらの行を追加するだけです

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

これにより、reduxストアに変更が加えられるたびにAsyncStorageが更新されます。

次に、jsonに変換されたストアをロードします。アプリが読み込まれるとき。そして店を再びセットします。

なぜなら、rex-persistは、wix反応ネイティブナビゲーションを使用するときに問題を引き起こすからです。その場合は、上記のサブスクライバー機能で単純なreduxを使用することを好みます