Create SharedElement-style Transition

[fabiendevos]

No description provided.

[mkodekar]

do you mean shared element transitions ? @fabiendevos

[fabiendevos]

@mkodekar yes, except obviously there is only one activity with Magellan, but something very similar yes.

[SpicyCactuar]

I was about to create an issue about Shared Element transitions. It was out of curiosity that i entered this one before doing that. Should we change the name of the issue?

Going back to the issue itself, it would be lovely to have them. In fact, i was thinking about diving in and submitting a PR. It may be hard for a first PR though. What do you think?

[ryanmoelter]

I agree about renaming this issue. I've been thinking about how to implement this for a while, and there are a lot of different factors to consider. I'll put some of them here, in case you have time to implement it before I do. I'll list them in vague order of importance.

1. What do we want the interface to look like? I'm leaning towards a fluent API / builder pattern, personally (e.g. SharedElementTransition.with().curvedMotion(R.id.view1, R.id.view2).build()). I think it could be powerful and flexible enough to work without having to create a new class for each transition. (Side thought: we would need to make the class extendable so people can add their own types of animations.)
   Another option could be to leverage the Android's Transition framework and use XML files to define the animations. I personally think this would be more clunky than a builder pattern, but it could be more flexible and could separate concerns better by putting animations in a completely separate file.
2. How do we want to handle items in lists? The easiest way to define these transitions is to use just the id of the view, but that would obviously break with any item in a list. So we'd need a way to pass in a view, and we'd need to make sure that we animate back to the same view.
3. How do we handle back animation? I'd imagine we'd want to essentially play the animation in reverse, but that gets difficult when the view redraws itself and you have lists and such. Step one is to retain the Transition object so we can make the transition symmetric, as in Save Transitions to use for back navigation #70.

I think this could be one of Magellan's most useful features if we pull it off well.

[ryanmoelter]

@emalamela Since (as you can see) making a general solution will take a lot of effort + time, you might want to make a custom Transition for your particular use case in your own repo before tackling the more general problem here.

[SpicyCactuar]

Nice suggestion! I'll definitely try a 'local' solution first.

As for the other points:

1. I prefer the fluent API / builder pattern. Android's Transition XMLs don't seem too hard to emulate through a custom SharedElementTransition class. I understand the point about separating concerns but having a class means it's easier to parametrize and manage through code. Another (possible) upside is that we can make the reversing easier to implement since we are in full control. Regarding the flexibility, i was considering SharedElementTransition to be created in an inline manner, with something like a Builder too. Thus avoiding creating new classes for the most common use cases.

2. Using the ids will definitely break. Using tag could work but users could be utilizing it in another ways so no-go as well. What about using the transitionName property of Android's View to match? Upside: Re-using a known property and requires less programmatic configuration. Downside: we have to inspect the hierarchy each time a View is created 😕. I can't think of ways to optimize this without changing the user's layout. I'll keep on banging my head into this a little more. Maybe something that combines passing it and using transitionName.

3. Not much to add. Fully agree. The extra is what i mentioned in 1.

I think this will be a killer feature for Magellan, specially for the ones that can't make the jump from Fragment/Activitiy because of this.

As a last thought, i believe investigating how Android handles this for Fragments and Activities could prove useful. I will do this before implementing anything. Hope it inspires me.

[Shakezulla57]

@emalamela Have you gotten any time to work through your idea(s) at all?

[SpicyCactuar]

Actually, i couldn't. What's worse is that the semester is looking more demanding than i expected so i'm not optimistic about having any time. I'm sorry 😞. For now what i can offer is discussion since i'll keep on following the issue. I'll comment if i get to something.