IssueTracker

Three things:

1. You're right, it's a bit brittle. I think the algorithm to derive a swipe path can be improved though if I split the path in the first (duration - 100).ms and the last 100.ms and relax the constraint that the last path needs to follow a function that goes through the start point.

2. The error must be improved, it reports the values for a single axis only. That works fine for horizontal or vertical swipes, but won't make sense for diagonal swipes. Also the velocity is in the wrong unit (must be *1000)

3. Note that the velocity is in px/s and not in dp/s, so a 500.ms swipe across a 100.dp box will yield different velocities on different densities. If the swipe spans the same amount of pixels on each device, it should have the same behavior on each device though.

Thanks for the 3rd pointer. Moving to declare velocities in dp-per-second makes my tests waaayy less flakey (commit). Is it worth updating the swipeWithVelocity to accept a similar unit?

I took a quick look at Modifier.swipeable() and turns out that the velocityThreshold in that modifier is specified in dp as well. So I think you're right, we should follow that practice.

Coincidentally I'm currently working on an improved version of swipeWithVelocity that loosens some of the restrictions and should make it a lot easier to generate valid swipes. I'll update that CL to include the move to dp, which will involve deprecating the px version.

On second thought, even though it is technically possible, I'm not sure if it makes sense to have this particular bit of API accept dp while all other methods accept positions in px. What I can do, however, is let TouchInjectionScope extend Density, so you can always easily convert between px and dp. I think in combination with a clear explanation in the docs that will give the cleanest API. What do you think?