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