I don’t know if anyone had this confusion, but I was using ‘onPress’ with an onOff switch and not getting what I expected for the value of isOn. Turns out onPress returns the CURRENT value of the switch - and onRelease returns what it’s GOING to become. Is this intentional? Found it a bit confusing.
Hi @jflowers45,
Yes, this is intentional behavior which we decided upon when implementing it. We decided that some users might need the current state before the switch actually gets triggered, and also the state it will be in upon a successful trigger (as in, the user actually released the switch and didn’t slide off it, thus not triggering it).
Best regards,
Brent
To add to what Brent said, If you think of the switch as a Touch handler (which it really is), there is a “began” phase and an “ended” phase. onPress triggers on the “began” phase, onRelease triggers on the “ended” phase. The button state when the began phase happens is it’s current state. Logically the state changes in between the two and by the “ended” phase, it’s now changed to the new state.
We went back and forth on this because some developers may want the switch to change as soon as it’s pressed others like the more mouse-like behavor of waiting until the mouse is released to activate the change. But the other side of this is that if you want to do something when the touch begins and do something when the touch ends, you should be allowed to. The button state should reflect the state of the button at the time your accessing it.
Rob
Thanks to both of you for the in-depth response. I hadn’t realized that the switch doesn’t trigger if you move the mouse outside of the switch area before releasing. Now that I “know” I agree it gives more flexibility - I just submitted the wufoo form in the docs with a suggestion to maybe add a blurb to either of these pages, if you think it makes sense.
http://docs.coronalabs.com/api/type/SwitchWidget/isOn.html
http://docs.coronalabs.com/api/library/widget/newSwitch.html
Noted… I’ll add it to those docs soon. 
Thanks,
Brent
Hi @jflowers45,
Yes, this is intentional behavior which we decided upon when implementing it. We decided that some users might need the current state before the switch actually gets triggered, and also the state it will be in upon a successful trigger (as in, the user actually released the switch and didn’t slide off it, thus not triggering it).
Best regards,
Brent
To add to what Brent said, If you think of the switch as a Touch handler (which it really is), there is a “began” phase and an “ended” phase. onPress triggers on the “began” phase, onRelease triggers on the “ended” phase. The button state when the began phase happens is it’s current state. Logically the state changes in between the two and by the “ended” phase, it’s now changed to the new state.
We went back and forth on this because some developers may want the switch to change as soon as it’s pressed others like the more mouse-like behavor of waiting until the mouse is released to activate the change. But the other side of this is that if you want to do something when the touch begins and do something when the touch ends, you should be allowed to. The button state should reflect the state of the button at the time your accessing it.
Rob
Thanks to both of you for the in-depth response. I hadn’t realized that the switch doesn’t trigger if you move the mouse outside of the switch area before releasing. Now that I “know” I agree it gives more flexibility - I just submitted the wufoo form in the docs with a suggestion to maybe add a blurb to either of these pages, if you think it makes sense.
http://docs.coronalabs.com/api/type/SwitchWidget/isOn.html
http://docs.coronalabs.com/api/library/widget/newSwitch.html
Noted… I’ll add it to those docs soon.
Thanks,
Brent
How come it doesn’t default to turning on/off with a swipe left/right over the switch when it’s in onoff mode? That seems more natural to me. What would be the recommended way to add that functionality myself?
Dave
Hi Dave,
Which theme are you using? iOS7+ or one of the Android Holo themes? Or a custom theme?
Brent
iOS7+ is the one I’m specifically talking about. It seems to work like it should with the Android theme. We’re just using the defaults.
Hi Dave,
If I recall correctly, we did not implement “sliding” on the iOS7+ switch because of the complexity in how that switch animates (see how Apple does the native switch and how the handle sort of “morphs” while the background transitions from green to white). Now, we did implement a reasonable facsimile of that animation effect in our widget, but we don’t support actually sliding this switch back and forth and having the handle stretch/morph as the users moves it around (note that this switch is fairly small and most users will not even notice that it morphs when they slide on it).
But as to your main question, it seems that you just want to trigger the switch when a slide/flick action occurs upon it, correct? In this case, you’d have to dig into the widget library a little (it’s open source, of course) and look for where that event occurs. If I recall from my own previous edits to the widget code, it’s not intensely complex, and you can probably figure it out pretty easily.
Alternatively, if you need a faster workaround, you can probably override the normal functionality by adding a touch listener to the switch’s view, like so:
[lua]
local function swipeMe( event )
print( event.phase )
end
switch._view:addEventListener( “touch”, swipeMe )
[/lua]
Then, using the typical event phases, you could detect whether a sufficient “swipe” occurred on the switch (it would be up to you for what is considered a sufficient swipe).
Take care,
Brent
I’ll try that and see if it will work. It sounds like it might.
Hi Dave,
It definitely works, meaning that the switch’s view will gather the touch events. But as for detecting what you consider a “swipe”, that’s up to you… perhaps just sense a “began” X coordinate and the “ended” X coordinate, and depending on their relation, do a “switch:setState()” call on it for the proper state it should go to.
Brent
How come it doesn’t default to turning on/off with a swipe left/right over the switch when it’s in onoff mode? That seems more natural to me. What would be the recommended way to add that functionality myself?
Dave
Hi Dave,
Which theme are you using? iOS7+ or one of the Android Holo themes? Or a custom theme?
Brent
iOS7+ is the one I’m specifically talking about. It seems to work like it should with the Android theme. We’re just using the defaults.
Hi Dave,
If I recall correctly, we did not implement “sliding” on the iOS7+ switch because of the complexity in how that switch animates (see how Apple does the native switch and how the handle sort of “morphs” while the background transitions from green to white). Now, we did implement a reasonable facsimile of that animation effect in our widget, but we don’t support actually sliding this switch back and forth and having the handle stretch/morph as the users moves it around (note that this switch is fairly small and most users will not even notice that it morphs when they slide on it).
But as to your main question, it seems that you just want to trigger the switch when a slide/flick action occurs upon it, correct? In this case, you’d have to dig into the widget library a little (it’s open source, of course) and look for where that event occurs. If I recall from my own previous edits to the widget code, it’s not intensely complex, and you can probably figure it out pretty easily.
Alternatively, if you need a faster workaround, you can probably override the normal functionality by adding a touch listener to the switch’s view, like so:
[lua]
local function swipeMe( event )
print( event.phase )
end
switch._view:addEventListener( “touch”, swipeMe )
[/lua]
Then, using the typical event phases, you could detect whether a sufficient “swipe” occurred on the switch (it would be up to you for what is considered a sufficient swipe).
Take care,
Brent
I’ll try that and see if it will work. It sounds like it might.