Remember previous position in timeline when reopening app

[caoilte]

I suspect there are a couple of ways to trigger this bug. Here's how i just did it.

• I was looking at a thread on someone's timeline
• I closed the app
• I reopened the app a few hours later and I was still on their thread (yay! rehydrate remembered where i was)
• I navigated back to the homepage
• Pachli jumped me ahead to the latest toot instead of restoring me to where I was before I clicked into someones thread.
• I had to scroll back six hours and figure out where i left off reading the timeline.

This is an inherited Tusky issue (hilariously official mastodon client also has it) that the auto-timeline loading in pachlii has sadly made worse. In Tusky it wouldn't have automatically have loaded the missing toots, so it wouldn't have automatically jumped me ahead of them all (although it would have jumped me to the head of whichever toots i'd had loaded so it would have been effectively as bad).

The fix is to remember the point up to which you've read your timeline and restore to that point when returning to the homepage from some other part of the app.

[nikclayton]

Thanks for the report. This is mostly fixed with

• fix: Restore the user's home timeline position #44
• fix: Restore the user's reading position in more circumstances #49

which will be in the 1.1 release. They appear to work correctly in almost all scenarios that involve returning to the app that I've tested (warm start, cold start after installing a new version of the app, cold start after opening the "Recents" list and swiping the app away).

There's one issue that they don't seem to resolve -- leaving the phone overnight, then unlocking the phone and opening the app. The logs show that the reading position is being restored, but the reading position jumps to the top. I'm testing another fix for that now, but since I can't trigger the problem on demand it's difficult to know for sure that it's resolved the issue.

[caoilte]

Nice!
Haven't looked at the code, but would it help if the code was refactored to make it impossible to load the home screen from the top (ie the only way to load it was via read position).

Feel free to close if this is a dupe. Looking forward to 1.1. already happily switched from tusky.

[nikclayton]

That's pretty much what it should be doing at the moment. The only time there isn't a saved read position is if you're running the app for the very first time.

If I consider the following two scenarios (with the code on develop right now):

1. Open the app, scroll to a position on the home timeline, leave the app by going back to the launcher, do a bunch of other things on the device so Android closes Pachli, and
2. Open the app, scroll to a position on the home timeline, open the "recents" list of apps, and swipe Pachli away so it's forceably closed

and then re-open Pachli, the behaviour should be identical -- you should be returned to the home timeline, and the reading position should be restored to the first status that was completely visible at the top of the screen when you left the app.

That works for scenario 2, consistently. It does not work for scenario 1, and I don't currently understand why. The logs in both cases are identical, showing:

• The ID of the status is correctly saved and retrieved
• The network requests to the Mastodon server are correct (i.e., they contain the correct status IDs)
• Data is fetched and added to the list in the same order
• Debug logs show the reading position being restored (by scrolling the list) appear, and the ID of the status to scroll to is correct

I can't reproduce scenario 1 in an emulator either.

This is something the Android libraries are supposed to handle automatically, https://developer.android.com/reference/kotlin/androidx/paging/PagingDataAdapter notes:

State Restoration: To be able to restore RecyclerView state (e.g. scroll position) after a configuration change / application recreate, PagingDataAdapter calls RecyclerView.Adapter.setStateRestorationPolicy with RecyclerView.Adapter.StateRestorationPolicy.PREVENT upon initialization and waits for the first page to load before allowing state restoration.

but there are also open issues like https://issuetracker.google.com/issues/214253526, so this may be a library issue.

I'm going to leave this open to track the issue at the moment, and get 1.1 out the door, which does fix a number of other important issues. There's quite a lot of refactoring work to be done as well, and that might make the underlying issue more obvious.

[tinsukE]

Was also affected by this issue on version 1.1. Note how from the app info, it seems to be running (not a cold start), as the "Force stop" button is enabled:

scroll.position.mov

The scenarios you described above seem to be (1) hot start and (2) completely cold start. I think this is a case of (1.5) not so hot or cold start, when the app hasn't been closed, but has been suspended from memory, which caused its instance state to be saved and, when the user returns to the app, restored.

One could test this by either of:

A. On Developer options, enable "Don't keep activities". If you leave the app and return to it, the components' states will get saved and restored. On this case, the process is kept running and things like singletons would still be the same, kept in memory.

B. On Developer options, set the "Background process limit" to "No background processes". If you leave the app and return to it, the whole process will get suspended, but the components' states will still have gotten saved and restored. On this case, all will be instantiated again, but with a state to restore.

C. Send the app to the background, run adb shell am kill app.pachli, then return to the app.

Method C above should, as far as I understand, behave just as B. But I actually have been able to consistently reproduce the issue by using C (while not with A or B):

signal-2023-09-19-202038.mp4

[foss-]

Seeing timeline jumps in 1.1 on each timeline refresh. Went through the settings a few times without finding the Remember reading position option. Should it be there? If so, where? If not, is remembering reading position the default in Pachli?

[caoilte]

I think it's just broken. I've switched back to tusky for the moment. Hoping the fix doesn't require a rearchitecture

[nikclayton]

@tinsukE -- thanks, that's very helpful. I'm also wondering whether the (inherited) android:configChanges settings in the manifest is causing problems, and is blocking the list / layout manager from restoring the state correctly. Lots to experiment with over the next few days.

@foss- -- there's no setting, it's supposed to just work. That it isn't is a bug that I'm focused on for the 1.2 release.

@caoilte -- that's reasonable. The tradeoff is that Tusky will have gaps in the timeline. I'll ping you here when the bug is fixed in Pachli.

[nikclayton]

@tinsukE In your second video (signal-2023-09-19-202038.mp4) the different steps appear to be:

1. Open on home timeline
2. Swipe refresh to confirm you're at the top of the timeline
3. Scroll down a few screens
4. Open launcher
5. DO SOMETHING HERE
6. Open recents, select Pachli
7. Pachli re-opens, and briefly displays splash screen
8. Reading position is lost, user is at the most recent post

What are you doing at step 5?

I've tried to recreate that, and I can't.

At step 5 I'm running adb shell am kill app.pachli. This works -- I can see the "PROCESS ENDED" message in the logs when it completes, and at step 7 I also see the splashscreen when returning to Pachli (which does not happen if I do the same process and skip step 5).

But when I do this the app correctly restores the previous reading position. I see that on both an emulator and a real Pixel 4a.

[tinsukE]

@nikclayton indeed, step 5 is running adb shell am kill app.pachli.

And it is still easily reproducible for me:

signal-2023-09-22-192913.mp4

Device info:

• OnePlus 6
• Android 13
• LineageOS 20-20230912

[nikclayton]

@tinsukE Thanks.

Is there any chance you can trigger it in an emulator, and if you can, send the definition file you use for the emulator?

Because this is what I see if I do the same thing. In the following video I'm running the release version of Pachli 1.1 in an emulated Pixel 4a with the API 30 Android level. As you can see, when returning to the app from the "Recents" screen, after running the adb command (and observing the "PROCESS ENDED" message in the logs) the reading position isn't lost.

As you can imagine, not being able to reproduce this locally makes working out if I have a fix very difficult.

Pachli-1.1-Refresh-From-Warm-Start.mp4

[tinsukE]

@nikclayton I completely understand.

I think the earliest I can give this a try would be Sunday or Monday. But I'll check it out.

[nikclayton]

Thanks, I appreciate that. For completeness I just tried in emulators running API 33 (which corresponds to Android 13) and API 34 (Android 14) and see the same thing as in my video -- the app resumes at the right reading position.

Just to confirm -- your videos were only running the adb kill command, yes? You hadn't made the "Don't keep activities" or "Background process limit" settings changes you mentioned in a prior post?

The only way I can reproduce the problem at the moment is to leave my physical device alone for a long enough period, typically overnight. I'm running a custom build on that at the moment with some small changes to see if they have any effect, but I won't know until tomorrow morning...

[tinsukE]

Correct, no other change/setting than the adb command while the app is in background.

[tinsukE]

Got some limited time this morning and I tried to reproduce the issue on a freshly created emulator, API 33, with the 1.1 APK downloaded from releases.

Couldn't so far, but this happened as soon as I issued the first adb shell am kill app.pachli: I can't get the TL to "remember" being at the top, it always resets to the middle of it, even after a pull to refresh. Maybe related?

Screen_recording_20230925_090233.mp4

I can try more later, but I could also run an APK with fix attempts/logging on my device where I can easily reproduce the original issue and see if it is fixed.