UIScreenEdgeRecognizerGesture smooth like safari - swift

Question

My container view controller has a screen edge pan gesture to change the views. The code for panning the views looks as follows:
func changeView(recognizer: UIScreenEdgePanGestureRecognizer) {
println("INITIAL: \(recognizer.translationInView(view))")
if recognizer.state == .Began {
// Create and configure the view
println("BEGAN: \(recognizer.translationInView(view))")
}
if recognizer.state == .Changed {
println("CHANGED: \(recognizer.translationInView(view))")
let translation = recognizer.translationInView(view)
currentView.view.center.x += translation.x
pendingView.view.center.x += translation.x
recognizer.setTranslation(CGPointZero, inView: view)
}
if recognizer.state == .Ended {
if recognizer.view!.center.x > view.bounds.size.width {
// Animate the view to position
} else {
// Animate the view back to original
}
}
}
While this works, I'm still having an issue with the start of the panning. When a user swipes quickly, translation will have a value big enough to make the start of the pan looking "unsmoothly".
For example, with a quick swipe translation will start with a value of 100. The value is then added to the center.x of the views causing the undesired effect.
I noticed Safari has a screen edge gesture as well to change views and this effect doesn't occur no matter how quick the swipe is. Nor does this happen with a normal UIPanGestureRecognizer.
I've tried wrapping the "animation" in UIView.animateWithDuration(). It does look more smooth, but then it feels it's just lagging behind the actual gesture, unlike how it's done in Safari.
Can someone please tell me a better way to pan the views so it will look as smooth as in Safari?
EDIT:
I've added several lines to check the value of the translation and the problem is it jumps from 0 to some value causing the unwanted behavior. It doesn't matter where I put recognizer.setTranslation(CGPointZero, inView: view).
The output is:
INITIAL: (21.5, 0.0)
BEGAN: (21.5, 0.0)
INITIAL: (188.0, -3.0)
CHANGED: (188.0, -3.0)
After some more testing:
func changeView(recognizer: UIScreenEdgePanGestureRecognizer) {
println("INITIAL: \(recognizer.translationInView(view))")
recognizer.setTranslation(CGPointZero, inView: view)
}
INITIAL: (0.0, 0.0)
INITIAL: (130.5, -35.5)
FINAL:
Seems like creating and preparing the new view is causing some kind of minor lag in Began. The small amount of lag is enough to create a difference in translation of 100-200.
Probably have to preload the views somewhere else I guess.

Answer 1

This won't solve all your problems, since, as you have rightly said, a screen edge pan gesture recognizer is a little crusty in its behavior; but do note that you are omitting one valuable piece of data - the question of what recognizer.translationInView is in the .Began state. At that time, obviously, the finger has already moved considerably; for, if it had not, we would not have recognized this as a screen edge pan gesture! You will thus be much happier, I think, if you construct your tests like this:
switch recognizer.state {
case .Began:
// ... do initial setup
fallthrough // <-- TAKE NOTE
case .Changed:
// respond to changes
default:break
}
In that way, you will capture the missing datum and respond to it, and the jump will not be quite so bad.
I tried logging in both began and changed and my numbers (showing translationInView with no setTranslation back to zero) are this sort of thing:
began
changed
(-16.5, 0.0)
changed
(-41.5, 0.0)
changed
(-41.5, 0.0)
changed
(-58.5, 0.0)
(The first one, preceded by began, is the fallthrough execution of changed.) So yes, we do go from nothing to -41 very fast, but at least there is an intermediate value of -16.5 so it isn't quite so abrupt.
Also I should add that if there is a serious delay and jump it may well be that you have multiple conflicting gesture recognizers. If so, you can detect this fact by using delegate methods such as gestureRecognizer:shouldRequireFailureOfGestureRecognizer: - which will also let you prioritize between them and perhaps make the other g.r. give way sooner.