/b/tard 1.3.1
The mods on /b/ happened to sticky a thread with a picture of right goat.
So this caused some parsing problems that meant the first post was always “loading”. I fixed the parsing problem but all that people got after that was a picture of a push pin and not the goat. I wasn’t going to do a lot more work for a presumably singular event.
These threads however do pose new stresses on the app because the max post and image count are not limited in this sticky threads.
So I found the current lazy loading implementation (which was very lazy) actually spent a lot of time blocking the main UI thread just trying the schedule the lazy loading of the images. I’m going to have to spend some time down the line making this more efficient.
On the horizon I’m toying with the following
Select channels ( so more than just /b/)
—
Obvious expansion, almost guaranteed to come. I just want to make sure it’s not intrusive for those genuinely just wanting to see /b/ which is most people.
Get all pages (as opposed to just page 0)
—
I actually whipped up slow and nasty version of this on my phone. It meant not having to do anywhere near as many refreshes. The big problems though;
- no longer feels like /b/
- not as fun
- massive bandwidth requirements, 1.1MB just in HTML and 1.1MB in thumbnails on initial load
On the upside
- quicker, instead of querying and waiting for that page to return, we query 16 pages at once and wait for ANY to return and let the rest lazy load. So it’s more responsive.
Tablet Layouts
—
Still very unsure as to how to approach this. The obvious tablety thing to do is to use a split pane and fragments. In reality though we aren’t going to get much value out of that. Perhaps a grid view is the best compromise for truly large displays (10.1″).