[Fix issue #1152] Enhance event-flick module with flickleft, flickright, flickup, flickdown sugar events

[tilomitra]

This pull request fixes issue #1152 by enhancing the event-flick module.

What's in this pull request?

flick* events

Added 4 new synthetic "sugar" events that developers can hook on to:

• flickleft
• flickright
• flickup
• flickdown

These events have the exact same public API as the generic flick event, but fire only when the axis and direction properties match up to the respective directions.

Bit of code cleanup

I separated out the monolithic _onEnd() callback into smaller functions:

• _onEnd()
• _isValidFlick()
• _fireEvent()

This helped me re-use a large portion of the CustomEvent config object when defining the new flick* events. These new events only overwrite the _isValidFlick() method. Check out

In addition to that, there was some minor code cleanup to make the code more readable.

minDistance default value change

I made a change in the flick event's minDistance property. By default, its value is now 100, so that it catches a legitimate flick, instead of a slight move of the finger. I believe it was 10 before.

Improve Test Coverage

event-flick did not have great tests. There were only 3 of them and they probably weren't working correctly because the assertions were inside a custom fire() method. If fire() wasn't called, the tests would pass anyway, since an empty test with no assertions passes. I improved the way the tests are written and added a bunch of new tests. event-flick has ~98% line coverage in all browsers. I'm not using event-simulate so these tests are very stable.

I also added a new manual test (flick-simple.html).

Tested on:

• IE7-10
• Latest Chrome/Safari/FF
• iOS 7
• Android 4.0.3

If someone has an Android device running on a newer Android version, it would be great if you can help me test this. No need to pull it down, just ping me and I can give you a URL that you can hit on your browser to run through the unit and manual tests.

TODO before merging

This is so I don't forget.

• Update event-flick documentation
• Push build files

[ericf]

This logic exists 5 times! Sounds like it needs to be a function that's reusable to me.

[tilomitra]

It's not the same logic though. The if() statement in each implementation is different. The axis and direction checks change based on the type of event that is being subscribed to. How should I break this out more?

[ericf]

Also code comments and docs on what it means to be valid.

[tilomitra]

I suppose I could split out this chunk into another function since it's shared:

if (isFinite(velocity) && (Math.abs(distance) >= params[MIN_DISTANCE]) &&
(Math.abs(velocity)  >= params[MIN_VELOCITY])) {
  return true;
}
else {
  return false;
}

[ericf]

There's two checks:

1. Is the flick valid
2. Was there a specific direction

The first thing is repeated 5 times, it can be written once and called from the other places. Even better would be to simply check the axis first since that's an easier comparison before calling into the _isValidFlick() shared function.

[tilomitra]

Looks like something failed downstream in Scrollview. I'll investigate this and report back.

Update: The fix that I made to processArgs() seemed to fix the failing test in Scrollview. It wasn't picking up that preventDefault = false, but it does now. All Scrollview unit tests pass and the manual tests work too.

[triptych]

@tilomitra if you import Hammer.js would that render this PR out of date?