Suppose that we have an application with one button - send a request to add a message to the chat. By clicking on it, a loader appears on the screen and a request is sent to the server.

While the request is being executed, an event may occur:

  1. Screen orientation change
  2. Application collapsed -> request (not) executed -> application expanded
  3. The application was minimized -> the request was not executed -> the application was killed by the OS
  4. The application is minimized -> the request was executed -> the application was killed by the OS

With the first two items, everything is clear - we save the state in onSaveInstanceState and restore it in onRestoreInstanceState. The request to the server itself lives in the interactor, and is therefore not destroyed when activating is destroyed, so after the coup, we will find out if the request is still being executed. If yes - then we subscribe to the answer, if it has already been completed - we get the result.

The third item also fits the logic normally - after recovery, we find that there is no request in the interactor at all and again we are creating a new request to the server.

But what to do with the fourth point is not clear to me. It is necessary to save both the state that the request has been completed and the result of this request. However, onSaveInstanceState has already been completed, and we can no longer add data to the bundle, it seems like. At the same time, to fence a bunch of models for each query + state and, all the more so, to store it all in a database - it seems to be some kind of overhead.

Maybe someone can tell me how to handle such a situation correctly? Or maybe I have built the wrong architecture and need to think in a different direction?

  • If the interactor does not cache \ save the results, then the same as in case 3: "after recovery, we find that there is no request in the integrator at all and again create a new request to the server" - Eugene Krivenja
  • @EugeneKrivenja Now that's exactly what's done. But in this case, the chat will get two identical messages, which should be avoided. How to implement results caching in interactor? (And you need to cache not only the answer, but also the state. And the belonging of this particular request to the presenter / activation) - Linq
  • Sorry, I somehow badly read initially that the question about sending ... - Eugene Krivenja

1 answer 1

You need somewhere globally to store something simple such as timeStamp, which will update the interactor upon successful completion.

Accordingly, in onRestoreInstanceState, read the timeStamp of the beginning of the request and compare it with the global timeStamp. Draw conclusions.

The simplest thing that came to mind.