I want the "backup" part to be done in the background and would only start if the user is not using it. I am using android-priority-jobqueue and have made a Job object that would achieve this.
Here are my current problems :
But now I am thinking of how I can make sure that the user is not using the app so that I can run the job. I am also thinking how I can backup or sync the database while the user is using the app like in multiple other apps.
I don't know how I can restore the data back to the app without missing any data. Like for instance, there are two devices. Device 1 backed-up its database into Google Drive. Now, Device 2, being that it had no connection for a few hours, it created new entries into the database. Then it connected to internet and it has to get the other entries from the Google Drive without overwriting the entries it currently has.
I really am confused about when to sync, when to backup, and how they can be flawlessly achieved.
Can anybody please help me
For #2, if you are using GDAA to upload the file, you can pass an ExecutionOptions that allows you to handle conflicts. This lets you implement any arbitrary logic to resolve the upload conflict, e.g. maybe in your case it's to merge contents from both devices. However, note that currently conflict detection is only possible for updating an existing file, not for creating a new one.
For more reference:
https://developers.google.com/drive/android/completion#conflict
https://developers.google.com/android/reference/com/google/android/gms/drive/ExecutionOptions.Builder.html#setConflictStrategy(int)
Sample code for conflict resolution:
https://github.com/googledrive/android-conflict
Related
I am trying to learn Google Cloud Storage with JAVA for some days and i was inserting some data in datastore and the inserted data's could be seen from here //localhost:8080/_ah/admin/ . Now when i stopped this session and again run the backend some weird behavior i saw.
Case 1: When i am running it again my previous data's are gone.
Case 2: If i have inserted 4 data's in the datastore in a session and then in the next session 2 or 3 of my previous data are missing.Here in this case not all the data. And also sometimes one data is missing.
I searched for this and i saw that the local_db.bin will be created in every run. I prevented it by adding the following condition in VM arguments - Ddatastore.backing_store=PATH.
But still i am having inconsistent behavior. Though the local_db.bin file is not being deleted, but the datastore behavior is erratic. (For example sometimes the entities are successfully preserved, and sometimes some of the entities are deleted).Will this happen when i integrate with my android app?
During startup, the App Engine dev server displays the location of the datastore file it is using. I have seen in the past where a different datastore file is used when starting the server each time.
You can copy the datastore file to a location of your choice. Use the datastore_path flag to inform the dev server which data file to use. This will allow the dev server to use the same datastore file each startup.
dev_appserver.py --datastore_path=/data_path/myapp_datastore myapp
You should not see random data disappear from your app as you have mentioned. One thing to keep in mind is that the Google Cloud Datastore uses an eventual consistency model. So, if you are inserting a new record in the same process as returning a list of all records - you may not see that new record until you refresh the page in your app.
There are ways to force strong consistency by using ancestor queries. More on ancestor queries can be found in the documentation:
https://cloud.google.com/appengine/docs/python/datastore/queries#Python_Ancestor_queries
In cause you're developing in Java, you've to provide VM arguments like this
-Ddatastore.backing_store="/path/to/datastore/file/location/local_db.bin"
More here: https://code.google.com/p/android/issues/detail?id=68225
You can also find another solution for custom datastore location using Java dev server in my question.
//localhost:8080/_ah/admin/ shows only data that is used locally on your computer for testing purposes only. It is not linked to the actual Datastore in any way. You should also test your app with actual data after you deploy your app to the App Engine.
So I have an application that logs medical data entered by user. I need to add functionality for backing up and restoring that data in case user changes their Android phone OR switches to and iPhone (there is an iPhone version of this app, which I have limited visibility into).
The data is currently stored inside a SQLite DB on the device.
I need help figuring out cleanest/easiest way to do this. So far I am thinking about these options:
add UI to email DB file to + UI to accept a DB file and copy it over current DB. Seems hacky.
create a web service which will store user data and sync on the background. I would need to build sync process and introduce some kind of account system. This seems like quite a bit of work, though likely the most flexible solution in the long run.
switch to Google Calendar as my data storage (data is essentially a set of event entries anyway). This would probably be most seamless, but iPhone option is out of the window.
Are there other pros/cons to these options that I am missing? Or perhaps there are some standard solutions to this?
Option #1 is filled with a lot of problems. Sideloading databases from files coming from external sources is no easy task. I wouldn't recommend it.
Option #3 should be a possibility - but it require the user to set up a Google account which (imho) shouldn't be required. Furthermore the addition of a new calendar and/or a lot of events wouldn't be many users favorite feature. Personally I would hate it.
The second option seems like to most promising. You can build it as simple as you like. You could even make it require only a simple identification code for backing up - or only provide "live" synchronization. It is true that you need some sort of server and accounting system - but these things come as standards and servers are cheap. This option would be the one of my choice.
I saw a lot of tutorials on syncing an android database on a cloud server but this is not what I need.
I have to sync my own application provider with an android native provider(e.g MediaStore). I am still looking into AbstractSyncAdapter API, though, most of the tutorials, again, uses this to sync in a server instead of another local provider. Also, it needs an Account which I think is unnecessary for my application.
I have already considered other options like using ContentObserver and catching the ACTION_MEDIA_SCANNER_FINISHED intent but it would mean I have to check all changes made in the whole database since there is no way for me to know what exact row or column has changed. I am, by the way, developing in Android 2.2(Froyo/API level 8).
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.
I have an Android app, where a part of the app is a list of data which is currently contained in a string-array (in an xml resource). I currently release updates every so often to the actual app, which do nothing more than update this list of data. (yes, in hindsight this method was a bad idea to start with).
My goal now is to change this so that I will be able to only update that one part of the app that needs to be changed. I have a webserver, and am now serving a JSON version of the data off a URL. So all the app has to do is hit that URL, check if it changed (perhaps using a version number), and then update.
My problem lies in the actual implementation:
Where/how should I store this data? As a raw file? SharedPrefs? Database? [i.e. what are the pros and cons of each]
How can I preform a seamless upgrade where even if something devastating happens during the update [such as a user pulling a battery...], it still won't break the app?
Should the updating code live in a service?
I would separate your data crud into a small background service. Use the provided SQLLite. To verify data consistency you could use md5 checks, database rollback features and most importantly design a small set of tests. One only sending a partial file, i.e. "the broken transmission test", garbage file, etc. Keep it a separate and testable component of your app.