Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
The community reviewed whether to reopen this question 5 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I am still new in the React Native world, and generally in the mobile/native world as well, and I am finding the documentation a bit lacking when it comes to data persistence.
What are my options for storing data in React Native and the implications of each type? For instance, I see that there is local storage and async storage, but then I also see things like Realm, and I'm confused how all of this would work with an outside database.
I specifically want to know:
What are the different options for data persistence?
For each, what are the limits of that persistence (i.e., when is the data no longer available)? For example: when closing the application, restarting the phone, etc.
For each, are there differences (other than general setup) between implementing in iOS vs Android?
How do the options compare for accessing data offline? (or how is offline access typically handled?)
Are there any other considerations I should keep in mind?
Thanks for your help!
Here's what I've learned as I determine the best way to move forward with a couple of my current app projects.
Async Storage (formerly "built-in" to React Native, now moved on its own)
I use AsyncStorage for an in-production app. Storage stays local to the device, is unencrypted (as mentioned in another answer), goes away if you delete the app, but should be saved as part of your device's backups and persists during upgrades (both native upgrades ala TestFlight and code upgrades via CodePush).
Conclusion: Local storage; you provide your own sync/backup solution.
SQLite
Other projects I have worked on have used sqlite3 for app storage. This gives you an SQL-like experience, with compressible databases that can also be transmitted to and from the device. I have not had any experience with syncing them to a back end, but I imagine various libraries exist. There are RN libraries for connecting to SQLite.
Data is stored in your traditional database format with databases, tables, keys, indices, etc. all saved to disk in a binary format. Direct access to the data is available via command line or apps that have SQLite drivers.
Conclusion: Local storage; you supply the sync and backup.
Firebase
Firebase offers, among other things, a real time noSQL database along with a JSON document store (like MongoDB) meant for keeping from 1 to n number of clients synchronized. The docs talk about offline persistence, but only for native code (Swift/Obj-C, Java). Google's own JavaScript option ("Web") which is used by React Native does not provide a cached storage option (see 2/18 update below). The library is written with the assumption that a web browser is going to be connecting, and so there will be a semi-persistent connection. You could probably write a local caching mechanism to supplement the Firebase storage calls, or you could write a bridge between the native libraries and React Native.
Update 2/2018
I have since found React Native Firebase which provides a compatible JavaScript interface to the native iOS and Android libraries (doing what Google probably could/should have done), giving you all the goodies of the native libraries with the bonus of React Native support. With Google's introduction of a JSON document store beside the real-time database, I'm giving Firebase a good second look for some real-time apps I plan to build.
The real-time database is stored as a JSON-like tree that you can edit on the website and import/export pretty simply.
Conclusion: With react-native-firebase, RN gets same benefits as Swift and Java. [/update] Scales well for network-connected devices. Low cost for low utilization. Combines nicely with other Google cloud offerings. Data readily visible and editable from their interface.
Realm
Update 4/2020
MongoDB has acquired Realm and is planning to combine it with MongoDB Stitch (discussed below). This looks very exciting.
Update 9/2020
Having used Realm vs. Stitch:
Stitch API's essentially allowed a JS app (React Native or web) to talk directly to the Mongo database instead of going through an API server you build yourself.
Realm was meant to synchronize portions of the database whenever changes were made.
The combination of the two gets a little confusing. The formerly-known-as-Stitch API's still work like your traditional Mongo query and update calls, whereas the newer Realm stuff attaches to objects in code and handles synchronization all by itself... mostly. I'm still working through the right way to do things in one project, which is using SwiftUI, so it's a bit off-topic. But promising and neat nonetheless.
Also a real time object store with automagic network synchronization. They tout themselves as "device first" and the demo video shows how the devices handle sporadic or lossy network connectivity.
They offer a free version of the object store that you host on your own servers or in a cloud solution like AWS or Azure. You can also create in-memory stores that do not persist with the device, device-only stores that do not sync up with the server, read-only server stores, and the full read-write option for synchronization across one or more devices. They have professional and enterprise options that cost more up front per month than Firebase.
Unlike Firebase, all Realm capabilities are supported in React Native and Xamarin, just as they are in Swift/ObjC/Java (native) apps.
Your data is tied to objects in your code. Because they are defined objects, you do have a schema, and version control is a must for code sanity. Direct access is available via GUI tools Realm provides. On-device data files are cross-platform compatible.
Conclusion: Device first, optional synchronization with free and paid plans. All features supported in React Native. Horizontal scaling more expensive than Firebase.
iCloud
I honestly haven't done a lot of playing with this one, but will be doing so in the near future.
If you have a native app that uses CloudKit, you can use CloudKit JS to connect to your app's containers from a web app (or, in our case, React Native). In this scenario, you would probably have a native iOS app and a React Native Android app.
Like Realm, this stores data locally and syncs it to iCloud when possible. There are public stores for your app and private stores for each customer. Customers can even chose to share some of their stores or objects with other users.
I do not know how easy it is to access the raw data; the schemas can be set up on Apple's site.
Conclusion: Great for Apple-targeted apps.
Couchbase
Big name, lots of big companies behind it. There's a Community Edition and Enterprise Edition with the standard support costs.
They've got a tutorial on their site for hooking things up to React Native. I also haven't spent much time on this one, but it looks to be a viable alternative to Realm in terms of functionality. I don't know how easy it is to get to your data outside of your app or any APIs you build.
[Edit: Found an older link that talks about Couchbase and CouchDB, and CouchDB may be yet another option to consider. The two are historically related but presently completely different products. See this comparison.]
Conclusion: Looks to have similar capabilities as Realm. Can be device-only or synced. I need to try it out.
MongoDB
Update 4/2020
Mongo acquired Realm and plans to combine MongoDB Stitch (discussed below) with Realm (discussed above).
I'm using this server side for a piece of the app that uses AsyncStorage locally. I like that everything is stored as JSON objects, making transmission to the client devices very straightforward. In my use case, it's used as a cache between an upstream provider of TV guide data and my client devices.
There is no hard structure to the data, like a schema, so every object is stored as a "document" that is easily searchable, filterable, etc. Similar JSON objects could have additional (but different) attributes or child objects, allowing for a lot of flexibility in how you structure your objects/data.
I have not tried any client to server synchronization features, nor have I used it embedded. React Native code for MongoDB does exist.
Conclusion: Local only NoSQL solution, no obvious sync option like Realm or Firebase.
Update 2/2019
MongoDB has a "product" (or service) called Stitch. Since clients (in the sense of web browsers and phones) shouldn't be talking to MongoDB directly (that's done by code on your server), they created a serverless front-end that your apps can interface with, should you choose to use their hosted solution (Atlas). Their documentation makes it appear that there is a possible sync option.
This writeup from Dec 2018 discusses using React Native, Stitch, and MongoDB in a sample app, with other samples linked in the document (https://www.mongodb.com/blog/post/building-ios-and-android-apps-with-the-mongodb-stitch-react-native-sdk).
Twilio Sync
Another NoSQL option for synchronization is Twilio's Sync. From their site:
"Sync lets you manage state across any number of devices in real time at scale without having to handle any backend infrastructure."
I looked at this as an alternative to Firebase for one of the aforementioned projects, especially after talking to both teams. I also like their other communications tools, and have used them for texting updates from a simple web app.
[Edit] I've spent some time with Realm since I originally wrote this. I like how I don't have to write an API to sync the data between the app and the server, similar to Firebase. Serverless functions also look to be really helpful with these two, limiting the amount of backend code I have to write.
I love the flexibility of the MongoDB data store, so that is becoming my choice for the server side of web-based and other connection-required apps.
I found RESTHeart, which creates a very simple, scalable RESTful API to MongoDB. It shouldn't be too hard to build a React (Native) component that reads and writes JSON objects to RESTHeart, which in turn passes them to/from MongoDB.
[Edit] I added info about how the data is stored. Sometimes it's important to know how much work you might be in for during development and testing if you've got to tweak and test the data.
Edits 2/2019 I experimented with several of these options when designing a high-concurrency project this past year (2018). Some of them mention hard and soft concurrency limits in their documentation (Firebase had a hard one at 10,000 connections, I believe, while Twilio's was a soft limit that could be bumped, according to discussions with both teams at AltConf).
If you are designing an app for tens to hundreds of thousands of users, be prepared to scale the data backend accordingly.
Quick and dirty: just use Redux + react-redux + redux-persist + AsyncStorage for react-native.
It fits almost perfectly the react native world and works like a charm for both android and ios. Also, there is a solid community around it, and plenty of information.
For a working example, see the F8App from Facebook.
What are the different options for data persistence?
With react native, you probably want to use redux and redux-persist. It can use multiple storage engines. AsyncStorage and redux-persist-filesystem-storage are the options for RN.
There are other options like Firebase or Realm, but I never used those on a RN project.
For each, what are the limits of that persistence (i.e., when is the data no longer available)? For example: when closing the application, restarting the phone, etc.
Using redux + redux-persist you can define what is persisted and what is not. When not persisted, data exists while the app is running. When persisted, the data persists between app executions (close, open, restart phone, etc).
AsyncStorage has a default limit of 6MB on Android. It is possible to configure a larger limit (on Java code) or use redux-persist-filesystem-storage as storage engine for Android.
For each, are there differences (other than general setup) between implementing in iOS vs Android?
Using redux + redux-persist + AsyncStorage the setup is exactly the same on android and iOS.
How do the options compare for accessing data offline? (or how is offline access typically handled?)
Using redux, offiline access is almost automatic thanks to its design parts (action creators and reducers).
All data you fetched and stored are available, you can easily store extra data to indicate the state (fetching, success, error) and the time it was fetched. Normally, requesting a fetch does not invalidate older data and your components just update when new data is received.
The same apply in the other direction. You can store data you are sending to server and that are still pending and handle it accordingly.
Are there any other considerations I should keep in mind?
React promotes a reactive way of creating apps and Redux fits very well on it. You should try it before just using an option you would use in your regular Android or iOS app. Also, you will find much more docs and help for those.
Folks above hit the right notes for storage, though if you also need to consider any PII data that needs to be stored then you can also stash into the keychain using something like https://github.com/oblador/react-native-keychain since ASyncStorage is unencrypted. It can be applied as part of the persist configuration in something like redux-persist.
We dont need redux-persist we can simply use redux for persistance.
react-redux + AsyncStorage = redux-persist
so inside createsotre file simply add these lines
store.subscribe(async()=> await AsyncStorage.setItem("store", JSON.stringify(store.getState())))
this will update the AsyncStorage whenever there are some changes in the redux store.
Then load the json converted store. when ever the app loads. and set the store again.
Because redux-persist creates issues when using wix react-native-navigation. If that's the case then I prefer to use simple redux with above subscriber function
you can use sync storage that is easier to use than async storage.
this library is great that uses async storage to save data asynchronously and uses memory to load and save data instantly synchronously, so we save data async to memory and use in app sync, so this is great.
import SyncStorage from 'sync-storage';
SyncStorage.set('foo', 'bar');
const result = SyncStorage.get('foo');
console.log(result); // 'bar'
you can use Realm or Sqlite if you want to manage complex data type.
Otherwise go with inbuilt react native asynstorage
I think question title is self explanatory, however following are more details
Background
I am developing one turn based android game with the help of Firebase realtime database. Concept is very simple, all players are connected to single room which I create by pushing into firebase database. Now every player attaches child value listener to that node. Now I can update game status in this node and everyone will get update in real time.
Problem
During development phase, I am still trying out different ways to structuring this data and implementing in android client. I am not working on any company or enterprise hence I have to use my own mobile internet (where internet data is costly). Plus many times I am in area where there is no internet connectivity. This reduces amount of time spent on testing any network related testing.
Question
Is there way I can simulate (or emulate) firebase database locally ? So that once it is working fine, I can test it on real network ? Any ideas or hints regarding this will be helpful.
It sounds like you probably want to try firebase-server. It is basically a replacement Real-Time Database server that you can run locally.
You need to edit your OS's hosts file to make a 3-part domain name (like localhost.firebaseio.test) resolve to localhost, because of some weird restrictions built into the Firebase client libraries. Some people have found a way around this by injecting mocks into the client library, but this never worked for me; I think it only worked in an old version.
Note that this is NOT the officially recommended way to write unit tests; it's considered better to totally mock out the Firebase client library. It can be quite useful for integration tests, though.
There's a useful thread here that covers some testing questions.
You can use the Firebase Local Emulator Suite it has many modules (including the Realtime Database). Check their official docs here:
https://firebase.google.com/docs/emulator-suite/connect_and_prototype?database=RTDB
After almost 2 years of commercial Android development I'm still confused whether use an internal database or not. The documentation of the framework as vague and leaves it up to the developer to decide.
For a specific example: a catalog application that consumes an external API for it's actions, such as getting and updating items. The application stays "locked" when the connection to the Internet is lost, but you can still see the data that was already loaded, such as lists and user profiles. No commenting or data input is accepted.
Balancing between code complexity, user experience and application performance, should I store it in the database and ensure its consistency using an ORM, or the database is too expensive and I should only store the data while the app is opened?
Thinking about the experience, it makes sense to store in the database, because after a restart I'll be able to preload the data, event without internet. For older devices, it seems logic to store in disk or database because memory is more limited.
How do you guys decide whether to use it or not in your android projects?
I think FireBase Database solves pretty much all these issues. Take a look at it here.
I would like build a mobile application in order to learn the technology.
I have chosen Ionic framework for the same, as it takes care of majority of settings for building the application. But, when coming to database for the app which I am trying to build, I am bit confused.
Some links as a result of googling suggest me to use SQLite and some pull me towards Firebase. My doubt is, are they related for comparison? I guess, SQLite and Firebase cannot be compared with. Please clarify.
Thanks
Manikandan J
SQLite is your phone's database and Firebase is an online database.
Using SQLite, you can create apps which do not support sharing with others. An example, pac man. Say you got a highscore of "20". But you cannot share this highscore with other people's phones because it is local (inside your phone).
Using Firebase, you can store data online, for example, registration details etc. Once people have registered they can login with their info using multiple platforms (depending on your target). You can make them share things with eachother and so on.
SQLite is more suitable fro developing offline android application. Firebase always required a server but SQLite did'nt require any server so for Firebase you should have internet required but in SQLite you can achieve your goal offline. So depending upon the conditions you can use one of this.
I have several applications built on the same engine. This engine is storing data in SQLite. The database structure is the same for all applications. I need to organize a common storage for all these applications.
For example, there is an application A and B. First user installed the application A and added data, then installed the application B and this is necessary to synchronize databases of those two apps. Using a function of Content Providers will not work because in this case application B will not work without the application A. And also we will not know which application user installs first.
There is an idea to synchronize the database of all applications and each application will remain with its own database, but then I will have a copy of the databases. Means as many apps are installed as many copies of databases I will have.
Perhaps there is some kind of a neat way to realize the idea?
Why don't you try using "sharedUserId" across all your apps. With this you can access the data of the other apps as well.
Assuming you already know all the your others apps, on first load of every application you start searching for a common folder where you create your database. This folder can be in your sdcard. If you find the DB file there then you can open it and use it. Otherwise you create one. Then use the same database across all apps?
I'm not sure what are the implications of opening/writing to the same DB from various apps. Maybe you need to figure out a way for locking mechanism during writes (Maybe create a .lock file when writing to the DB?)
I encountered myself same design problem (multiple apps using same engine contains persistent SQLite database tables, Services, and tons of logic).
after I did my own research, I afraid that the conclusion was that the only way doing that is: doing that in Googles's way:
Google Play Services is a process that google made up exactly to solve this problem for their own scenario - engine that should be always available to all apps (including thier own). that's mean that it's an independent application that exposes it services and content providers to all apps.
Google force Google Play Services installation seamlessly in background via Google Play store app. that's a privilege that no other app can have, because they controlling both apps, and the OS Android itself (not fair!)
so, if you can force your users to download dedicated application only for your engine (like Google do) - that's great!
if not - then you will have to settle until then with a Master/primary app that must be installed, and it's the only one the exposing the data and services to all other.
You can store the database on the external storage and access it from all of your applications (Use getExternalStorageDirectory).
Use the openOrCreateDatabase method of the SQLiteDatabase class to access it and read/write data from it.
Since accessing from multiple processes can cause locks, I suggest you manage that yourself using a file with the name/packagename of the locking application so you can sync the data access between your applications.