I need to store information in the mongoDB database on the phone to be used while off-line. The app will download the data while online, and store it in the DB, to be used while off-line. Then when the user is online again, I will send the mongoDB info collected, using my API.
I don't want the mongoDB to be synced with the server while online, either. I want to keep the data on the individual phone. I want to use the data in mongoDB while offline. I need the app to be able to quit/restart, without losing the data on the phone locally.
What is the best way to go about doing this?
There are some options to consider.
1) Create a local mongo database - this is client only storage with no server publication (not sure if it persists between app invocations)
2) sqlite can do the job, but only on Android (not IOS)
3) LokiJS is a fast JS only database that promises to be useful - haven't explored it, but it would be good to hear some feedback
4) If the data is small, you could use LocalStorage, it's pretty simple, you just need to look after serialising and de-serialising it yourself
Related
We are building an app for our teams out in the field that they collect their daily information using Firebase. However one of our concerns is poor connectivity. We are looking to build an Online/Offline button they can click to essentially work offline for when things slow down. We've built a workflow in which we query all the relevant information from Firestore.
I wanted to know if there was a way to tell Firestore to work directly on the cache only and not try to hit the servers directly. I don't want Firestore attempting to make server calls until they enable online again.
You shouldn't need to do this. If you use realtime listeners, they will already first return the data from the local cache, and only then reach out to the server to check for updates.
If you are performing one-time reads, the SDK will by default try to reach the server first (since it has only one chance to give you a value). If you want it to only check the local cache, you can pass an argument to the get call to do so.
You can also disable the network completely, in which case the client will never call on the network and only serve from the local cache. I recommend reading about that and more in the documentation on using Firestore offline.
I have an application that needs to send data to a cloud database (DynamoDb).
The app runs on a computer that can lose internet connectivity or be switched off at any time, but I must ensure that all data eventually gets to the cloud database.
I can assume the application will eventually be switched on, and will eventually get internet access back.
The app is written in VB .NET
What are some schemes for achieving this, and are there any ready-made products that already achieve this?
You could implement a write-through cache using a local DynamoDB instance (or even using SQLite). But without getting specific details about what kind of data you'd be storing into the database, and what data should be made available "offline" it's hard to say exactly how you should structure your application. You'll definitely want to not keep everything local, unless the volume of data is really small overall.
Then there is the problem of resolving conflicts that may occur during network partitions (ie. a client goes offline and makes some database modifications, while other clients also make modifications to the database; these need to be reconciled and it's up to you, and your users to determine how)
It's not a simple problem to solve.
I have a Xamarin.Forms app that uses a local SqLite database as its source for data. The data is proprietary, so I want to protect it so that if someone gets access to the database file, they would have to decrypt it to access the data.
I also want to limit the number of queries users can make against the database so that at a certain point they have to purchase the ability to use more of the data (in-app purchase).
I want to avoid making network calls as much as possible to minimize impact to the user's data plan and allow the app to work well in conditions where there is poor or no connectivity. So, I want the data stored in a local database (perhaps in SqLite).
I'm curious how different people would approach this problem to protect the data and at the same time minimize network usage.
Here is kind of what I was thinking (if it's possible):
1) Let the user download/install the app.
2) On first load, the app will upload a key based on the device id and the user's current purchase information. Then it will download a SqLite database file that has been encrypted using the uploaded key.
3) When the user reaches their limit of queries, the database file is deleted. If they purchase more data, then a new key is uploaded and a new encrypted database is downloaded to be used.
Thoughts? Is there a better way?
I would suggest SQLCipher! It is a Component within Xamarin (http://components.xamarin.com/view/sqlcipher-for-xamarin-ios) but can also be built from source as it is Open Source (https://www.zetetic.net/sqlcipher/open-source/)
That will totally secure your database :)
UPDATE 8/2/2018 - SQL Cipher is now free and easy to implement thanks to the greatness of Frank Krueger. sqlite-net (https://github.com/praeclarum/sqlite-net) is the defacto sqlite library for Xamarin now (if you're still using the Sqlite.Net fork I recommend going back to sqlite-net as soon as possible as Sqlite.Net has been abandoned) and it now includes SQL Cipher support completely free of charge.
As clb mentioned, SQLCipher is open source. So if you don't want to pay for the component you can download and build the source yourself, then wrap it for use in Xamarin. This is, admittedly, a technically challenging task.
If that's not an option, I would recommend two other options:
Reevaluate your need to store data locally. It's extremely unlikely that you need to transfer enough data to even cause a blip on a user's data plan. And between cellular and wifi, it's not that common anymore for users to be without a connection. It certainly does happen, and there are certain apps where this is very important, but you may have to make concessions if the data is that sensitive.
If you absolutely have to store the data locally, and you can't use SQLCipher, your last real option is to use a cryptography library and encrypt the data itself, rather than the database file. This is less than ideal, typically, for a variety of reasons, but it may be your last resort. PCL Crypt is a PCL capable crypto library that you can look into.
https://github.com/aarnott/pclcrypto
I am creating an app with user login using sqlite i am storing the login details which includes the users favorite movies.suppose another user who has downloaded the app also picks the same movie i want to be able to let the other 1st know about 2nd user.how do i do that.does the sqlite db used to store login details be available for the other user or should i have server to upload each user's login details?I think my confusion is stemming from the fact that i dont understand how people use sqlite in iphone app ?
In very rare instances SQLLite should be used directly. The best way to handle data storage local to an iOS device is CORE DATA. I would suggest you consider using Core Data for storage and not call or mess with SQL Lite directly.
i was wondering if there is a way to enable cloud features for a SQLite database application.
Should i save the whole database to the cloud each time ? For example when i quit the application is it required to save the whole database to the cloud.
What do you suggest ?
Should i drop SQLite and use another database for cloud programming .
iCloud supports SQLite databases.
When properly setup it will only sync change logs instead of the entire database. In theory it's pretty nice. I haven't however had the best of luck using it yet, it seems to be a little too buggy to actually use in ios 5, hopefully it's better in 6.
To be most efficient you could manage a changelog of objects that are modified by the app. Then when its time to sync (while closing the app for instance), you can make operational requests to the Cloud. For add and update you can send the entire object, while for delete just the oid should suffice.
This is a very simple sync scenario. Things can get complicated fast if you are looking to send changes that happen in the Cloud down to the device. That is a scenario for a different thread.
Based on your question, you just need to sync from the device to the Cloud.