Application shutdown event

Context

A client-server application where the server is the provider of a large graph of related data. Portions of the graph are downloaded upon request by the client, displayed to the user, and stored locally in the database to avoid re-request.

Different types of nodes in the chart are requested (and displayed) by different actions. At any time, many tasks can be present in a task, each of which displays its own nodes.

Sometimes the schedule changes and the server presents a completely new schedule to the application.

To find out what happened, the client keeps (say, in shared privileges) a revision of the schedule that he is familiar with. When new data is requested, it informs the server of this revision. The server compares the revision it requested with its current revision, and if it differs, it responds with a "schedule revision mismatch" rather than the data.

When the client receives such a response, it informs the user that the graph has been refreshed and (re) starts its root activity with FLAG_ACTIVITY_CLEAR_TASK, effectively "restarting" the application.

Problem

We want to minimize the number of times we are forced to restart the application this way. To this end, the server will send a GCM message to the client informing him that the schedule has changed.

The problem is this: when a client receives a message like this, how do we know when it is "safe" to update a locally saved version?

If there are actions in progress or "saved" (in the sense of saveInstanceState), then we consider it "unsafe" to update the local revision, as this will cause inconsistency between the state of these actions (either in memory or saved) and the data they receive from the server in new edition.

Decision

Our current solution is to update the locally stored version in Application.onCreate (), but this solution doesn't work if we add long-term services to it.

Another approach we are considering is to use Application.registerActivityLifecycleCallbacks and trigger an update when the number of unused activities becomes 0. This approach has two problems:

• It does not solve the problem of "saved" (in the sense of onSaveInstanceState), since their saved state may contain links to the graph - for example, they were asked to display the node identifier in their intent. Because of this, when they are restarted, they may crash or display incorrect data. However, we can at least detect this state by storing the revision in onSaveInstanceState and comparing it to the current version when such an activity is recreated.
• Big problem . I'm not sure when, if at all, Android will destroy all activity in the application. Perhaps some versions of Android will never do this if they have enough memory. In any case, I don't think there is a promise that this will ever happen, especially if the application has long lasting services.