Hi Mark

hello, Ed!

how can I help you today?

I have two 'widgets' in an event storm....

more or less

I'm used to doing something like this... with text widgets... .removeTextChangedListener(this);

um, I'm not sure what an "event storm" is

call back events are stomping on each other

I've got two paths a user can do input

one via a percentage slider

and another via direct text edit

seekbar slider

is there a clean way to make a widget not react to changes without nuking the listener?

does that question even make sense

have a smarter listener, perhaps

lol

otherwise, no

if the problem is that the listener is doing something that you don't want done in all situations, encode that logic in the listener

(or in something that the listener invokes, such as a method on your controller/presenter/whatever)

imagine you have the famous TIP application

you can move a slider

that updates the TextEdit field

or you can directly edit the TextEdit field

I need them to be "in sync"

so the slider can change the text amount

and the text amount can change the slider

I'll just add a flag to short circuit the listener

so much for MVC

I'm use to updating a model

then when I'm doing firing a listener or telling an adapter... to update it's views or fire listeners

I guess that I don't really understand the problem, other than perhaps figuring out the simplest way to implement "debounce" logic with the EditText, so you only update the SeekBar after the user is done typing

the seekbar is at the top

it works fine

the issue happens on the EditText value change

not smooth

flicker and some other odd behaviors

but that is what is causing it

are you attempting to update the SeekBar on every text change?

IOW, for every character typed (or deleted), you try to update the SeekBar immediately?

yes

so imagine that application where you put in an Amount

then a slider for the TIP

moving seekbar changes tip amount as well as shows percentage

then you can also directly edit the tip amount

only update the SeekBar after the user is done typing

doing that would update the SeekBar

where "done typing" is determined by "have not received a new text-change event after X milliseconds", for some value of X that works for you via experimentation (e.g., 500)

if you happen to be using RxJava, Jake Wharton's RxBinding stuff makes adding this "debounce" logic fairly easy, as I understand it

Thanks Mark

or, perhaps, use this: https://github.com/gregacucnik/EditableSeekBar

which is a SeekBar/EditText combination widget

or, examine that library's code and see how it handles debounce