In the tenth year of Android’s existence, Android mobile app development should get faster. Google has also been listening to developers and trying to make Android apps more efficient. In the last year, we’ve heard from developers that lifecycle management is difficult for Android development, so we launched a lifecycle component. We also heard that the API gives you 5 or 6 different solutions for doing background tasks, so which one should you use most? To address these issues, Android JetPack was born.

We hope that JetPack will not only provide apis for various functions, but also give developers a blueprint to follow when developing mobile applications.

What is Android JetPack and what makes it

What is Android JetPack? Android JetPack is a set of components, tools, and architectural guides that link our existing Support library with architectural components. As you will see in a moment, these are all architectures and components that you are very familiar with and are using.

Android JetPack consists of four parts: architecture, interface, foundation, and behavior. See the figure below for details of each part

Last year, we launched architecture components, which were well received by developers. The advantage of architecture components is that you can solve the problems you encounter in the development process by using one or several architecture components. On the basis of last year, today we launch new architecture components, namely: WorkManager, Navigation and Paging. Paging has reached stable version, WorkManager and Navigation are still in alpha stage.

The second part of JetPack is behavior. Most of the components of the behavior category include familiar components, such as Download Manager for big data downloads, Media&Playback and Permissions for audio and video processing and Permissions. Notifications is the handling of push. These components have one common feature: they are backward compatible.

We also added a new component, Slices, to the behavior. Slices provides a new way of traversing data for applications, and is now covered in Google Assistant and Google Search.

The next part of JetPack is the interface, which includes sections for Fragment, Layout, Palette, Animation&Transitions, Auto.TV & Wear, Emoji, and more. We want the interface part to not only make the interface look better, but also to give users a good user experience.

The last part of JetPack is the foundation, which, as its name suggests, is an essential part of your application development process. We have introduced the Kotlin Extensions (KTX), which take advantage of the Kotlin language’s own features, such as extension functions, properties, etc., to help you write concise Kotlin code. AppCompat is a well-known backward compatibility library. V4 and V7 had a lot of problems in the development process, so we packaged it and released AndroidX, which you can use by using Android Studio3.2

Architectural components

Last year, we released a set of architecture guidelines and a set of components to complete the architecture guidelines. By using architecture components, you can make your application more modular and easier to test and maintain. The purpose of architectural components is to make Android development easier.

At last year’s GDD, we wanted to introduce four stable architecture components: Lifecycles, LifeData, Room, and ViewModel. As you can see in the figure below, the interface component is responsible for displaying the UI, the ViewModel is responsible for processing the UI data, and you can use LiveData to update the data and then update the UI. Respository is a unique data layer structure, and you can use Room for data persistence.

On this basis, we also introduced Paging, which can help you to better clip Paging data in RecyclerView. The stable version of the Paging library.

Next, let’s look at the two libraries that handle the alpha phase, Navigation. When users use your application, you design destinations for them, as shown in the image below. And guide the user through these destinations. Here are some guidelines we must follow for navigation:

  • There needs to be a common physical destination
  • Navigation state needs a stack to represent (last in, first out)
  • The up and back buttons of the system and application should provide a unified user experience
  • Good DeepLink support

Let’s take a look at the example of Deep Link (shown above). In this application, from the home page to the category to the content, step by step to such a page. Of course, your users can also go directly to the interface through a URL. When you’re a developer, what do you need to do in order to provide a consistent and predictable experience for your users? You need to unify the rollback stack. Developers in the solution to this problem, or their own navigation library logic to complete, or write a lot of code to achieve this function, but the code is not easy to maintain. And it’s error prone.

Navigation is designed to solve such problems. Navigation successfully solves the following problems:

  • Processing fragments the Transactions
  • Handling ‘Up’ and ‘Back’
  • Support Deep Link
  • Provides animation, jump effects

Navigation provides a visual Navigation editing interface in Android Studio. The visual interface is an XML file. Below is an example of an XML file.

We say Acitivty will act as an entry point for Navigation, making the Fragment a carrier of content. The Activity is only responsible for an overall navigation, and the middle part is hosted by a NavHost.

In order to obtain the NavController, we provide you with the following three methods

If you want to jump through a button an interface, we provide a convenient way to createNavigateOnClickListener, if you don’t want to use this method, we also offer to another method, reference to the image below

For Navigation jump animations, you can refer to the following image:

When navigating, we often need to pass parameters, but one of the issues we often need to consider when passing parameters is that we cannot ensure type safety. So Navigation comes with a plugin called Safe Args.

A common DeepLink type is usually a notification, Shortcuts, Widget, Action, or Slices, for which we provide a method called NavDeepLinkBuilder. NavDeepLinkBuilder can be used in the following figure:

For other deeplinks, such as urls or custom Scheme URIs, we need to add the < DeepLink > tag in the Navigation diagram

Due to time constraints, we can’t cover all the methods of Navigation, so we recommend that developers try Navigation for themselves after the conference

WorkManager

Another part of the Android development process that is very important to users, but also invisible to us, is running in the background.

From the beginning, we provided Background Services and AlarmManager, to API 21, we provided Jobs. For applications using Google Play Services, We also provide Firebase Job Dispatcher and GcmNetWorkManager. The chart above shows the distribution of Android versions in the app market. To cover these models on the market, you may need to write a long if and else code to determine the condition of the device and choose the appropriate API.

When it comes to background operation, we have to mention the problem of electric quantity of equipment. In the case of Background Services, applications often run in the Background, resulting in rapid battery consumption of the device. In order to solve this problem, Android has introduced features in recent versions to reduce the power consumption of the device. See the following figure for details:

For now, we have selected the following apis for running in the background:

So which of the apis shown above should we choose first? The answer is WorkManager.

WorkManager is an API that is as simple as a dowork() operation to control the execution of the daemon. It also supports backward compatibility. Whether or not you use Google Play services in your app, you can already use WorkManager.

For example, if we want to upload a photo, here is the WorkManager API I used to upload the photo

Upload an image to a file.

In this task, we override a doWork method. The doWork method runs in the background and returns whether the task was successfully uploaded or not.

After creating a task, we also need to create a task request:

What if we don’t have an Internet connection while uploading images? This requires us to add a constraint when creating a task:

How to determine whether the photo uploaded successfully? Here we can use LiveData to observe the task status:

I just showed you a new class called WorkStatus, which has two methods, getId and getState

If you want to compress your photos before uploading them, WorkManager also provides several methods that you can perform sequentially or synchronously.

First, create a compression task, and then create a upload task, and beginWith and then add the previous two tasks to the group, you can complete the task.

What if I want to upload multiple images? WorkManager also provides a method to do this by calling enqueue and adding multiple task requests to the method in turn.

When we need to select an image to upload, we need to enter a URI. When we need to do this task, we need an input value. In The WorkManager, we provide a Data as the input value.

First, we make a bundle for each URL we want to upload an image to, and pass it into our task request:

Get the address of the image to be compressed, and then save the address of the compressed image:

If we string these two tasks together, we have a WorkManager task chain like this:

How to cancel upload? CancelWorkById cancelWorkById cancelWorkById cancelWorkById cancelWorkById cancelWorkById cancelWorkById cancelWorkById cancelWorkById cancelWorkById

We recommend that you use Tags to tag your tasks:

We then use getStatusByTag to get the Tag task or cancel the task.

Another very important feature in background tasks is synchronization, and another feature of synchronization is that we don’t want to have multiple synchronization tasks at the same time.

In order to achieve this effect, we provide you with the UniqueWork method:

The specific implementation principle is as follows:

WorkManager is also in alpha stage. Welcome to use WorkManager after the conference.

Here are some resources on Androd JetPack, Navigation, and WorkManager that you are welcome to visit after the conference.

Thank you!

I’m going to follow this little sister on Twitter 😁.