feat: preserve article scroll position when Android recreates the process#1115
Conversation
…ticle, related to feature request spacecowboy#411
… the linting error
|
Thanks for the PR. That does seem like a fairly elegant solution. If I understand it correctly, when an article is opened, then at first the scroll position defaults to 0. Then, as the user scrolls, the view model updates every 500ms. Later, when the user switches articles, the view model gets destroyed and a new view model gets created for the new article, so the scroll position always starts at 0 for a newly opened article. So it would probably work if Android destroys the process and it gets recreated later. So better than the state today. Would still be nice to have it save it in such a way that you can go back to the list and then open the same article again and the scroll position would be kept. But that can be kept as a future improvement. |
|
The going back to the list view and then back to an article preserving reading posisiton should be possible but I think then it would have to be serialized somehow, possibly to the db, which would require a regression test that I didn't want to do. This seemed a little less invasive a change. |
Feeder on Android seems to lose the scroll position in the currently open article. When reading a long form article in Feeder, if one changes context to another app and Android kills the process the behaviour of Feeder is that it goes back to the feeds index and refreshes the feeds. Which interrupts the reading experience and can be disruptive.
This PR keeps note of where in the article the reader was and preserves that across the process wake cycle.
Preserves scroll position in article, only for curretly opened article, related to feature request #411. In that feature it is suggested that Feeder do that for every article, which would involve storing that state somewhere (probbly in the db). The approach suggested in the PR is only for the currently opened article and needs no database chages/migration.