Have you noticed that animation classes come in pairs? For example, there is FadeAnimatedText and FadeAnimatedTextKit. There was a significant refactoring with Version 3 that split the original FadeAnimatedTextKit into FadeAnimatedText and AnimatedTextKit, then FadeAnimatedTextKit was adjusted for backwards compatibility.
When introducing a new AnimationText subclass, you may wonder if you also need to also introduce an additional Kit class. The answer is NO. 🎉
Going forward, we are championing the adoption of the Version 3 approach, and will be deprecating the legacy Kit classes. This will make creating new animations easier.
As a result, we need to:
Annotate the existing Kit classes (except AnimatedTextKit, obviously) as Deprecated.
Revise the README, example app, and test cases accordingly.
Until the code is removed, we should still provide adequate test coverage of the legacy Kit classes. But those test cases should be isolated because they will be removed. (Likely for Version 5.)
Have you noticed that animation classes come in pairs? For example, there is
FadeAnimatedTextandFadeAnimatedTextKit. There was a significant refactoring with Version 3 that split the originalFadeAnimatedTextKitintoFadeAnimatedTextandAnimatedTextKit, thenFadeAnimatedTextKitwas adjusted for backwards compatibility.When introducing a new
AnimationTextsubclass, you may wonder if you also need to also introduce an additionalKitclass. The answer is NO. 🎉Going forward, we are championing the adoption of the Version 3 approach, and will be deprecating the legacy Kit classes. This will make creating new animations easier.
As a result, we need to:
Kitclasses (exceptAnimatedTextKit, obviously) as Deprecated.exampleapp, and test cases accordingly.