Book Image

Android Studio 4.0 Development Essentials - Java Edition

By : Neil Smyth
Book Image

Android Studio 4.0 Development Essentials - Java Edition

By: Neil Smyth

Overview of this book

Android rolls out frequent updates to meet the demands of the dynamic mobile market and to enable its developer community to lead advancements in application development. This book focuses on the updated features of Android Studio (the fully integrated development environment launched by Google) to build reliable Android applications using Java. The book starts by outlining the steps necessary to set up an Android development and testing environment. You’ll then learn how to create user interfaces with the help of Android Studio Layout Editor, XML files, and by writing the code in Java. The book introduces you to Android architecture components and advanced topics such as intents, touchscreen handling, gesture recognition, multi-window support integration, and biometric authentication, and lets you explore key features of Android Studio 4.0, including the layout editor, direct reply notifications, and dynamic delivery. You’ll also cover Android Jetpack in detail and create a sample app project using the ViewModel component. Finally, you’ll upload your app to the Google Play Console and handle the build process with Gradle. By the end of this book, you’ll have gained the skills necessary to develop applications using Android Studio 4.0 and Java.
Table of Contents (88 chapters)
88
Index

38. Working with Android Lifecycle-Aware Components

The earlier chapter entitled “Understanding Android Application and Activity Lifecycles” described the use of lifecycle methods to track lifecycle state changes within a UI controller such as an activity or fragment. One of the main problems with these methods is that they place the burden of handling lifecycle changes onto the UI controller. On the surface this might seem like the logical approach since the UI controller is, after all, the object going through the state change. The fact is, however, that the code that is typically impacted by the state change invariably resides in other classes within the app. This led to complex code appearing in the UI controller that needed to manage and manipulate other objects in response to changes in lifecycle state. Clearly this is a scenario best avoided when following the Android architectural guidelines.

A much cleaner and logical approach would be for the objects within...