I have faced with very strange behavior in listview android.
I puts several ViewGroups(actually RelativeLayout) into a ListView as
its item. The ViewGroup has TextViews and ImageViews.
I registered OnClickListener on the ImageViews in the ViewGroup.
When I tabbed the ImageViews, The OnClickListener is called in delayed
(It was over than 2 seconds.). Sometimes, the OnClickListener is
never called unless I tabbed another view in a device.
In that case, the method is called multiply and in burst.
I think it seems to be related to focus. But I can not find a solution.
This strange behavior occurs in only Galaxy S3. It works fine in Galaxy S4.
Meanwhile, OnTouchListener works fine even in the case in Galaxy S3.
It means that a touch event arrives the View in the ViewGroup. I can not
understand why the OnClickListener is called delayed or in out of focus
even it receives touch events in OnTouchListeners.
12-27 23:31:51.203: I/debug(19534): myimageview touch event!!!
12-27 23:31:51.268: I/debug(19534): myimageview touch event!!!
12-27 23:31:51.278: I/debug(19534): myimageview touch event!!!
12-27 23:31:51.278: I/debug(19534): myimageview touch event!!!
12-27 23:31:53.333: D/AbsListView(19534): unregisterIRListener() is called
12-27 23:31:53.433: D/AbsListView(19534): unregisterIRListener() is called
12-27 23:31:53.518: I/debug(19534): dofollow clicked!!!222222222222
In above log, you can see 4 times touch event. But OnClickListener is
call after 2 seconds from last touch event.
UPDATE:
I did reset my device(GalaxyS3) by tabbing reset button which is shown when
I pressed long a power button of my device. And I tested it again. But,
It was same result.
However, Today, I powered off my device by seperation of a battery.
And powered on. It works fine without any source code changes!.
Is there any difference between the reset by power-off and software-reset?
Anyway, It words good this time. I will report it again if the
behavior occurs again next time.
UPDATE:
I figure out that this issue is happened in all android devices. I guess
that it is related to drawing cache of ListView. I guess that ListView
makes drawing caches for its child views in sometimes. I checked it out
by enabling showing boundaries of all views in android system setting.
After enabling showing boundaries, I navigates several items in ListView.
Then, I saw some view of child of ListView does not have its child
layout boundary. It means that it is just image not a view.
In that time, All controls(including ImageView) does not work.
After just little scrolling of the ListView, The queued click events are
flushed to a child control at that time. It means that scrolling of ListView
triggers changing of the cache image with the real view.
I can not find a way turning off this drawing cache in ListView.
UPDATE:
I solved this issue. I feeds views created statically by myself instead of
using convertView in getView method. In this case, something wrong is
happend inside of ListView. I changed it to use convertView always.
Related
I am creating an android app in which I need to track the pointer on a couple of elements that are inside a GridView. The problem is that if the pointer moves a little bit up or down, the GridView enters some kind of scrolling mode (even if it fits easily inside the screen), so the events do not reach the child views anymore. Is there anything I can do to prevent this behaviour and keep tracking the pointer inside those children?
So to clarify: the pointer tracking works neatly, until the vertical difference between starting and current position becomes to large. At that moment, no touch event reaches my child elements anymore, and the gridView starts scrolling if it does not fit inside the screen.
I found a solution at another StackOverflow post. Simply put, the solution is to create a class that extends the GridView and overrides the onInterceptTouchEvent method, which must return false when scrolling (or any other form of interception) has to be prohibited.
I have this bizarre behaviour when calling invalidate.
I have made a custom viewgroup containing a bunch of imageviews.
I set up a onTouch listener with the on touch method to scroll the view.
I know all the code is correct in terms of distances to scroll etc. by using logcat.
Now, for some reason the onLayout method is not being called after I call this.invalidate(). When I try to scroll, nothing changes on the screen. However, after I pause the activity and resume it, the screen will have shifted by the amount I scrolled.
I am not blocking the UI thread because there is nothing to block it with. In any case, I have tried postInvalidate() and nothing has worked.
Anybody have any bloody idea what's going on?
invalidate() does not relayout the view, it only causes the view to be redrawn. If you want to relayout it (which will invoke onLayout()) you also have to make a call to requestLayout().
We have an app that's rather complex with a fairly deep view hierarchy. It works fine on every device between 4.x and 4.4.2, however in 4.4.3 weird stuff starts happening. Sometimes (read most of the time) when we show a page with a horizontal scrollview and a viewpager we can't scroll the horizontal scrollview and the viewpager doesn't measure new views. I've chased the bug down and the horizontal scrollview seems to scroll fine, but the call we do to requestLayout sees that isLayoutRequested on getParent is already true, and stops doing anything (and therefor doesn't redraw).
When this happens I've set a breakpoint on the base "View" class onLayout function. The debugger does stop there when I draw up the initial layout, but when I end up in a state where it's broken triggering requestLayout never triggers a onLayout in ANY view.
In what scenarios can you call requestLayout on a view and never have a debugger trigger on View.OnLayout? How can I debug this without having the 4.4.3 sources so I can see whats going on deeper in the stack?
In my application I have a custom gallery which shows some LinearLayouts (custom components to be precise, but that doesn't matter I think).
What I want is that if I scroll in between to items that it stays there and doesn't select the closest one (as it does by default).
If I override the onTouchEvent and in the case of an ACTION_UP ignore the event I get the desired result, BUT then I lose the onFling (the scrolling doesn't continue but stops immediately).
Then I think I'll have problems with my indicator of the position as I will probably lose the OnItemSelected handle, but I'm not sure of that (of course).
every suggestion is welcome.
Doubtless this is caused by my decidedly unorthodox layout - I have buttons in a LinearLayout in an Activity which is placed by an ActivityGroup into a Gallery. The ActivityGroup is also the adapter implementation and the over-all effect is full-screen sliding, snapping panels.
This is working (a treat, actually) except that a touch event on the parent layout puts all the buttons into the pressed state (and any release removes the state). A touch on an individual button is only delivered to that button.
The buttons are not receiving any events, they're only changing state.
Have I done something obviously wrong? Is this a known bug and is there a work-around?
Any insights would be very much appreciated.
As obscure as this problem is its solution may be of use to someone else, so I'll answer my own question.
As mentioned, I'm (mis)using the Gallery to provide a slidey-panel à la iPhone. I do this by returning the top level window of an Activity when the Gallery asks its Adapter implementation for a view.
Typical use of a Gallery would result in small Views to which it's desirable for the press event to be applied - it's more like a button then it is a panel. Our use means that there are many buttons in a single view and we don't want the press event to ever be applied globally.
So the work-around was very easy. I extended Gallery and deliberately broke pointToPosition(int x, int y), returning INVALID_POSITION every time. The Gallery still does everything else expected of it but skips trying to apply the touch down event to any elements but itself (to prepare itself to scroll or fling).
I hope this is of value to someone.