Button down listener

[1g0rrr]

Hi, @ryaa as I can see, we don't have ACTION_DOWN event yet. How about to add it?
I still need it for "push to talk" feature and @p-caetano seems need it too for precision starting timer.

We can add two variables to result instead of one. First one for type of the button and second one for action of the button, like this:

ret.put("direction", "up");
ret.put("action", "down");

I can add PR if you wish, and discuss solution beforehead

[ryaa]

@1g0rrr great idea. We may also extend VolumeButtonsOptions to add the property, for example actionsToListen, to indicate which actions should triggers VolumeButtonsCallback. It can be ACTION_DOWN, ACTION_UP, ACTION_ALL (this one can be the default value).. what do you think?

[1g0rrr]

@ryaa yes, sounds good. But how can we know in VolumeButtonsCallback what action was called ACTION_DOWN or ACTION_UP while using ACTION_ALL option? So we probably need to put action name into "ret" anyway.
And in this case isn't actionsToListen option will be redundant? As we already can check what action was triggered.

Or are you suggesting to use watchVolume twice in client code, one for ACTION_DOWN and one for ACTION_UP?

[ryaa]

@1g0rrr my suggestion is to use your approach with two variables to result instead of one. However, allow the consuming app to choose if it wants to receive a callback for ACTION_DOWN, ACTION_UP or ACTION_ALL. For example, in my application i only need to receive ACTION_UP callbacks. I can filter by action === 'up' but my guess that there will be many ACTION_DOWN events sent which from native code which I don't need anyway and will discard them in my cross platform code. let me know if this makes sense. thank you

[1g0rrr]

@ryaa Ok, I agree. We can do it this way.
As for default value we can use ACTION_UP to not break exsiting workflow

[ryaa]

@1g0rrr in other words, i would prefer to filter actions in the native code and invoke the callback only for the actions that the application asks/needs. I hope that this makes sense.

[ryaa]

As for default value we can use ACTION_UP to not break exsiting workflow

Great suggestion!!

[1g0rrr]

@ryaa Ok. So let's implement?

[ryaa]

@ryaa Ok. So let's implement?

yes :)

[1g0rrr]

@ryaa
I'm making down handler, but find strange behaviour.
If I call
call.resolve(ret);
then android volume UI appeared in 1-2 seconds of pressing the button.
If I comment this line, then android UI didn't appear.
Despite I return true in both case.
I tested this on my real device.
Do you have any idea why this can happen?

[p-caetano]

Hi. I missed this conversation. I tried to implement the key down handler already, on top of 1.0.2 release. I'm filtering the events in the native code (android only) and didn't change the output contract; just added a new option.
The behavior is, if you click down and stay, multiple events are generated (every few millis). But it's what I'm expecting. The system UI never appear.

My current problem is not being able to receive the configuration made in my ts app in the native code (call.getString("triggerKey") is always returning null). After that I would create an issue/PR, but I see you are already doing that. Great!
I'm available to help. My current impl is not yet ready for PR.