- Implemented a new settings page using Jetpack Compose.
- Added a new settings option to enable the redesigned settings page.
- This option allows for gradual integration and testing of the new
settings page, minimizing disruptions to current functionality.
Plan for Settings Items:
- Jetpack Compose does not have a direct equivalent to the
Preference/settings library.
- We could consider using third-party libraries that offer preference
items as composables.
- However, these libraries may be incomplete or lack active development.
- Given our specific needs for only a subset of preference types,
creating custom composables would be beneficial.
- This approach allows for fine-tuning the components to our specific
use case.
Next Steps:
- Continue development by adding more composables for settings
functionalities and screens.
This pull request integrates Jetpack Compose into NewPipe by:
- Adding the necessary dependencies and setup.
- This is part of the NewPipe rewrite and fulfils the requirement for
the planned settings page redesign.
- Introducing a Toolbar composable with theming that aligns with
NewPipe's design.
Note:
- Theme colors are generated using the Material Theme builder (https://m3.material.io/styles/color/overview).
This change is in line with a recent change in how the play/pause button behaves in the player ui: if the buffering indicator is shown, it's still possible to toggle play/pause, to allow e.g. pausing videos before they even start.
This change was needed because on Android 13+ notification actions can't be null, and thus the buffering hourglass action wasn't shown.
Disable loading all tabs at once, since there can be many of them, and use default strategy of only keeping in memory the two tabs adjacent to the current tab.
Reduced memory footprint of FeedUpdateInfo objects. Those objects might stay around for a while and accumulate (up to BUFFER_COUNT_BEFORE_INSERT = 20 at the moment), so in order not to fill up the memory it's better to keep as little data as possible.
Previously ChannelInfo data was stored, causing ReadyChannelTabLinkHandler objects to be also stored uselessly (and those channel tabs contain prefetched JSON data which used ~700KB of memory).
The fix just involves removing some really outdated code (6 years ago) added in 33e29be7db (diff-38bd2cf1b92659b499c08e1cf6ac9ef384c7e13381b906f2f98c57cbb758756dR778) (blame: 9318bb5306/app/src/main/java/org/schabi/newpipe/detail/VideoItemDetailActivity.java (L778)).
What that code did was setting the 'buddy' image to the uploader avatar as a placeholder, and then setting the actual image if it existed and after it had loaded.
That code remained there up until now, but now it doesn't make sense anymore, since Picasso already takes care of setting placeholders.
The problem is, starting from #10066 the actual uploader image is set before (not after) those lines of code, making them do the wrong thing, i.e. always overwrite the currently set image.
But then why did the channel avatar image work normally sometimes?
My guess is that since Picasso loads images in the background, when opening a video from scratch setting the placeholder still happened before Picasso finished loading the image.
However when the image is already cached it's loaded much faster and therefore setting the placeholder happens after, effectively hiding the loaded image.