7

I have a system overlay that sits above all Activities and Windows. The only problem is that it can only detect MotionEvents when a user places his/her down on the screen (it can't track the finger's movements or detects when the finger is lifted). As a possible solution, I've implemented a second view (I'll call it the tracking view) that is able to handle all the touch events, but stays hidden until a touch in the desired location is detected by the system overlay; in that event, it will bring up the tracking view. Only problem is, that the tracking view doesn't start detecting touch events until the user places his/her finger back down on the screen. So to resolve this, I want to intercept the view that's getting the touch events (which is the view beneath the system overlay) and forward all its touch events to the tracking view to process.

Does anyone know how I can get the view that's receiving all the touch events and redirect all the touch events it's receiving?

This question refers to the examples used in this question.

Community
  • 1
  • 1
Brian
  • 7,955
  • 16
  • 66
  • 107
  • I have the same problem, did you find an answer? – fargath Jul 26 '11 at 11:11
  • Sorry no, I originally was going to use this method for a special interface I was making. I ended up giving up that idea and went with a different one. I would still love to know if someone has an answer to this. – Brian Jul 27 '11 at 00:39
  • Thanks Aerodroid, Do u have any suggestions for this nw, because i need to implement this by any other way too. – fargath Jul 27 '11 at 04:54
  • Well my original interface idea was to detect some swiping gestures but after so much frustration of not being able to find out a working solution, I resorted to just building an interface that uses taps instead of swipes. – Brian Jul 27 '11 at 05:06
  • i saw a app in a market, i think it has this functionality. please refer this. https://market.android.com/details?id=mobi.conduction.swipepad.android – fargath Jul 27 '11 at 07:31
  • Yea that's pretty much one of the exact same apps I was trying to get my idea from. I ended up just thinking that I should build an interface that utilizes taps instead of swipes. It seems like that apps like SwipePad use some pretty clever methods that I can't seem to figure out or find. I can understand your frustration. :( – Brian Jul 27 '11 at 17:45
  • ya thanks aero, and i let you know if i make this with a good solution. – fargath Jul 28 '11 at 05:02
  • Please do, I would still like to see how this is done despite the fact that I haven't been able to figure it out. – Brian Jul 28 '11 at 17:48
  • @Brian: Wow, this is exactly what I've been trying to do as well. Just like you I'm trying to implement something to get swipe information with an overlay, while at the same time allowing the event to pass through my activity/service to the underlying view. Can't find jack on any possibilities though... – While-E Jan 31 '12 at 17:52
  • I am trying to implement the same thing, has anyone figured it out? – Reyansh Mishra Jan 17 '18 at 07:19
  • My original goal with this question was to implement a system overlay View (similar to Messenger ChatHeads). If this is what you're trying to achieve, take a look at this: https://gist.github.com/bjoernQ/6975256 – Brian Jan 17 '18 at 19:19

1 Answers1

6

You can't do exactly what you are asking. The input system is very careful to restrict what windows can receive what events; it is deliberately not like other systems such as Microsoft Windows where you can get involved in the low-level event dispatching and see everything going on. The only things allowed are:

  • A window that can receive all events that would go to it or any windows behind it (without allowing those events to be received by the windows behind it). This is called "touch modal".
  • A window that can receive all events within its rectangle without letting those go to windows behind it, but events outside of the rectangle are allowed to go to the appropriate window behind it without being seen by it. This is called "not touch modal".
  • A variation on "not touch modal" that allows it to be told about only the down event that happens outside of its window. It will not receive any other further events, however, and is delivered as a special action code: http://developer.android.com/reference/android/view/MotionEvent.html#ACTION_OUTSIDE

A further core rule of event dispatching to windows is that once a window is selected as the target of the touch event, it will continue to receive the event stream until the final up. Traditionally in Android this would apply to all further fingers of the touch gesture (it receives all fingers, no matter where they appear, until the last finger goes up). More recent versions of the platform allow you to modify this behavior to be multi-touch aware: http://developer.android.com/reference/android/view/WindowManager.LayoutParams.html#FLAG_SPLIT_TOUCH

So those are the tools you have in your tool box. You can build the things that are possible with them, but this is not intended to allow you to do any possible kind of interaction with the event system, so there are going to be limits.

hackbod
  • 90,665
  • 16
  • 140
  • 154