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.
Related
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.
I am making a mobile app using Cordova and I need to save some sensitive and not so sensitive data inside the phone. I am a bit lost on what is the best way to do it.
I need to save:
A JSON web-token (for authentication).
A response from server (I save this to populate my page in case the GET request fails).
Coordinates information when user is logging data to the app (for later upload to a server from with in the app). These will be many separate logs, and can be large in size for local storage ~5-10 MB.
Till now i have been successfully saving everything I need to the local storage but I don't think that is the correct way to do it. So that is why I need some help in deciding what is the best course to take from security point of view.
Saving server response is just for better UI experience and static in size so I guess local storage is a good option to use.
But web-tokens and GPS logs is sensitive information and I dont want to keep it in the local storage as it is accessible from outside the app.
What other options do I have?
Cordova still doesn't have encrypted storage.
Is saving to files a good approach? This here says that data contained inside cordova.file.applicationStorageDirectory is private to the app.So can I use it to save the logs and the token?
The plugin also lists the file systems for Android and iOS and lists which of those are private.
I am currently working with android phones but want to extend the app to iOS later. I have never worked with file systems and caches before so I am a bit lost.
I'm developing an internal iOS cocoa app, in which multiple devices need to connect and read/write to a data connection. It will be similar to an inventory application.
Would this be best done using a server-side SQLLite communicator or some other kind of server-side data store? Or is there a method i don't know of that multiple devices can share data.
Any help is appreciated. Thanks.
A third-party service possibly worth checking out is Parse.
With Parse, you can add a scalable and powerful backend in minutes and launch a full-featured app in record time without ever worrying about server management. We offer push notifications, social integration, data storage, and the ability to add rich custom logic to your app’s backend with Cloud Code.
Depending upon the complexity and assuming that all devices can be connected to the same icloud account you could utliize icloud for this.
http://www.raywenderlich.com/6015/beginning-icloud-in-ios-5-tutorial-part-1
I'm creating an app that relies quite heavily on Core Data. It is a content-driven app that primarily delivers question/answers to the user.
On its first load, the app delegate pulls through lots of data from an SQLite into the app's persistent store. The data is basically lots of content that is not only in-app purchasable, but is also copyright-protected.
Normally, developers requiring encryption/protection for Core Data need it for storing sensitive user-data. However, as in this (my) case, I would need to protect the persistent store from external access from anyone or any source (including the user), purely due to the fact that I don't want someone to be able to download the app's entire Intellectual Property from the persistent store.
I noticed on the iPhone Simulator that locating the persistent store and opening it (with an SQLite browser) was no trouble at all. This is a little worrying, and so, if this is also as easily possible for a release installation on a device, then I would like to know:
I don't necessarily want to go all-out on encryption, as I've found ways to do this row-by-row (lazily), so is there a quick way to obfuscate/scramble a persistent store?
This article shows how to encrypt individual attibutes(of course you can encrypt all attributes).
We know that Dropbox desktop clients use a binary diff algorithm to break down all files into blocks, and only upload blocks that it doesn't already have in the cloud (https://serverfault.com/questions/52861/how-does-dropbox-version-upload-large-files).
Nevertheless, the Dropbox API, as far as I see, can only upload the whole file (/files_put, /files (POST)) when a sync is needed.
Is there any way to do differential/incremental syncing using the Dropbox API, i.e. upload only the changed portion of the file like the desktop clients do?
If this is not possible, then what are the best practices to periodically sync large files that has small changes using the Dropbox API?
Unfortunately this isn't possible and I would suspect that it may never be available.
After doing a bit of research, I found a feature request for delta-syncing to be integrated into the API[*]. Dropbox hasn't responded, nor has the community upvoted this request.
I would make an educated guess that the reason why Dropbox hasn't provided this functionality, and likely never will, is because this is a dangerous feature in the hands of unknown developers.
Consider the case where you write an application that uses such a delta-change update system for updating large files. You thoroughly test your app and publish it to an app store. A couple of weeks after your initial release, and numerous downloads, you start receiving bad reviews and complaints because you managed to miss a very specific test case.
Within this specific, buggy case you've miscalculated a differential offset by 1-byte. Oh no! You've now corrupted thousands of files, for hundreds of users!
Considering such a possibility, I think I would personally request that Dropbox NEVER provide such a dev feature. If they integrated such a function into the API, they would be breaking their #1 purpose-- to provide consistent, safe, & reliable cloud backups of your important files.
[*]: This was the original reference location, but it is now a dead link.
(https://www.dropbox.com/votebox/1515/delta-sync-api-for-mobile-applications)