Fixed
Status Update
No update yet.
Comments
lp...@google.com
Wow, it seems like a very important bug to fix.
Doing some investigations...
It works fine with CoreTextField as well as BaseTextField.
ma...@gmail.com
It works fine with Material TextFields (both filled and outline) if you use TextFieldValue based overloads.
It doesn't work when you use String based overloads however (both Outline and Filled). I believe this is related to the one-frame lag as we host TextFieldValue internally and proxy only string.
jb...@google.com
Chatted with Anastasia.
We have this code
// "value: String" comes as a param in TextField
TextFieldImpl(
type = TextFieldType.Outlined,
value = textFieldValue,
onValueChange = {
selection = it.selection
composition = it.composition
if (value != it.text) {
onValueChange(it.text)
}
},
and this value is always "" for me, as it's captured my lambda when lambda was created and this lambda is saved and reused by CoreTextField.
Anyway, two things we can do:
- Remove this if and invoke
onValueChangeeverytime, even on the selection change (which we don't care about). This will allow us to workaround quickly and not to let it slip through. - Find and implement the proper fix in CoreTextField
Let me know what you think
ma...@gmail.com
Updated the details here
Description
PreferenceFragmentCompat sets this adapter (PreferenceGroupAdapter), which implicitly registers an observer. PreferenceFragmentCompat never sets the adapter to null when the view is destroyed, so the observer keeps references to the RecyclerView and doesn't get gc'ed.
I've worked around this by explicitly setting the adapter to null in an override of onDestroyView, but since my component doesn't explicitly have ownership of the list handling, I'd argue that PreferenceFragmentCompat should do this cleanup.
It would be solved by setting the RecyclerView adapter to null in the fragment's onDestroyView.
Here's a memory dump.