[MUSIC PLAYING]
ALAN VIVERETTE: Hi.
I'm Alan Viverette, and I'm a technical lead on the Android
Jetpack team at Google.
I'm joined today by Anna-Chiara Bellini, a product
manager on Jetpack Compose.
In this talk, we'll be covering the latest Jetpack libraries
with a special deep dive on Compose integrations.
As you may recall from previous years,
Android Jetpack is a suite of libraries, tools, and guidance
to help developers follow best practices,
reduce boilerplate code, and write
code that works consistently across Android versions
and devices.
In short, Jetpack makes it easier
for developers to focus on the code they care about.
Most apps are already using Jetpack's core libraries
for basic functionality, but adoption
of optional libraries like Room and WorkManager
has continued to grow.
Last year, over 3/4 of the top 1,000 apps
relied on two or more non-core Jetpack libraries.
And today, over 90% of the top 1,000 apps
rely on Jetpack to address common pain points
and make development easier.
One major aspect of that is opinionated libraries focused
on application architecture.
Room is a database persistence library
that provides an abstraction layer over SQLite
to allow for more robust database access
while harnessing the full power of SQLite queries.
Most recently, Room 2.4 has graduated
support for Kotlin Symbol Processing
to stable, including support for Kotlin 1.6.
KSP is a replacement for KAPT that processes
annotations natively in the Kotlin compiler
and can significantly reduce build times.
Room 2.5 brings the initial stages
of a full Kotlin rewrite.
It remains binary compatible with the previous Java-sourced
version, but lays the foundation for future Kotlin-related
improvements.
We've also introduced built in support
for Paging 3.0 via the Room Paging artifact,
meaning Room queries can now return paging source objects.
Additionally, Room has gained support
for relational query methods using multimap, nested map,
and array return types.
This allows developers to perform join queries
without defining additional data structures.
For developers performing database migrations,
Room has added additional properties and annotations
to simplify the task.
A new auto-migrations property on the database annotation
can be used to declare which versions
to auto-migrate to and from.
And when Room needs additional information regarding
table and column modifications, the auto-migration annotation
can be used to specify the inputs.
The Paging library makes it easier
for developers to load data gradually and gracefully
within an app's RecyclerViews or Compose LazyColumns.
Paging 3.1 brings stable support for Rx and Guava
integrations, which provide Java alternatives
to Paging's native use of common co-routines.
The library has also improved handling of invalidation race
conditions with a new return type, LoadResult.Invalid,
to represent invalid or stale data,
as well as improving handling of no-op loads and operations
on empty pages with the new on pages
presented and add-on pages updated listener APIs.
And to help developers ramp up on Paging 3,
we've added a simpler Getting Started Paging code lab
on the Android Developer site.
The Navigation library provides a framework
for moving between destinations in an app,
and the latest version includes quite a few improvements.
First, the new Navigation Compose artifact
provides integration between the Navigation component
and Jetpack Compose.
It uses composable functions as the destinations in your app.
Support for Multiple Back Stacks has gotten easier as well.
Navigation UI now automatically saves
and restores the state of pop destinations, meaning,
developers can support Multiple Back Stacks without any code
changes.
Large screen support has also improved,
with a navigation fragment artifact providing
a pre-built implementation of a two-pane layout
in abstract list detail fragment.
This fragment uses a sliding pane layout
to manage a list pane, managed by your subclass,
and a detail pane, which uses a NavHostFragment.
Finally, all navigation artifacts
have been rewritten in Kotlin and feature improved
nullability of classes using generics,
such as NavType subclasses, with more usability
improvements to come.
The DataStore library is a powerful and reliable
replacement for many SharedPreferences use cases.
Last year, we showed examples of using DataStore,
and this year, we're providing a new series
of videos and articles within modern Android development
skills focused on DataStore, including guidance
on testing your app's usage of the library
and using it with dependency injection.
We've just covered some of our key architecture libraries.
If you'd like to learn more about how they all
fit together, we've created additional content
in a series called Modern Android Development Skills--
Architecture.
It's a collection of videos and articles
covering best practices for modern Android development,
including deep dives on the libraries
that we've talked about today.
We've also been hard at work putting together libraries
to help developers assess and improve
the performance of their apps.
The JankStats library helps you track and analyze
performance problems in your apps,
including reports on dropped rendering frames,
commonly referred to as jank.
JankStats builds on top of existing Android platform APIs,
such as frame metrics, but can be used down to API level 16.
The library also offers additional capabilities
beyond those built into the platform, heuristics that
help pinpoint causes of dropped frames,
UI state that provides additional context in reports,
and reporting callbacks that can be used
to upload data for analysis.
First impressions matter for users,
and the speed of your app right after installation
can make a big difference on user retention.
To improve that experience, we've
created Baseline Profiles.
Baseline Profiles allow libraries
to provide the Android runtime with metadata
about code path usage, which it uses to prioritize
ahead-of-time compilation.
This can make apps faster and reduce
dropped frames the first time a user interacts with an app.
This profile data is aggregated across libraries and lands
in an app's APK as a baseline.prof file,
which is then used at install time
to partially pre-compile the app and its statically
linked library code.
We're already using Baseline Profiles within Jetpack.
We've added Baselines to popular libraries,
like Fragments and Compose, to help provide a better end-user
experience.
To create your own Baseline Profiles,
developers will need to use the Macrobenchmark library, which,
in addition to helping with generating baselines,
help developers better understand their app's
performance and can be used to assess complex use cases,
including app startup and integrated UI operations,
such as scrolling a RecyclerView or running animations.
Recent updates to the library have greatly
increased testing speed and added
several new experimental features,
including custom trace-based timing measurements
using TraceSectionMetrics, which allows developers
to benchmark specific sections of code;
AudioUnderrunMetric, which enables
detection of audio buffer under-runs
to help understand audible jank; and baselineProfileRule, which
can generate profiles to help with runtime optimizations
that we've just described.
baselineProfileRule works similarly
to other macro benchmarks where you represent user actions
as code within lambdas.
In this case, the critical user journey
that the compiler should optimize ahead of time
is a cold start, opening the app's landing activity
from the launcher.
For more details and a full guide on generating and using
Baseline Profiles with Macrobenchmark,
check our guidance on the Android developer site.
For developers interested in profiling their apps'
performance, the Tracing library enables accurate event
tracing in non-debug builds down to API level 14,
similar to the manifest tag, which
was added in API level 29.
Rounding up recent User Interface changes,
we've got developments in large-screen compatibility,
foldables, and emoji support.
The new WindowManager library helps
developers adapt their apps to new form factors,
like foldables, by providing a common API surface with support
down to API level 14.
The initial release targets foldable device use cases,
including querying physical properties that
affect how content should be displayed,
and future versions will extend to more display
types and window features.
Jetpack's SlidingPaneLayout component
has already been updated to use WindowManager's smart layout
APIs to avoid placing content in occluded areas
such as across a physical hinge.
The new DragAndDrop library also assists with new form factors
and windowing modes, allowing developers
to accept drag-and-drop data both from in
and outside their app with a consistent drop target
affordance, and it supports down to API level 24.
Most developers will be familiar with the AppCompat library,
which provides foundational back ports of UI features
like dark mode and tinting.
Starting in 1.8, we've integrated AppCompat
with the Emoji2 library to bring default support for new emoji
to all text-based views supported by AppCompat
on API level 14 and up.
We have also backported custom locale selection from API level
33 down to API level 14, including
support for downloading additional locales using
Play splits.
This is available in the latest 1.9 alphas of AppCompat
and allows for manual persistence of locale settings
across app starts.
Note that you'll want to avoid storage mechanisms
like SharedPreferences that perform disk access when you're
storing your preferences.
The feature also supports automatic persistence
via a service meta-data flag which tells the library
to load the locales asynchronously and recreate
any running activities as needed.
On API level 33 and above, however, persistence
is managed automatically by the platform
with no additional overhead.
And now I'll hand over to on Anna-Chiara
to talk about the latest in Jetpack Compose.
ANNA-CHIARA BELLINI: Compose has been stable since July
last year, and it launched with a full set of UI components
to allow you to build UI in a modern and declarative way.
While it's been only a few months,
we're seeing great adoption with over 100 of the top 1,000 apps
now using Compose.
We worked closely with some of them
in their journey to deliver UIs written in Compose to millions
of users.
And we have published several developer stories and case
studies to show you how successfully they
adopted Compose, even in the most critical parts
of their apps, and how their productivity, code
health, and delivery time have improved.
If you search for anything on the Play Store
or if you use Twitter communities, the UI you'll see
is written in Compose.
And today, you can learn about Airbnb's experience,
so go check it out.
But we know that we're not done.
And in the last several months, we
focused on adding features to support your most advanced use
cases and making Compose as powerful as the view system,
but way easier.
Let's see what is new.
As you progressively integrate Compose in your existing apps,
you need solid, reliable interoperability between views
and Compose, especially in common use cases
like nested scrolling.
Starting with Compose 1.2, embedding a scrolling
composable in a coordinator layout is much smoother,
and things like the collapsing toolbar are easy to set up.
We are still working on improving
all the possible permutations of views, RecyclerViews,
and LazyLists, so please continue to give us feedback.
We know how important fonts are for your branding.
Up until now, you had to either rely
on fonts delivered with the Android platform, which
can vary on different devices, or bundled fonts with your app,
increasing the APK size.
Starting with Compose 1.2, you can use downloadable fonts
just like with views.
You can express your brand at its best while taking
advantage of shared font caches and dynamic font resolution.
One Compose feature that dramatically improves developer
productivity is how you can use LazyLists instead
of very verbose RecyclerViews.
But we know that your needs go beyond the simple rows
and columns.
So we're expanding the lazy loading of elements
to more advanced layouts like grids and custom layouts.
For details, check the Lazy Layouts in Compose Talk.
With Compose changing the way UI is created
at a fundamental level, you need new tools
to support your productivity.
You've been asking for tools to understand
and debug recomposition and for faster updates.
So if you've missed the What's New in Android Studio talk,
I suggest you go take a look and see the exciting announcements.
To help you make the most of Compose,
we are publishing a set of new talks, called Labs and Docs,
targeting intermediate or advanced use cases.
In particular, we've seen some developers struggle
with writing a performance UI while getting
used to the Compose programming model.
The talk about commons performance gotchas
and the new documentation on performance
should help you avoid those pitfalls.
If it's that you're just getting started
with Android development or Jetpack Compose,
we recently released that the first few units of the Android
Basics with Composed course.
And if you're watching this talk on the I/O website,
congratulations.
You've just got yourself a new badge for your developer
profile.
You can earn up to four badges by completing two more steps--
take the Migrating to Jetpack Compose Code Lab
and follow the Jetpack Compose Setup Guide.
You can earn more developer profile badges for learning
about our latest technologies.
See how at g.co/learntoearn.
In Android, we're full steam ahead with Compose,
and we're not stopping at phone UIs.
If you want to see how to go beyond resource qualifiers
when targeting different device sizes,
like tablets and foldables, you will not
want to miss the talk about implementing Android
apps for all screen sizes.
And if you're taking your device reach a step further to WearOS,
you'll be happy to use the same intuitive, powerful Compose
APIs for your app.
Go check the talk to see how.
And that's all for Compose.
Back to you, Alan.
ALAN VIVERETTE: Thanks, Anna-Chiara.
Before we close out, I'd also like
to talk about some recent developments in the Annotations
library, some additional talks, and our GitHub.
The annotation library provides familiar annotations
like NonNull that pair with lint checks
to improve the correctness and usability of code.
First and most importantly, we're
working on migrating the annotation
library to Kotlin sources.
This means that Kotlin developers will
see more appropriate annotation targets, including file,
and that annotation now depends on the Kotlin standard library.
We've also added a number of highly requested annotations
with corresponding lint checks, including several concerning
method or function overrides, and the DeprecatedSinceApi
annotation, which provides a corollary to RequiresAPI
and discourages use beyond a certain API level.
We also have exciting news for developers using the media
libraries.
Media3 has launched, which includes
the initial stages of merging ExoPlayer and providing
a unified API surface.
You can learn more about that in the What's
New in Android Media talk.
The fragment library has also been undergoing
some serious changes.
Check out the Fragments-- the Good, Non-Deprecated Parts
to learn more about StrictMode and other best practices
for modern fragment usage.
And continuing our themes of performance and Compose,
learn more about Compose performance
with the Common Performance Gotchas in Jetpack Compose
talk.
And finally, I'd like to draw your attention to our GitHub
where we now have over 100 modules, and more on the way,
open for contributions using the standard GitHub-based workflow
that developers expect.
Please check the landing page for more information
on how we handle pull requests and to get started writing code
in Jetpack.
You can learn more about recent Jetpack releases
or check out the MAD Skills video series at our Android
Developer site.
Thanks for watching.
[MUSIC PLAYING]