I have two threads, each of which handle syncing data one way either from the server or to the server. The thread for getting data off the server needs to run once a day. The other sending data to the server needs to run every 15 mins. I am currently using an Alarm Manager to create repeating alarms for each of these threads. This is then received by a BroadcastReceiver, from which i call an activity, which then according to the data passed into the activity either runs the to server syncing thread or the from server syncing thread. I am using the activity to display a dialog box, to prevent the user from using the application until the syncing has been completed as they both access the database required by the application. Is this the correct way to accomplish this task, or are there better alternatives?
Thank you in advance
This question is not really fit for SO... This is more a debate without any details on how your app works.
Anyway I would use an Android Service to do so. You do not need to bother the user just to upload data. Also why block the use of the app for uploading? Since for uploading you only need to read, just make a snapshot of the current data and upload it. Any changes the user is making right now will be uploaded in next upload, so that's not a problem.
For downloading, you most likely do need to block the app use, but maybe not. This depends on how the app works. You could start DB transactions to avoid doing that.
Related
I was reading about background service limitation in Android 8 and from what I read it seems that you can't run your service in the background for a long time. This seems reasonable but because I use background service to keep connection to server - currently pooling new stuff, sending location and responses I am a bit confused. The responses are OK, I can respond only when interacting with the app, but the pooling new stuff is problematic because it needs to get an stuff from server and if something new come present the user with a notification to respond to it.
If I understand it correctly I can use JobScheduler to schedule some job every several seconds. I can basically schedule the pooling. For the background locations, well there are those restrictions so only foreground service is an option to get updates in requested time.
I will be migrating to websockets and then the pooling is off, the connection to server will be persistent and the app will get updates from server, I was planing to do this in the background service so something would receive stuff from server everytime. However it seems I can't since Android 8. How would you solve this? Should I use foreground service for location and server connection? Or is there a better way to do background networking in an android app on android 8?
Thanks
Here are a few options for performing background work on Android O:
Use JobScheduler. You already seem to have a good grasp on this one- the downside is that it is periodic, not persistent.
Use GCM/FCM or a similar push service to push data to your app when it is relevant instead of constantly holding a connection to your server.
Use a foreground service. This will allow you to continue performing your background work without your app being in the foreground, but will put a notification in the status bar to inform your user that you are doing that work.
Before you select one of these methods, you should take a moment to step back and look at the data that you need from your server and determine why you need a persistent connection and whether the first or second options might be sufficient.
If you absolutely need a persistent connection to your server, the last option is your best option. The idea behind the changes in O is to still allow background work such as what you are describing, but to make it painfully obvious to the user that your app is doing so. That way if they don't think your data is as important as you do, they can take action.
I have built a simple application that accepts data entered by the user and saves it to the local sqlite database. If wifi connection is available it will transmit the data to a REST service hosted on a remote server.
I have done the above part and it is working pretty fine. If WIFI is not available it will just move on and will expect new data from the user.
When the wifi becomes available, i have registered a broadcast receiver which will hit my database and get the values stored and send them to the remote server.
I would like to know, while the broadcast receiver is trying to query my database, if the user is entering data at the same time and it is being saved in the same database, will it fire a SQLException.
As i recall, only one service can access the SQL instance at a time. If it will pose a problem what shall i do to overcome it. I have looked at ContentProviders, would that be the solution?
I am fairly new to android. Please advice.
You may want to take a look at this.
What are the best practices for SQLite on Android?
For me, I would suggest to always create a ContentProvider together with DatabaseHelper when you need Database, no matter you need to provide your data to external application or not. It is actually not difficult to do, the best reference I used to build my ContentProvider is DeskClock, the official app from Android.
Edit:
As a side note, you should consider to create a IntentService to be called by your boardcast receiver to do the work, as broadcast receiver should not be used for long running task, like sending things to server.
BroadcastReceiver#onReceive
When it runs on the main thread you should never perform long-running
operations in it (there is a timeout of 10 seconds that the system
allows before considering the receiver to be blocked and a candidate
to be killed).
I'm developing an Android app that talks to a Play-framework app, the two apps are passing user data between one another using Volley requests, my question is this:
Is it desirable to have the Android app sync with the Play server constantly to check for changes to the user profile? (like syncing during a fragment change)
Or is it better practice to have the user on the Android app logout and back in before that changes occur.
Or is there some alternative solution that only syncs with the server if a change occurs?
I think the last option would be the most efficient and desirable, but I fail to see how could do the check without sending a request first to the server and if I'm sending a request to check for changes anyway, wouldn't it make sense to have the changes in the response.
You should not sync whenever a fragment changes. It is a waste of the user's battery and data. You also most likely don't want to force a logout/login all that often as it becomes inconvenient for the user.
If you are expecting very infrequent changes to the user profile, it might be better to send a push request from the server using GCM to inform the app that it should invalidate its local cache. Then query the server for new profile information.
If using push is unfeasible for some reason, you might want to look into using a SyncAdapter and syncing infrequently. In most cases, it should be okay if profile information is potentially behind unless the user is specifically checking the profile settings, in which case you might want to check the validity of your cache when they check their settings.
I am trying to develop a mechanism for Sync data with app & server, like Google Drive/Dropbox for one of my android based application where data are stored locally on device and I would like to sync data with server.
Ways thought -
1) Observer which looks for change and call web service
2) Background service which runs in background and check for changes
3) Set Alarm which checks at particular time and sync all the data with server
I have not started to which option to go with, I would like to get experts view on this and like to get some guidance so that I can achieve the sync mechanism in best possible way for my app.
All suggestion are welcome.
Thinking on same line as you have been,the aim should be to achieve a balance between the number of times the server is queried for same set of information AND the data consistency.
for this, I would fire a GCM message from my server to the device for which the data on the server has changed, I would maintain a count for these Update Messages(No Notification genereated). If this count Exceeds the minimum-threshold-count-value, I would immediately call for an UPDATE. Or otherwise, if this count still is less than the threshold-count-value, for a certain period, that I would call the threshold-waiting-period, then too I call for an UPDATE.
The UPDATE would be using Sync Adapters and Services. This link explains its basics.
Hope this prooves to be helpful!
...so that I can achieve the sync mechanism in best possible way for my app
Well, the BEST mechanism depends completely on what kind of application, you are developing. Also, your option 1 and 2 seems very similar to me except few implementation changes. However, how frequently your device data is changing, that also matters a lot. If you have authentication mechanism, you can configure sync up, at the time, whenever you login to your app. Like in case of confidential data, sync up should happen immediately.
If data is managed well based on authentication and authorization based on user roles or so, you also need to take care of synchronization among them. For example, one user has updated an entity which is not yet sync and another user tries to update the same, then first user will see his changes are not synced or has been lost.
The best way (means having least drawbacks) to do this would be sync up trigger at a particular interval of time OR at every login time. (still as I said, depends on your app).
Hope this would clear some or all of your doubts.
I'm developing a Java web application. The scenario is described below:
Many users submit their status and they can see others' statuses as well. It looks like a kind of social network.
Their statuses have a period of time to display, after this period, their statuses in database will be deleted.
At the time their statuses are deleted, send a notification to all users to request an update (the deleted statuses have to be vanished in realtime!)
I've tried to do that automatically by a thread in the Java web application. However, I'm stuck at some problems:
+Is it possible to manage database like that? I've thought of database event, but when a record is deleted, I will not be noticed.
+I'm using web socket to make the application work in realtime. If a person update a new status or change it, it's possible to send an update notification to all of the users by using web socket. But when the changes come from database, I don't know how to send a notification like that.
Can you give me some ideas? Thank you in advanced!
You can use DelayQueue to store each item to be removed at a specified delay,and when you are removing the item,remove the record in database and send a notify to browser.
Here is the tutorial how to use a timer service in a Java EE 6 application:
http://docs.oracle.com/javaee/6/tutorial/doc/bnboy.html
If you need the statuses to be deleted even if your program crashes, then I recommend that you use quartz - this way if your program crashes then quartz will update the database when you re-load your program. If your program doesn't need to be this robust then use a DelayQueue instead.