I did some updates on the client which included a lot of updates for various google libraries and build SDK (and some minor async stuff so that swiping between articles is somewhat less jittery). This is the kind of changes that cause issues so I’m interested in feedback / new crashes.
Beta APK should be up for all testers in a few hours, version code 417.
Android 7 - used it today without any special occurences/crashes
I use ‘Mark read on scroll’ so it’s a minor issue but if you use ‘swipe to mark read’ it only works good if your starting point is the lowest point of your swipe. If you swipe from top left/right to more bottom the tile resets repeatedly.
if you use ‘swipe to mark read’ it only works good if your starting point is the lowest point of your swipe
this im afraid is out of my hands, it’s all handled by the library which also does listview animations.
the library is dead and since listview is also dead and everyone should rewrite everything to use a different control google decided to invent instead of fixing it (which has way less functionality but this is google doing what google always does) no alternatives exist.
e: best part how this crash gives you zero information to figure out what the deal is and you have to go google shit until you find out its google silently changing rules for how a very important thing (state saving) works.
also, this:
From that doc, the 1MB is “is shared by all transactions in progress for the process. Consequently this exception can be thrown when there are many transactions in progress even when most of the individual transactions are of moderate size.”
Which means any call to save instance state can push you over the limit, even if it’s tiny. So, again, how is one supposed to know they’re potentially breaching that limit?
basically “we trained everyone for years to obsessively serialize activity/fragment state on exit because our retarded bespoke platform literally restarts your application when you rotate your phone, which is something we thought was a good idea. well, now we’re making actual storage limits for this serialization protocol we wanted you to use completely unpredictable thus making built-in state saving thing completely useless. no, there’s no alternative provided other than “use the database, lol.” additionally, fuck you.”
Through testing, apparently the WebView.saveState() method adds a byte array of several kilobytes per page in the WebView history stack. The size seems to vary depending on the page content. One link resulted in 8 KB added to the Bundle; 10 links totaled 140 KB; I randomly clicked around a news site for a few minutes, and the byte array seemed to top off around 400 KB. I guess the history stack truncates after a certain length.
tfw some guy on a beta build crashes consistently somehow during swiping (?) but never posts so it’s impossible to figure out what he does exactly and why this happens
i’m primarily interested in crashes related to headlines list, and video functionality. i haven’t added any restrictions to android versions so it might just not work on your shit-tier chinese 4.4 phone, at all. if so, report here.
Is this just me or does loading preview images when scrolling to new articles a lot longer now?
this largely depends on your network connection. one minor thing is loading progressbars are unfortunately indeterminate now which might have a perceptual effect.
in other android news for the next release listview animations (used for headlines list) and swipe to dismiss are getting removed.
both are provided by same third party library which has been dead and unsupported for a while now which wouldn’t have been a problem but the library is inherently unstable (at least with tt-rss) and i got bored seeing crash reports related to it. especially swipe to dismiss, it doesn’t take much effort to crash tt-rss if you just swipe a lot for a minute or so, which just won’t do.
swipe to dismiss might return if i find a properly working solution for legacy (thanks google!) listview.