I develop a simple Android app, and I want to know how many fingers is touching the screen. It's simple with OnTouch event but this solution doesn't work if the user touch the keyboard software (for security and privacy issues)
I have tried to use a specific overlay like this : Creating a system overlay window
It work, the onTouch event is called everytime, everywhere, but the overlay block all the touch event and the app is unusable (touch button, write with the keyboard software, all interaction doesn't works)
How can I receive touch events on my overlay and on my others view behind this overlay ?
Related
I'm currently trying to make a utility overlay similar to Facebook Messenger chatheads in which you can move the view around the screen. When you click the view, it expands into a more complex layout. However, the problem is if I set the LayoutParams' flag to WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE, the apps behind receive the touch events while my overlay doesn't receive any touch events at all. But if I remove that flag, the overlay receives the touches but it blocks the touch. Meaning I can't even open the app drawer since the touches are being blocked.
I am using a fullscreen transparent Activity as background so I can move my overlay "widget" around it.
Is there any way I can make it so that it doesn't block touch events. Even if I don't set it to fullscreen, as long as I don't have the FLAG_NOT_TOUCHABLE flag, my overlay completely blocks all screen touches.
Please Remove this flag
WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE
with this flag
WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE
see this link https://medium.com/#kevalpatel2106/create-chat-heads-like-facebook-messenger-32f7f1a62064
The past few months I've been on a mission to implement widget support in my home screen replacement for Android, and it's proving rather difficult. I can now add and remove widgets to/from the home screen, but they can't be resized or moved yet. Currently what I'm trying to achieve is to resize them. To do this I have every widget embedded in a View, over which I put an overlay to make sure the touch events don't get caught by the widget underneath it (which caused trouble in past attempts).
What I have now is this layout for the container; http://www.hastebin.com/uwocaxukel.xml
The widget is put in the FrameLayout with id widgetContainer. As you can see in the screenshot below there is an orange dot in the middle of every border.
Now what I've always tried to do so far is catch touch events, figure out whether the user is trying to drag one of the borders (MotionEvent.ACTION_MOVE), and if he is, change the required properties in the LayoutParams object and call this.requestLayout () on the view. This is finicky, and less than ideal. Very often the touch events would stop registering because the user dragged faster than the view could refresh = user is no longer on the view which is listening for touch events, or the border would be too thin to hit.
So far it's all been very finicky. But there are other apps which seem to do this pretty much perfectly. Is there a library, a class I've overlooked, or something else I can use to achieve my goal?
This is an example of something that kind of worked, but was very finicky and just not remotely user-friendly; https://github.com/RobinJ1995/be.robinj.ubuntu/blob/869d48af2e7a3d8f0332f84edd2a8cd28564424a/UbuntuLauncher/app/src/main/java/be/robinj/ubuntu/widgets/WidgetHostView.java#L75
In my Android app I have a gallery which contains some TextViews. I realized that some users don't understand that they can scroll that gallery although the previous and next TextViews are partially visible. So I put an ImageView with a horizontal arrow under the gallery.
Now the users try to drag the arrow. Is it possible to redirect the touch event from the ImageView to the gallery so that dragging it would scroll the gallery?
Thanks in advance,
Fri
The simplest thing (if you don't mind scrolling one item at a time) is to detect the direction of the touch event on the arrow and then dispatchSetSelected(boolean selected) on the gallery... I believe that will work. after the user does that once, they will probably intuit that they can then just drag the gallery. Of course if you want to measure the touch event speed and do the calculation for how far to scroll based on that, you can do that too... but that seems like a lot of unnecessary trouble.
If i read correctly, the mouse and keyboard listeners are intended to capture movement within an application. what I want to do is capture movement system wide.
Mouse movement/clicks and button presses.
Ideally i would like a manner of capturing this movement and being able to replay it by passing appropriate commands to the robot class. Does this seem reasonable, or am i going about this all wrong?
It is possible if you create transparent full screen window and capture events on it.
To replay the events use class java.awt.Robot.
Use this resource for more info how to create transparent window:
http://java.sun.com/developer/technicalArticles/GUI/translucent_shaped_windows/
I have to develop a touch screen application based on swing for the GUI part.
The application will have to be displayed on different screen, one 15" 4/3 screen and one 20".
What kind of layout stategy should i go for, to keep the same proportion in my components from one screen to another ?
The application will have a kind of status bar at the top displaying some information coming from a server, a menu bar at the bottom, the main central part of the application will display graphs, and on the right an area that will display the same information as the graphs, but in digital format. Buttons from the menu bar and labels in display/status bar have to be quite big as the users that will play with the screen may wear gloves...
Thanks you for help.
any specific layout manager is not gonna do the trick....Handling the window size is not a problem as that can be taken care of (use ToolKit for that). Only problem is that u gotta make sure that, the component sizes are not fixed, cos when screen size changes that gotta change as well. This is a peculiar problem, lot of trail and testing may be required.