Adding live tracking of page turns with swipe / pan position

[ryanwaggoner]

Hypothetically, how much work would it take to change the library to respond to live tracking of a swipe/pan, so that the user could drag the page and have it track their finger? Where would you even start?

[mpospese]

0 work as it already supports that! And yes, it's quite complicated (doing the pan as compared to a complete animation), and no, it's not perfect.

[ryanwaggoner]

Sorry for being dense, but am I missing something in the docs or code about how to enable this? I'm not seeing this working in the sample project, for example. If I do a pan on the page, nothing happens until some threshold is reached, and then the transition starts and completes, regardless of my finger position. I can't wiggle my finger back and forth in a one-inch area and have the page wiggle with it, for example.

[mpospese]

It's configured so that the pan is only recognized if you're close to the right or left edge of the view (I believe within 44 points). This is to prevent confusion / collision with the gesture recognizers used by the content view (remember, you can have pretty much anything in there).

Also start out going slow with your pan- if you go too fast, it will think you mean a swipe and just trigger the full animation.

You should be able to adjust both the margin amount (44 points) or the threshold velocity for triggering a swipe (at what point does it decide you meant a swipe instead of a pan) within the code to fine-tune it to your app's needs.

[mpospese]

There's also (unfortunately) some delay between when pan / swipe is detected and when the visual state actually changes - this is because both the old and new views have to be rendered as images to do the animation and this takes some time (4x longer under retina and especially noticeable on say iPad 3). There's a flag shouldRenderAllImages (or something like that) that you can set NO to only render the moving half of each view as an image and that should reduce any startup lag by approximately half, BUT that means the other (non-moving) half will be the actual live view (not static) and so depending on the content, may actually change while the animation is happening).

To eliminate the startup lag, the code could be modified to accept pre-rendered images of the page halves to be animated, so that it wouldn't have to render them when you trigger the pan / animation. But in order to do that, the content would have to be something static so that you could cache an image of it and not have it change.

[ryanwaggoner]

Oh awesome…got it now :)

On Jan 18, 2013, at 10:04 AM, Mark Pospesel wrote:

It's configured so that the pan is only recognized if you're close to the right or left edge of the view (I believe within 44 points). This is to prevent confusion / collision with the gesture recognizers used by the content view (remember, you can have pretty much anything in there).

Also start out going slow with your pan- if you go too fast, it will think you mean a swipe and just trigger the full animation.

You should be able to adjust both the margin amount (44 points) or the threshold velocity for triggering a swipe (at what point does it decide you meant a swipe instead of a pan) within the code to fine-tune it to your app's needs.

—
Reply to this email directly or view it on GitHub.