Refactoring TransitionAnimationType

[tbaranes]

Following the discussion in #134, I tried to review the implementation of TransitionAnimationType in order to make it thiner. The current implementation is answering that needs: the enum is really smaller, and the switch is more generic / readable.

The architecture seems nice, but there are some points that need a generic solution:

• TransitionAnimationType from string -> how to implement it?
• Iterating on TransitionAnimationType and handles all the cases (which means with the different directions...) to update the examples. That also implicate a way to divide the final array in different section for each transition family and readable name
  For now, I just hard coded one case of SystemCube, and Fade, it's working as expected.

Any suggestions for these issues? Until now, I didn't find any nicer solution than the implementation currently used in master.

If you want to make some tests, use this branch, it's still very experimental 💭

/!\ NOT READY TO BE MERGED /!\

[JakeLin]

I think that may not work since it is a fully qualified like SystemCube(IBAnimatable.TransitionFromDirection.Left)", we may need to do some like what we did in maskStarFromString in MaskDesignable, in IB, we may configure the string as "SystemCube(Left)"

[tbaranes]

Yeah, sure. That part is really not finished 😅 I let it that way to talk that new implementation, but didn't find a nice solution yet.
In order to do as MaskDesignable, we are will need to hard code all the enums, is that a good solution?

[JakeLin]

@tbaranes nice attempt , I really like the new TransitionAnimationType, we maybe able to do similar thing for MaskType as so on.

[tbaranes]

Here two new commits who may finalise that PR if it seems correct to everyone:

• TransitionAnimationType: it will ask a bit more work than before, we have to add a new if for each new transition. I tried to make it generic (at least the direction). I don't like that much this generator, but don't have any better idea right now, and I'm not sure that we can make it more generic using an enum with params since we are using hard coding string from xib.
• Example project: here again, a bit more work, one line will be add manually for each new transition, but it's worth it even if it's not generic. The interface is cleaner and more readable for the user:

Everything is working as expected! What do you think about that implementation? :)
Also, shouldn't we create a new release with or without that PR? The changelog is already not that bad 😆

[JakeLin]

Very cool implementation. I like it very much.

We may have more else if branches in static func fromString(transitionType: String) -> TransitionAnimationType? in the future to support some transition more than direction. For example, ZoomIn/Out.

I will update the wiki to mention generateTransitionTypeData when we develop new transition animations.

Please merge it when you feel is ready. 👍👍👍 Well done.

[tbaranes]

Let's merge that first step! It's still improvable with less breaking change 😆

Could you update the CHANGELOG to explain the breaking change? Since it's a big one, I prefer let you write it to be clear. Also, if it's ok for you, we can release the IBAnimatable 2.1 👍

[JakeLin]

Cool, @tbaranes doing 2.1 now.