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
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
This adjust various paths through InputMethodManager so that the flow
in switching focus from one application to another is cleaner, resulting
in less work being done, resulting in it being able to happen quicker.
Some of the changes here avoid doing stuff when not needed, such as when
we are told to unbind but are not currently the active input. A big part
is also a change to the flow when a window receives input. Previously
this would first do a checkFocus() which would tell the input method to
switch focus to whatever view has focus in the window, followed by the
windowGainedFocus() call telling it the window had gained focus. This
would result in extra work because the input method service would first
handle the focus switch, seeing the IME is currently displayed, so the IME
would remain up and reset its focus to the new view. The app would
immediately then tell it about the window, causing the service to find out
the IME should be hidden and telling the IME, but the IME couldn't hide
itself until it had first take care of switching its input.
There is the definite potential of this breaking IME showing/hiding in
cases depending on the order things may be relying on them to happen. I
haven't seen any problems with a brief trip through the UI.
Change-Id: I8494cbd6e19e2ab6db03f2463d9906680dda058b
Commit for issue http://code.google.com/p/android/issues/detail?id=24388
[Problem]
TimePicker doesn't call handler's onTimeChanged when AM/PM changed on
ICS althou it does on Gingerbread.
[Solution]
Call onTimeChanged as like as Hour/Minutes does.
Change-Id: I9911c351874168001b69c186f012836fc51285f5
Signed-off-by: SeongJae Park <sj38.park@gmail.com>
