I've been reading that we dont need to use AsyncTask when working with volley. I had a question though, one of the button click in my activity triggers a HTTP request. Now in case my app is closed, will volley still be able to process that request.
When I launch my app again, is it possible to figure if my previous HTTP request was sent or not.
What would happen to the response? Will I be able to catch the response and maybe make some db updates (local to app)?
What is the right design to do these kind of http requests?
Also, in case I want to make some HTTP requests while the app is not launched, can I not use a background task to do all this with volley?
You don't need to use an AsyncTask or Thread for Volley because Volley does that for you. So that's correct.
When you say your app is closed- do you mean the app is in the background, or the app is terminated? In the first case, the request will continue. In the second, it will not, and any response coming in would be ignored at the OS layer because there's no listening app on the socket. Also remember that apps not in the foreground can be killed by the OS at any time.
You can't send an HTTP request when your app isn't launched. You can do so in a JobScheduler or WorkManager item, but then your app is launched, you just aren't showing a UI.
Related
I hope I can explain this well ...
I am trying to understand better how to handle HTTP callbacks in Android, so I have created a simple app that uses Volley for HTTP requests. It only has a button that triggers an HTTP request to a service that, basically, just updates a number in a database and sends it in the JSON response after 5 seconds. The Activity gets the response and displays the response in a TextView. I am testing it in a real device that has enabled the "Don't keep activities" option in Settings - Developer Options.
This is the scenario I am testing:
Start App.
Tap the button that triggers the HTTP request.
Inmediately after tapping the button, tap the device's home button to send the app to background. onDestroy method is called because of the "Don't keep activities" option.
Wait a few seconds for the HTTP response. I can see the device gets it because it is printed in the logcat monitor and the database is updated.
Before running the callback, I check that the activity is still alive. Since the activity has been destroyed, the callback is ignored. If the app is restored from background, there is no crash but the Network Response is missed. Also, if I tap the button again, it sends a new HTTP request and increases the number again ...
So, the questions are:
Which are the best practices to deliver network responses to the UI? I mean, if instead of a simple operation let's say it was a register form and I get a phone call or something that forces me to send the app to background, where anything can happens, how can I make sure to not miss the network callback? Is there something that could delay the callback execution until the app is again in foreground?
Is there a way to save a Bundle like the one in onSaveInstanceState after onDestroy has been called and restore it when app is again in foreground?
Let's say the information that the HTTP response contains is sensitive. Is there a recommended way to handle this case? I was thinking to save the response in the internal storage and check for it when the app is again in foreground, but I don't know if it is possible to do that after onDestroy has been called, or if it not a good idea with sensitive data.
Thanks in advance!
1)YOu can never miss the network callback. You'll be called even if you're in the background, unless your entire app (not just the activity is killed). You'll just get the callback while backgrounded.
2)No. If you need the result of a network call the next time the activity starts like that, I suggest you use a Loader to load the data. That way you can query for the Loader results next time, and start the request only if needed.
3)Do what I suggested in 2 and there's no need for this question, its all in app memory.
I want to create a Android background service, which creates a notification, if a server has restarted, but I need some ideas how to implement it.
I thought about a http connection, where the background service waits until a message comes in, but I think the connection can not be keep up while a restart. After this there came up a new idea, where the background service pushes a notification, when the connection breaks.
Would this be possible (if yes, what would be the easiest way) or is there a better way to solve this?
Create an asynchronous task that tries to connect to the server in an endless loop. Use an time limit to cancel the process after a given time or return an ok value if the server responds an 200.
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.
I'm about to write an application that sends data to a server with a post request. These requests can fail and if they do I want them to be sent when the connection is back online.
What is the best way to implement this behavior?
EDIT
I've read some articles and come up with the following idea. I register a BroadcastReceiver in the manifest and tell it to listen for android.net.conn.CONNECTIVITY_CHANGE and android.net.wifi.WIFI_STATE_CHANGED. When the request can't be send I store the request. If the connection becomes alive then I will send the cached requests.
What is the best way to implement this behavior?
Make Volley requests from a bound Service, and send the result back to the Activity if it is still in the foreground.
EDIT:
won't this be a problem if the user decides to close the application?
That's exactly why you need to use a Service. If you do it from an Activity, the request continues even when the Activity is dismissed. If your Volley request is expressed as an anonymous class instance, it continues to hold an implicit reference to the outer Activity class, which leads to a memory leak / exception.
Check your Internet Connection continuously by using Handler or service ,if it is sends the data to the server otherwise dont send it.
I need to make a http request in my main activity and if the request completes while the user is reading the basic info in this activity, I must store the returned info in a variable. However, if the user clicks in a button in this activity, another activity will be opened. This new activity will continue waiting the same request started from main activity, and display the data when it finishes.
I've read about IntentService, however it can't be aborted (am I right?) and the user can ask for new data before the request is completed.
What alternatives do I have?
PS: The request will only work while the app is running.
PS2: I'm using Volley for http requests.
Sounds like you might want to use a Service instead of an IntnetService, since volley will kick off on a separate thread. You can then handle the management of the volley task in that service.