I am doing a `pointerInput(Unit) { … }` somewhere, and inside there I call `this.size.width` to calc...

# compose

[Stylianos Gakis]

I am doing a pointerInput(Unit) { … } somewhere, and inside there I call this.size.width to calculate something regarding its width.
Due to the fact that in my activity I am saying that I am handling the configuration change of rotating the phone, this does not get updated in that case.
Is my best bet to do something like pointerInput(LocalConfiguration.current) so I key properly to restart that lambda and on the new instance I will get the right width again? Or is there something better I can do instead?

[Stylianos Gakis]

I am doing this on a custom private fun Modifier.customModifier() where I am not in a composable context, and I gotta go with a composed in order to achieve this it seems like.

[Stylianos Gakis]

Well, it works this way rubber duck

[Alex Vanyo]

What is this referring to in this.size.width and how is it being called?

Keying off of LocalConfiguration.current for the size is pretty suspicious to me: That’s a “global” window-level signal, and maybe the composable you’re using pointerInput for changes size completely separately from the window resizing

[Stylianos Gakis]

this there is just PointerInputScope which is what this is inside the pointerInput already.
I didn’t like this solution either, but how else can I make sure that the val size: IntSize inside this PointerInputScope is up to date?

[Stylianos Gakis]

How it’s called is basically the line here https://github.com/HedvigInsurance/android/pull/1667/files#diff-6675483cb22ff6aa9681ed7f63e52919cafde7e4c9720b573f924ebae38c6cd7R107, just as soon as we’ve entered the `pointerInput`’s lambda

[Stylianos Gakis]

Which btw is heavily inspired from this codelab, which does access the size too, if you check on the part of the code which does

offsetX.updateBounds(
  lowerBound = -size.width.toFloat(),
  upperBound = size.width.toFloat()
)

[Alex Vanyo]

Huh, that’s tricky. I wonder if you could make your calculation of endPoint “lazier”, and repeatedly calculate the sizes as needed later. So instead of val endPoint = // ..., you could do
fun getEndPoint() = // … so that you fetch the most up-to-date width each time

[Stylianos Gakis]

Aha, interesting idea!
My offsetX.updateBounds( would also need to be updated in this case too then, since it’s also initiated once and then the slider doesn’t go all the way due to that, it looks so silly with this bug 😅

I turned endPoint to:

val getEndPoint = {
  val endPoint = this.size.width - circleDiameter.toPx()
  offsetX.updateBounds(
    lowerBound = 0f,
    upperBound = endPoint,
  )
  endPoint
}

And this does in fact work without the configuration local as a key

[Stylianos Gakis]

But still, this feels like a hack, I wonder how could I in a reliable manner be able to re-run this code which updates the the bounds of my animatable whenever the size.width changes 🤔

[Stylianos Gakis]

I feel like what I should just do is just use the lazy getEndPoint which you suggested (thanks) and for the updateBounds I should just use a separate modifier which gets called on any change of size. onPlaced or something like that, afk atm and I can't remember for sure

[Stylianos Gakis]

Yep, this has been working well for me after all with this approach.
Thanks for steering me away from using the configuration as a key in the way that I was doing before.