MVP: Continue async http request or cancel?

Question

In my phone when minimize aplicatoin then the Android destroy activity. In Developer options I turn "Don't keep activities".

I try to implement MVP.

I have a activity with button.

Steps:

1. User click button
2. As result activity call method from Presenter: presenter.dowanloadFile(). This is a async http request. The size of file is about 10 MB.
3. Show progress
4. After 10 seconds user get success http response
5. Presenter call method from view: view.hideProgress

OK. This case work fine. Nice.

But suppose the next case:

1. User click button
2. As result activity call method from Presenter: presenter.dowanloadFile(). This is a async http request.
3. Show progress
4. After 2 seconds user minimize application
5. As result activity is destroy (because turn Don't keep activities)
6. After 3 second user return to application
7. As result create new activity
8. After 5 seconds user get success http response
9. Presenter call method from view: view.hideProgress

The question is:

Is I need to continue http request when user minimize application (item 4). Or I must cancel current http request. And when user again return to application I must again start new async http request?

I want the next: When user return to application and if http request success finish then to show result. If the request is not finish then continue to wait http response.

Answer 1

It depends on what you want to happen? It seems like it's wasteful to cancel a request that is expensive (10 seconds is a lot), however you also need to consider what "cancel" mean in the context of an HTTP request.

For example, if cancelling a request, only prevents results from being delivered. Than means that your file was actually uploaded but you don't get callbacks anymore for that request result. Also be careful if your upload thread has a reference to your view, it will be leaked till the upload is done.

If you don't really care about the request, you can just cancel it. Assuming your server is smart enough to identify another request for the same file, so you don't duplicate it if your activity was re-created.

Another option would be not cancelling the request. Then you would need some mechanism of having your "presenter" survive the Activity re-creation.

There are numerous ways of doing that:

• Having a cache for your presenters and not re-creating it if it exists in the cache.
• Using headless fragments, which are basically are fragments with setRetainInstance(true) to survive an activity re-creation.
• Moving your upload logic to a background Service or JobScheduler, and having your presenter/view only subscribe to the state of the upload process, but not actually own it.

You can investigate each option individually when you decide what is the most convenient for your application.