Warning on setOnTouchListener() of all Views - android

Recently after updating Android Studio to 3.0 and everything was working fine, but from today it shows warning on every setOnTouchListener() of any view also the logic inside it dose not seem to work properly anymore, i don't exactly remember if i have updated any library.
Warning message:
Custom View 'NestedScrollView' has setOnTouchListener called on it but does not override performClick
After searching on Stackoverflow i implemented following solution but it did not remove the warning.
switch (motionEvent.getAction()) {
case MotionEvent.ACTION_DOWN:
//some code....
break;
case MotionEvent.ACTION_UP:
view.performClick();
break;
default:
break;
}
Any idea why this is happening?

Too late with an answer, but for others who is running into the same issue. Actually, the solution is given in the warning text: you need to override performClick() method in your class. Just put this code in it:
#Override
public boolean performClick() {
return super.performClick();
}

Related

onClick() does not work after appying dexguard. Is there any way to solve this?

i am using dexguard to secure my app. Recently i updated the dexgaurd version
from 8.0.1 to 8.2.15. Earlier everything is working fine before the update. But with the version 8.2.15 when i apply dexguard, onCick method does not works in one of fragment SettingsFragment, for all of the other Fragments it works fine. However the code and method of implementing onClick() is same for all Fragments. But for SettingsFragment it's not working. Please help.
Here is my onClick method in SettingsFragment
View.OnClickListener onClickListener = new View.OnClickListener() {
#Override
public void onClick(View view) {
switch (view.getId()) {
case R.id.relSignOut:
mCallback.doSignOut();
break;
// case R.id.relEditProfile:
// loadManageProfile();
// break;
case R.id.btn_edit_profile:
loadManageProfile();
break;
case R.id.relDynamicFxRate:
parent.startSetExchangeAlertActivity();
break;
}
}
};
Thanks in Advance
You should exclude obfuscation of onClick methods like this:
-keepclassmembers class * {
public void onClick (android.view.View);
}
(Converting my comment to answer)
Please kick off the switch statement and replace it with if-else. May seem bit unscientific and illogical, but I worked for me many times.
I don't know if it's a possible bug in the compiler or in Android or not, but sometimes rejecting switch statement only doesn't help. Then I've to replace view.getId() with view.getPosition() and check by order or something like this to make it work anyway.
From T.Neidhart's comment: The reason it fails is probably due to resource optimization which remaps resource IDs. Normally these remapped resource IDs get replaced everywhere in the code, but it might go wrong in case of switch statements. You can disable resource optimization like that: -optimizations resource/compaction –

Missing focus cursor on input field hybrid android cordova webview

We have android hybrid app with Cordova where are creating custom inappbrowser with cordova webview to show the content. In Android lollipop devices, when user selects input field, keyboard pops up and user can enter test but there is no curser in the input field. This is not happening in pre lollipop. I tried below options, also this happens sporadically, i am getting focus sometimes but most times it is not working
inAppWebView.getSettings().setJavaScriptEnabled(true);
inAppWebView.requestFocus(View.FOCUSABLES_TOUCH_MODE);
or
inAppWebView.requestFocus(View.FOCUSABLES_ALL);
or
inAppWebView.requestFocus(View.FOCUS_DOWN);
or
inAppWebView.setOnTouchListener(new View.OnTouchListener() {
#Override
public boolean onTouch(View v, MotionEvent event) {
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN:
case MotionEvent.ACTION_UP:
if (!v.hasFocus()) {
v.requestFocus();
}
break;
}
return false;
}
});
Any suggestions?
Though now probably seomewhat outdated, the solution can be found at https://issues.apache.org/jira/browse/CB-11248
Basically, you need to change onPageFinished to
public void onPageFinished(WebView view, String url) {
super.onPageFinished(view, url);
view.clearFocus();
view.requestFocus();
}
After quite some thinking and effort looking through the repo history, we finally nailed it down & fixed it.
While initializing a plugin we did perform some javascript on the WebView. We we're using 'evaluateJavascript' to perform the javascript (this does work on Lollipop, not on KitKat btw), but that somehow had the side-effect of making the caret disappear. After using 'loadUrl' instead, it did work again.
In the javascript we did add a custom attribute (HD_APP) to the window, so nothing that should cause such a side effect. As you can see in the screenshot, the input was no longer identified with ":focus" by css.
Hope this helps..
The thing that caused the issue for me is that I called evaluateJavascript before I had any page loaded.
After I made sure that my page was ready for JS before sending any, the issue disappeared.

Android 4.4 WebView issue with requestFocusFromTouch

I am seeing some unexpected behavior when using a WebView in Android 4.4 (build target 18). One one page in particular we have some edit text fields, and to get the soft keyboard to pop up appropriately, we had to use a code snippet similar to the ones described here:
https://code.google.com/p/android/issues/detail?id=7189
webview.setOnTouchListener(new View.OnTouchListener() {
#Override
public boolean onTouch(View v, MotionEvent event) {
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN:
case MotionEvent.ACTION_UP:
if (!v.hasFocus()) {
v.requestFocus();
}
break;
}
return false;
}
});
This worked as expected up through version 4.3, but beginning with 4.4 the code above caused an undesired effect of having the content of the webview snap/scroll back to the top of the page on the completion of a touch - after scrolling down the page.
Has anyone else experienced this new behavior - or figured out a workaround? The only thing I have come up with so far would be to subclass a webview that allows the edits (so the code above can be removed from read-only pages that now have the scrolling issue). Of course, if a page both scrolls and has edit fields, this would not work.
Thanks in advance!

Android OnLongClickListener strange / unreliable behaviour

I'm currently fighting against the OnLongClickListener on Android Api Lvl 8.
Take this code:
this.webView.setOnLongClickListener(new OnLongClickListener() {
#Override
public boolean onLongClick(View v) {
System.out.println("long click");
return true;
}
});
It works perfectly. I can press anywhere on the WebView and the event triggers every time.
Now take a look at this one:
this.webView.setOnLongClickListener(new OnLongClickListener() {
#Override
public boolean onLongClick(View v) {
final EditText editText = getUrlTextField();
switch (editText.getVisibility()) {
case View.VISIBLE:
editText.setVisibility(View.GONE);
return true;
case View.GONE:
editText.setVisibility(View.VISIBLE);
return true;
default:
return false;
}
}
});
Assuming the URL EditText components is currently visible, it gets gone from the display and should be shown again when another long click event is triggered.
But if you run this, the event just works once (!) when one performs a long click on any position on the WebView. To make things complicated, the long click works again when it is performed on a link on the website...
Can anyone explain if it is a bug in the sdk and/or if there is a mistake in my thinking how the OnLongClickListener is working?!? :/
EDIT:
I've run now several different scenarios on a Nexus One and come to following conclussion: Changing the layout on runtime more or less kills the OnLongClickListener... I haven't found a way to get it work reliably at all...
I would really appreciate if anyone could give me a hint... I'm at my wits end :(
Personnally, I ended up by re-setting the listener after each relayout.
I've run into this issue as well. It seems that if the view layout changes in a way that child view bounds need to be modified (i.e. TextView is wrap_content width and you set its text to something longer/shorter than it was before), views in the hierarchy will have their onStartTemporaryDetach method called (most likely due to a layout pass, although I haven't dug deep enough to find out for sure). If you look at the source for View that onStartTemporaryDetach ultimately unsets the pressed state of the view.
Changing the views in your layout that will be updated periodically to have bounds that will not change regardless of the value you set, will fix the issue. Although, that is still not awesome.

Android: ScrollView 'setOnScrollListener' (like ListView)

I want to do something when the user has scrolled >90% down, so I thought I could just add a onScrollListener like I would in a ListView. Unfortunatly, ScrollView doesn't seem to have a similar method. Is there any way I can do what I want; getting a notification when the user scrolls approx 90% down?
Thanks,
Erik
This is what I end up doing to know if the user was interacting with my ScrollView or not:
findViewById(R.id.scrollview).setOnTouchListener(new View.OnTouchListener() {
#Override
public boolean onTouch(View v, MotionEvent event) {
switch (event.getAction()) {
case MotionEvent.ACTION_SCROLL:
case MotionEvent.ACTION_MOVE:
setScrollState(OnScrollListener.SCROLL_STATE_FLING);
break;
case MotionEvent.ACTION_DOWN:
setScrollState(OnScrollListener.SCROLL_STATE_TOUCH_SCROLL);
break;
case MotionEvent.ACTION_CANCEL:
case MotionEvent.ACTION_UP:
setScrollState(OnScrollListener.SCROLL_STATE_IDLE);
break;
}
return false;
}
});
You can try extending ScrollView and overriding View#onScrollChanged and the doing your checks there. You have to extend ScrollView since onScrollChanged is a protected method.
You can implement an onTouchListener and use the getScrollX and getScrollY callbacks of the view
If you want a scrolling view that works like a listview, may I suggest trying out a horizontal listView library:
https://github.com/sephiroth74/HorizontalVariableListView
it's based on the original ListView, and it works very well.
it has its OnScrollListener , and even though the website says it supports Android 2.3 and above, I think it should work from API 7 and above (and with some tweaks even older).

Categories

Resources