I frequently get interrupted when reading a story in the android app. If I switch back to the app quickly then things are normally fine. But if I take longer to return I often get the frame around the content of the story but just a loading indicator where the story normally is, and the story never loads. Further, if I try to open the original page in the browser I get the page for a different story. Even more strangely, when I press the back button I’m taken back to the list of feeds, not the list of stories in this feed. The story is marked as read so I wind up leaving lots of stories unfinished.
I was an engineer on the Android team way back before it launched, so I’ll venture a guess about what’s happening: when the phone is low on memory it evicts your process from memory. When I return to the app the activity is asked to restore from its saved state and it does this incorrectly.
2 Likes
Yeah I definitely want to solve this problem. iOS does a great job of holding onto the app, even though it technically suffers from the same issue. The other issue is that I think it should reset you after N hours. On iOS it’s about 6 hours.
Daniel, are we doing any state restoration today, and if not, how hard would it be to save the active story and feed? We don’t even have to do scroll position, although that would be nice as well. Scroll position shipped on iOS a year ago but it didn’t work reliably until just a few months ago.
This is an artifact of the ever-problematic Pager framework from the support library. Though we save all the necessary state to restore the correct story after being evicted from memory (which on Android happens far more often than you would think), when we get un-frozen after a long time the framework will often re-use incorrect Fragments. I would absolutely love to come up with a heavy-handed workaround or better yet replace the ancient Pager system with a modern component, but so far this hasn’t found priority in the time budget. Interestingly, some of the upgrades required to create the new story list are requiring us to at least partially address this, since newer versions of the support libraries deprecate parts of the Pager (though, annoyingly, do not suggest a replacement). I suspect that swapping in a newer (or custom) version would be about on the same effort scale as the new story list, and would fix not only this bug, but also the tendency for notification taps to bring up incorrect stories.
I’m glad that you all are aware of this and that fixes might come at some point. It’s a pretty annoying issue for me so eventually I’ll be motivated to look for alternatives if things don’t improve.
I’m curious about what you mean by resetting after N hours. Do you mean that if I don’t use the app for that duration then you’ll deliberately clear the activity state? If so, what’s the benefit of this?
Daniel, I’d love to prioritize this over the new grid. I think the pager system is the biggest difference between web, iOS, and android.
> I’m curious about what you mean by resetting after N hours. Do you mean that if I don’t use the app for that duration then you’ll deliberately clear the activity state?
I’m not sure about iOS, but on Android there is no hard limit. I’ve revived long-forgot activities after several weeks an had them restore state just fine. (the pager bugs aside)
> I think the pager system is the biggest difference between web, iOS, and android
Apart from this bug (which I think has a fairly small impact surface - I can’t actually repro it on purpose since about v6.0 or so), what are the big differences?
One thing that would help a lot here is if anyone who ever sees this bug, as quickly as possible after it happens, go back to the feed list and use the “Send app feedback -> Email a bug report” feature from the menu. This lets me get at least partial repro info from the device.
Ok. I’ll send you some bug reports. I get this several times a day so there shouldn’t be a shortage of them.
I no longer have a dev phone with console access but I figured that if you pkilled the process and then went back to the activity the bug would probably reproduce. Not so, huh?
I’m not 100% sure. The bug is in the way the FragmentManagerPager system incorrectly reusues fragments, so totaly killing it might clear *too* much. Even a single report from the live bug should help a lot, though.
Daniel, I think the difference is that stories pop into view while you’re looking at other stories in the list. What I do on iOS is show a custom toast that animates in from the bottom of the story list. It’s the same toast used elsewhere on iOS.
This screenshot shows it. What happens is that opening the feed shows an empty loading bar (similar to the web). If after 1 second the request hasn’t come back yet, show the offline cache of stories, but also show the “Fetching recent stories…” toast. That way when the stories jump when the request does finish after 2-3 seconds, it isn’t as jarring. And they don’t flash in for the 99% of time when the request takes less than 1 minute.
I think we’ve got out wires crossed. This thread is about the story-level view not correctly showing a story after being backgrounded. I’ll follow up separately about any issues with the story list.
I’ve just mailed you a bug report. One theory that I have is that this only happens when more stories have appeared in the feed while I was reading the current story. Certainly, I haven’t managed to trigger this bug by simply forcing the app out of memory or by waiting a long time while viewing a feed that rarely posts. But when I get it very frequently on the Ars Technica feed.
I also have a screenshot that I took. It stays like this indefinitely as far as I can tell.
Incidentally, as a result of some dependency upgrades, I had to almost entirely rewrite the workaround code that deals with the pager. Some quick testing by fork-bombing the app out of memory is showing expected behaviour on my devices, at least, so look out for the next beta.
Great! I’ve signed up for the beta at https://play.google.com/apps/testing/com.newsblur/join. I hope that’s still the right way. (The link that I found was pretty old.)