Method slideOut won't slide out everytime

[tbaranes]

Following the code, the slideOut methods are always 300 * force, but if we are running this example on an iPad with a force to 1, it will never get the outside screen.

Is there a reason to have hardcoding that constant?

[JakeLin]

Will add SlideFadeOutLeft which is like SqueezeFadeOutLeft.

[tbaranes]

👍

[tbaranes]

After check the implementation of SqueezeFadeOutLeft, we will have the same issue, the slideOut should go outside of the screen, whatever is the distance between it's current position, and the next one, isn't it?

[JakeLin]

@tbaranes you are right. that is the problem of SlideOut animations. The slide out animations require the width or height of the device. And the animating element itself doesn't have the info. All we can use UIScreen. mainScreen. bounds to get. Or we can add some animations like moveX(), moveY(). That may fix this issue. Do you have any suggestions?

[tbaranes]

We shouldn't use UIScreen to get the frame since the container where we are doing the animation could have any frame depending of the context.

Something like that would be more appropriate:

  public func slideOutLeft(completion: AnimatableCompletion? = nil) {
    let x = -frame.width * force
    animateOutWithX(x, alpha: 1, completion: completion);
  }

  public func slideOutRight(completion: AnimatableCompletion? = nil) {
    guard let unwrappedSuperview = self.superview else {
      return
    }

    let x = unwrappedSuperview.frame.maxX * force
    animateOutWithX(x, alpha: 1, completion: completion);
  }

The only bad point is that we can't use Animatable without an UIView but it won't be a big issue, is it?

[tbaranes]

After a better looking in the code, the solution would be more something like this:

  public func slideOutDown(completion: AnimatableCompletion? = nil) {
    guard let unwrappedSuperview = self.superview else {
      return
    }

    let y = (unwrappedSuperview.frame.height - frame.minY) * force
    animateInWithY(y, completion: completion)
  }

I will make some tests, and a PR if that's working on monday

[JakeLin]

@tbaranes My concern is the animating view may not be the directly subview of the the root view. For example, VC.view -> UIStackView(not 100% width and height) -> UIView(one item within StackView) -> AnimatableView.

I have some ideas to get the distance (width/height).

1. Get device width and height as the distance. we may need to set a constant for playground file. And need to consider the orientation.
2. Traverse up to the top most view.
3. Get the associated VC then use VC.view.

I don't know which one can be the solution yet. please let me know if you have any ideas.

[tbaranes]

Oh right, I didn't think about the UIStackView issue. I'm not sure how you can really handle all the case. Maybe the point 2 / 3 or the best one, but it won't be exact all the time following if we want to slide out of the screen or just the container. Maybe we need to handle the both cases?

[JakeLin]

@tbaranes To slide out the container. we can use containerView, then put a VC within it. that's why i put the 3rd option above. But I haven't thought carefully for all options. But first thing would be side out of the screen.

I think the library is hard to handle 100% of scenarios. It need to add a lot of @IBInspectable properties to support more customisation. We need to balance that.

[tbaranes]

I agree with that. Following the case, the option 3 seems to be the right one using with container view controllers. 👍

[JakeLin]

@tbaranes using the device width/height should be a feasible solution. In that case if we want to slide out from a sub view (container view) we still can slide out but it will move further. In our case, it looks faster that it should be because the visible distance is shorter than the actual moving distance. We can modify some parameters to customise the speed.

[tbaranes]

I think it's add complexity following the usage case. Anyway, it's still a good option, improvable later if necessary.