- Added side hints back
- Only scale down icons if spring-loaded
- Only show App Info drop target if spring-loaded
Change-Id: I4b0dddccbe0e80b7ceb6b7266fc527f757744148
The problem was due to a race condition between removing a prebound
widget view from the drag layer and adding the same view to the
workspace upon dropping it; if you let go of the widget immediately
after picking it up, the latter happened before the former.
Specifically, the flow was: long-click a widget --> drop --> remove
the view from the drag layer if it's not null (it is, so nothing
happens) --> the view is finally bound/inflated and added to the drag
layer --> add the view to the workspace --> already has a parent.
There are actually 2 problems here: one is that the bind/inflate is
asynchronous, and can therefore happen after dropping the widget view
being inflated, and the other is that the view is added to the
workspace even though the transition has barely started (we usually
ignore drops if the transition is less than half complete). It turns
out that this second problem was also due to a race condition, this
time between dropping a widget or app onto the workspace and calling
LauncherStateTransitionAnimation.dispatchOnLauncherTransitionStart().
If the drop happened before the dispatch, as in the case of the
crash, then the drop was accepted because the transition progress was
still 1.0 from the previous transition.
I fixed the first problem by removing the drag layer widget view
in Launcher where it is potentially used instead of Workspace. And I
fixed the second problem by setting mTransitionProgress to 0 in
Workspace.onLauncherTransitionPrepare().
I also added some debugging logs.
Bug: 23896857
Change-Id: I66944e6d3f23b70dea15f7fb01af0763a1bfcbda
Using itemId instead of generating a new id for each item. This is because
if the process gets killed, View.generateId will get reset but we will still
receive the generated item id map in onRestoreInstance. This will cause
conflicts with newly generated item ids.
We wrap all the generated homescreen views inside a single sparse array. This
ensures that we do not cause any conflict with dynamically generated views in
other parts of the UI.
Bug: 16840760
Change-Id: I6fe69c2e1dd463402f51222715fae31b9d4dd240
1) Use a different content description for temporary new page
2) Use different accessibility description for add widget toast
3) Announce when an item is deleted
4) Announce when hovering over a drop target
5) Announce state during drag-n-drop and widget resize (similar to seekbar)
Bug: 23573321, 24057944
Change-Id: Icabb317625e70c78e11c0b4f99b9339172d93594
The search for this page starts at the current one and
continues to the right (on LTR) until a page is found that
can accomodate the widget, taking possible resizing and
reordering into account.
Bug: 11338870
Change-Id: I2e9a310eb8f74024dca9150f55a525e1309c2f07
Since power save mode (introduced in Lollipop, also known as battery saver)
disables animations, the ReorderPreviewAnimation looks bad - instead of
displaced folders subtly and smoothly moving up and down, they violently jump
between up and down positions in rapid succession. Setting the animation to not
repeat in this case avoids this issue.
Bug: 23675090
Change-Id: I8149610af75e7023dca28a942b3447228083cd33
(cherry picked from commit 9e0702f4af)
Since power save mode (introduced in Lollipop, also known as battery saver)
disables animations, the ReorderPreviewAnimation looks bad - instead of
displaced folders subtly and smoothly moving up and down, they violently jump
between up and down positions in rapid succession. Setting the animation to not
repeat in this case avoids this issue.
Bug: 23675090
Change-Id: I8149610af75e7023dca28a942b3447228083cd33
Using itemId instead of generating a new id for each item. This is because
if the process gets killed, View.generateId will get reset but we will still
receive the generated item id map in onRestoreInstance. This will cause
conflicts with newly generated item ids.
We wrap all the generated homescreen views inside a single sparse array. This
ensures that we do not cause any conflict with dynamically generated views in
other parts of the UI.
Change-Id: I6fe69c2e1dd463402f51222715fae31b9d4dd240
This will enable an easier migration to the new M APIs for identifying
button presses from stylus / other tools.
Bug: 20430722
Change-Id: I41cfa6eff8d76bb83cf1bdaf6623ec1092ed554c
This is per an earlier CR comment "we should probably move all this code to its own package (launcher3.dragndrop) in a separate cl".
I'm not moving DragSource because it's referred from gsa code.
Bug: 22609426
Change-Id: Ia7204dab99c0c395c66b77143a2d60411153f5f3
> Instead of resizing the rect for dragoutline in onDrow, store the resized rect itself
> Remove unnecessary inverse matrix calculation
Change-Id: If13c3c5aaecba5a1d3a4f5d39199ed82e9662c62
> Filtering the widget list and excluding widgets which dont fit the grid
> setting minSpans for the widget item when binding.
Bug: 22541314
Bug: 22559137
Change-Id: Ieda48b56c95bee0c7ec71dd691af7e23e2d43db6
> Using View property instead of strings to avoid extra reflection step
> Using ViewPropertyAnimator when several properties are being animated
Change-Id: I41625643b38b70bac11e2c81d18058ec878d73bd
- This is due to the TransitionDrawable which does not actually
start an animation until it is first drawn. This workaround
will just immediately reset the transition if it is not currently
visible instead of animating (which is actually deferred until
the next animation into overview mode).
Bug: 22414257
Change-Id: Id481303d0c99a20c1d16396c024ab50303f45576
> Changing dragObject to ItemInfo
> Removing dropPos which is always null
> Removing requiresDbUpdate which is only used in CellLayout
Change-Id: I753ddaae0880c8a9bfee5a1266095ff34610284a
This updates almost(*) all locations that use a long press listener to
also set a custom touch listener that recognizes the stylus button press
action.
The stylus button press action is: when a stylus touches a view while the
primary stylus button is pressed which may occur on a DOWN or MOVE event.
*The location this is *not* enabled for is: Longpress to enter "overview"
mode -- this isn't really a selection or drag n drop action; it is also
easy to accidentally do this while using the stylus gesture to drag n drop
items which is not an ideal interaction. Also not set for the "cling" that
demonstrates this.
Bug: 20430722
Change-Id: I9343f143261a7b4fada9afca28b8a11a60dbecca
> Make package-private and @Thunk all private methods and constructors accessed from inner classes.
Change-Id: Ie5913860a0c33e48e9bf68f9b5b1699f64c2f174
> Adding empty page synchronously, instead of waiting for a frame
> Changing launcher state from widgets screen in the same frame, similar to all apps
> Removing DragEnforcer, and moving that logic in side the workspace, disabled by a flag
> Using first page to get page bounds in drag layer, as last page may not have been measured
Change-Id: I172ba4e5ce44648ac55402d49994542c6e10f101
-> Pulling out the parts of device profile which can (and need to be)
initialized and accessed without access to an Activity context,
ie. the invariant bits.
-> The invariant bits are stored in InvariantDeviceProfile which is
initialized statically from LauncherAppState.
-> The DeviceProfile contains the Activity context-dependent bits,
and we will create one of these for each Activity instance, and
this instance is accessed through the Launcher activity.
-> It's possible that we can continue to refactor this such that
all appropriate dimensions can be computed without an Activity
context (by only specifying orientation). This would be an
extension of this CL and allow us to know exactly how launcher
will look in both orientations from any context.
Sets the stage for some improvements around b/19514688
Change-Id: Ia7daccf14d8ca2b9cb340b8780b684769e9f1892
> Removing obsolete progrard rules
> Removing BackgroundAlphaMultiplier from CellLayout, which is always 1
> Removign otiline animation from workspace. This animation never runs,
as it is called during startReordeing which always happens when
overview mode (workspaceInModalState() is true)
Change-Id: I43219e41ea188771bc818988c1bcbd523f28cba6
> Not creating unnecessary bitmaps
> Final bitmap is generated as ALPHA_8 instead of ARGB_8888
> The shadow drawing is done directly in the view
Change-Id: I504fa2ea3abdc1a3c3fb9ad57d6e28880d2584a1
