From this site: https://developer.android.com/training/data-storage/room
".. The most common use case is to cache relevant pieces of data. That way, when the device cannot access the network, the user can still browse that content while they are offline. Any user-initiated content changes are then synced to the server after the device is back online."
Why is rooming trying to access the network, when the data is stored locally as Room is a local database?
That description seems wrong or do I misunderstand something?
Room doesn't require network access.
That is just giving an example of a situation where SQLite (and therefore Room) can be useful as SQlite is an embedded database. That is if the App gets data via the network but the device may not always have access then some data can be stored locally on the device freeing it from permenant newtwork access.
It is quite feasible to have Apps that use Room that have no network access at all. In which case the data would either be input by the device's user or perhaps distributed via the APK.
Related
I am planning to switch to Firebase as my local and online database for my Android app. As per the docs, Firebase stores changes to the local database first and then pushed it to the online DB when network is available.
In my app, I would be putting some really sensitive data about the user in the database. So here are my questions,
How secure is the local Firebase database?
How difficult is it for a well-intentioned hacker with the right tools to hack it?
Is it just a simple JSON file like the online database, which anyone with root access can open?
Thanks.
In a general sense, Firebase Realtime Database can be used while offline. However, the expectation is that the app is supposed to be connected most of the time, and changes to the database that happen while offline will be synchronized when it has connectivity. 100% offline use is not really a supported use case, because the canonical data store is on the server.
The local copy of the database is limited to (10MB, at least on Android this is the case). If you intend to write to the database beyond this limit while offline, it will evict part of your cached data to make room for whatever you’re adding. Then, you will no longer be able to read those evicted values until the app goes back online. Worse, managing a growing list of writes to apply when back online is taxing on the app, so you don’t want to plan a lot of writes while offline.
Also, if you have permissions or validations defined for your database, these can only be checked on the server. So, if you’re doing offline writing to your local cache and you no longer have an active listener, you may never know if those writes fail.
Because of these caveats, it’s better not to think of Firebase Realtime Database as an “offline” database. It’s better to think of it as a “synchronized” database that actively syncs to the server while connectivity is present.
We have an Android application which stores its data in a local SQLite database; primarily for performance, but also to allow for working off-line (as we are often in areas with low signal).
At the moment, the data is stored in encrypted format (passed down from our web servers), but this in itself causes a performance issue, where for example, if we want to search records for a particular "surname", we need to decrypt ALL of the data, rather than using a straight SQL query, to include where surname='Smith'
We cannot (as it currently stands) store the data in a more friendly 'open-format', as it's possible to 'root' the device, take a copy of the MySQL database, open it and read the data.
Is there the means (perhaps someone can provide an example) to either password protect the local SQLite database or somehow apply encryption, so that we can (from an application perspective) have the database available in open format, but so that if any would-be hacker got hold of the device and rooted it ... they would have a hard time reading our data?
I have searched for a suitable solution and cannot find any options for the SQLite database, any 3rd party software or any examples of code that do this.
SqlCipher, this will might work in your case
Remote Storage:
Your data is sensitive and needs to be accessed by the user on the go from different devices. If your app is a good one then the above line will hold true.
Security + Remote access from any device says you maintain your dB on a remote server.
Your flow can be :
User login --> Token --> Auth Token in every call --> Process request and get/put data in/from dB
Local Storage:
Let's say that you only want to store data locally and don't want to store it on the server. For this you can use public-key cryptography
You can use a public Key in your app to encrypt the data and store it. Now, you want to access the data. Request the private key from the server and decrypt it.
Again, to get access to private key you should use some form of authorization (or anyone can access your key).
Without the private key, even if a hacker roots the phone and gets his/her hands on the dB, the data would be useless.
I am working on an application that will, basically, allow people to create, join and manage groups of other people. The people within the groups can also message each other.
I have been wondering which path would be better:
Keep a remote database with all the information, including messages sent to and from users. And have the app query the server every time it needs information. Even information it has seen before.
Keep a remote database with all the information, including messages sent to and from users. Also keep a local copy of the remote database and just keep it synced with the remote database. Whenever the app needs to query for information, it does a query to see if the local table is up to date. If it is not up to date, it updates the table and runs the query on the local table. This way it will keep a local copy and the app will have fast queries when there is not an update to the remote table.
What is generally done with mobile applications and remote databases?
Would it be "bad practice" if i just did number 1?
From my point of view, in most cases, the database in the mobile is just a cache of the real database, the one in the server. So, my suggestion will be to keep locally all data that you need syncing with the server. This allows you to show information even when no connection and show something to the user while the info is updated.
Also, this approach makes the local data volatile without risk, as it's stored in the server. So:
All info is in the server
With a background process (service, thread, intentservice, whatever best suits you) you sync this information with the local database
UI is always showing info from local database
Of course, this is a very general approach, and needs to be examined for each case as different situations may need different approaches.
My base response is that I would keep the data in one place and access it remotely unless there is a major reason to keep it locally. There would have to be extenuating circumstances to mandate that I keep a copy of the data locally. Just make sure your queries are accurate and concise. Don't pull over more data than you need to.However, you can have a subset of data kept locally. Items that are specific to the user (like messages), but keeping data that is not relevant just adds overhead and bloat.
I am very new to android and am trying to understand db persistence.
Consider this scenario
on device1 local db created
it syncs with google via the BackupAgent by backing up the db file
on device2 db file is restored and local db is now in sync
The problem I think I may have what happens if there is no remote connection. Then this could happen
on device1 local db created
it syncs with google via the BackupAgent by backing up the db file
on device2 previous db file is updated offline
device2 goes online. Syncs with backup agent and device2 changes are lost
There are various scenarios where I think this pattern will cause conflicts between devices. Am I missing a simpler better way to store and sync data between multiple devices. Perhaps just only store things on a remote databse perhaps.
As i said I am new to this so any advice would be greatly received.
Thanks
From the docs:
The backup service is not designed for synchronizing application data with other clients or saving data that you'd like to access during the normal application lifecycle. You cannot read or write backup data on demand and cannot access it in any way other than through the APIs provided by the Backup Manager.
The backup agent is not meant to be used in the way you are using it. It is not meant to provide real-time syncing of data between multiple client devices. It is only designed to backup stuff such as user preferences so that if users move to a new device or reset their phones, they can restore their settings and things like that .
When you request a backup, the agent does not do it immediately. It does it at a later time based on a number of different parameters (such as network efficiency). It is generally meant to store the latest version of a users preferences.
If you want real-time syncing between devices, you would need to implement your own backend or try out one of the BAAS (Backend-As-A-Service) providers such as Parse or Firebase.
I'd like to make a basic to do app in android to get my feet wet. I have a rest api and online DB that handles the basic CRUD when there is a connection present.
Most task apps I've used however, allow creating tasks when there is no connection present.
What are the best practices for stuff like this?
Do apps usually store a copy of ALL data for a user locally so there is access to it when a connection is not present?
It looks like the app I use (astrid tasks) has no problem accessing all my tasks/history regardless of connection
If this is the case, how is syncing handled as far as the remote data's primary keys are concerned?
You have some encoding, let say one request per single data change to be executed atomically encoded as xml or json. Make a base class which is parent of connection and use it to send data update to remote db. If connection isn't present store entire command into file or sqlite. You can create multiple files (if going by file approach) based on their sizes, date etc. Create some rules how the oldest record will be chosen - if you need to update db in ordered manner.
One solution would be to have a local database in your application. When there's no internet connection store the data in this database.
Now let your application listen for network changes. When the device is connected to the network, you could upload the cached data from local database to the server without user interaction.