New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
onTextChanged implementation #31
Comments
Ah, that's the cool part of the new Anvil actually. Of course TextWatcher is the ugliest listener in the whole Android SDK: there is no way to tell if it's already added to the view or not, you can not call setText() from inside it etc etc. In the new Anvil I still provide a TextWatcher setter, which removes the previous TextWatcher and adds the new one if you use lambdas. Of course, having one TextWatcher instance stored somewhere in class attributes is a solution to avoid extra work. But there is a cool two-way data binding: |
Is there a way to subscribe to changes using the |
Oh.. I think the easiest way for now would be to override StringBuilder's |
It would be nice to have the TextWatcher DSL as it was in the old Anvil, but:
|
I ended up slightly tweaking my UX to remove the need to watch for changes. I'm using the |
@zserge Having problems getting this to work with
|
@danhawkes Yeah... TextWatcher is so far the most painful part of Anvil. It relates to a broader topic of two-way data bindings and is on my todo list for a long time already. Still, I don't see a perfect solution yet because Android's TextWatcher is broken too much.
I'm open to a discussion about how two-way data bindings should work in Anvil and how to simplify this process. I would prefer a solution to be more generic (e.g. cover not only EditTexts, but also Sliders, ToggleButtons and other views used for input). |
So far I could only think of two approaches:
Solution 1 requires less code from user and gives less control if you don't want to subclass your data classes. |
Add ability to set bidirectional animators in declarative style
Previously
EditText::onTextChanged
(in Kotlin) accepted a lambda that was called with the updated text. So I could do something like:Now, onTextChanged requires a full
TextWatcher
implementation. Of greater concern, it appears to be adding the watcher to the EditText over and over again, with every render. So after a few updates to the field the UI begins lagging noticeably.The old onTextChanged syntax was sufficient for my needs and more concise. I'm planning on creating my own
onTextChanged
using the old syntax. Is this something that you would be interested in getting a PR for or not?The text was updated successfully, but these errors were encountered: