I have been using Firebase Web SDK for my react-native app (I am using FIRESTORE to store the data). Up to this point, I have had no problems. It all works smoothly. But now I want to add some kind of offline storage mechanism to my app so that I could still offer some functionality or display some content that was cached from the last connected session even if my users are offline. After some investigation, I have the impression that react-native-firebase is the preferred way to go. Now I have some questions and I like to get some advice from the experienced.
Is react-native-firebase the only option to go? I have quickly read about AsyncStorage and it is just a key-value storage. Considering the simplest thing I want to do is page through a list of firestore documents, this kind of storage seems not to be suitable to do this offline. Like If I wanted to do this with AsyncStorage I would have to put all the content (maybe hundreds of documents) I get from the firestore backend, persist them as a single string value, fetch them back, parse them, page them etc. And write custom logic& methods for all these.
If I was to use react-native-firebase, just enabling the offline storage -I assume- takes care of this for you and you don't have to write any custom logic for offline storage usage. I assume the data that has persisted for offline usage has the same structure as it does in firestore database. I feel like If I use anything other than react-native-firebase, I would have to handle all the custom logic for persisting, reading and rendering the data offline myself. Is that right?
The biggest concern I have is the amount of code refactoring that might be required. I have many lines of code and so many .get().then() like lines where I get and render the data from firestore. In the documentation of react-native-firebase it says:
...aims to mirror the official Firebase Web SDK as closely as
possible.
I am not sure to what extent this is true. I have checked the react-native-firebase's firestore module's reference documentation but I just can't tell how many of these querying methods are actually supported.
So, the way to go is react-native-firebase's way? Would it take a heavy toll on me trying to refactor the existing code? Any similar experience do you have?
I would appreciate any help.
Thanks a lot...
Maintainer of the react-native-firebase library here.
...aims to mirror the official Firebase Web SDK as closely as possible.
This is a minor disclaimer as there are some differences between the two, mainly down to how certain things have to be implemented with React Native.
For example, enablePersistence does not exist on RNFB. Instead, persistence is enabled by default and can be toggled off (or on) via settings().
Is react-native-firebase the only option to go? I have quickly read about AsyncStorage and it is just a key-value storage. Considering the simplest thing I want to do is page through a list of firestore documents, this kind of storage seems not to be suitable to do this offline. Like If I wanted to do this with AsyncStorage I would have to put all the content (maybe hundreds of documents) I get from the firestore backend, persist them as a single string value, fetch them back, parse them, page them etc. And write custom logic& methods for all these.
This is technically possible, however there are downsides to this as you have mentioned. With Firestore, when the device goes offline (quite common on apps) and you attempt a read/write it'll read/update your local cache, which will still trigger event listeners. When the app goes back online, it'll automatically re-sync with the server for you.
If I was to use react-native-firebase, just enabling the offline storage -I assume- takes care of this for you and you don't have to write any custom logic for offline storage usage. I assume the data that has persisted for offline usage has the same structure as it does in firestore database. I feel like If I use anything other than react-native-firebase, I would have to handle all the custom logic for persisting, reading and rendering the data offline myself. Is that right?
This is all handled for you. We wrap around the native Firebase SDKs so expect the same level of consistency if you were developing a native Android/iOS app if not using React Native.
The biggest concern I have is the amount of code refactoring that might be required. I have many lines of code and so many .get().then() like lines where I get and render the data from firestore.
Generally everything is the same apart from a few minor methods for reasons mentioned above.
So, the way to go is react-native-firebase's way? Would it take a heavy toll on me trying to refactor the existing code? Any similar experience do you have? I would appreciate any help.
I'd recommend anyone developing with React Native & Firebase to use RNFB. It provides a lot of extra functionality the Web SDK cannot provide with React Native. Apart from a more cumbersome setup & changing imports, it should work very much the same.
Related
I want to build an app where users can jointly work on lists. The app should be avialable offline and sync changes when it goes online again.
For the app iteself, I've decided to go with Ionic Vue. For storage, I created a Firestore and was able to sync between my app and Firestore by using the Firesotre method onSnapshot() (doc). Although this working at the moment, the resulting code does not look very elegant and I have to create multiple very similar Firebase calls in different components. This slows the app down and (I think) also prevents me from making the lists available offline and sync them again when there is a connection.
I recently discovered vuex and the idea sounds quite fitting for my case: I store all app data in the vuex store and sync it (both ways) to Firestore. My components access the vuex store instead of the Firestore directly. Here are some questions regarding this idea:
Is this in general how the vuex store and Firestore are supposed to be used?
Can I make the vuex store data available on my phone and only sync it to the Firestore whenever there is a connection (to make the app available offline inlc. modifying data)?
If so, what is the easiest way to sync the vuex store to Firestore?
Regarding the syncing: I found Vuexfire, but it does not really work for me as expected - I guess this is because it is built on Vue 2 (as against Ionic which is built on Vue 3). I also found Vuex Easy Firestore, but I'm a bit reluctant to try new tools, as Vuexfire cost me several hours.
Thanks for reviewing my implementation ideas!
As the question suggests, I'm trying to figure out how to persist cached data beyond a phone reboot or app closure using React Native with Redux Toolkit Query. I've noticed that the cached data gets wiped in those scenarios. I believe that caching data beyond an app closure or phone reboot is a common practice.
I have thought about simply storing the data in client-side Redux using Redux Persist to get around this issue, without persisting the api slice. As this post indicates, persisting the api slice is a bad idea:
What happens when i use RTK Query with redux-persist?.
Any tips on this would be appreciated! Thank you.
Generally I can only repeat what I already said in the other issue:
I do not recommend doing this. Data from a server should be fresh, and this way it defitely won't be.
That said, we are currently working on SSR integration and that, too, will need similar functionality. So some kind of rehydration mechanism will be integrated, probably in Redux Toolkit 1.7 - but until then you have the choice between not keeping api data cached (again, my recommendation. No user wants to open an app and see data from five weeks ago - rather show them a loading screen!) or restoring it, but potentially ruining cache collection of said data.
I'm working on a game-companion app and I was looking for a neat way to fetch data from multiple APIs initiated by starting my app (and maybe also if the user is refreshing the current page with swipe-to-refresh).
The thing is, I planned a dashboard-style homescreen (mostly reduced data from every API), where the user can navigate to different pages (all fed with different API's) and get detailed information for the specific section. I'm not sure how I can provide the API-data 'globally'.
I feel like my main.dart would be way too overloaded, but i can't think of any other way.
What's your thought on that?
Few approaches:
You can use a persistent db and write a wrapper DAO over it that such that anybody with access to this DAO object can write and read from DB. Packages like sqlite help in this regard.
If you are adopting bloc way of state management in your flutter app, then you can create blocs which could be used to share data across your app. flutter_bloc is a good place to start with this.
Via Singleton , If you want a sensitive data that needs to be available within the app globally, then you can create a singleton class that provides read and write from a secure vault. For this secure vault, flutter_secure_storage is convenient or shared_preferences for non sensitive data
How can i make an offline app. For ex. user needs to use an app in offline like bible, dictionary app etc..
How can I make similar like this?
Every mobile app is an offline app unless it communicate with a server via some sort of https request.
Anyway, I would suggest you look into Async Storage (built-in react-native) or i would personally use SQLite.
Make sure to save your data mostly or wherever possible as text and render it on some sort of object to display. which will take less space than images making your apps faster and smaller in size.
How does the Dropbox Datastore API differ from similar offerings like Parse? One difference that I see is that my users pay for server storage instead of me. Are there other differences?
Disclaimer: I'm a Dropbox engineer who worked on the Datastore API, and know about the Parse API only indirectly. Weigh my opinion appropriately. Major differences I know of (pro and con):
Dropbox Datastores are free to the developer, and free the user for the first 5MB per-app (after which their Dropbox quota applies). Parse charges developers based on how many API requests they’re making.
Parse has minimal offline support, while Dropbox has full offline operation. With Dropbox, if the developer modifies data while offline, those modifications will be reflected in subsequent queries (with Parse, those changes are not reflected). Dropbox provides on-device query logic (unlike Parse) so that apps can continue to generate the views they need to, even when there’s no Internet available. In addition, Parse does not provide conflict resolution or querying offline.
Parse provides the ability to share data between users, and global data for all users of the app. Dropbox Datastores only support per-user data (for each app) for now (sharing is on the roadmap).
I would also add that:
Parse is full feature of backend of as service. You can find a pretty complete list of the other player in this field: http://en.wikipedia.org/wiki/Backend_as_a_service. They provide feature like:
Data service
User registration/auth
Push notification
Social
The dropbox Datastore APIs is more focusing on data services. (You also got the User part for free too?) Also it works full offline.
The Parse framework can store data that can be ready by any user in the application.
The Dropbox datastore, store data for each user, and you can't accesss data from other user. That's the main difference.
So easy to get lost in this since you have to read between the lines. My take is that with Datastore you are working with objects stored offline locally as json. I'm hoping they will soon release a Xamarin Android component - they released an IOS component last month. Since Xamarin targets both Android and IOS and Winphone, who knows why they made a dedicated IOS DLL for Xamarin but I digress. With Parse, it appears to me their intent is the always-connected-device. Sure you can save queries locally and you can save (save eventually) locally where Parse will push to the server when it is connected. But saving "eventually" and saving queries for offline work is a different design than just saving and letting Parse do it all in the background for you - which it does not unless I have missed something that would make this attractive to me. I cannot see Parse useable for devices that you know will be sometimes-connected, without a lot of code to make this happen and sync.