(audience claps)

- Thank you.

Can you hear me?

Okay, yeah.

Welcome everybody, thank you for joining me today.

First of all, remember to join the conversation

in Twitter, #gotocph.

Remember to engage so you can rate

my actual session and ask questions.

My name is Israel Ferrer Camacho.

I'm an Android developer at Twitter.

You can follow me on Twitter too,

and ask me questions there too.

I work on the Moments teams which is a

nice experience, fullscreen experience

horizontal scrolling where you can add

a list of tweets, and it's a story.

It doesn't have to be following a chronological order there.

For those who are not an English native speaker as me,

smoke and mirrors is an expression used

to describe something that is

obscuring or embellishing the truth.

It's usually used for magicians because they do magic

which is simply not real.

It's just a trick, just so you know.

Sorry if I spoil you guys.

The reason for this title

was in the last Google I/O during the RecyclerView talk,

where Adam Powell and Yigit Boyar,

by Adam Power and Yigit Boyar.

Adam Powell actually started the talk by saying

UI developers, we have a lot of things in common

with magicians, and that is actually true.

If you think about some of the animations that we do,

and some of the components that we use in the framework,

and that's the idea of this talk.

I'm gonna be showing some examples in the Android framework

or where we are using this smoke and mirrors

to make an application just great, flawless, and smooth.

After that I will start talking about one of my

favorite apps in Android, and how that experience

is actually built, and I will do a demo with that.

So let's just start with the Android framework.

So these are Timeline.

Hopefully you know what is Twitter.

So theoretically, anytime like you have infinite tweets,

as you can see we're scrolling really fast,

performance's really good by the way,

so it is a problem right?

The problem is we have infinite amount of views

that we wanna show but we have limitation.

We cannot just instantiate thousands of views

at the same time.

Actually, what we have really do is

which is need to do this.

We are showing one, two, three, four views in the screen.

We don't need to actually show any

or instantiate any order view.

Just five at the same time, seven, eight tops

if the tweets are really small

but Jake likes to talk a lot so they're just big.

So, anyway how we do that?

We use this component called RecyclerView,

the name will give you a hint of

what it's actually doing, which is recycling.

I wanna talk about it, how internally works

because I think it's interesting.

Internally, it has the linear LayoutManager,

which actually recycles,

which actually is responsible for measuring

and positioning the item views,

and as well as determining when to recycle those views

that are not shown anymore.

So when you try to actually show the next position,

the LayoutManager is gonna go to the RecyclerView,

and invoke the method getViewForPosition.

When that's called, RecyclerView will go to the Adapter,

and will ask for the type of that view

because you can have many types of views

in your RecyclerView so example

if you want to have different headers or you want

to have a cutout so for showing ads for example, okay.

So yeah, we get the type the RecyclerView is gonna

go to the RecyclePool, which is where all the views

that ViewHolders that we can recycle.

It will get a ViewHolder for that type.

If there is none, it will go the the Adapter

and then create one.

But if there is one, it would just send it

back to the Adapter and say hey,

can you find this ViewHolder with a new data,

with a data for that new position that we wanna show,

the one that was showing on the animation.

Once it holds the information, it just return it back

to the RecyclerView, and then the LayoutManager will

actually lay it out in the screen, that item.

This is a really simple explanation of how the RecyclerView

actually recycles views, and you can learn a lot more

in the Google I/O talk that I was talking about,

the one that inspired this talk.

It's called RecyclerView Ins and Outs,

and they talk a lot more about how to animate items,

and do transitions in between the states.

Another example on the Android framework is this one

that I'm showing in the Twitter app.

As you can see, there is a list of images,

and when you click one with transition to fullscreen.

Those are called Shared Element Transitions.

Shared Element Transitions, they have smoke and mirrors too

but first let's dig in on how it works.

The way it works is the activity has an activity transition

a state which persists a state of that transition,

and it has like the most important part is the shared views

that are gonna be transitioning from one screen to another.

When activity life cycle is invoked, for example

it goes through onDestroy, or onPause so it's disappearing,

and then we are gonna start a new activity,

it will call the activity transition state to start

a new transition which will actually call to the

activity transition coordinator.

The ActivityTransitionCoordinator is a base class.

There are actually two.

There is entering and exiting coordinator,

so one handles the enter transition,

and one the exit transition,

and that has a transition manager,

and it will begin the transition.

So by the default the transition is a translation

but you can change that on your theme,

and you can actually customize your own

transitions between activities.

But you must be thinking, you're talking a lot about

how this works but what is the actual smoke and mirrors

in transition in the shared elements.

Well, think about it.

When an activity is being, going to hide

or to the background, and another one comes in the top,

how they are actually re-enabled to do that transition

from one to another.

Well what they do is they hide the target activity,

and they have a list of the views that are transitioning

from what position they are transitioned

so they pretty much in any activity do that transition,

that's what they are doing.

How they do that, well, they use ViewOverlay,

which is used by the default transition in the framework.

ViewOverlay provides a transparent layer

on the top of a view,

to which you can add any type of visual content,

(mumbles), and that doesn't affect the

layer hidden (mumbles) on the top so that means

that you can pretty much animate anything,

and it just works and doesn't mess with

the layer hierarchy, it's great.

It's gonna be your best friend forever in animations, okay.

Think about that, that word of what I said.

So let's imagine this, you can see there is two layers.

There is the LinearLayout which has a nice image view

with a Saturn illustration,

and then this is the ViewOverlay.

In order to make an animation,

I'm gonna add that to the ViewOverlay.

How do I do that?

Well LinearLayout, any view has that,

LinearLayout, getOverlay, and then you add to that overlay.

What is gonna happen is that suddenly that ImageView

is not gonna be part of the LinearLayout anymore.

It's gonna be in this temporary ViewOverlay

that we're gonna use for animations.

When you do that, the rect of that ImageView is

invalidated in the parent so that force a re-layout

so you have to be careful if you depend on that view.

Otherwise you will mess the whole hierarchy.

But the good thing is, any type of touch or animation,

touch depend on animation, it gets delegated

to that ViewOverlay with that ImageView.

So if you are actually, imagine you have a reference

to this ImageView, and you try to do animation,

it will animate even if it's not part of

the LinearLayout anymore, which in this case

is part of the ViewOverlay.

So unfortunately, shared element transitions are real nice

but there are limitations.

The first one is that the user can't control

the transition with a touch.

It just an simple animation from one place to another

so the eye of the user gets caught,

and doesn't lose the context between the screens

but it doesn't allow the user for example

to pinch and zoom, and control the transition

with a pinch and zoom, right.

So that's a limitation.

Another limitation is that one,

actually when I was doing the code, I saw that here.

The transition doesn't track the target destination

so if you don't eat all the touch events

while the transition is running, it looks terrible

and it's just a limitation.

I mean, we can simply fix that

by using this TransitionListener.

Thankfully, we can hear all the life cycle events

of the transition so what we can do is onTransitionStart,

we are just gonna eat all the touch events, pretty much.

Then when the transition finishes, we'll just set the

touch listener again to the right place.

Easier right?

Okay, so before entering into the interesting part

of the talk, which is the demo,

let's talk about two important attributes for an image.

Consistently these are the attributes that are actually

might as well be thought type of

rendering outside the parent.

So first of all is the ClipChildren.

The ClipChildren attribute is an attribute of

a ViewGroup and by default is set to true,

which makes sense because it clips the children

to the bounds of the parent ViewGroup,

and that's exactly what we want right.

By default, we want that to happen.

So it looks like this.

Right, you're not allowed.

That's me actually, that's my avatar

so I'm not allowed, my ImageView is not allowed

to draw outside the parent view

unless I set ClipChildren to false.

In that case, I'm gonna be able to draw

outside the first parent but not the second,

not the following parent.

So what I have to do is, spoiler alert,

I have to set that to false in all the parents,

which is kind of like, but that's how it works.

So, yeah okay, really bad animation that I got there.

It just shows the point.

Okay, so ClipPadding, so ClipPadding is the same.

So if you have the ClipChildren false

but you have a padding, the view is still

gonna clip to that padding, yes, that happens,

especially with RecyclerViews, happens a lot.

So just remember if suddenly a view of yours gets cut,

in a RecyclerView, maybe it's because there is a padding

and you didn't set that to false.

So this is what it looks like.

It gets clipped to the padding,

and pretty much already at some point,

I think a long time ago,

was creating this type of utility,