Some actions from the user may trigger multiple events and handlers, like the well known LongClick ~> Click.
I am looking for some kind of a hierarchy graph that summarizes this potential trigger-order relation for Android Events, but no success so far.
Any pointer on this please ?
Related
I am keen to know how Android's event handling and dispatching work. Code walk-through is an option, of course. But, if there's any document one can refer me to, that'd be great.
As a concrete example, consider a click event on a button. How does that click propagate within the framework? In case of multiple event occurring one after another, is there some sort of event queue, and a dispatcher calling methods on the events in the queue? What goes on under the hood? If not any document, if one can point me to the relevant part of the code I should look at, that'd be great.
According to my knowledge the parent is the first asked, if he can handle the event, otherwise he asks his childs who can handle this event ?
https://developer.android.com/training/gestures/viewgroup
We have started to look into the Building Accessibility Service for Android at https://developer.android.com/guide/topics/ui/accessibility/services.html. Based on this documentation, we can perform custom gestures on behalf of user as mentioned under section "Taking actions for users" at https://developer.android.com/guide/topics/ui/accessibility/services.html#act-for-users.
We have following questions based on this documentation.
1) As we understand, there are gestures that user would perform and our code would listen to. Let's call these Listening Gestures. Then there are gestures that could be performed by our code for user. Let's call these Performing Gestures. Question is where do Performing Gestures impact - over touch-and-explore layer or underneath the touch-and-explore layer? For additional information, touch-and-explore is feature of Android Operating System that can be requested by Accessibility Services.
2) Does the Performing Gesture trigger any AccessibilityEvent which is notified to Accessibility Service? If yes, there's possible recursion if both Listening Gesture and Performing Gesture happen to be same. That is Listening Gesture could be swipe right which triggers some event. Performing Gesture is also let's say a swipe right. Now, this will also in turn trigger same event handler.
3) How do we determine that Performing Gesture executed successfully? The whole thing holds significance if Performing Gesture happens underneath the touch-and-explore layer.
Any help would be greatly appreciated.
1) No, performing gestures on behalf of users utilizing Accessibility service capabilities DOES NOT end up being caught as a "listening" gesture. The AccessibilityService actually sends the gesture through to the API that calculates screen touches in the exact same way that the screen does, circumventing the screen completely. So, these events are invisible to the assisstive technology. Though, if you hang on to a reference, you could of course call the callbacks from AccessibilityService for these gestures yourself. So, any gesture you perform will not trigger a touch to explore gesture. In fact, you could trigger performing a gesture as a result of a touch to explore gesture.
2) This, to me is actually the same question as question 1. No, it does not, because of all of the same reasons in question 1.
3) There are two answers to this. The first is 'dispatchGesture' returns a boolean. This boolean is true when the operating system runs into no technical issues dispatching your gesture. Potential issues for example would be: Your attempting to interact off screen. This would be stupid of you! LOL. If a "true" is returned from this method, your gesture was generally accpetable and was performed. At this point, we can be as sure that a gesture was performed as a user actually performing the gesture themselves. It's the exact same logic in the Operating System... check out the AOSP for yourself if you don't believe me :)
3B) The only way to be sure things are working is to watch your gesture take actions on the screen.
I was troubleshooting a view-related issue: a click listener that is not fired when it's supposed to. After a long session of trial-and-error, I found out that a parent view was disabled, thus discarding all events to its children.
Is there a way, in Android, to find exactly what happens to a touch or click event when it is injected to the app? Like how was it dispatched, which views were traversed by it, who ignored it (and why), who discarded it (and why) and finally who consumed it.
Ideally it would be some kind of low-level dump on Logcat emitted for every click in the app.
As you can see in the similar post at the issue tracker Dianne Hackborn writes:
There currently isn't a way to do this.
Meaning, there is no such an API in the framework.
But you can have a custom root ViewGroup and listen for each and every touch event (via onInterceptTouchEvent()) and dump the MotionEvent.
I believe that's the only possible way so far.
I am currently researching for better ways to handle events in my app.
Currently I have multiple listeners that are subscribing and unsubscribing to interesting objects on different events.
E.g. on a button click a listener is created, that listens on a client object, if a operation succeeded (in that case it automatically unregisters itself) or if a non fatal error occurs (in that case it automatically retries the operation).
The client object in turn is starting a android service that can emit different status events, that should result in the user interface updating itself or alternatively show notifications, if the app is currently not visible.
In my app I have a really big listener clutter, that is not easy to follow and that is not working on all occasions.
To resolve this issue I would like to implement a event bus with RxJava that hopefully reduces the complexity of my application.
The problem:
Is it possible with RxJava to have a fallback observer for a observable, to react to events, if no other observer is available?
E.g. All activities/fragments register themselves to get informed about certain events, so they can update the UI, if necessary.
When a activity/fragment is created/destroyed it automatically registers/unregisters itself from the event bus.
If the app is now in background, there should be no observers registered anymore. In that case only I would like to use a fallback observer that is handling those events.
I would like to achieve the following:
If in foreground: On event, update the UI.
If in background: On event, show toast / notification.
In my opinion your app shouldn't show anything when it's in the background (user is not interested in it anymore, or is doing something else, so don't spam him with toasts (as he probably would not even know which application raised this toast)).
However,
You can solve this problem with Subject. Let say you have MyServiceErrorHandler class with PublishSubject> inside, so every time there is some part of UI is visible and capable of showing error is should be subscribed to this subject. Then you can expose method like onError(Throwable t) which will call subject.hasObservers(). If yes it pushes data to subject (so it will emit an event to currently subscribed UI) if no you can do some fallback thing (like displaying toast/notification/logging something/etc). This solution is however error prone to rotation as you may receive your result while screen is rotating (thus not subscribed yet)
You can extend this approach a little bit and use a BehaviourSubject which will replay it's last event for every subscriber (pretty handy in case of screen rotation). So you're posting event to this subject even though there are none subscribers, and when user opens this app back again (and one of your UI element will subscribe) it will receive last event with error (so you can show it properly). But in that solution you would need a little bit more logic to clear this subject in case of obsolete/already consumed errors (to prevent it from showing on every rotation/etc).
I am an undergraduate research assistant working on an android accessibility project. My task involves collecting as much data about the user experience as possible, including touch events and other view interactions. I require 2 services: an accessibility service to gather details about the view current interaction, and a TouchListener service that is able to intercept MotionEvents.
My problem is with the TouchListener service. Is there any known way to intercept all touch events and pass them on to the current view?
Essentially, it seems like an invisible system-overlay view is needed to constantly listen for touch events, but the view can either intercept all touch events and NOT pass them to the view behind, or it can pass the even back and register the touch event as an ambiguous ACTION_OUTSIDE event, giving no details about the interaction.
My question is similar to this one, and the obstacle is discussed here. If anyone has found a work-around, please post!