Jump to content

[TOPIC: topicViewTemplate]
[GLOBAL: userSmallPhoto]
Photo

Physical volume buttons do not work correctly
Started by soyenrique Jan 21 2019 04:29 AM

6 replies to this topic
[TOPIC CONTROLS]
[/TOPIC CONTROLS]
[modOptionsDropdown]
[/modOptionsDropdown]
[reputationFilter]
[TOPIC: post.html]
#1

soyenrique

[GLOBAL: userInfoPane.html]
soyenrique
  • Observer

  • 3 posts
  • Corona SDK

Why Android does not work the physical buttons of the volume? If I keep them pressed, they do not slide continuously.
 
Is there any way to fix it?
Thank you!


[TOPIC: post.html]
#2

Rob Miracle

[GLOBAL: userInfoPane.html]
Rob Miracle
  • Moderator

  • 25,648 posts
  • Enterprise

Corona doesn't generate continuous events. Doing so would jam up the event system. Most people handle this through a combination of detecting the up and down state on the key, along with a flag indicating the state of the button (up or down) and a Runtime:enterFrame() listener that will continuously change the value you want while you detect the button is in a down state and when you detect the up state, you stop changing the value.

 

Rob



[TOPIC: post.html]
#3

soyenrique

[GLOBAL: userInfoPane.html]
soyenrique
  • Observer

  • 3 posts
  • Corona SDK

Ok, very good explanation. I understand perfectly what you say, but ... when changing the volume the position of the slider will also change?



[TOPIC: post.html]
#4

Rob Miracle

[GLOBAL: userInfoPane.html]
Rob Miracle
  • Moderator

  • 25,648 posts
  • Enterprise

If you're using a widget.newSlider(), not it will not automatically update. You would have to set the value of the slider in that enterFrame listener.

 

Rob



[TOPIC: post.html]
#5

soyenrique

[GLOBAL: userInfoPane.html]
soyenrique
  • Observer

  • 3 posts
  • Corona SDK

So, from what I understand, it is not possible to move the operating system slider. The solution is to create a custom slider.
Will this solution pass the google quality tests?


[TOPIC: post.html]
#6

Rob Miracle

[GLOBAL: userInfoPane.html]
Rob Miracle
  • Moderator

  • 25,648 posts
  • Enterprise

You have a choice of letting the OS handle those buttons, in other words, you don't intercept the key presses and let the device control its master volume. Or you can intercept the buttons to control the sound in your app while leaving the system sound volume alone.

 

The system slider is only going to show if you let the OS handle the buttons. Personally I never intercept the volume buttons. When you set the volume in your app, you're setting it to a percent of the device volume. If the user has their sound at 30%, 100% in your game is 30% of the device volume. Think of it as the volume of your sounds relative to the users desired device setting.

 

Rob



[TOPIC: post.html]
#7

SGS

[GLOBAL: userInfoPane.html]
SGS
  • Corona Geek

  • 2,077 posts
  • Corona SDK

I think what he means Rob is if you have a keyEvent listener and you return false for volume up and down the native functionality is still interrupted. 

 

For example, outside of Corona press volume up button and the volume (and OS animation) will be smooth and continuous.

 

In Corona app, you press volume up and the OS slider moves around 5-10%.  You have to keep pressing the same button to reach the desired level,  It has always been this way.

 

Take this simple implementation...

function onKey( event )
  if event.keyName == "back" and event.phase == "up" then
      --do something
      return true
  end

  return false
end

This blocks the native (and repetitive) volume buttons.  I would say this was a bug.




[topic_controls]
[/topic_controls]