The problem is that the velocity threshold to activate the fling
was set using pixels per second, so a better aproach would is to
use dp/s. So now there is a variable set in the dimes.xml file
called base_swift_detector_fling_release_velocity.
Test: Manually tested
Fix: 201252634
Change-Id: Ief14f25de136dead74f03cb24d2120b67900239e
WM is making changes which allows apps to maintain
their orientation independent of the orientation of
the foreground app. This allows recents to always start
in portrait even when the app currently running is in
landscape. This means we have to give the illusion of
a landscape oriented overview when user swipes up in
gesterual nav when launcher is started in portrait
configuration.
PagedOrientationHandler abstracts all coordinate specific
logic from Paged/RecentsView primarily, but also all
other dynamic calculations throughout launcher.
PagedViewOrientationState is the single point of exposure
to other classes that depend on those changes. The goal
is to also minimize holding state to allow for default
implementations of PagedOrientationHandler for all the
3p/Fallback classes. PagedViewOrientationState also
holds other data around rotation that isn't
specifically tied to view logic.
The fake landscape overview can be toggled with:
adb shell settings put global forced_rotation [0/1]
Fixes: 146176182
Change-Id: I65d8d4e9f92b93931cbe0053ccaf0cda8d2ffd6c
There's a lot of resistance, but feels better than nothing
responding to your movement.
Bug: 143361609
Change-Id: I9d7e06279ebdbaa0317909ce96d6f001dbe9699a
Clients of BaseSwipeDetector are required to call finishedScrolling(),
which calls setState(IDLE). An obvious place to call this is in
onDragEnd(), which itself is called from a setState(SETTLING). If the
client does this, then the SETTLING state actually clobbers the IDLE
state, leading to undefined behavior. The reason we don't see this in
practice is because we usually call finishedScrolling() after an
animation from onDragEnd() instead of calling it immediately.
To fix this, we add a simple queue such that any calls to setState()
while one is in progress have to wait and are executed in turn. This
ensures we get all the proper state callbacks and end in the correct
one.
Also fix an incorrect call in AbstractStateChangeTouchController which
was masked by this bug. We were calling setState(IDLE) in onDragStart(),
which only worked because the original setState(DRAGGING) incorrectly
clobbered this. Now we only setState(IDLE) (via finishedScrolling())
when we fully clear the state, i.e. when the interaction is finished.
Test: added testInterleavedSetState
Bug: 141939911
Change-Id: Iae630ee7101921b57a85d40646468cf19f59b674
Existing clients now use the SingleAxisSwipeDetector subclass. A
followup CL will add BothAxesSwipeDetector, whose first client will be
the quick switch from home controller.
Bug: 126596417
Change-Id: I54c71088cfe99ff28cdc719a1eb7a7d06ac95d2d
It is now organized as follows:
- private constants
- public constants
- private final fields
- private variable fields
- constructors
- public methods
- private methods
- public interface/abstract class
This is intended to be a functional no-op.
Bug: 141939911
Change-Id: Iad5a9b3b73b35641f8a4f1d52ada6adef3825c47
Tested: Built and sanity checked manually.
Previously left was considered positive and right considered negative.
Now left and down are negative, and right and up are positive.
For RTL, left is positive and right is negative.
Change-Id: Ia31e8c687c8c2716fc632b2fe88aa8955b934bce
> Refactoring SwipeDetector to both allow vertical and horizontal swipes
> Using SwipeDetector and common overscroll effect for notification swipes
instead of a separate logic
Change-Id: Ib706ee179811ade59ddb68184e1c202365d147c4
