Animation doesn't work well for adding & removing views

[inamiy]

Though animation works nicely for reused views, newly-added or removed views don't get any good visual effects since their frames are either miscalculated (when added) or not even calculated (when removed).

It would be nice to have some effects for them e.g. fade in/out, and also delaying purgeViews so that animation don't get interrupted.

[nicksnyder]

Thanks for the report. You are correct that added views are just added and removed views are just removed.

When I was implementing this, my thinking was that all animated views should be in the before and after states. For add/remove this would be implemented as opacity fade (or even translating the frame on/off screen).

I am open to making improvements, but it would be helpful if you could provide a more concrete playground example that demonstrates the problem you have.

Can you clarify what you mean by purgeViews interrupting animations?

On Sat, Jan 14, 2017 at 6:07 AM Yasuhiro Inami [email protected] wrote:

Though animation works nicely for reused views, newly-added or removed views don't get any good visual effects since their frames are either miscalculated (when added) or not even calculated (when removed).

It would be nice to have some effects for them e.g. fade in/out, and also delaying purgeViews so that animation don't get interrupted.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/linkedin/LayoutKit/issues/88, or mute the thread https://github.com/notifications/unsubscribe-auth/AAuEUORMxvfnTw4KNOeczSXB76busW1jks5rSNasgaJpZM4Ljojm .

[inamiy]

I added playground demos in https://github.com/linkedin/LayoutKit/pull/89. Please take a look at "Test" page that demonstrates the awkward animation when view gets added/removed.

And, what I mean by "delaypurgeViews so that animation don't get interrupted" means that view-removal needs to be done after fade-out animation completes.

I think LayoutKit will probably need to call UIView.animate(...) from library side in the future.

[inamiy]

FYI I recently released https://github.com/inamiy/Zelkova (LayoutKit + Redux-like state management support). It also includes animation demo that is simpler than https://github.com/linkedin/LayoutKit/pull/89.

[staguer]

@inamiy I'm looking at Test playground page in inamiy/LayoutKit playground branch. Are you referring to the behavior of the Hello/World label that doesn't have a viewReuseId? Is the problem that it flies in from origin but you expect it to do something nicer, like fade in or out?

The way I would treat such animations is to consider the animation as being not just from some initialLayout to some finalLayout, but going through up to four distinct steps:

1. initial layout
2. pre-animation layout
3. post-animation layout
4. final layout

Any views that need to be faded in, would be added in the right positions in step 2 with opacity zero. They would also be present in post-animation layout but with full normal opacity.

Any views that need to be removed with a fade, need to be present in steps 2 and 3, with 1 and 0 opacity, respectively. These views would be finally removed when step 4 is applied.

This kind of approach is both simpler for the library side and allows the flexibility of doing other kinds of animations besides just fading in/out.

[nicksnyder]

@staguer explained this much better than I did :)

[inamiy]

I understand that adding more states for the intermediate layouts is the most certain way of making an animation. But that will require user side to do a lot of hard work for every single animation, and that doesn't seem ideal.

Since LayoutKit works like React.js, I think adding an animatable layout e.g. https://facebook.github.io/react/docs/animation.html may improve the usability (new DSL).

Or, I was also thinking of attaching animation style e.g. func prepareAnimation(for view: View, animationStyle: AnimationStyle) for various visual effects.

I don't know the best solution yet, but some heavy lifting on library side seems nice to me.

[staguer]

Yes, this sounds like a fair point.

This isn't a problem that we've run into ourselves, so I hesitate to suggest additions to the library just yet. Let me know if you have any proposals.

One thought I had was adding support for making modified copies of layouts. Maybe with some sublayout removed, or with an additional config added. Possibly even merging two layouts, a 'before' and an 'after' layout. This leaves many questions open and transforming Layout -> Layout seems significantly different from transforming State -> Layout, which is what we are trying to aim for usually.