More banner behavior tweaks

More banner behavior tweaks

* Prevent the banner from being hidden while it's being animated onto the screen for the first time.

* Use the GestureHandler's onShowPress() function to determine when to show a highlight.

* Tweak the fling dismissal behavior so it somewhat takes into account the fling velocity (which often has a sign... or magnitude... that doesn't make sense).  Track a secondary velocity determined by how long it takes for a user to translate the banner.

* Replace the word "banner" everywhere in SwipableOverlayView with "view".

* Change the banner interpolator to make it feel more floaty when it is coming back to the center of the screen.

Submitted as NOTRY=true because the Java-only changed passed the android bots.

NOTRY=true
BUG=341556
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=255531

[Ted C, 2014-03-06 23:37:50]

https://chromiumcodereview.appspot.com/187593007/diff/40001/chrome/android/ja...
File
chrome/android/java/src/org/chromium/chrome/browser/banners/SwipableOverlayView.java
(right):

https://chromiumcodereview.appspot.com/187593007/diff/40001/chrome/android/ja...
chrome/android/java/src/org/chromium/chrome/browser/banners/SwipableOverlayView.java:247:
mDragDirection = distance < 0 ? DRAGGED_LEFT : DRAGGED_RIGHT;
if the direction changes, should you reset the drag variables?

https://chromiumcodereview.appspot.com/187593007/diff/40001/chrome/android/ja...
chrome/android/java/src/org/chromium/chrome/browser/banners/SwipableOverlayView.java:435:
float remainingDifference = mDragDirection * getWidth() - getTranslationX();
should this not be a function of the parent's size?  Or is this match_parent so
it doesn't matter?

I was thinking you would need to get a combination of parent.getWidth() and
getX() and getWidth() (depending on direction).

https://chromiumcodereview.appspot.com/187593007/diff/40001/chrome/android/ja...
chrome/android/java/src/org/chromium/chrome/browser/banners/SwipableOverlayView.java:493:
public void onAnimationEnd(Animator animation) {
You might want to handle onAnimationCancel because you might not want to
removeFromParent if that were to happen.

[gone, 2014-03-07 01:09:49]

https://chromiumcodereview.appspot.com/187593007/diff/40001/chrome/android/ja...
File
chrome/android/java/src/org/chromium/chrome/browser/banners/SwipableOverlayView.java
(right):

https://chromiumcodereview.appspot.com/187593007/diff/40001/chrome/android/ja...
chrome/android/java/src/org/chromium/chrome/browser/banners/SwipableOverlayView.java:247:
mDragDirection = distance < 0 ? DRAGGED_LEFT : DRAGGED_RIGHT;
On 2014/03/06 23:37:50, Ted C wrote:
> if the direction changes, should you reset the drag variables?

Unsure... I think that could lead to some really wacky velocities if the user is
just wiggling back and forth.

https://chromiumcodereview.appspot.com/187593007/diff/40001/chrome/android/ja...
chrome/android/java/src/org/chromium/chrome/browser/banners/SwipableOverlayView.java:435:
float remainingDifference = mDragDirection * getWidth() - getTranslationX();
On 2014/03/06 23:37:50, Ted C wrote:
> should this not be a function of the parent's size?  Or is this match_parent
so
> it doesn't matter?
> 
> I was thinking you would need to get a combination of parent.getWidth() and
> getX() and getWidth() (depending on direction).

The banner doesn't span the whole screen, and are relatively tiny on a Nexus 10
compared to a Nexus 7 since they have the same max width.  If we required users
to move a percentage of the screen, users would practically never manage to
fling something away.

https://chromiumcodereview.appspot.com/187593007/diff/40001/chrome/android/ja...
chrome/android/java/src/org/chromium/chrome/browser/banners/SwipableOverlayView.java:493:
public void onAnimationEnd(Animator animation) {
On 2014/03/06 23:37:50, Ted C wrote:
> You might want to handle onAnimationCancel because you might not want to
> removeFromParent if that were to happen.

Shouldn't happen: cancelCurrentAnimation() explicitly prevents canceling an
animation if the user is getting rid of it.

[Ted C, 2014-03-07 01:54:56]

lgtm ... sounds good

[gone, 2014-03-07 01:55:18]

The CQ bit was checked by dfalcantara@chromium.org

[commit-bot: I haz the power, 2014-03-07 01:58:23]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dfalcantara@chromium.org/187593007/40001

[commit-bot: I haz the power, 2014-03-07 04:39:02]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-07 04:39:03]

Try jobs failed on following builders: mac_chromium_rel

[gone, 2014-03-07 04:40:19]

The CQ bit was checked by dfalcantara@chromium.org

[gone, 2014-03-07 04:41:52]

The CQ bit was unchecked by dfalcantara@chromium.org

[gone, 2014-03-07 04:41:52]

The CQ bit was checked by dfalcantara@chromium.org

[commit-bot: I haz the power, 2014-03-07 04:44:33]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dfalcantara@chromium.org/187593007/40001

[commit-bot: I haz the power, 2014-03-07 04:50:54]

Change committed as 255531