In 2018, at Google I/O, Android introduced a next-generation suite called Jetpack to accelerate Android development. Android Jetpack is a set of components, tools, and architectural guidance, that makes it quick and easy to build great Android apps. Components are unbundled but built to work together while leveraging Kotlin language features to make developers more productive. Technically, Jetpack consists of the existing support library, architecture components, and Android-ktx, in separate modules and rebranded in an adaptive way providing coverage for lifecycle management, robustness of data states, background tasks, navigation, and much more.

Source-: https://android.jlelse.eu/what-is-android-jetpack-737095e88161

As represented in the illustration above, Jetpack combines four major categories.

  • Foundation
  • Architecture
  • Behavior
  • UI

Each section consists of both old and latest components. The older components have been in use for quite a while. This post will focus mainly on a few newly developed components such as navigation, paging, Android KTX, and WorkManager.

Navigation

Source -: https://medium.com/@Alex.v/android-navigation-architecture-component-25b5a7aab8aa

The navigation component

  • Reduces boilerplate code to fragment transactions and reverse events – where the component is smart enough to navigate itself – and include bundle data if needed at runtime, based on provided navigation destinations and actions.
  • It gives developers an opportunity to navigate through the view hierarchy, similar to a storyboard in Xcode.

When it comes to passing data through the bundle, the navigation component library comes with a Gradle plugin called Safe Args to avoid mistakes made by developers such as passing random bundles or using the wrong keys to extract data.

Migrating to the navigation component is pretty straightforward; simply following the steps below would be adequate.

  • Create a navigation graph for separate activities if required.
  • Link separate activities through activity destinations, replacing existing startActivity()
  • In case multiple activities share the same layout, navigation graphs can be combined, replacing navigate calls to the activity destinations to navigation graphs

Paging

Apps work with enormous sets of data but only require the loading of a small portion of this data for a given timeframe. This should be a key consideration for a developer since it causes the battery to drain and wastes bandwidth. Jetpack provides a paging library to overcome this challenge by enabling gradual and graceful data loading. Furthermore, it can be integrated into RecyclerView and works with both LiveData and RxJava.

The Paging library consists of the following core elements.

  • PageList
  • DataSource

PageList is a collection that has the capability to load data as chunks asynchronously.

DataSource is the base class for loading snapshots of data to the PageList. The illustration below provides an easy guide on how data loads from the data layer to the UI components

Assuming the database is your data source and will pass the data to be created, DataSource allows the data to be handled in a repository with LiveData that is created by LivePageListBuilder. Then, through the ViewModel, data will navigate to PageListAdapter API which provides from the paging library to help present data from the page list to RecyclerView. PageListAdapter will use the Diffutill class to find new data and notifies automatically.

Refer to the following links for more details

https://developer.android.com/topic/libraries/architecture/paging/

https://medium.com/@sharmadhiraj.np/android-paging-library-step-by-step-implementation-guide-75417753d9b9

https://medium.com/@Ahmed.AbdElmeged/android-paging-library-with-rxjava-and-rest-api-e5c229fd70ba

Android KTX

Android KTX is another feature that comes with Jetpack that provides a set of Kotlin extensions. The purpose of Android KTX is to give more concision, reduce the lines of code and make them more readable. Refer to the following sample codes.

Kotlin

sharedPreferences.edit() 
    .putBoolean("key", value) 
    .apply() 

Kotlin + KTX

sharedPreferences.edit { 
    putBoolean("key", value) 
} 

Kotlin

Toast.makeText(this, 
    R.string.text, 
    Toast.LENGTH_SHORT) 
.show()

Kotlin +KTX

context.toast(R.string.text,) 


Kotlin

for (recipe in recipes) print(item)


Kotlin+KTX

recipes.forEach{ 
print(it)
 } 

Pretty simple, isn’t it? It’s fun and simple to understand.

WorkManager

Assuming you need to execute a task immediately or at a pre-scheduled time, Jetpack provides an optimal solution called the WorkManager. WorkManager is smart enough to execute the task based on the device’s API level and the app state.

Imagine the application wants to run a task in the foreground, WorkManager runs it in a separate thread inside the app’s processes. If the app is in the background, it will schedule a background thread based on the device’s capabilities. WorkManager might use JobScheduler, Firebase Job Dispatcher, or Alarm Manager. Basically, WorkManager has the power to select the best option based on the device’s capabilities and execute the appropriate API, reducing the boilerplate code to figure out the potential device’s state.

With all the new features mentioned above, it is evident that Jetpack is a great option for developing Android apps. I personally love Jetpack because of the boost in efficiency that it brings and for allowing me to focus more on application logic, reducing boilerplate code writing to a minimum.