How long to keep the UI state of an app, when app is in background? (Android)

Question

I'm designing an Android app that lets people observe medical data. Besides seeing live data, users can scroll back to inspect earlier data.

I'm trying to decide if, when a user scrolls back to see older data, then puts the app to the background, and again to the foreground, the app should keep the scrolled-back state or show the latest data.

There are two conflicting goals: One, the UI should keep the state the user left it in, so that they can resume their tasks even after, say, taking a phone call. Two, the most recent data (live data) is quickly visible upon reopening the app.

I see 3 options:

1. Whenever the app regains focus, scroll to the latest (live) data. Disadvantage: When a user looks at past data, takes a call and comes back to the app, the UI state has changed and he has to navigate to the previous state again.

2. Always keep the scrolled state, even after days of not opening the app. Disadvantage: The scrolled state is probably not interesting to the user after a while.

3. Define a time limit after which the app will forget the scrolled state and, when it regains focus, shows the latest data. A reasonable time limit would be 30 or 60 minutes I think.

4. Let the Android app lifecycle handle it. Basically, when Android decides to kill the app process, forget about scroll state. My problem here is that I don't know how fast this usually happens, and it might vary depending on the phone performance.

Comparable problems I considered:

• In messaging apps like WhatsApp, when in a conversation, putting the app in the background and again to the foreground, the conversation is still open (not the overview over all conversation).

• In Google Calendar, when scrolling back to an earlier date, putting the app to the background and again to the foreground, the calendar is still scrolled back.

In both cases the app maker decided to keep the state, but I don't know for how long.

What's the best option? Do you know more about how Android's app lifecycle plays into this?

Answer 1

The best (in terms of Android Development) and most common practice is to let the Android Application Lifecycle handle this. The way it should work is by keeping the state alive so long as the app remains "alive", in other words, while the app has not been killed by the OS or terminated by the user. The app may be killed for a number of reasons like memory concerns or the app's incorrect usage of resources.

By default when the app

• loses focus, as it does when it leaves the foreground or is interrupted, it will be paused and not killed. The app may be interrupted, for example, when the user presses the home button and comes back after a short while to the app in question or when the app is interrupted by some system event (like a call, an alarm, a notification, etc).
• regains focus the UI should be returned exactly to the point where the user had been interrupted, should you be saving your instance correctly.

The difference between regaining focus and restarting the app is exactly the difference you should keep in mind when implementing your solution for keeping state. If the user willingly exits the app by pressing the back button or goes into the "currently running apps" and closes the app the state should not be kept. If however the user presses the home button, is interrupted or may otherwise act in a way indicative of a desire to return to the app, then the state should be kept.

Another interesting case is that of a notification, in which best practices mention you should open the app to the point of interest which the notification is about. In this case, using the back button should only take you back to the screen hierarchically above or the main screen if no others exist. Thus again, when entering the app by notification the state should not be kept. In the case in which the app is already open and a notification is used, I have seen some implementations bring you back to the initial state afterward, however that is a bit contradictory as the intention of a notification is to take you to a new state which should mean the user would be done with their actions and have no problem exiting the current state. Just a thought to keep in mind.

I'd recommend you to take a look at common lifecycle usage patterns in the Android lifecycle and processes in Android

I hope this was helpful, Panos.

Answer 2

"In both cases the app maker decided to keep the state, but I don't know for how long."

If they are doing it right, and they are doing it well, then that state will be preserved until the next time the User foregrounds the app. If the User uses an alternate in-road into the app, however, such as clicking on a Notification, then that is an appropriate time to "forget" the previous state.

Your use-case is simple and the best-practice guidelines cover it. That said, you should spend more time reading about Android guidelines because this question indicates a lack of knowledge.

Here's a more advanced use-case that can give rise to diverging from guidelines: if your app facilitates, say, a Doctor-Patient session wherein a Doctor is seeing and treating a patient and the app is providing functionality pertinent to a session but not longer than a session (e.g. perhaps the app is monitoring the session?). A similar case could be with a Seller-Customer session, in say a Point of Sale app. Or even a sporting app where the backstack holds screens pertinent to the currently playing game, screens that should not be displayed once the game has ended. Those aren't typical scenarios in the average app yet could be make-or-break to a niche app. You may wish to implement the notion of sessions with timeouts and/or similar functionality to cater to such scenarios.