A feature suggestion: Open the app where I left
Closed, ResolvedPublicBUG REPORT
Actions

Assigned To

Authored By

	ARamadan-WMF
	Nov 21 2022, 9:32 AM

Description

We received this suggestion through our support email:

Hello,
I have a question about Wikipedia application on my ipad (ios).
When i read an article and close the application, for a short time, it retains the spot that i left when opening it again, which i like.
But after some (relatively long..) time, without opening the application, it starts in the opening page.
I wonder, if there is a way to configure it, so that it will always open where i left, no matter how much time passed.

Related Objects

Mentioned In: T337073: Improve navigation stack restoration load times
Mentioned Here: T219658: add ability to close app and reopen to same place

Event Timeline

ARamadan-WMF created this task.Nov 21 2022, 9:32 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 21 2022, 9:32 AM

Reedy renamed this task from A feature suggestion: Open the app. where I left to A feature suggestion: Open the app where I left.Nov 21 2022, 9:42 AM

LGoto triaged this task as Low priority.Nov 21 2022, 7:38 PM

LGoto moved this task from Needs Triage to Bug Backlog on the Wikipedia-iOS-App-Backlog board.

LGoto added a project: ios-app-v7.0.1.

Our first objective on the engineering side before any potential logic change is made is to audit the existing work to confirm how it currently works and the potential flexibility we have.

• JMinor moved this task from Tasks from Product Backlog to Ready for Development on the ios-app-v7.0.1 board.Nov 22 2022, 9:06 PM

LGoto edited projects, added ios-app-v7.1; removed ios-app-v7.0.1.Dec 8 2022, 7:39 PM

• Dmantena claimed this task.Dec 13 2022, 10:13 PM

• Dmantena moved this task from Tasks from Product Backlog to Doing on the ios-app-v7.1 board.

Here's my current understanding of how the app's navigation/article state restoration works[1][2]:

Regardless of where the user has navigated to in the app (an article, settings, saved articles etc.), backgrounding the app then foregrounding to return to it some time later will return the user to where they left off provided that iOS hasn't booted the app from memory.
If iOS has booted the app from memory or the user has intentionally force quit the app, our navigation state restoration logic kicks in.
This logic attempts to restore the user's navigation state only if the time of their last in app activity is before 5am the next day. For example, if the user...

Last backgrounded the app on Dec 1st at 1pm then opened the app before Dec 2nd at 5am, restore their app's navigation/article state as much as possible
Last backgrounded the app on Dec 1st at 1pm then opened the app AFTER Dec 2nd at 5am, present the app in a "fresh" state (likely presenting the Explore feed, but respecting their Explore feed on/off settings)

This means that if a user navigates somewhere in the app then backgrounds it, the possible interval of time before we return them to a "fresh" state (e.g. Explore feed) in the app can be between 5-29 hours depending on when they last opened the app.

Caveats:

The Open app on Search tab settings preference overrides/supersedes any navigation restoration.
Modal views (like article text preferences) and settings subpage states are not restored.

Here are some settings we have flexibility over that would be straightforward settings to surface to users:

Always restore navigation/article state regardless of time app has been in background
Disable this restoration behavior entirely
Allow the user to specify the time interval (e.g. 1 hour, 60 days, etc.) before we return the app to a "fresh" state.

[1] Previous Phab ticket: https://phabricator.wikimedia.org/T219658
[2] Github PR: https://github.com/wikimedia/wikipedia-ios/pull/3049

This task is currently blocked by product/design decisions on if/how we should support a user changing their state restoration settings. cc: @JMinor @cmadeo

Per our tea time discussion:

Let's aim to retain state as long as possible (eg. return user to their last opened article and depth whenever possible)
For Open app on Search tab setting, respect this setting and always open to the search tab with the focus on the search bar (do not retain state)
Deep links / quick actions / widget clicks will override state retention

In T323473#8521358, @cmadeo wrote:

Per our tea time discussion:

Let's aim to retain state as long as possible (eg. return user to their last opened article and depth whenever possible)

For Open app on Search tab setting, respect this setting and always open to the search tab with the focus on the search bar (do not retain state)

Deep links / quick actions / widget clicks will override state retention

👍🏼 thanks @cmadeo!

• Dmantena claimed this task.Jan 13 2023, 6:22 PM

• Dmantena moved this task from Blocked or Waiting to Ready for Development on the ios-app-v7.1 board.

LGoto edited projects, added iOS Release FY2023-24 (Archive); removed ios-app-v7.1.Jan 26 2023, 10:03 PM

LGoto moved this task from Tasks from Product Backlog to Ready for Development on the iOS Release FY2023-24 (Archive) board.

• Dmantena moved this task from Ready for Development to Doing on the iOS Release FY2023-24 (Archive) board.Feb 6 2023, 8:03 PM

Tsevener moved this task from Doing to Needs Code Review on the iOS Release FY2023-24 (Archive) board.Feb 9 2023, 8:41 PM

Aklapper changed the subtype of this task from "Task" to "Bug Report".Feb 17 2023, 8:27 AM

Tsevener moved this task from Needs Code Review to Waiting for Build on the iOS Release FY2023-24 (Archive) board.Feb 23 2023, 10:20 PM

Tsevener moved this task from Waiting for Build to Needs QA on the iOS Release FY2023-24 (Archive) board.Feb 24 2023, 2:07 PM