When used in a `ViewPager`, fragments that are present on the adjacent,
cached pages will receive context selection dispatches which, depending
on your fragment contents, can be difficult to determine whether or not
the event truly originated from your view.
By using the visible hint we restrict dispatching to only those fragments
which are marked as being visible. Since the fragment pager adapter
updates this setting properly most implementations will be afforded this
fix without any change required. If the user is implementing their own
adapter they likely already understand the implications of these cached
fragments and the reponsibility for updating the boolean falls to them.
Mirrors support library change Ie6a72c1c82c2784774373670007b6f5948fe16da
Change-Id: I1bc6f74e26660ef4a3c20419c077e37992412e94
If a fragment's saved view state is null and the user
visible hint is true then the `result` bundle will have
never been initialized to a value resulting in a
`NullPointerException`.
Mirrors support library change I8ba585bc6b9298841490d64bc22a8219cd261adb.
Change-Id: Iabd5ac293d2ece3771da9ef257479eca0dcd523c
Merged in http://review.cyanogenmod.com/#change,14109
Fixing a bug that when an app is dismissed or loaded that changes
the current active audio stream, if the volume overlay is visible during the swap,
if you adjust the volume (with hard keys) after the stream has changed while
the panel is still visible, the wrong panel (view) is still visible on-top of the
one that is being adjusted.
A good way to replicate this is to
Open the Phone APP
Go to the Keypad Screen
Adjust the volume (not the icon on the overlay)
While the volume is visible Hit the HOME hard key
Before the volume dissapears, adjust the volume with hard keys
You will hear and feel the volume adjusting, but the overlay will not update.
Change-Id: Ied50ed83b153234cff82c282e3fd76ed671b420b
Now the adapter reports the correct type count and type for group and child
views by overriding the respective methods from the base class. Each group
view has two types, one for expanded views, one for collapsed views. Each
child view has two types, one for the last view within a group, one for the
other views within a group.
Change-Id: I117b2c0f7e98fb7fe2fdd35c15f7d1f9dc06674f
Signed-off-by: Georg Hofmann <georg.hofmann@gmail.com>
The findNewActiveIndex method may return -1.
So, the code should check case of -1 before event.getPointerId
and if index0 is -1, gesture should be ended immediately.
Change-Id: I4aae5c84e3db61d10b0bfcfa7bfa6b9115231a52
Non touchscreen devices such as Google TV require the keypad
navigation to properly move the focus among widgets.
The Gallery is misshandling the keypress event and avoiding
the focus from going to other widgets on it's sides upon
keypress even after the user has reached it's first and
last items.
Change-Id: If32ee57e8513cac692deb161e1941d6cc85e3188
Signed-off-by: David Sobreira Marques <dpsmarques@gmail.com>
Commit for issue at
http://code.google.com/p/android/issues/detail?id=25916&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars&start=100
[Problem]
Dropdown popup of Spinner become wider than device's width if selected
item's content's width is larger than device's screen.
[Cause]
Spinner just display dropdown popup with measured content's width
although measured content's width is wider than device's screen.
[Solution]
If calculated content's width is wider than device's screen, set width
of spinner's dropdown popup to fit on device.
Change-Id: I3276e5ff745c6ba1437c07fc55645d6b53fef89a
Signed-off-by: SeongJae Park <sj38.park@gmail.com>
1. The NumberPicker was showing the IME if the input field
gets focus and hiding it when the the arrows are pressed.
The leads to a nasty behavior when the input is the first
focusable and the uses presser an arrow button. In such
a case the IME shows and hides on every arrow press pushing
the window content up and down - this looks pretty ugly.
Now the IME is show on double tap of the input field.
2. The NumberPicker input now by default has an IME action
done, hence after editing it the IME goes away.
3. The NumberPicker input now clears focus when it gets
IME action done, so the last picker in a sequence
does not show selection which is focus driven.
4. NumberPicker was incorrectly detecting double tap to
begin edit and it was possble to start edit on singe tap
if the user has double tapped before to start an edit.
Now double tap detection is using the double tap timeout
correctly.
bug:6071977
Change-Id: I0ff5a491064e51663b3abec675d839d0a65b986a
My previous change to speed up the time the IME is dismissed was
fundamentally flawed. That change basically switched the order
the application called the input method manager service from doing
startInput() and then windowGainedFocus(), to first windowGainedFocus()
and then startInput().
The problem is that the service relies on startInput() being done
first, since this is the mechanism to set up the new input focus,
and windowGainedFocus() is just updating the IME visibility state
after that is done. However, by doing the startInput() first, that
means in the case where we are going to hide the IME we must first
wait for the IME to re-initialize editing on whatever input has
focus in the new window.
To address this, the change here tries to find a half-way point
between the two. We now do startInput() after windowGainedFocus()
only when this will result in the window being hidden.
It is not as easy as that, though, because these are calls on to
the system service from the application. So being able to do that
meant a fair amount of re-arranging of this part of the protocol
with the service. Now windowGainedFocus() is called with all of
the information also needed for startInput(), and takes care of
performing both operations. The client-side code is correspondingly
rearranged so that the guts of it where startInput() is called can
instead call the windowGainedFocus() entry if appropriate.
So... in theory this is safer than the previous change, since it
should not be impacting the behavior as much. In practice, however,
we are touching and re-arranging a lot more code, and "should" is
not a promise.
Change-Id: Icb58bef75ef4bf9979f3e2ba88cea20db2e2c3fb
I had submitted the patch about this issue at
https://android-review.googlesource.com/#/c/20438/ before. But it
has never been included in any version.
In the latest implementation, touchSlop is a configurable value
which is declared in config.xml for each device. First of all,
the problem is that BiggerTouchSlop is not scalable and variable
value according to a configured touchSlop.
I don't think that there should be a new api in ViewConfiguration
for this. Because the bigger touch slop is a local threshold value
in GestureDetector. The only thing to be satisfied is that the
value should be bigger than configured touch slop and should not
be over double touch slop.
Change-Id: I2c6662400fcffb4a7192ede4ac8da08559aa7948
