mir/newpipe
2
0
Fork 0
mirror of https://github.com/TeamNewPipe/NewPipe synced 2025-08-22 01:58:16 +00:00
Code Issues Releases Wiki Activity

PlayerUIList: inline init block

Browse Source
This commit is contained in:
Profpatsch 2025-05-14 21:38:42 +02:00 committed by Stypox
parent 183cc580fc
commit 462f0ad5c0
No known key found for this signature in database
GPG Key ID: 4BDF1B40A49FDD23
1 changed files with 13 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
app/src/main/java/org/schabi/newpipe/player/ui/PlayerUiList.kt
View File

@ -3,10 +3,21 @@ package org.schabi.newpipe.player.ui
import org.schabi.newpipe.util.GuardedByMutex
import java.util.Optional
/**
* Creates a [PlayerUiList] starting with the provided player uis. The provided player uis
* will not be prepared like those passed to [.addAndPrepare], because when
* the [PlayerUiList] constructor is called, the player is still not running and it
* wouldn't make sense to initialize uis then. Instead the player will initialize them by doing
* proper calls to [.call].
*
* @param initialPlayerUis the player uis this list should start with; the order will be kept
*/
class PlayerUiList(vararg initialPlayerUis: PlayerUi) {
private val playerUis = GuardedByMutex(mutableListOf<PlayerUi>())
private val playerUis = GuardedByMutex(mutableListOf(*initialPlayerUis))
/**
* Adds the provided player ui to the list and calls on it the initialization functions that
/**
* Creates a [PlayerUiList] starting with the provided player uis. The provided player uis
* will not be prepared like those passed to [.addAndPrepare], because when
* the [PlayerUiList] constructor is called, the player is still not running and it
@ -14,16 +25,7 @@ class PlayerUiList(vararg initialPlayerUis: PlayerUi) {
* proper calls to [.call].
*
* @param initialPlayerUis the player uis this list should start with; the order will be kept
*/
init {
playerUis.runWithLockSync {
lockData.addAll(listOf(*initialPlayerUis))
}
}
/**
* Adds the provided player ui to the list and calls on it the initialization functions that
* apply based on the current player state. The preparation step needs to be done since when UIs
*/* apply based on the current player state. The preparation step needs to be done since when UIs
* are removed and re-added, the player will not call e.g. initPlayer again since the exoplayer
* is already initialized, but we need to notify the newly built UI that the player is ready
* nonetheless.