Touch events no longer delivered after RoboViewController disappears

12 views
Skip to first unread message

Guillermo Rodriguez Garcia

unread,
Feb 11, 2019, 10:37:11 AM2/11/19
to PlayN
Hi there,

In my application I need to switch between "native" (Android, iOS) and PlayN views. I have this already working in Android and I am now wrestling with the RoboVM part.

In order to switch between the native and PlayN views, I am calling setRootViewController() on the application's main UIWindow.

I found that if I switch from RoboViewController to a native UIViewController and back, touch events are no longer delivered to the application.

I also found that when this happens, instantiating a new Pointer object immediately after switching back to the RoboViewController instance is enough to get touch events working again:

    new Pointer(plat, rootLayer, true);

Any hints on what may be happening ?

Best,

Guillermo

Michael Bayne

unread,
Feb 11, 2019, 2:58:42 PM2/11/19
to pl...@googlegroups.com
That sounds very strange.

RoboViewController uses a custom GLKView subclass which (via RoboInput) converts iOS touch events to PlayN event objects and then dispatches them on the Input.touchEvents signal. Even if you were creating a new RoboViewController, the same RoboInput instance and touchEvents signal instance would remain and would be used to dispatch touch events by the new RoboViewController + GLKView combo.

Furthermore, none of that would be affected at all by creating a new Pointer object, because the only thing that does is add a listener to the Input.touchEvents signal.

So I would suspect something strange going on in your application code. You might try setting up a very simple test app that swaps out the root view controller on the UIWindow and otherwise just logs or does something with raw touch events to see if those are properly dispatched before and after the view controller swap. I suspect they will be, and that something else is changing along with your view controller swap that causes your app to somehow stop listening to events.

--

---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--

Guillermo Rodriguez Garcia

unread,
Feb 11, 2019, 3:53:33 PM2/11/19
to pl...@googlegroups.com
OK. I have been debugging this a bit and I think I found the problem.

In my test code I was switching back to the "native" view from PlayN from a Pointer.Listener.onStart() handler. I found that if I changed my code to do that from onEnd() instead, then the issue was gone.
Looking a bit into the code I think I see why this is happening.


When a new START event is detected, "active" is set to the event id (which in iOS is the UITouch object handle)
In my original code, this triggered the transition to the native part immediately, so PlayN never saw the END event. This means that "active" was never reset to -1.
Later, when I switched back to the PlayN part, new START events would not be processed because all new UITouch objects would have a different id, and so the event.id == active check would always fail.
This also explains why creating a new Pointer object seemed to "fix" the issue (the new Pointer instance has its "active" field initialised to -1 again)

Does this make sense?

Guillermo
Guillermo Rodriguez Garcia
guille.r...@gmail.com

Michael Bayne

unread,
Feb 11, 2019, 4:22:46 PM2/11/19
to pl...@googlegroups.com
Ah yes, that is unfortunate. Pointer has to be a bit stateful to know which finger is acting as the pointer when operating on a touch device, and yanking the rug out from under it by disconnecting it from the UI event stream in mid-interaction is bound to cause trouble.

If you can trigger this mode switch on onEnd, then that's probably the best solution. Most UI elements trigger on release rather than on press even on touch devices, so this would be a sensible behavior in any case (indeed they usually double check that the pointer is still inside their bounds when released prior to firing their action; this is also how TriplePlay buttons work).

Otherwise you'll need to replace the Pointer object. There's no API for "resetting" it and I'm reluctant to add one because this is a somewhat esoteric case. A more generally useful API might be a way to cancel all in-progress interactions, which a game/app might reasonably want to do for special reasons, and that would cover this particular circumstance as well. I'll take a quick look at how complicated that would be to add.

Guillermo Rodriguez Garcia

unread,
Feb 11, 2019, 4:44:03 PM2/11/19
to pl...@googlegroups.com
Hi Michael,

In fact I don't really need to do anything in onStart in the actual application. I just came across this in a Q&D "proof of concept" app. I didn't know whether it was something wrong on my side, a bug in PlayN, or both, and wanted to make sure before moving forward :)

Anyway, here's a quick thought: What is supposed to happen if the "active" finger is lifted while others are still down (in a multitouch gesture)? I assume that the behavior is not really specified. If so, perhaps the easiest would be, if the "active" touch is not found in the array of currently active touches, then pick any of the existing ones as the "new" active finger.  This would not make any difference for single touch cases (the majority) and would avoid this kind of problems.

What do you think?

Guillermo 
To unsubscribe from this group and stop receiving emails from it, send an email to playn+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--

--

---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
Guillermo Rodriguez Garcia
guille.r...@gmail.com

--

---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--

--

---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Michael Bayne

unread,
Feb 11, 2019, 4:53:18 PM2/11/19
to pl...@googlegroups.com
That sounds like it would cause problems if you started touching with one finger, pressed a second one, lifted the first and continued with the second. I'd rather not try to work around this totally unrelated problem by changing the "which finger is the pointer finger" heuristics.

I'm adding a notion of "game has focus" to Input, and I should be able to have all of the platform input machinery automatically cancel all in-progress interactions if the game loses focus for any reason. This makes sense and avoids these same problems occurring if someone pressed down the mouse button, removes focus from the app, then releases the mouse button while the app no longer has focus, etc.

Once the focus stuff is in place, your changing of the UIViewController may automatically trigger a loss of focus. But if it doesn't, it will be trivially easy to manually dispatch a "lost focus" event to let everything know that the game view is no longer active.

To unsubscribe from this group and stop receiving emails from it, send an email to playn+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--

--

---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
Guillermo Rodriguez Garcia
guille.r...@gmail.com

--

---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--

--

---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
Guillermo Rodriguez Garcia
guille.r...@gmail.com

--

---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--

Guillermo Rodriguez Garcia

unread,
Feb 11, 2019, 5:28:01 PM2/11/19
to pl...@googlegroups.com
El lunes, 11 de febrero de 2019, Michael Bayne <m...@samskivert.com> escribió:
That sounds like it would cause problems if you started touching with one finger, pressed a second one, lifted the first and continued with the second. 

Yes, That's what I meant when I said that the behavior when the active finger is released in multitouch gestures isn't really specified: Having the second finger become the "active" one if the first is released should be as good as any other alternative.


I'd rather not try to work around this totally unrelated problem by changing the "which finger is the pointer finger" heuristics.

Makes sense :)
 

I'm adding a notion of "game has focus" to Input, and I should be able to have all of the platform input machinery automatically cancel all in-progress interactions if the game loses focus for any reason. This makes sense and avoids these same problems occurring if someone pressed down the mouse button, removes focus from the app, then releases the mouse button while the app no longer has focus, etc.

Once the focus stuff is in place, your changing of the UIViewController may automatically trigger a loss of focus. But if it doesn't, it will be trivially easy to manually dispatch a "lost focus" event to let everything know that the game view is no longer active.
 
Yes, this is probably the best solution :)

Guillermo 

 

To unsubscribe from this group and stop receiving emails from it, send an email to playn+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--

--

---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
Guillermo Rodriguez Garcia
guille.r...@gmail.com

--

---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--

--

---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
Guillermo Rodriguez Garcia
guille.r...@gmail.com

--

---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--

--

---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Michael Bayne

unread,
Feb 11, 2019, 6:30:21 PM2/11/19
to pl...@googlegroups.com
OK, I pushed these changes. I tested things on Java desktop (where the OS subverts my plans by sneakily dispatching a mouse up when the window loses focus), and on HTML5 (where the OS/browser is differently sneaky, it keeps dispatching mouse events if you have the mouse down when the window loses focus; so you can see that mouse events keep coming, but the active pointer interaction is canceled, which is intended).

In theory, I plugged in in the right places in Android and iOS/RoboVM, but I was not able to easily test them. So you can try this out with your test app and see what you find.

To unsubscribe from this group and stop receiving emails from it, send an email to playn+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--

--

---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
Guillermo Rodriguez Garcia
guille.r...@gmail.com

--

---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--

--

---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
Guillermo Rodriguez Garcia
guille.r...@gmail.com

--

---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--

--

---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
Guillermo Rodriguez Garcia
guille.r...@gmail.com

--

---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--

Guillermo Rodriguez Garcia

unread,
Feb 12, 2019, 7:33:28 AM2/12/19
to pl...@googlegroups.com
I can confirm that my iOS test app now works fine with the latest changes, even if I switch views from the onStart handler.

Re. Android I didn't have a test app exhibiting any problems but at least I can confirm that my existing test apps work fine without any breaking changes.

Thank you!

Guillermo

Michael Bayne

unread,
Feb 12, 2019, 7:04:20 PM2/12/19
to pl...@googlegroups.com
Awesome!
Reply all
Reply to author
Forward
0 new messages