0

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?

2

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.

  • StackExchange brings the user back to previous state if you pause it, open via notification and then press back. While it might be as much a quirk of the implementation as done on purpose, it's a good behaviour in this case. If I research my reply, open a Google link to SE and then go back to the app I'm back to my reply. – Jan Dorniak Oct 7 at 20:37
  • "If the user willingly exits the app by pressing the back button" – I would assume that the back button is more associated with leaving an app, not closing or "killing" it, and so I would give it the same behaviour as when pressing the home button: keep the UI state. – bootsmaat Oct 8 at 6:50
  • @bootsmaat I guess it would really depend on your implementation and the state. After all, these are just recommended practices. "Leaving an app" should be synonymous to "exiting" it, not "pausing/stopping" as the home button does, but should you feel that's better suited to your implementation I think you just found the answers you were after! – Panos Gr Oct 8 at 11:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.