Non-swizzling version? about easyanimation HOT 14 CLOSED

Well "by definition" and "everyone thinks X" won't convince me. Further the link you gave me says "method swizzling is reasonably safe" under Considerations.

from easyanimation.

Hey Daniel, it's the first time I hear that swizzling is not safe :) Where did you read that 😀

from easyanimation.

You can read about it everywhere :-)

The thing is that you are changing behaviour of system apis - and you cannot know the effects of that over other mechanisms.
It's by definition unpredictable and should only be used when there's absolutely no other way.

It's common sense, but if you want a "source" other than me/common-sense, you could read about it here: http://nshipster.com/method-swizzling/, in the last section "considerations".

from easyanimation.

Are you ready to consider non-swizzling version - since the problems like #14 and other problems that I experienced during a 10 minutes play with the library - prove that swizzling is unpredictable as I said?

from easyanimation.

well - I'm open to suggestions of course :) what do you think we should change?

from easyanimation.

Well, right now you are replacing the native UIView animate... function to supply a "zero configuration" setup.

What I would recommend is having a separate static function for animating, something like UIView easyAnimate... or UIView coreAnimate etc.

Then having a setup function that takes care of the swizzling, and and the user can call on "appDidLaunch".

The bigger problem, is with current users. They are used to the swizzling being the default- so having that as the default configuration will solve that, and having an "unswizzle" function.

That's the general idea- and I think that the most important thing is first to allow working with the library without swizzling so people who are experiencing bugs with OS animations will be able to void them, and then you have the time to improve the swizzling method to maybe take care of certain bugs.

But note that it's not a given that there's a fix for the swizzlng- as much of the behaviour is code you cannot see, and may change from version to version.

I thnk that eventually swizzling should be an opt-in feature, and that the docs should mention this being turned off by default since version X.Y.Z...

from easyanimation.

okay - I have already thought in that general direction as well. For me personally is more interesting to understand why do those animations break and if it is possible to avoid that happening.

Another idea that popped in my mind was to just include a new animation option you can add along with .Repeat, .Autoreverse, etc. called say .AnimateLayers that would enable the swizzled version for that particular animation.

I will have to think more what would be the leanest way to handle this

from easyanimation.

Oh yes - versioning is not a problem major version changes are okay to break so in case the bahavior drastically change, e.g. opt-in swizzle I'll just relase it as 2.0.0

from easyanimation.

Actually .AnimateLayers sounds beautiful! The only problem is that it is still possible to break. On the upside it will reduce the chances of collisions drastically (As long as the flag will be drastically higher than the current highest flag value)

from easyanimation.

tbh apple has not introduced any new animation options since iOS2, I don't think it's gonna be a problem any soon

from easyanimation.

Well they did not - but they did generally add animation options, like spring etc. So it's not that the animation mechanism is not evolving.
Anyway now I'm looking at their animation options, and it looks like most of the space is already occupied:
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIView_Class/#//apple_ref/swift/struct/c:@E@UIViewAnimationOptions
It looks like something like 1 << 12 would be fine to use.

I really hope that the next evolutionary step would be Apple embracing this and adding to the UIView implementation. I mean, you've already done all the work...

from easyanimation.

I have already introduced a few, but haven't advertised them at all: https://github.com/icanzilb/EasyAnimation/blob/master/EasyAnimation/EasyAnimation.swift#L103

Thought I might get rid of them in favor of other more interesting options

from easyanimation.

Well you will always need to reserve space for at least the trigger for CA animations///

from easyanimation.

Adressed in https://github.com/icanzilb/EasyAnimation/releases/tag/2.0.0 Thanks!

from easyanimation.