[MUSIC PLAYING]
IAN LAKE: So when the Android framework goes
to start your application from the Launcher icon, or an app
shortcut, or what you see when you're doing Multi-Window,
those are all activities, right?
So they really are, kind of, the entry point into your app's UI.
When the user goes to launch your app,
they're launching an activity.
What you actually want if you want to build the layering
you actually need.
So in this case, we can have multiple things,
multiple destinations within an activity,
and share information across each of these destinations
by using the activity scope as an actual useful element now.
So for example, you could have a shared view element or view
model that both destinations talk to.
So one destination could put data in.
And the other one could observe changes to that data.
You don't need to work at the application scope
level for this to work.
When we're thinking about this, like if we're
moving from this activity world to a destination and world--
we really want to make that world as easy as possible.
Otherwise, why would we move?
And we focused on two things.
One was that global UI thing.
Like, how can we make that are easy?
It's something that every app has the same kind of patterns
and we really don't want that to be something that
takes a lot of effort to do.
Also, the navigating between destinations--
that start activity, activity compact thing--
can we make that even easier?
So we started the navigation architecture component.
And we introduced it to you all in I/O this last year in 2018.
If you have arguments to something,
how do we make this nice?
So we built a cradle plugin called safe-args, which,
for every destination in your graph--
such as this main fragment--
we generate a directions object.
Which has a nice, simple show profile method,
which gives you a directions object with type safe arguments
that you define in your navigation graph.
And then you just call a navigate.
And that's it.
We'll take care of all of the fragment
transaction-- all of that sort of stuff for you.
So this makes it a lot easier.
So rule number one of testing things
at the destination level is don't
test the destination level.
it's really the number one thing with testing
is making things nice and separate.
And extracting some of that business logic
out of a destination and into something you
can test in isolation.
So how can we do this?
So this Monday, we released Fragment 1.1--
the first alpha.
And with this, became a new artifact
called fragment testing--
just about six years overdue.
And it's really around being able to test your Android X
fragments in isolation.
Separate from an activity, separate from everything else,
but being able to test and verify that,
that fragment is doing the right thing.
We have a mockable layer.
One of the things that we found when building navigation is
that most companies--
once they got to a certain point and they're like, wow,
we should add some testing.
And they're like, wow, we can't really test start activities.
So they built their own navigator,
which just provides a layer to mock out the start activity
calls.
Well, that layer is handled for you.
It's called NavController.
We test NavController.
So now what we can do in our activities
is just mock out that NavController
and confirm that yes, you're calling
the right navigate calls.
You can actually do constructor injection into fragments.
You no longer need to only have a no args constructor
to use fragments.
You can use a fragment factory to instantiate your fragments
for you.
We do recommend using multiple activities.
Not a lot, though.
So what I'd like to say is you don't actually
need multiple activities.
what you need are multiple tasks.
I'd really like to end this with one note.
A lot of you have existing apps that
have very different kinds of experiences.
And I'd like to say, do what's right for your app.
I think single activity is great.
If I was writing a new activity, it
would also be single activity.
But I realize that going to your PM
and being like hey, let's rip the whole app
apart is sometimes a hard sell.
Some of them don't like your current app
so maybe you'll actually get some yeah, OK.
Go for it.
Really depends on your experience.
If you find yourself contorting your own experience
and it's not making sense to you, don't do it.
If something is working--
that's good.
Keep it working.
But if you're finding you're running into issues,
you're having inconsistent behavior,
or you want to do things like shared view models--
maybe that's the time to think about moving
towards a single activity structure.