[4] Android Introducing Jetpack - mariamaged/Java-Android-Kotlin GitHub Wiki

Android - Introducing Jetpack

1. Key Elements of Jetpack

1.1 Layout

  • By "Layout", Google is referring to the overall widget-based UI setup.
  • Layout resources - and the widgets they use - are essential for most Android apps.

1.2 Fragment

  • A layout does not exist on its own.
    • Something has to arrange to use a layout resource and show it one screen.
  • Fragments are wrappers around layout resources and their widgets.
    • Many apps might consist of a single activity, with each different "screen" being represented by a fragment that uses associated layout resources and code.
  • The user, as part of using the app, will switch from fragment to fragment as needed - for example, clicking a button might cause another fragment to be shown on the screen.

1.3 AppCompat

  • It gives us an API for our activities and fragments that resembles the latest-and-greatest version of Android.
  • When your app runs on older devices, AppCompat tries to fill in the gaps of UI functionality where it can.

1.4 Data Binding

Our Android user interfaces are going to have all sorts of widgets:

  • Fields.
  • Buttons.
  • Checkboxes.
  • List.
  • Some of them, such as fields, usually are static: we set up their properties in a layout resource and do not need to change them.
     
  • Others, though, will need to be filled at runtime, such as populating a form with data that we obtain from a Web service or database.
  • Similarly, we will need to respond to user input supplied to those widgets, such as reading in that form and updating the database when the user clicks "save".
     

We can do all of that work from our Java/Kotlin code.

  • Data binding: allows us to add smarts to our layout resources, using snippets of code that look like Java/Kotlin.
    • Our layout resources can contain simple rules for pulling data from our app, rather than use writing code to push data top the layout from our activities or fragments.

1.5 Navigation

While some apps might have just one screen of information, most have more than one.

Users click on widgets and are taken to other screens.
Users then press the BACK button and return to the screen they had on originally.
And so forth.

  • We had ways of accomplishing this sort of navigation since Android's introduction.
    • However, it involves Java/Kotlin code, and sometimes quite a bit of it, for complex interactions.
  • Google keeps trying to move some of that sort of work into resources, where it can.

1.6 Lifecycles, ViewModel, and LiveData

  • It turns out that our activities and fragments have "lifecyles", and they come and go not only based on user navigation but also these configuration changes.
  • Keeping our state as the user rotates the screen is important.
  • To that end, Google nowadays offers two Jetpack pieces to help with this:
    • Special code for dealing with lifecycles.
    • A ViewModel class that helps maintain our state across configuration changes.

1.7 Permissions

Some things that may want to do in our app require user permission.

  1. Permission to get at personal data of their contacts.
  2. To send SMS messages on their behalf.

Sometimes, the concern is privacy and security.

Sometimes, the concern is cost, whether in terms of money or in terms of system resources, such as battery consumption.

  • Google has declared certain APIs to be protected by permission.
  • Before we use those APIs, we need to ask permission from the user.
    • This involves putting some entries in our manifest to say what we want in general.
    • It also involves having some code that specifically requests the permission the first time that we have a concrete need for it.

1.8 Room

Many apps need a database on the device.

  • Sometimes, the database serves as more of a local cache, for data -
    • That we obtained from a server.
    • That we need to get to a server.
  • Sometimes, that is the "system of record", as the data is only on the device.
     
  • Room also works nicely with LiveData, to help you do your database I/O on background threads.

1.9 WorkManager

Many times, the work that we need to do on background threads has to be performed in near-real time.

But sometimes the work that we need to do can happen totally independently from what the user may (or may not) be doing in our UI.

  • We can teach WorkManager about background work to be performed, then schedule that work to occur.
  • That schedule might be based in part on:
    • Time ("do it soon", "do it every few hours", etc).
    • State of the device ("do it when the device is on a charger", "do it when the device is on WiFi", etc).

1.10 Android KTX

  • One of Kotlin's features is the "extension function": this is a way for a library to add functions (Java methods) to somebody else's Java/Kotlin class.
  • For developers using the class, the extension functions are seamlessly integrated with the functions that were part of the class from the outset.
     

Android KTX is a collections of such extension functions, designed to make common aspects of the Android SDK a bit easier

2. What Came Before: Android Support Library

  • The Jetpack libraries are all AndroidX libraries, where we will be referring to libraries and Java packages that have androidx in their names.