I'm starting with Android development, and I'm trying to do an application that will help users to find events around where they live. Most of those events are static, and therefore could be stored in an internal database. However, there are other events that might have to be added, or existing events that might have to be modified.
My questions are the following:
Which aspects should I take into consideration in order to decide whether should I use an internal database or external database?
If I decide to use an internal database, what are the approaches to update the user database with the new events or whatever changes that might have to be done?
Thanks :)
To extend a bit Kevin's answer I would add that one of the approach could be to use an external database that just return through a webservice a timestamp of the last database update. If this timestamp changes, your local database should be update (maybe by sending only differential changes).
Internal database is an interesting solution if : your app means to be running without connection or the data volume is too important to be requested at each launch.
Without too much detail about your app, I'd keep an internal database that you periodically update from a remote server (which I assume you're calling the "external database").
Related
I use the ObjectBox in my kotlin project. Users can erase the database by clearing the application Data from the Android settings.
I want to prevent database removal or change ObjectBox Store mode to SQLite!
thanks
In case you want to make user data persistent you definitely should save and check DB copy on your server.
First of all, as you probably know, this is "normal" behavior on Android. When you delete an app's data, you have to start from scratch. E.g. all local data lost and log-in again etc. I'd guess that 0.01% of users would actually know about it and actually do that.
Anyway, yes, the question is if you want to extend data scope to cloud/server... That's a different topic though. ObjectBox will offer data synchronization later this year.
Alternatively, there's also Android's backup function: https://developer.android.com/guide/topics/data/autobackup.html
I am creating a data repository layer in my application which in turn serves data from two sources, either network API calls or getting data from local storage. When there is a request to the data repository layer, I first need to check if the data is present in the local storage or not. If not, I then make a call to my API to get the data. To check if the data is in local storage or not, I was thinking of two ways to implement this:
On app startup, I load all the data in the database into the memory (eg. lists, maps etc.) and then whenever I have to check of existence of data in the local storage, I check from the memory. This has a possible problem that I have faced earlier as well. When the app is in background, Android system, might clear up this allocated memory to serve memory to other apps. This makes things complicated for me.
Whenever I want to check the existence of data in the local storage, I directly make queries to SQL tables and decide based upon that. This is much more leaner and cleaner solution than the above mentioned case. The only worry for me here is the performance hit. I wanted to know if the SQLite database runs after being loaded into the memory or not? If yes, then the memory layer of data that I had created above is useless. If not, is it safe to keep on querying the SQLite database for each and every small data request?
SQLite caches some data, and the Android OS will keep the database file in its file cache, as long as there is enough memory.
So when using SQLite, your app's performance is automatically optimized, depending on available memory.
My app tracks school grades, calculates averages, etc. and stores all of this in a SQLite database. If a user has to reinstall or gets a new phone, I'd like to be able to restore their data.
It looks like most developers do this either by backing up to SD card or by using Android Backup Service through Google. I'm not sure which is the better method. I'd like restoring to be simple but reliable. I welcome any comments on this.
One thing I'm trying to understand is why Google says to extend BackupAgent instead of BackupAgentHelper if using a database.
If you have an SQLite database that you want to restore when the user re-installs your application, you need to build a custom BackupAgent that reads the appropriate data during a backup operation, then create your table and insert the data during a restore operation.
Why can't I just back up the database as a file and then restore the file? My SQLiteOpenHelper class already handles upgrades if db versions are different. I guess I could just abort on a downgrade.
Why can't I just back up the database as a file and then restore the
file? My SQLiteOpenHelper class already handles upgrades if db
versions are different. I guess I could just abort on a downgrade.
Reason: same database file may not work on different device models(even though most of the cases, it should work, there are cases where it will fail). It depends on parameters like page size etc set at sqlite engine level. Ideal way is to backup the data rather than copying the whole file
It's suggested that you avoid backing up the whole db file all the time mostly because that's a lot of redundant data traffic, especially if you've only changed one record in a large db. Being able to write per-record updates to the backup system is much more efficient (though of course is not nearly as simple to implement).
I have made an application which is about pets, at first I had kept the database local to the phone, however as new features arrive I want to make it a network based application with remote database. However I have around 500 downloads on the play store and I dont want my previous users to lose data. I came up with an idea of rolling out an update in which I copy all the databases to the SD card and then mail them back to me and update them in the remote database. I wonder if there is a better way to go around this. Help will be highly appreciated.
A better way would be to write a webservice to which you can send the database row by row. The webservice will then update your Server database(s).
This not only prevents duplication of your database between internal and external memory, but it also allows automation and more flexibility in the update process. You can also pause the transfer, and pick up from whichever row was last sent easily.
I am trying to decide on what data storage methods to implement. Here is the situation. Whatever method I choose, it is going to be updated once week (can I update a SQLite db without putting out an update in the market?). The user cannot add or remove items from this ListActivity, they can only pick the ones they want. This data method should be able to remember the selected items during any given week. Let me know what method you would use and why. Thanks so much in advance.
A webservice would allow you to update the data whenever you want without having to push updates to the market. And updating your app in the market doesn't guarantee that users will apply the update. Ofcourse the downside here is that your users would need to be connected to the internet while using the app.
Moving your database to remote server will give you freedom to manipulate data without actual application being updated, thus no need to update on the market. If it is a matter of access to internet, you can still use this practice, just more work has to be done (adding Broadcasters that will listen to connectivity than update the local database with global one on your server, or something similar).
If you want to update the data on the device once a week, then you will need to use the local SQLite database and interact with a web service that provides the updates. You will not need to go through the market to do this. However, if you need to update the structure of the database (add, remove, or change columns or tables for example), then you will need to update your app on the market.
I highly recommend watching the Google IO 2010 talk Developing Android REST client applications. The speaker is the author original author of the Twitter app for Android, and talks about the design patterns and best practices that he uses.