[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]