When it comes to Jetpack, everyone thinks of it as a bunch of frames, but it’s actually much bigger. This article takes Preference component as the starting point, and explores its past life step by step.

Preference as a standard to set the picture, we are not unfamiliar. This component was born with the Android system and has changed since then. First a separate version appeared in the Support library, then was integrated into AndroidX, and finally, with Android 10, the SDK version was scrapped completely.

1. Design of Preference

The Preference component API is designed to be very simple and clear.

  • A PreferenceActivity or A PreferenceFragment manages the lifecycle and event interaction of the screen
  • PreferenceScreen builds the entire list of Settings
  • PreferenceCategory and Preference show a set or a single set of Settings
class role
PreferenceActivity Provides a Preference layout setting and a lookup ListActivity
PreferenceFragment Display the Fragment specific to the Preference layout
Preference The base class for all Preference components presets the basic API that Preference handles
PreferenceGroup Extends from Preference to nest Preference components and manage them with a built-in List
PreferenceScreen Extension from PreferenceGroup, nested in the root layout of Preference component, internally manages the list View and corresponding Adapter
PreferenceCategory Extended from PreferenceGroup to show a subtitle that sets the group of items, non-clickable, non-focus
SwitchPreference The Switch control has a built-in Preference component. Similar extensions include ListPreference, EditTextPreference, and so on
.

2. Lonely SDK

Preference component is Android 1.0 released on the introduction of the old class components, that RecyclerView has not yet launched, naturally using the classic ListView to build the entire list of Settings.

It’s very simple to use, just like a normal view.

<PreferenceScreen android:title="@string/my_preference_settings">
    <PreferenceCategory
        android:title="@string/my_preference_general" >
        <Preference
            android:fragment="com.android.settings.applications.ManageApplications"
            android:key="app"
            android:title="@string/my_preference_general_apps" />
    </PreferenceCategory>.</PreferenceScreen>
Copy the code
public class SettingsActivity extends PreferenceActivity {
    public void onCreate(Bundle bundle) {
        super.onCreate(bundle); addPreferencesFromResource(R.xml.my_preference_layout); }}Copy the code

The principle is not complicated:

  1. The PreferenceManager and PreferenceInflater are responsible for resolving the Preference layout and building the Preference instance tree
  2. PreferenceScreen creates a PreferenceGroupAdapter instance using the Preference instance tree and binds it to the ListView view
  3. Adatper#getView() calls back to the onBindView() of each Preference component to prepare the corresponding View

The ListView’s performance is poor, and it no longer works well with complex Settings screens, especially those of a system Settings App with lots of content.

3. Melee Support library

The Support library is a Support library that provides backward compatibility for new apis. It contains a large number of functional classes such as application components, views, Material Design, and so on. The rewritten Preference component is also included.

Depending on the version of the compatible API, the Support library branches are numerous and messy, making it increasingly tedious and cumbersome to use.

V7 package

The Preference component is changed for the first time in the V7 package of the Support library, mainly by copying the Preference component from the SDK version and rewriting it.

The external API is just fine-tuning, and the differences are mostly focused on the internal implementation details:

  1. No longer provides a dedicated PreferenceActivity, only a dedicated class for fragments
  2. PreferenceScreen for setting lists is changed to RecyclerView for better performance
  3. Add the PreferenceViewHolder class to reuse the view of the set item
  4. Preference removes the onBindView() API and adds itonBindViewHolder()To provide a view of the item to RecyclerView

In addition, for the implementation of large changes in the API, in the original name of the Compat word, such as PreferenceFragment to PreferenceFragmentCompat.

Import additional dependencies to use:

Implementation 'com. Android. Support: preference - v7:28.0.0'Copy the code

In addition to pay attention to is loaded in the fragments of the layout of the API by addPreferencesFromResource () instead of setPreferencesFromResource (). Since the API is just tweaked, little else has changed in usage.

public static class PrefsFragment extends PreferenceFragmentCompat {
    @Override
    public void onCreatePreferences(Bundle savedInstanceState, String rootKey) { setPreferencesFromResource(R.xml.preferences, rootKey); }}Copy the code

V14 package

The second change occurred in the V14 package. The difference was that the word Compat was removed from the name and the API difference from the SDK version was weakened.

Such as:

  • PreferenceFragmentCompat → PreferenceFragment
  • SwitchPreferenceCompat → SwitchPreference
  • PreferenceDialogFragmentCompat → PreferenceDialogFragment

Import requires only minor adjustments:

Implementation 'com. Android. Support: preference - v14:28.0.0'Copy the code

V17 package

As Android became more popular on larger devices like TVS, Google introduced Leanback navigation, which was introduced in V17. The Preference component also follows the Leanback pattern with a series of new components.

The new class role
BaseLeanbackPreferenceFragment Swiss Army Knife style PreferenceFragment abstract base class, internal integration of the VerticalGridView control
LeanbackPreferenceFragment The outer package of the title BaseLeanbackPreferenceFragment subclasses
LeanbackSettingsFragment Root for the Fragment components LeanbackSettingsRootView layout, main and LeanbackPreferenceFragment cooperate to use
LeanbackPreferenceDialogFragment Leanback Fragment component with DialogPreference
LeanbackListPreferenceDialogFragment Take ListPreference LeanbackPreferenceDialogFragment components

4. AndroidX

For example, the Preference components in the Support library branch correspond to AndroidX:

Support library AndroidX
com.android.support:preference-v7 androidx.preference:preference
com.android.support:preference-v14 androidx.legacy:legacy-preference-v14
com.android.support:preference-leanback-v17 androidx.leanback:leanback-preference

It is also easy to use, just specify the corresponding package name and version:

Def preference_version = "1.1.1" implementation "androidx preference: preference: $preference_version"Copy the code

AndroidX and the original Support library API mapping, you can query the official mapping table:

  • Package: the relationship between developer.android.com/jetpack/and…

  • Class mapping relationship: developer. The android. Google. Cn/jetpack/and…

Is it different from the Support library?

Comparing the core Preference class shows that the code logic is almost identical except for differences in format and writing style.

AndroidX provides the PreferenceFragment class, which is implemented almost idenically to the Support library version.

AndroidX replaces the original support library APIs with packages in the androidx namespace. Only the package and Maven artifact names changed; class, method, and field names did not change.

As officially described, AndroidX is an integration and replacement for the Support library. The only difference is the repository address and package name. Because of this, AndroidX has a clear and unified version management, making it easy and flexible for developers to use.

ROM development needs attention

Previously, new apis, such as Preference components, were distributed in various branch packages of the Support library. Source files were also integrated into the AOSP source code, which ROM vendors could modify.

For example, the Preference component of the V14 package is located in the AOSP source code.

​ /frameworks/support/v14/preference/src/android/support/v14/preference/

Android 9 was initially integrated into AndroidX, but the source files were retained in the AOSP source code for the transition. We can still modify the source code.

​ /frameworks/support/preference/src/main/java/androidx/preference/

Android 10 starts to move all over to AndroidX, eliminating the Support library altogether. AOSP source code is no longer integrated, only the corresponding AAR package is provided, which also makes it difficult for ROM vendors to change the implementation, requiring extra attention.

​ /prebuilts/sdk/current/androidx/m2repository/androidx/preference/

How do I migrate to AndroidX

To simplify backward compatibility development, it is necessary to fully migrate the Support libraries to AndroidX. Just set the Gradle plugin flag below.

  • android.useAndroidX: The Android plugin uses the corresponding AndroidX instead of the Support library
  • android.enableJetifier: Android plug-ins automatically migrate existing third-party libraries to use AndroidX dependencies by rewriting their binaries

Migrating to AndroidX: Menu → Refactor → Migrate to AndroidX can also be manually migrated from the AndroidStudio Menu.

More detailed migration details can be found in this article:

www.jianshu.com/p/41de86896…

The composition of AndroidX

Based on the official list of components of AndroidX, I have summarized and created a map of the components of AndroidX.

As you can see, In addition to integrating with the Support library, AndroidX actually includes a number of well-known Jetpack frameworks, which are actually derived from the Android Architecture Components (AAC) released in 2017.

5. Transient AAC library

There are many pain points in Android App development, including dull management of Activity/Fragment lifecycle, complex data transfer between threads, and tedious SQLite encapsulation. To improve on this and guide App Architecture, Google IO 2017 has released Android Architecture Components, or AAC.

It contains several classic frameworks:

  • Lifecycle
  • LiveData
  • ViewModel
  • Room
  • Other thingsPaging,NavigationandWorkManager

Google also showed Android developers the recommended application architecture, which at first looks a little simpler as the Jetpack family grows.

The AAC library is in the process of being improved and migrating to AndroidX along with the Support library, giving rise to a much bigger and stronger concept called Jetpack.

6. Who is Jetpack

Just over a year later, Android Architecture Components is out of the picture, and a new Jetpack development suite has been released at Google IO 2018.

  • The core Architecture module covers the familiar framework, formerly the AAC library, which was released last year

  • And packages integrated from the Support libraries, such as Preference, Framgent, AppCompat, and more

  • In addition, the KTX and Test kits are also included

Android Jetpack is a set of libraries, tools and architectural guidance to help make it quick and easy to build great Android apps. It provides common infrastructure code so you can focus on what makes your app unique.

So it’s not accurate to think of Jetpack as a series of frameworks. It’s actually a suite of frameworks, KTX, development tools, and development wizards designed to improve the efficiency of Android development on multiple levels.

  • Provides best practices for Android App development
  • Eliminating a lot of boilerplate code makes it easier for developers to write great applications
  • Provides backward compatibility, providing consistent development experience on devices of different versions and configurations
  • Change the clutter of fragmented versioning

What’s the relationship with AndroidX?

The source code management for the Jetpack development suite is available on AndroidX, including the previous Support libraries, the later AAC libraries, and so on. The evolution of Jetpack is briefly plotted. (Painting, painting into the image of Android robot, ha ha)

If you have to sum up the relationship between Jetpack and AndroidX, it’s as well described by the great god fundroid.

AndroidX is an internal management pack for apis outside of the SDK, and Jetpack is a publicised development suite.

“AndroidX” is a cool name, so why not just use it for promotion? Some personal understandings:

  • The name “AndroidX” is too abstract to understand and has no particular meaning
  • “Jetpack” means “Jetpack” or “booster”, which can better convey the original design intention of boosting development efficiency and is easy to understand and spread. With the Android Logo to create a rocket robot image, very interesting and recognizable

7. Jetpack Memorabilia

  • In March 2011, the first version of the Support library V4 package was released
  • In October 2014, the Support library added RecyclerView, AppCompat Support
  • In August 2015, Preference Support was added to the Support library
  • In February 2016, VectorDrawable Support was added to the Support library
  • On May 17, 2017, Google IO 2017 announced the release of Android Architecture Components
  • Android Architecture Components 1.0.0 beta was released on September 21, 2017
  • In March 2018, the Support library code was gradually integrated into AndroidX
  • On May 8, 2018, the Android Architecture Components code was gradually moved to AndroidX
  • On September 21, 2018, Google IO 2018 released AndroidX, along with the Jetpack development kit, ending the Support library and moving to AndroidX
  • On May 7, 2019, Jetpack CameraX 1.0.0 Alpha was released
  • On July 22, 2020, Jetpack Hilt 1.0.0 Alpha was released
  • On March 10, 2021, the beta version of Compose 1.0.0 was released

8. Google

Android has too many branches, too many iterations, and developers are struggling to cope. Google has been trying to change this mess, from the classic Support library, to the transformative AAC library, to the continuing popularity of the Jetpack suite.

At the same time, as The Android system gets better and the SDK becomes more stable, the annual OSV will eventually be a tinker. However, the continuous development of the industry will inevitably give rise to an endless stream of new ideas and technologies. Google, of course, is not going to stop. It’s going to change and respond with more frequent and larger initiatives, and it’s going to focus on areas outside the SDK, like Jetpack, MAD, etc.

MAD, or Modern Android Development, is Google’s new concept for the Android platform. It takes a higher view than Jetpack and aims to guide new Android development through languages, tools, release formats, frameworks, and more.

In addition to the Jetpack suite MAD also includes:

  • Official IDE for continuous improvement,Android Studio
  • Android firstKotlinDevelopment of language
  • advancedAndroid App BundleIssuance of format
  • The future of UI developmentComposekit

MAD is an important technology that every Android developer should know and master, and I’m going to explain this new development concept.

The resources

Version description for AndroidX

Description of the Support library

The composition of the Jetpack

Application Architecture guide based on Android Architecture Components

Jetpack’s relationship to AndroidX

Recommended reading

The new widgets on Android 12: beautiful, easy and useful

The new app splash screen on Android 12.

Fully retrieve Backup features that Android developers tend to overlook