This was working fine under I think `dev05` but un...
# compose
c
This was working fine under I think
dev05
but under 8 it says failed to cast to MutableState:
*val* position = _state_ *{* _SliderPosition_(valueRange = sliderRange, initial = range.*first*.toFloat(), steps = 9) }
a
try a clean build and make sure you don't have older dependencies that aren't migrated forward to dev08 as well, some rather significant binary compatibility properties of the compiler plugin output changed between dev05 and dev08 and the gradle setup isn't necessarily aware of it
c
ok @Adam Powell thanks, I am pretty happy with the build, I had other ways of doing this input and the other one works fine, but lemme clean and see if that helps..
a
ah, never mind, just recognized the problem there.
SliderPosition
is itself a
@Composable
factory function call in dev08 so it can't be called in a
state {}
or
remember {}
initializer block and we're just not catching it.
It'll
remember {}
itself internally, you should be able to just use
Copy code
val position = SliderPosition(...)
instead.
๐Ÿ‘๐Ÿป 1
There's a small set of these kinds of APIs cropping up because they access some other ambient configuration, in this case it's setting up an animation clock to dispose ongoing animations properly
I'm not really happy with it and want to revisit this sort of thing once
suspend
is fully operational, for animation clock subscription stuff like this we shouldn't need it
the studio canaries don't seem to have the latest compose IDE plugin active; normally there would be a visual indication of this with the composable call highlighted in green
not to mention an error about a composable call in a non-composable block
the other one that bugs me at the moment is
ScrollerPosition
since it wants to read the density; the standard android fling scrolling curve depends on it (even though perhaps it never should have)
sorry for making you sit through a clean build ๐Ÿ™‚
โ˜บ๏ธ 1
z
On the topic of this API, the fact that this function/model has an
initial
parameter instead of just a "current value" that's always passed in is confusing to me. It's not clear why the initial value needs to be passed in after the first composition pass, what it would mean to change the "initial" value after the user has adjusted it, or why you'd want to. It also seems awkward with declarative code already stores the numeric slider position in its own state, since that initial state seems to need to be duplicated (set the initial state in parent, and also always be passing it to the slider). It seems inconsistent with other similar composables. Maybe I just have the wrong mental model of how this composable works?
a
nah it's not just you, it's kind of weird.
in terms of duplicating state from a parent, no that's not the intention.
though it probably often becomes the implication, as you've noted.
I would expect this to change in the future
๐Ÿ‘ 2
z
This
LabeledSlider
is more like the API I would expect (minus the text bits): https://gist.github.com/zach-klippenstein/e2c8e6edf0d950d8ba527cd0681c5b60#file-drawlayerdemo-kt-L92
a
yeah. I imagine that this arrived here because
ScrollerPosition
looks similar in the presence of the component changing itself for touch scrolling.
and animation introduced that idea of behavior transparent to the parent
scroller has the added bit of the range being defined by the layout, and correct usage involves saved instance state, which also gets interesting and wasn't fully in place when these things were initially put together
add in a pressure to keep animation state firmly in `@Model`/`State<T>` objects rather than composable parameters to avoid recomposition for changes prior to a ton of skipping optimizations landing, and it makes sense how we got here for the time being
๐Ÿ‘ 1
m
In dev09 there will be
Slider
with
value: Float
and
onValueChange: (Float) -> Unit
params, fwiw ๐Ÿ™‚
๐Ÿ˜ 2
๐Ÿ™ 1
a
Oh good, thanks @matvei, I couldn't remember where our API discussion on this one went ๐Ÿ˜…
c
THanks @Adam Powell yeah just removing the
state {}
made it work..