This article was first published on Android platform Kotlin, welcome to follow!

In the last issue of What is Jetpack? According to Google’s official definition of Jetpack, we extracted two core points:

  1. It is a set of component libraries.

  2. Using Jetpack helps us implement working code that behaves consistently across Android versions and devices.

At the same time, I also classified and marked Jetpack’s 85 component libraries in detail, which were divided into 7 categories to help you understand what these component libraries are for from a global perspective, so that we can quickly choose appropriate components in different scenarios and help ourselves to complete the realization of corresponding functions.

For those of you who haven’t, check out the previous article

Today we’ll talk about the second question in the definition: why does Jetpack help us implement working code that behaves consistently across Android versions and devices?

Jetpack, AndroidX, and Support libraries

Jetpack and AndroidX are the same thing, from a product perspective it’s called Jetpack, and from a technical perspective it’s called AndroidX. All of the component libraries in Jetpack currently have package names that start with AndroidX.

For the first time in 18 years of Google I/O, the Android team introduced a new support library: AndroidX is the Alpha version of AndroidX, which is designed to solve the long-standing Support library confusion. You can also think of AndroidX as a more powerful Support library.

What does the Support library do?

In previous Iterations of Android updates, all feature updates were released with each specific Android release, such as Fragment in Android 3.0, The Material Design component is updated on Android 5.0. Due to the large number of Android users, every Android update cannot cover all users. At the same time, due to the large number of mobile phone manufacturers, but limited support, You can’t keep iterating to the latest Version of Android for all the devices you produce, so the Android versions on the devices you own are fragmented.

From a technical point of view, Android engineers will encounter many difficult problems when maintaining projects due to the inconsistency of device versions among users.

In order to solve these compatibility problems caused by the inconsistencies of Android versions, Google has introduced the Support library.

The Support library is a complement to the Framework API, which is released with every Android version and has strong relevance to the device. The Support API is integrated by the developers themselves and will eventually be included in our released applications. This allows us to develop applications on the latest versions of Android, while addressing potential compatibility issues using the Support API to help developers implement working code that behaves consistently across devices with different Versions of Android.

What are the drawbacks of the Support library?

The first Support library was released in 2011 with the version number: Android.support. v4, also known as V4 library. In 2013, based on V4, the Android team released v7 library with the version number: Android.support. v7, followed by V8, V13, V14, and V17 for specific scenarios.

If you just started learning Android a few years ago, you must be very confused about these strange numbers. What do 4, 7, 8, 13, 14, 17 mean?

For example, the first generation of support library V4 was originally intended to be used as a minimum support for API 4 devices. V7 is the minimum support for API 7 devices. However, as Android releases continue to update, API 4 and API 7 devices have long been obsolete.

In July 2017, Google increased the minimum VERSION of API supported by all Support libraries to API 14. However, because the package name cannot be changed, the previous V4 and V7 naming standards are still used. Therefore, the first problem that cannot be solved by the Support library is the confusion of version growth.

At the same time, the Support library also faces a very serious problem: heavy dependency caused by the architectural design itself. The earliest Support library is V4. V7 is a supplement based on V4. Because V4 and V7 are too large and have concentrated functions, if you want to develop new Support libraries, you can only carry out secondary development on the basis of V4 and V7. RecyclerView, CardView, etc.

So it may be severe repeated dependent problem, used in both the official repository, or a third-party library, we all need to keep the whole project Support library version is consistent, I believe that a lot of people on this issue on pit, although is there a way to solve this problem, but virtually increase a lot of work.

We all know that composition is better than inheritance, but the Support library was originally designed to favor inheritance over composition. I guess that’s because the people who developed the Support library were the same people who developed the Framework API. There are various types of inheritance logic in the Framework API, such as activities, fragments, and Views.

Although Google tried to split the Support library in the later stage, for example, it launched independent Support libraries: Support: Design, Support: CustomTabs, etc., but it could not solve the problem of dependency from the root.

The emergence of the Jetpack

So to solve these two deadly problems once and for all:

  1. Support library version growth disorder

  2. The Support library has repeated dependencies

AndroidX has split the Support library into 85 Support libraries, ditched the version naming convention associated with minimal API Support, and replaced it with 1.0.0. And each library is later versioned according to strict semantic versioning rules.

At the same time, by combining dependencies, we can choose the component library we need instead of relying on all of them like Support, which reduces the size of the application to some extent.

At this point, if you understand the purpose of Support in the first place, you should be able to understand why Jetpack helps us implement working code that behaves consistently across Android versions and devices.

It’s important to note that it doesn’t change with a particular Android release, it’s controlled by the developer and included in the apps we release.

If Jetpack were just a refactoring of the Support library, it wouldn’t be a big deal, because it would just be Google solving its own historical code problems.

More importantly, Jetpack provides you with a set of best practices, including: Architecture, data processing, background task handling, animation, UI, all that stuff, you don’t have to worry about all the things that Android has to do with, but you have to focus on the business requirements, and that’s what’s really great about Jetpack.

For example, if you want to process data securely and asynchronously, you now have DataStore. For easy dependency injection, Hilt is now available; For secure page Navigation, you now have Navigation; If you want to implement MVVM architecture, there are LiveData and ViewModel to help you.

If you follow the Android documentation as often as I do, you’ll find that the explanations, examples, and best practices are much more detailed and updated frequently. If you’re new to Android, reading the Android documentation is a great way to get started. If you’re an experienced Android developer, keep an eye out for updates to the official Android documentation so you don’t become obsolete by the technology.

If Android’s first decade was built on a thriving ecosystem of open source communities, I think Jetpack will help Android get better in the next decade.

Thanks for watching and let me know in the comments, what would you like to know about Jetpack? I’ll be back with more Jetpack articles later.

If the content of this issue is helpful to you, I hope you can forward, comment and like, so that more people can see this article, which will also be of great help to me.

Thanks, and I’ll see you next time.