After releasing my product, I've started getting complaints that a certain screen was not working for some phones. After a lot of research and a lot of attempts to fix this issue, I found out that phones that are controlled by heat instead of pressure have this issue. Unfortunately I have only identified the problem. What is happening is the mouse up and mouse move motion events seem to be the same motion. Here is how my code works:
if(event.getAction()==MotionEvent.ACTION_MOVE)
{
lockdown=true;
}
else if(event.getAction()==MotionEvent.ACTION_UP && lockdown==false)
{
...
}
else if(event.getAction()==MotionEvent.ACTION_UP)
{
...
lockdown=false;
}
This code works on a pressure touch phone like mine just fine. It's designed that while the touch is dragged certain things will not function. I could really use some insight on how to fix this issue.
after an exhuasting night of going back and forth with my testers this is what ive come up with
// somewhere in the prior code a pressure sample is needed
public float dwnPressure
if(event.getAction()==MotionEvent.ACTION_DOWN)
{
dwnPressure=float(event.getPressure()*0.99)
}
back to the code where i had problems
if(event.getAction()==MotionEvent.ACTION_MOVE)
{
if(event.getPressure>dwnPressure)
{
lockdown=true;
}
}
else if(event.getAction()==MotionEvent.ACTION_UP && lockdown==false)
{
...
}
else if(event.getAction()==MotionEvent.ACTION_UP)
{
...
lockdown=false;
}
this change works perfectly on some of the phones that had the problem prior. Some phones there is a significant performance improvement but is a bit finicky. I figured id at least share my hard work even if it isn't 100%, since this question wasn't answered as fast as im used to on stackoverflow
Related
I have not been able to replicate this, but is anyone aware of what might cause the entire screen on an Android device to go light blue? It seems related to selecting a radio buttons and then scrolling. It happens on Nexus 5x with Android 8.
Here is what it looks like:
I have only heard of one other instance of this occurring. Could it be device specific? Strangely enough, once it happens it seem to stay this way, though the user says it is somewhat intermittent.
Update:
This only seems to happen on Android 8, if that helps anyone...
So, I eventually found the offending code. I verified this is only happening on Android 8 devices, maybe only Samsung? The offending code was:
mFormScrollView.setDescendantFocusability(ViewGroup.FOCUS_BEFORE_DESCENDANTS);
mFormScrollView.setFocusable(true);
mFormScrollView.setFocusableInTouchMode(true);
// Hide the keyboard when moving the screen up or down. This should only
// be an issue when
// on a text edit field. Also disable focus jump using
// "requestFocusFromTouch"
mFormScrollView.setOnTouchListener(new OnTouchListener() {
public boolean onTouch(View view, MotionEvent event) {
if (event.getAction() == MotionEvent.ACTION_UP || event.getAction() == MotionEvent.ACTION_DOWN) {
Utilities.hideKeyBoard(FormActivity.this, view);
}
// Keeps screen from jumping to nearest EditText
// view.requestFocusFromTouch();
return false;
}
});
The offending line is commented out - the view.requestFocusFromTouch() method, which was meant to keep the screen from auto jumping to the next text field when the keyboard was hidden and focus lost. On Android 8 this is not happening, but I need to verify with older versions.
My Cardboard-like VR-Viewer has a button that works by touching the screen. I created an app in Unity3D and this trigger mechanic first worked like a charm. Now all of a sudden, I think I only added an explosion particle effect, the touch function stopped working completely. I have tried things like removing the explosion from my scene again, but nothing seems to work. Another curious thing is, that I can't close the app in a normal way anymore (normally in VR Apps you have an X-Button in the top left of your screen, but clicking it doesn't do anything anymore too (It used to work!)). App still runs, doesn't crash, but no interaction is possible. I looked at the debug logs via adb - no errors there... App works like it used to when I start it inside the Unity Editor.
Did someone encounter a similar error or may have an idea about what the problem is? I'm using Unity Daydream Preview 5.4.2f2.
Edit: I forgot to mention I was using GvrViewer.Instance.Triggered to check if the screen was touched.
For all having the same problem, I worked around it by also checking if a touch just happened. In my Player : Monobehaviour I used:
void Update()
{
if (GvrViewer.Instance.Triggered ||
Input.touchCount > 0 && Input.touches[0].phase == TouchPhase.Ended)
{
//Do stuff.
}
}
Situation: hammer.js 2.0.4, jQuery 2.1 on a Cordova cross-platform mobile app. I was running into well-documented (for example) issues with delay of click events, so I thought I'd try hammer.js for this. It works beautifully on my iPad, but on my Android phone (Android v4.4) is dreadful: very slow to respond, and frequently misses taps entirely.
I implemented my own small tap detection (using mouseUp events) and it performs much better than Hammer.js on my Android (but terribly on my iPad).
So my question is: are there known issues for hammer.js on Android, or known workarounds? I'd really prefer not to conditionally use two different approaches based on platform, especially when there is no conceivable way for me to test all possible mobile platforms.
Example of the hammer.js tap code; nothing very interesting going on:
$(".menuitem").each( function(i, elem) {
var mc = new Hammer.Manager(elem);
mc.add(new Hammer.Tap());
mc.on("tap", action);
});
In addition there is a top-level swipe recognizer that covers the entire page:
var swipelistener = new Hammer($("body")[0], {
recognizers: [[Hammer.Swipe,{ direction: Hammer.DIRECTION_RIGHT }]]
});
swipelistener.on("swipe", swipeRight );
In total there will be fewer than two dozen elements responding to tap events, and no overlapping or nested elements. I thought it might have something to do with the swipe recognizer overlapping the tap recognizers, but removing the swipe listener didn't change the tap behavior at all.
You need to play with the settings of each recognizer.
hammertime.get('swipe').set({
direction: hammer.DIRECTION_ALL, threshold: 1, velocity: 0.1
});
This worked for me for swipe on 4.1.1
Would be really helpful if someone could write some example code for tap as I'm still fiddling with that.
Also, you don't need mc.add as the Manager by default has all the recognizers. You only need to use .add once you've manually removed (using mc.remove) one.
If you are unsure what settings any of the recognizers have, look on their website eg http://hammerjs.github.io/recognizer-swipe/ shows that I could set direction, threshold and velocity etc as per the code above.
As I can see you need to detect swipe on entire screen without any specific options. Maybe cordova-android-gestures (only for Android) helps you? This plugin "catches" gestures on total device surface. So, for detect swipes:
//check the platform
if (device.platform=="Android") {
MegaduckGestures.swiper(function(direction){
switch (direction) {
case 'rightSwipe':
//do your staff
break;
case 'leftSwipe':
//do your staff
break;
default: break;
}
});
}
else {
//use your iPad approach
}
And for handling tap on menu item:
$(".menuitem").each( function(i, elem) {
//check the platform
if (device.platform=="Android") {
MegaduckGestures.swiper(function(direction){
if (direction=='singleTap') {
//do your staff
}
});
}
else {
//use your iPad approach
}
});
I've tried both techniques in this answer to get a "dragging touch highlight" across elements in my PhoneGap App (testing on Android).
Here's my JSFiddle of the touchmove approach
$("td").bind("touchmove", function(evt){
var touch = evt.originalEvent.touches[0]
highlightHoveredObject(touch.clientX, touch.clientY);
});
Here's my JSFiddle of the vmousemove approach
$("#main").bind("vmousemove", function(evt){
$('.catch').each(function(index) {
if ( div_overlap($(this), evt.pageX, evt.pageY) ) {
$('.catch').not('eq('+index+')').removeClass('green');
if (!$(this).hasClass('green')) {
$(this).addClass('green');
}
}
});
});
Both work perfectly when emulating the app from desktop browser. Both work when viewing the JSFiddles from my Android tablet browser. But in the installed app on the tablet, it doesn't work. Instead of an updating highlight as I drag across the elements, all I get is a highlight on the first-touched event. The same for both methods.
Any ideas what's going on?
A comment on this question has an intriguing suggestion that "If you are running on android you also need to cancel the touchmove event to get new ones while touching. Don't ask me why...". Does that ring a bell, and if so, how would I "cancel the touchmove event to get new ones" with either of these approaches?
Alternately, has anyone successfully done a "dragging highlight" effect on a PhoneGap app, and would you care to share your technique?
I'm coding an app specifially designed for the blind and vision impaired and I'm trying to override the behavior of TextView when specific AccessibilityEvent are fired. The screen layout consists in 4 TextView arranged vertically that fill the screen. I just want to change the color of the background to reflect which one is "focused" so in my custom TextView I have this method
#Override
public boolean dispatchPopulateAccessibilityEvent(AccessibilityEvent event) {
System.out.println(event.toString());
if (event.getEventType() == AccessibilityEvent.TYPE_VIEW_HOVER_ENTER ||
event.getEventType() == AccessibilityEvent.TYPE_VIEW_ACCESSIBILITY_FOCUSED) {
this.setBackgroundColor(mColorArray[2]);
}
if (event.getEventType() == AccessibilityEvent.TYPE_VIEW_HOVER_EXIT ||
event.getEventType() == AccessibilityEvent.TYPE_VIEW_ACCESSIBILITY_FOCUS_CLEARED) {
this.setBackgroundColor(mColorArray[0]);
}
return super.dispatchPopulateAccessibilityEvent(event);
}
My problem is that AccessibilityEvent.TYPE_VIEW_ACCESSIBILITY_FOCUS_CLEARED is never fired. The three others fire correctly when using ExploreByTouch or swiping left/right up/down.
Any help would be greatly appreciated
If I understood correctly, the accepted answer from this link might solve your problem.
Be careful that if you set your target sdk to 17, there's some extra similar steps to do as described in the comments of the link.
Well I might have read this too fast, it's strange that some are fired and others are not.