Update Jetpack Compose Slider Progress based on ExoPlayer playing audio position - kotlin

I have created a custom UI for player an audio file and I am using Exoplayer to get the file and play it. I am not using the custom controller for exoplayer and my UI has a Slider that needs to update based on the current audio position. How can I achieve this? Please help.
var currentValue by remember { mutableStateOf(0f) }
currentValue = mediaPlayer.getCurrentPosition()
Slider(
modifier = Modifier.weight(1f),
value = currentValue ,
onValueChange = {currentValue = it },
valueRange = 0f.. mediaPlayer.contentDuration()
)

According to your code, you're expecting mediaPlayer.getCurrentPosition() to trigger recomposition somehow.
Compose can only track State object changes, which a special type created to trigger recompositions.
When you need to work with some non Compose library, you need to search for the way to track changes. In most of old libraries there're some listeners for such case.
In case of ExoPlayer there's no direct listener. In this issue you can see suggestion to use the listener to track isPlaying state. In Compose to work with listeners you can use DisposableEffect so when the view disappears you can remove the listener.
And then when it's playing - call currentPosition repeatedly with some interval. As Compose is built around Coroutines, it's pretty easy to do it with LaunchedEffect:
var currentValue by remember { mutableStateOf(0L) }
var isPlaying by remember { mutableStateOf(false) }
DisposableEffect(Unit) {
val listener = object : Player.Listener {
override fun onIsPlayingChanged(isPlaying_: Boolean) {
isPlaying = isPlaying_
}
}
mediaPlayer.addListener(listener)
onDispose {
mediaPlayer.removeListener(listener)
}
}
if (isPlaying) {
LaunchedEffect(Unit) {
while(true) {
currentValue = mediaPlayer.currentPosition
delay(1.seconds / 30)
}
}
}

Related

Jetpack Compose Navigation Is Triggering Recomposition

I have a simple Jetpack Compose application that uses the Navigation Component.
My UI is comprised of the following composables (redacted UI to be concise):
NavHost:
#Composable
fun NavHost(
navController: NavHostController = rememberNavController(),
startDestination: String = "main"
) {
NavHost(
navController = navController,
startDestination = startDestination) {
composable("main") {
SomeList(onNavigateToItemView = {
navController.navigate("listItem")
})
}
composable("listItem") {
ItemView()
}
}
}
SomeList:
#Composable
fun SomeList(onNavigateToItemView: () -> Unit) {
Column {
Row ( Modifier.fillMaxWidth(),
horizontalArrangement = Arrangement.Center
) {
Text(text = Constants.APP_TITLE, fontSize = 30.sp, fontWeight = FontWeight.Bold)
}
Box(modifier = Modifier.fillMaxSize(),
contentAlignment = Alignment.Center
) {
LazyColumn(
horizontalAlignment = Alignment.CenterHorizontally
) {
items(items) { item->
ItemCard(item, onNavigateToItemView)
}
}
}
}
}
ItemCard:
#Composable
fun ItemCard(item: ItemModel, onNavigateToItemView: () -> Unit) {
Card(
border = BorderStroke(2.dp, Color.Cyan),
modifier = Modifier
.fillMaxWidth()
.padding(bottom = 5.dp)
.clickable {
onNavigateToItemView()
}
) {
Row(
verticalAlignment = Alignment.CenterVertically,
horizontalArrangement = Arrangement.SpaceBetween
)
{
....
}
}
}
Now, whenever the user clicks on an ItemCard, he/she transitions to an ItemView.
What I am seeing is that the ItemView is being recomposed several times when navigating to it and also when navigating back from it.
According to the guide linked above,
The NavController's navigate function modifies the NavController's
internal state. To comply with the single source of truth principle as
much as possible, only the composable function or state holder that
hoists the NavController instance and those composable functions that
take the NavController as a parameter should make navigation calls.
Navigation events triggered from other composable functions lower in
the UI hierarchy need to expose those events to the caller
appropriately using functions.
And as you can see above, I am following that practice.
So, am I doing something wrong in my implementation or is this just how navigation and Jetpack Compose work together?
The multiple recomposition calls are affecting my UI unnecessarily.
Short Answer
Yes, navigating using compose navigation will recompose your composable each time you are navigating to it.
Workaround
When you are using navController.navigate() it will automatically recompose the targeted route. However, you can use an option to save the current state of the screen that you leave and restore the state of the screen that you target.
For example :
A->B->A->B
The first time you will load A & B you will recompose because you have no state saved yet. The moment you go from B to A (B->A) the state will be restored so you'll not recompose. Same things occurs the second time you go from A to B (A->B)
Use
Accord to documentation, you can make an extension function like this
fun NavController.popUpTo(destination: String) = navigate(destination) {
popUpTo(graph.findStartDestination().id) {
saveState = true
}
// Restore state when reselecting a previously selected item
restoreState = true
}
And use it like this
SomeList(onNavigateToItemView = {
navController.popUpTo("listItem")
})

Exoplayer within AndroidView not switching video when setting a new MediaItem on the fly

So I got declared an exoplayer2 inside a composable function like this:
DisposableEffect(
AndroidView(
modifier = Modifier
.weight(3f)
.fillMaxSize()
.clip(RoundedCornerShape(RoundedSizeStatic.Medium))
.shadow(
elevation = 4.dp,
shape = RoundedCornerShape(RoundedSizeStatic.Medium),
spotColor = Color.White,
ambientColor = Color.White
)
,
factory = {
PlayerView(viewModel.context).apply {
player = largeVideoPlayerHandler.videoPlayer
useController = false
resizeMode = AspectRatioFrameLayout.RESIZE_MODE_FILL
FrameLayout.LayoutParams(
ViewGroup.LayoutParams.MATCH_PARENT,
ViewGroup.LayoutParams.MATCH_PARENT
)
}
}
)
) {
onDispose {
largeVideoPlayerHandler.videoPlayer.release()
}
}
and the video exoplayer is initiated like this:
fun GetCameraPlayer(url: String): ExoPlayer {
var rendersFactory = DefaultRenderersFactory(context).forceEnableMediaCodecAsynchronousQueueing() //prevent buffering memory leaks
var newExoPlayer: ExoPlayer = ExoPlayer.Builder(context).setRenderersFactory(rendersFactory).build().apply {
setMediaItem(MediaItem.fromUri(url))
repeatMode = ExoPlayer.REPEAT_MODE_ONE
playWhenReady = true
prepare()
}
return newExoPlayer
the initial video is being displayed fine, but whenever I try to change and prepare the next MediaItem for this Exoplayer it won't change. Code:
fun SwitchLargeVideoDisplay(url: String) {
largeVideoDisplay.videoPlayer.setMediaItem(MediaItem.fromUri(url))
largeVideoDisplay.videoPlayer.prepare()
}
videoPlayer is the Exoplayer which was returned.
The funny thing is that whenever I execute this SwitchLargeVideoDisplayin the same composable function it does work. But executing this code outside of this composable function with the correct refrence to the exoPlayer, the exoplayer won't change its video/mediaItem
somebody knows a solution for this problem?

Unable to trigger re-composition after re-assigning mutableStateList inside a coroutine scope

I'm still a bit of a beginner with Jetpack compose and understanding how re-composition works.
So I have a piece of code calls below inside a ViewModel.
SnapshotStateList
var mutableStateTodoList = mutableStateListOf<TodoModel>()
private set
during construction of the view model, I execute a room database call
init {
viewModelScope.launch {
fetchTodoUseCase.execute()
.collect { listTypeTodo ->
mutableStateTodoList = listTypeTodo.toMutableStateList()
}
}
}
then I have an action from a the ui that triggers adding of a new Todo to the list and expecting a re-composition from the ui that shows a card composable
fun onFabClick() {
todoList.add(TodoModel())
}
I can't figure out why it doesn't trigger re-composition.
However if I modify the init code block below, and invoke the onFabClick() action, it triggers re-composition
init {
viewModelScope.launch {
fetchTodoUseCase.execute()
.collect { listTypeTodo ->
mutableStateTodoList.addAll(listTypeTodo)
}
}
}
or this, taking out the re-assigning of the mutableStateList outside of the coroutine scope also works (triggers re-composition).
init {
// just trying to test a re-assigning of the mutableStateList property
mutableStateTodoList = emptyList<TodoModel>().toMutableStateList()
}
Not quite sure where the problem if it is within the context of coroutine or SnapshotStateList itself.
Everything is also working as expected when the code was implemented this way below, using standard list inside a wrapper and performing a copy (creating new reference) and re-assigning the list inside the wrapper.
var todoStateWrapper by mutableStateOf<TodoStateWrapper>(TodoStateWrapper)
private set
Same init{...} call
init {
viewModelScope.launch {
fetchTodoUseCase.execute()
.collect { listTypeTodo ->
todoStateWrapper = todoStateWrapper.copy (
todoList = listTypeTodo
)
}
}
}
To summarize, inside a coroutine scope, why this works
// mutableStateList
todoList.addAll(it)
while this one does not?
// mutableStateList
todoList = it.toMutableStateList()
also why does ordinary list inside a wrapper and doing copy() works?
The mutable state in Compose can only keep track of updates to the containing value. Here is simplified code on how MutableState could be implemented:
class MutableState<T>(initial: T) {
private var _value: T = initial
private var listeners = MutableList<Listener>
var value: T
get() = _value
set(value) {
if (value != _value) {
_value = value
listeners.forEach {
it.triggerRecomposition()
}
}
}
fun addListener(listener: Listener) {
listeners.add(listener)
}
}
When the state is used by some view, this view subscribes to updates of this particular state.
So, if you declare the property as follows:
var state = MutableState(1)
and try to update it with state = 2.toMutableState() (this is analogous to your mutableStateTodoList = listTypeTodo.toMutableStateList()), triggerRecomposition cannot be called because you create a new object which resets all the listeners. Instead, to trigger recomposition you should update it with state.value = 2.
With mutableStateList, the analog of updating value is any method of MutableList interface that updates containing list, including addAll.
Inside init it works because no view is subscribed to this state so far, and that's the only place where methods such as toMutableStateList should be used.
It is important to always define mutable states as immutable property with val in order to prevent such mistakes. To make it mutable only from view model, you can define it like this, and make updates on _mutableStateTodoList:
private val _mutableStateTodoList = mutableStateListOf<TodoModel>()
val mutableStateTodoList: List<TodoModel> = _mutableStateTodoList
The only exception when you can use var is using mutableStateOf with delegation - this is where you can use it with private set because in that case the delegation does the work for you by not modifying the container, but only it's value property. Such method cannot be applied to mutableStateListOf, because there's no single value field that's responsible for the data in case of list.
var someValue by mutableStateOf(1)
private set

Compose: remember() with keys vs. derivedStateOf()

What is the difference between these two approaches?
val result = remember(key1, key2) { computeIt(key1, key2) } (Docs)
val result by remember { derivedStateOf { computeIt(key1, key2) } } (Docs)
Both avoid re-computation if neither key1 nor key2 has changed
.
The second also avoids re-computations if downstream states are derived, but else, they are identical in their behavior, aren't they?
derivedStateOf {} is used when your state or key is changing more than you want to update your UI. It acts as a buffer for you, buffering out the changes you don't need. That is the primary difference between a keyed remember {} and derivedStateOf {}. With remember {}, you will still recompose as much as your key changes, which isn't a bad thing if that's what you need. If you don't need those recompositions though, that is where derivedStateOf {} comes in.
Take for example showing a button only if the user has scrolled a LazyColumn.
val isVisible = lazyListState.firstVisibleItemIndex > 0
firstVisibleItemIndex will change 0, 1, 2 etc as the user scrolls and cause a recomposition for every time it changes.
I only care about if it's 0 or not 0 and only want to recompose when that condition changes.
derivedStateOf is my buffer, it's buffering out all of those extra state changes I don't need and limiting the recomposition to only when the derivedStateOf changes.
val isVisible = remember { derivedStateOf { lazyListState.firstVisibleItemIndex > 0 } }
For the example given in the question, a remember(key1, key2) {} is the correct API to use there, not derivedStateOf {} because you want your UI to update any time the key changes, there isn't any change to buffer out.
Update: There is a detailed explanation of derivedStateOf in this talk https://www.youtube.com/watch?v=ahXLwg2JYpc&t=412s
AFAIK there is no difference here. It's just a coincidence that both constructs are doing the same thing here in this context. But, there are differences!
The biggest one is that derivedStateOf is not composable and it does no caching on it's own (remember does). So derivedStateOf is meant for long running calculations that have to be run only if key changes. Or it can be used to merge multiple states that are not in composable (in custom class for example).
I think the exact explanation is blurred for "outsiders", we need some input from some compose team member here :). My source for the above is this one thread on slack and my own experiments
EDIT:
Today i learned another derivedStateOf usage, very important one. It can be used to limit recomposition count when using some very frequently used value for calculation.
Example:
// we have a variable scrollState: Int that gets updated every time user scrolls
// we want to update our counter for every 100 pixels scrolled.
// To avoid recomposition every single pixel change we are using derivedStateOf
val counter = remember {
derivedStateOf {
(scrollState / 100).roundToInt()
}
}
// this will be recomposed only on counter change, so it will "ignore" scrollState in 99% of cases
Text(counter.toString()).
My source for that is as direct as it can be - from the author of compose runtime and the snapshot system, the Chuck Jazdzewski himself. I highly recommend watching stream with him here: https://www.youtube.com/watch?v=waJ_dklg6fU
EDIT2:
We finally have some official performance documentation with small mention of derivedStateOf. So the official purpose of derivedStateOf is to limit composition count (like in my example). sauce
val result = remember(key1, key2) { computeIt(key1, key2) } re-calculates when key1 or key2 changes but derivedStateOf is for tracking a change in one or more State/MutableState as stated in documents as
var a by remember { mutableStateOf(0) }
var b by remember { mutableStateOf(0) }
val sum = remember { derivedStateOf { a + b } }
// Changing either a or b will cause CountDisplay to recompose but not trigger Example
// to recompose.
CountDisplay(sum)
It's convenient to use derivedStateOf when you need to track a change in property of a State object. The value you store in State can be an object but when you need to track one or some properties of object you need to use derivedStateOf. And if it's not derived from a State/MutableState or object with an interface with #Stable annotation Composable won't recompose since recomposition requires a state change.
For instance an Input layout or number of items that you need to trigger another recomposition after a certain threshold or state.
var numberOfItems by remember {
mutableStateOf(0)
}
// Use derivedStateOf when a certain state is calculated or derived from other state objects.
// Using this function guarantees that the calculation will only occur whenever one
// of the states used in the calculation changes.
val derivedStateMax by remember {
derivedStateOf {
numberOfItems > 5
}
}
Column(modifier = Modifier.padding(horizontal = 8.dp)) {
Row(verticalAlignment = Alignment.CenterVertically) {
Text(text = "Amount to buy: $numberOfItems", modifier = Modifier.weight(1f))
IconButton(onClick = { numberOfItems++ }) {
Icon(imageVector = Icons.Default.Add, contentDescription = "add")
}
Spacer(modifier = Modifier.width(4.dp))
IconButton(onClick = { if (derivedStateMin) numberOfItems-- }) {
Icon(imageVector = Icons.Default.Remove, contentDescription = "remove")
}
}
if (derivedStateMax) {
Text("You cannot buy more than 5 items", color = Color(0xffE53935))
}
}
This is whatsapp text input that displays icons based on whether text is empty or not by reading from text
internal fun ChatInput(modifier: Modifier = Modifier, onMessageChange: (String) -> Unit) {
var input by remember { mutableStateOf(TextFieldValue("")) }
val textEmpty: Boolean by derivedStateOf { input.text.isEmpty() }
Row(
modifier = modifier
.padding(horizontal = 8.dp, vertical = 6.dp)
.fillMaxWidth(),
verticalAlignment = Alignment.Bottom
) {
ChatTextField(
modifier = modifier.weight(1f),
input = input,
empty = textEmpty,
onValueChange = {
input = it
}
)
Spacer(modifier = Modifier.width(6.dp))
FloatingActionButton(
modifier = Modifier.size(48.dp),
backgroundColor = Color(0xff00897B),
onClick = {
if (!textEmpty) {
onMessageChange(input.text)
input = TextFieldValue("")
}
}
) {
Icon(
tint = Color.White,
imageVector = if (textEmpty) Icons.Filled.Mic else Icons.Filled.Send,
contentDescription = null
)
}
}
}

TornadoFX: Error while updating label inside runAsync

I tried to implement a chat application using socket connection in Kotlin and TornadoFX library to make the GUI.
The problem comes when I try to launch the client because it keeps waiting a message from the Server although I put that code that update the label and receive the message inside a runAsync. I red the TornadoFX documentation and saw youtube videos but I cannot come to the solution.
I know that the issue is that the program is stuck in that block but can't figure how to do it.
class MyFirstView: View("Chat"){
var input: TextField by singleAssign()
var test = SimpleStringProperty()
val client: Client by inject()
init {
client.connect()
val t = thread(true) {
while (true) {
random = client.getMessage()
println(random)
Platform.runLater { test.set(random) }
}
}
}
override val root = vbox {
hbox {
label(test) {
bind(test)
}
}
hbox {
label("Write here some text")
input = textfield()
}
hbox {
button("Send") {
action{
client.writer.println(input.text)
}
}
}
}
}
You can only update UI elements on the UI thread, so if you want to manipulate the UI from a background thread, you need to wrap that particular code in runLater { }.
On another note, you shouldn't manipulate the text of the textfield or store ui element references with singleAssign. Instead you should bind your textfield to a StringProperty and manipulate the value instead. This is covered in the guide, so check it out :)