Feature request: when refreshing, keep the focus on the last toot you were viewing about amaroq

[ReticentJohn]

Thanks for the detailed explanation :3
This is a pretty frequently requested feature, and it makes complete sense in-line with what the other social networking apps do.

[apiarian]

@ReticentJohn any plans to do this? I'm thinking of maybe taking a crack at it over the upcoming long weekend. (Though probably won't get far since I haven't really done any real iOS dev work before.)

[ReticentJohn]

@apiarian I already have a limited version of this in the dev/staging branches, but it is incomplete. Currently only holds position if the last toot seen within the first page of the refreshed timeline. Needs to either fill in the gaps without massive network spam or we need to start having the feeds listen to the streaming API, but that'll take a good chunk of work and time I don't have right now. You're more than welcome to explore the problem further, or devise your own solution!

[apiarian]

So if I'm reading all this right, it seems that you always load timelines from the beginning, and if the id of the previous top toot is in the stuff returned in that first request, it gets shown at the top. Otherwise you just show the newest toot.

The API makes it pretty straightforward to get newer toots without asking for all of them, using the since_id parameter. So it theoretically should be possible to load the max_id=[previous-top-toot] list if necessary to fill a page, and then just "paginate upwards" with the prev link. Though I guess if we were to do this we would probably want some way to force our way up to the freshest bit of the timeline. Not sure what that would look like.

Is there some fundamental flaw to doing things this way? Something about the UITableView not playing well with this sort of "stuff loading in off-screen at the top" process?

[apiarian]

@ReticentJohn these don't seem to get set anywhere https://github.com/ReticentJohn/Amaroq/blob/master/DireFloof/MSTimelineStore.m#L21-L22 . There's some code for resetting them to nil, but nothing that would set them to something non-nil. Was there a plan to use them but it never got implemented? Or is there some subtle thing I'm missing?

[apiarian]

@ReticentJohn there's my first step. Next: messing with the timeline controllers somehow.

[apiarian]

Idle thought: if we get this working, does that mean we can add a periodic automatic load-newer-toots-if-possible process so that you don't have to manually pull to refresh?

[apiarian]

Well this brings me to a bit of a dead end mastodon/mastodon#5819 =[

[ReticentJohn]

I apologize for the slow response on this @apiarian I truly appreciate the effort you've been expending on this issue. <3

I'll try to address your string in order here...

The API makes it pretty straightforward to get newer toots without asking for all of them, using the since_id parameter. So it theoretically should be possible to load the max_id=[previous-top-toot] list if necessary to fill a page, and then just "paginate upwards" with the prev link. Though I guess if we were to do this we would probably want some way to force our way up to the freshest bit of the timeline. Not sure what that would look like.

This is the initial idea, yes. The problem arises with the UX to force our way up to the freshest bit of the timeline, and this is where I've ultimately gotten stuck, resulting in my latest solution where we only provide the "new toots" notification and maintain position if we can find that last toot in the completely refreshed timeline. I can't really think of an intuitive way to paginate upwards and provide a way to jump to top. :(

Is there some fundamental flaw to doing things this way? Something about the UITableView not playing well with this sort of "stuff loading in off-screen at the top" process?

Yes, actually. Because Mastodon allows such a large amount of text in every toot (this isn't bashing just a reality), the estimated cell height varies wildly for individual toots. This makes it extremely difficult to get the UITableView to play nice, without jumping/scrolling issues. The only way I can readily think of is to calculate an estimated size in advance, but this comes with other performance woes. I'm still trying to think of a way to pull it off, maybe something to assemble as part of the process of loading in all the JSON.

@ReticentJohn these don't seem to get set anywhere https://github.com/ReticentJohn/Amaroq/blob/master/DireFloof/MSTimelineStore.m#L21-L22 . There's some code for resetting them to nil, but nothing that would set them to something non-nil. Was there a plan to use them but it never got implemented? Or is there some subtle thing I'm missing?

This is a remnant from a time where I was thinking I'd build a much more robust toot caching system - it was just never pulled out. x3

Idle thought: if we get this working, does that mean we can add a periodic automatic load-newer-toots-if-possible process so that you don't have to manually pull to refresh?

I've been playing with the idea to listen to the streaming api whenever the app is in the foreground, which would allow us to pull toots in as they're made. This would provide our automatic functionality without the need play around with polling.

I'm not giving up on this yet, I'm just not sure which will come first: a wonderful localized solution to Amaroq only, or a Mastodon API one. P:

[mthld]

Hello,

The missing API feature was merged into Mastodon in September 2018, adding this is it still planned?
Thanks,

[apiarian]

hi, sorry! i’ve mostly stopped using social media, so i don’t have much of a stake in this ticket anymore.