Status Update
No update yet.
Comments
mg...@google.com
mg...@google.com
ap...@google.com
+cc Siyamed and Matvei
-
For the context, there've been this bug
b/155211005 -
Since we're considering merging the BaseTextField and CoreTextField, do we want to have the primitive override in a single 'core' text field?
pr...@google.com
do we want to have the primitive override in a single 'core' text field
I don't think so. This whole bug is a side effect of the naming problem we've already fixed. I would suggest to close this bug as fixed because of renaming and original problem being infeasible anymore.
If someone is reimplementing their TextField for their design need, I expect them to be ok with TextFieldValue hoisting or them be able to wrap this API with their string overload.
It seems reasonable to separate selection range and value long term, but maybe I'm missing some cases there where this might not work. Over to Siyamed to give some input here
Description
Component used: Lifecycle
Version used: 2.5.0-rc02
Right now methods to create a
ViewModelare marked asMainThread. It would be nice if that limitation was removed andViewModelProvider(and hence the creation of ViewModels) could be made thread safe.This would be particularly helpful for cases such as with the Lifecycle ViewModel Compose API of
viewModel(), which would ensure future compatibility for multi-threaded composition.