[ROCKET BLAST]
LYLA FUJIWARA:
Android Jetpack is
a set of libraries and guidance
for modern Android development.
Now, there are four categories
that make up Jetpack.
This video is all
about architecture.
Here are the architecture
component libraries.
These libraries work
great on their own,
but they're also built
with each other in mind
and can fit together
like puzzle pieces.
The documentation
contains a guide
to app architecture, which
shows one way that these puzzle
pieces can combine to create a
testable and maintainable app.
This architecture revolves
around the following
principles--
the separation of
concerns, loose coupling,
the observer pattern,
and inversion of control.
OK.
Let's go ahead and
start at the bottom.
Room is a SQLite
object mapping library.
It gives us annotations to
generate boilerplate code
for you.
You declare your SQLite
tables using entity objects.
Entity objects are just simple
objects with a few annotations.
For example, I can take this
class representing a user,
and after I add a
few annotations,
it becomes a representation
for this SQLite table schema.
When defining the operations
you perform on your database,
you essentially write
annotated SQL statements.
This is where Room's
object-mapping capabilities
come in.
You can put entity
objects directly
into your Room database, or have
your database return entities.
No conversion or
intermediates are needed.
Compile time checking
is also included.
So if you mess up
your SQLite queries,
Room lets you know right away.
Room also supports
observable queries--
including RXJava flowables;
lists, optionals,
and Guava classes; migration
between schemas; and testing.
Another fundamental
part of any data layer
is threading and
background work.
To make sense of background work
in modern Android development,
we've created the guide to
background processing, which
includes this handy table.
You'll notice that there is this
new library here, WorkManager.
The WorkManager library provides
a unified API for deferrable,
one-off, or recurring
background tasks
that need guaranteed execution.
The background tasks are
work request objects.
With WorkManager, you can build
a complex processing and upload
flow like this using
chains of work requests.
As part of the
chain, you can define
the output of one work request
as the input of another work
request.
You can also set
conditions on when
the work request should run.
WorkManager then performs the
work requests in the order
that you specified
while also taking
care of compatibility issues
and best practices for battery
and system health.
As part of guaranteed
execution, WorkManager
handles continuing your
work across device restarts
and if your process
is force stopped.
Finally, WorkManager can return
the state of the work request
so that you can represent
this state in your UI.
OK.
Let's go ahead and take a look
at the Lifecycle libraries.
The classes in this library
help with Android Lifecycle
management, specifically
with avoiding memory leaks
when updating your app's UI.
Here is one example.
Have you ever rotated a
device and had the app crash
or lose data?
Well, adding a ViewModel
can help fix this.
Unlike activity objects,
a ViewModel object
isn't destroyed when the
device configuration changes,
such as when the
screen is rotated.
This property of ViewModel
makes it a good, stable place
to put all of your UI data.
The ViewModel usually contains
another Lifecycle object,
LiveData.
LiveData is built for easy
communication between the UI
and deeper layers of
your app's architecture.
LiveData is an
observable data holder
for data that is meant
to be shown on screen.
Basically, it'll wrap
around an object,
like this user object
over here, and allow
the UI to automatically update
whenever properties of the user
object change.
LiveData is also
Lifecycle aware.
This means a
LiveData object only
tells the UI to update
if the UI's Lifecycle
state is in the correct state.
For example, if your
activity is not on screen,
then the LiveData will
not trigger updates.
Also, if the activity
gets destroyed,
then this observation
connection is cleaned up for you
automatically.
So as your data
changes, you never
accidentally trigger
an activity or fragment
that is offscreen or
destroyed to redraw itself.
The Lifecycle libraries include
other powerful features.
For example, LiveData
supports transformations.
As mentioned before, Room
can return LiveData objects,
which allows your UI to observe
objects in the database.
ViewModels and LiveData also
now support data binding.
You can bind these classes to
an element in your app's XML
layout definition.
That lets you get rid of all
of this boilerplate code.
The Lifecycle's library also
contains classes and interfaces
for querying and observing
UI Lifecycle states.
The Paging Library
integrates directly
with Room and LiveData.
Now, there's a common situation
where you have a lot of data
that you want to load in
small, manageable chunks.
The Paging Library is built
exactly for this use case,
and it avoids tricky SQLite
cursor performance issues.
The library offers the
following features.
It allows you to
define the data sources
that you're going to use,
be it data from the network,
a database, or another
data source of your choice.
It works out of the box
with Room and RecyclerView.
It supports lists of
any size, including
lists of infinite length.
It leverages LiveData to update
your UI as more data is loaded,
and it has support for RxJava.
Finally, there's the
Navigation Library.
The Navigation
Library and Tooling
simplify implementation of
complex, but common navigation
requirements and help you
visualize your app's navigation
graph.
Now, for trivial apps,
navigation might seem simple,
but when you add things
like fragment transactions,
the need to implement
proper back and up behavior,
support deep linking,
add a bottom bar,
and include animations
between screens,
let's just say that things
get a little bit messy.
The Navigation Library
simplifies all of this.
Now, the basic building
blocks for navigation
are called destinations.
Destinations are specific
screens you can go to.
There's out-of-the-box support
for fragments and activities
as destinations, but you
can also make your own.
The new guide to
navigation encourages
you to have activities as
entry points for your app.
They also contain
global navigation,
such as the spot of nav.
Now, in comparison,
fragments will
be the actual
destination-specific layouts.
This UI structure allows you
to share an activity ViewModel
between all of the fragments
associated with that activity.
As the user navigates
from fragment to fragment,
you don't need to
serialize that shared data.
The new navigation
editor in Android Studio
enables you to quickly specify
destinations and visualize
your app's navigation
architecture.
The connections here show
the possible navigation paths
between each destination.
This generates XML, which
you can edit by hand.
The library uses this
new navigation graph
resource and a new
nav control object
to move your user
through your app.
Now, this is just
scratching the surface
of the proverbial iceberg
that is the architecture
components in Jetpack.
Hopefully, some or maybe
all of these libraries
piqued your interest.
To learn more, we've
got DevBytes for all
of the stable components.
We also have Codelabs for each
component, and, of course,
thorough documentation.
Now, if you find yourself
left with questions,
we've also got StackOverflow
tags and an issue tracker.
Or you know, you can
yell at me on Twitter.
Actually, don't yell
at me on Twitter.
Happy coding.
[ROCKET BLAST]
