Fix transaction too large in channel tab fragments #10673
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is it?
Description of the changes in your PR
This PR contains a really hacky workaround, that avoids storing useless data in the
ChannelTabFragment
state.ChannelTabFragment
uses the corresponding tab link handler to be able to fetch data, since unlike other things in the extractor, channel tabs are not supposed to be obtained from a url (e.g. provided by the user), but rather always from a channel page internally in the app.The problem is,
ReadyChannelTabListLinkHandler
might contain raw JSON data that uses a lot of memory (e.g. ~800KB for YouTube). While 800KB doesn't seem much, if you combine just a couple of channel tab fragments you easily go over the 1MB save&restore transaction limit, and getTransactionTooLargeException
s.What this PR does is to discard the
ReadyChannelTabListLinkHandler
after the first time the raw data has been parsed (i.e. the fragment'shandleResult
has been called). A new link handler with the same properties is then created. The good thing is, even if now the raw data is not in the link handler anymore, ifgetChannelTab
is called on the newly created link handler, the app cache will kick in to still prevent network requests. Note that I didn't test this link-handler-recreation with all services, I will let users do this (or @AudricV could provide some feedback).A proper solution would require rethinking about
ReadyChannelTabListLinkHandler
s, but that's out of scope for 0.26.0. We might need to rethink how the cache works, and instead of returning link handlers with raw data (which turned out to be a really bad idea) , we should put the raw data directly in an extractor cache.You can test the changes by putting one channel from all NewPipe services (Youtube, Soundcloud, ...) as a main page tab. Then open settings and the app should not crash. All video/audio tabs from all channels should still allow e.g. playing in the background without crashing.
Fixes the following issue(s)
APK testing
The APK can be found by going to the "Checks" tab below the title. On the left pane, click on "CI", scroll down to "artifacts" and click "app" to download the zip file which contains the debug APK of this PR. You can find more info and a video demonstration on this wiki page.
Due diligence