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.
Related
I've read a lot about regarding offline cache strategies but unfortunately I found nothing that can fulfils my requirements.
Let's say that I have a list of Order in my local database that need to be synced back with the server if one of them is modified. The Order can have multiple statuses like: New, Started, Paused and Completed. The status changes must be synced sequentially with the server because the order is also important.
Creating the table with "isModified" column is not good for me because i need to sync every status change one by one sequentially, not just the last one.
What are the best strategies to store all status changes when the device is offline? I am thinking about duplicating the Order table or creating a new one for the sync data because there can be also other objects not just Orders.
Any advice would be much appreciated.
If the order of modifications is relevant, you should store each modification in some kind of ordered data structure, e.g. another local table.
Use Firebase Database for offline database. It synchronises automatically when an internet connection is active.
Add the line below in your Application class:
FirebaseDatabase.getInstance().setPersistenceEnabled(true);
My Android app is fetching data from the web (node.js server).
The user create a list of items (usually 20-30 but it can be up to 60+). For each item I query the server to get information for this item. Once this info is fetched (per item), it won't change anymore but new records will be added as time go by (another server call not related to the previous one).
My question is about either storing this info locally (sqlite?) or fetching this info from the server every time the user asks for it (I remind you the amount of calls).
What should be my guidelines whether to store it locally or not other than "speed"?
You should read about the "offline first" principles.
To summarize, mobile users won't always have a stable internet connection (even no connection at all) and the use of your application should not be dependant on a fulltime internet access.
You should decide which data is elligible for offline storage.
It will mainly depend on what the user is supposed to access most often.
If your Items don't vary, you should persist them locally to act as a cache. Despite the fact that the data mayn't be really big, users will welcome it, as your app will need less Internet usage, which may lead to long waits, timeouts, etc.
You could make use of Retrofit to make the calls to the web service.
When it comes to persisting data locally within an Android application, you can store it in several ways.
First one, the easiest, is to use Shared Preferences. I wouldn't suggest you this time, as you're using some objects.
The second one is to use a raw SQLite database.
However, I'd avoid making SQL queries and give a try to ORM frameworks. In Android, you can find several, such as GreenDAO, ORMLite, and so on. This is the choice you should take. And believe me, initially you might find ORMs quite difficult to understand but, when you learn how do they work and the benefits they provide us, you'll love them.
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.
I have an architecture question. If you have a web app that is storing information on a DB server, theoretically, I should be able to use the middle tier logic for a mobile app. When the mobile app starts it can connect and populate a local SQLite DB or use JSON to store information within the mobile app. What if the mobile app also needs to work in off-line mode? Do you have it sync the next time it is connected? Do you have the mobile pull down and populate a complete DB or so it available in off-line? What are the best ways to architect a mobile app that has to go from on-line to off-line?
The simplest solution would be to put a "LastEdited" column into every table in your database and then pull query all the data which has updated since the last sync ( and you can perform a check on the index to detirmine if you need to update or insert into your own local cache. )
The ability to delete rows should actually be limited to a boolean "isDeleted" flag in this case to keep the sync process nice and simple.
If you have then the ability to edit or create rows from your app then you should keep a local table of changes to sync when you can go online and may have to implement some form of "merge" logic.
Several things you need to consider.
If your app is read only, you should implement a 'delta sync' logic in your local d. Keep a timestamp of last sync and get updates from your server. Of course, you need to consider the local db size in getting too large.
If you app is read/write, when working offline, you need to consider the two way sync especially when same record can be updated in different devices/users.
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.