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.
This format is not supported by ExoPlayer when returned as HLS streams, so we
can't play streams using this format and this delivery method.
Also improve the Javadoc of ListHelper.getPlayableStreams.
This behavior was present before 0.24.0 and the player UI separation and
avoided crashes for which their exception contained
"Context.startForegroundService() did not then call Service.startForeground()".
Some player nullability checks have been also added, and the player service is
now stopped when it has been started from a media button and there is nothing
to play.
As the player can be null in some cases, we have to make sure that the player
is not null, by using Optionals on the player itself instead of its methods
returning Optionals.
If the player is null, the play queue audio track menu will now be hidden.
As the fragment context can be null in some cases, we have to make sure that
the context is not null before calling
DeviceUtils.hasAnimationsAnimatorDurationEnabled.
If the context is null, the button will now not be hidden automatically.
- Currently, only a list of videos separated by newline are added in
the share content.
- This makes it difficult to identify a specific video in a list of
Urls.
- Used string resources for the sharing content formats.
- Added a confirmation dialog for users to choose between sharing
playlist formats.
- Added Playlist name as the header and corresponding video name for
each video url in following format.
Playlist
- Music1: https://media-url1
- Music2: https://media-url2
- Music3: https://media-url3
Co-authored-by: TobiGr <tobigr@users.noreply.github.com>
Instead of searching for the first audio stream matching a compatible media
format, this change makes SecondaryStreamHelper.getAudioStreamFor use methods
isLimitingDataUsage, getAudioFormatComparator and getAudioIndexByHighestRank of
ListHelper to get an audio stream which can be muxed into a video-only stream,
if available.
This allows users to download videos with the highest audio quality available
if no resolution limit on mobile data usage has been set.
The order of formats used to search a compatible audio stream has been kept.
Do not restore last opened license after a rotation change when the license was closed earlier.
This commit adds onCancelListener and onDismissListener to the AlertDialogs which are used to display the licenses.
imageListToDbUrl should be used if the URL is going to be saved to the database, to avoid saving nothing in case at the moment of saving the user preference is to not show images.
Following settings have been move to the new category:
- import database (from ContenttSettings)
- export database (from ContenttSettings)
- reset settings (from DebugSettings)
Add the separate utility class PlayButtonHelper to handle the initialization of the listeners.
The ClickListeners on playlist controls had different behaviours. This commit fixes that.
The commit also refactors the way how the app determines whether it is started for the first time. The previous version was not clean and recent in this PR caused it to fail.
The previous "main" tab is now just a normal tab returned in getTabs().
Various part of the code that used to handle channels as ListInfo now either take the first (playable, i.e. with streams) tab (e.g. the ChannelTabPlayQueue), or take all of them combined (e.g. the feed).
* added LoadingDialog for improving download experience
* [LoadingDialog] Apply some review comments and make title customizable.
* removed permission handling from loading Dialog
* fix checks
* remove <p> Tag from first sentence
---------
Co-authored-by: rishabaggarwal <Rishabaggarwal@sharechat.com>
Co-authored-by: TobiGr <tobigr@users.noreply.github.com>
The RuntimeException was not explicitly declared and thus not caught at every call of this constructor. This change ensures that this possible exception is handled by the dedicated error handlers.
- don't check for isAudioOnly == !videoEnabled, as this prevents enabling again
video and text tracks renderers in some cases;
- when reloading play queue manager if that's needed, disable or enable video
and text tracks renderers, as they may need to be enabled again in some cases
like starting a video in main player, opening play queue, switching to
background player on it and switching back to main player;
- disable or enable video renderers also for streams with AUDIO_STREAM
StreamType, as doing so doesn't raise any issue and simplifies code;
- reword and move some comments to make them easier to understand.
We don't know if, on muxed video streams we get for all services which support
multiple audio languages, that the audio language returned is the original one
or not, even if it should be the case.
In order to avoid saying potential false information, this word has been
removed from the string resource (ID and value) and the corresponding layout ID
in the download dialog.