I've been wondering if there is any way with Volley to queue and then execute a request until the mobile data connection is available.
I have to create an Android app that have to work in areas with no mobile service, so I have to queue and postpone any POST request that my app perform using Volley, until the internet mobile service is available.
The app have a registration form that have to be filled, and when I press send, if there is mobile service the form is sent, but if not, the form information have to be store and the POST request have to be queue in order to be performed later when the phone count with service connection.
Is there any way to do this with Volley? Or with any other Android HTTP Connection library.
Thanks
I saved my information to a database on the device with a "transmitted" flag. This way, even if the user completely closes the app, the information is always saved.
I then created a service (https://developer.android.com/training/run-background-service/create-service.html) that checks every 15 minutes for records that have not been transmitted. If they are found, it tries to transmit again.
The transmit is also executed as soon as a user enters and saves the information. Successful transmissions update the "transmitted" flag on the record.
Related
I have an Android application that has a screen for displaying information about any user of the service for which mobile application was developed. Users are able to subscribe to other users on that screen.
Current solution with Rx and Retrofit works fine but when user leave the screen I clear disposables and then the http call under the hood of Retrofit is being canceled. So if user leaves the screen his operation on it (such as subscribing or likinng/disliking) get lost.
I want to keep that requests which modify some data (usually POST-request) and send them until backend of my application will receive it and send a response. Moreover I want to persist that request on disk to survive the app's process death. It means that if user leaves screen and system kills my app then after it launched again it will perform an attempt to send saved requests. Of course if there is an internet connection.
I wonder if out-of-box solution for that purposes exists. I appreciate any advice.
Workmanager can be used to schedule this kind of request.
I am currently storing my transactions in SqLite DB if there is no internet connection at the moment and when there is internet available i send the pending transactions with the new one made so making it quite a lot of data and a lot of API hits which chokes the device and it becomes unresponsive. So need help with a proper way to sync these transactions to the server. Also these are being sended to a Socket as well as a Server.
I tried using AsyncTask for it but it also causes problems if transactions are above 200. Tried Retrofit for it and to some extent the count exceeded from 200 to almost 350 but the issue and unresponsivness remains.
You should give a try to PriorityJobScheduler lib or WorkManager from JetPack.
When there is no network connection you can queue those request and those request will be send ones network connection is available. (So you dont need to wait until someone made new transaction to send old queued data too)
Also, in your current scenario, rather than sending single request for each transaction, ask your API Guy to accept request in List of object format. So you just need to create list of request body object and send to server
I am relatively new to developing Android apps. I have an android app that downloads several resources from the internet and keeps on generating these requests. I want to create a queue of such download requests when there is no internet connectivity and get them started as and when the connection is restored. In this case, the connectivity may be in either form both Mobile data as well as over Wifi
There are several parts to this: first, detecting whether you're online now, if you're not online detecting when you'll come online, and having the actual queue.
The queue itself can use a SQLite database. You just need to store enough information to reconstruct what the request should be when you resume.
You can see the documentation on monitoring the connection state here.
Basically, if you're targeting API less than 24, you register a broadcast receiver to receive the CONNECTIVITY_ACTIVITY broadcast. (Otherwise, you can "listen" for CONNECTIVITY_CHANGE). Your logic once you figure out what request you want to queue will probably be something like the following:
Push request onto the queue
Check to see if you have connectivity
If so: start processing the queue.
Otherwise: wait for a broadcast receiver to notify you that you have connectivity again and start your service that does the processing.
Sorry to be a little vague (I'm not sitting in front of an IDE right now) but hopefully that outline'll be at least semi-useful.
There's a number of popular "job queue" libraries that allow you to specify dependency on network being available (along with various retry policies). For example:
https://github.com/yigit/android-priority-jobqueue
https://github.com/evernote/android-job
Create a local database which should have HTTP request details, time stamp and its status. Whenever your application initiate HTTP request store it in database with HTTP request details and time stamp of its initiation and its status to non completed.
When your HTTP request is complete change its status to complete so when your Http request generates some kind of exception or error you don't have to do anything.
Now your application should have a connectivity broadcast listener so when your application connects with internet read your database and initiate your HTTP requests.
My intention is to stop receiving data from the server after the user has moved away from the activity which has made the service request. The motivation is to reduce the unnecessary bandwidth consumption as the user has navigated away from the activity and hence, the data is no longer required.
As far as I know, in Volley, it is only possible to cancel a request if it's in the request queue and not if it has already been sent.
So, is there any way to refuse the data being sent to the phone from the server or else, change the priority of the data acceptance to a lower level?
You can cancel the Volley Request which means you will not receive the response. When you are initiating Volley Request the request tag and cancel it via tag.
Hope this helps.
My android app has a ContentProvider and stores data (strings) in a SQLite table
These rows need to eb sent up to an internet server
I want this data to be uploaded in the background when the remote host is available (WiFi on for instance)
The data should be sent asap (when network available of course)
without interfering with my app's ui
It should send even when my app does not have the main focus (user may be sms-ing or using the camera)
New data could be added to the table (out queue) every 5 seconds
Q: Should I use a background service to send the unsent rows?
It seems too frequent to use the "Alarm Service", but I could be wrong
Battery life is my main concern, but secondly is that it needs to send as soon as possible (or shortly after internet available)
Android Studio
targeting API 17+
A background service would be best to handle the request and save battery life. You could either check the connection state and send yourself and just let the service handle when there is no connection, OR better yet just use the service to always send the data and let it decide when to send it.
As for the service, see this question: How to be notified on wifi network status change?
The idea would be to use the code in that answer to implement a broadcast receiver in your service to detect when there is an available connection. When that connection is available then you could send the data.