Android and architecture

The Android operating system provides a powerful foundation for developing applications that work well on a wide variety of devices and form factors. Now, as they say, we have heard the complaints of the developers: it is difficult to create "bug-free" applications in the conditions of complex life cycles of objects and the lack of the recommended application architecture.

We, the creators of Android, need to make writing sustainable applications simple and fun in order to translate the efforts of developers into areas where innovation can be created. Today, we are announcing a guide to the architecture of Android applications and the preview of the libraries of Architecture Components. Instead of reinventing the wheel, we recognize the work done by the authors of popular third-party Android libraries (lane: WAT?).

Tips and not prescriptions

It is clear that there are many ways to create Android applications. We want to offer a set of guidelines that could help develop an application architecture that best fits the behavior of the Android system. The SDK has excellent APIs for interacting with the OS, such as activations, but these are the points of contact, not the building blocks of architecture; SDK components do not require separating the data model from the UI components and do not provide normal ways to store data regardless of the life cycle.

Building blocks

Architecture Components together help to implement a reasonable architecture, although individually they solve individual popob "developers". The first version of the components helps:

• Automatically manage life cycles of activations and fragments to avoid memory leaks and resources.
• Save Java data model objects to SQLite.

Lifecycle management components

New components provide constructs for binding the application kernel to life cycle events, eliminating the obvious dependencies. A typical observer model should start tracking in onStart() and stop at onStop() . It sounds simple enough, but often you have several simultaneous asynchronous calls, and all of them handle the life cycles of their components. You can easily skip any boundary case. And here can help new components.

Lifecycle, LifecycleOwner and LifecycleObserver

The main class for all of this is Lifecycle . Him inside neonka there is ENUM for the current state of the life cycle, and ENUM for the set of events, and it uses them to track the life cycle of the associated component.

LifecycleOwner is the interface that the Lifecycle object returns when getLifecycle() called, and LifecycleObserver is the class that can track component lifecycle events if you add a couple of annotations to the component methods. Putting it all together, we can create components that automatically track life cycle events and can query the current lifecycle state.

 public class MyObserver implements LifecycleObserver { public MyObserver(Lifecycle lifecycle) { // Starts lifecycle observation lifecycle.addObserver(this); ... } public void startFragmentTransaction() { // Queries lifecycle state if (lifecycle.getState.isAtLeast(STARTED)) { // perform transaction } } // Annotated methods called when the associated lifecycle goes through these events @OnLifecycleEvent(Lifecycle.Event.ON_RESUME) public void onResume() { } @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE) public void onPause() { } } MyObserver observer = new MyObserver(aLifecycleOwner.getLifecycle()); 

Livedata

LiveData is a data wrapper that monitors the life cycle. And she knows how to "observable". Your UI code can subscribe to changes in the data LiveData with LifecycleOwner , and LiveData will make sure that the observer:

• Receives data updates while the component is in the active state ( STARTED or RESUMED ).
• Removed when LifecycleOwner destroyed.
• Receives actual data when LifecycleOwner restarts due to a configuration change or when it is returned from back stack.

This helps to eliminate a lot of ways to get memory leaks and reduces the likelihood of crashing by preventing events from being sent to stopped activations.

Several listeners can subscribe to LiveData , each of which is tied to the life cycle of a fragment or aktiviti.

Viewmodel

ViewModel is an auxiliary class that contains user interface data for an activity or a fragment and which serves to separate data management in the interface from the UI controller logic. The ViewModel persists as long as the area of ​​its activit or fragment habitat is alive, including situations when the activit or fragment is destroyed and re-created due to a change in configuration. This allows the ViewModel to make UI data accessible to recreated actions or fragments without the need for manual recovery. Wrapping the UI data stored in the ViewModel into the LiveData object creates for the data warm cozy house with life cycle support and observers (observable). LiveData keeps track of change notification mechanisms, and the ViewModel ensures that data is saved and restored at the right time.

Data persistence

Architecture Components also simplify data storage using the Room library.

Room provides an object-mapping abstracion layer, allowing easy access to the database along with all the power of SQLite. The Android SDK provides native support for working with raw SQL content. Although this is a powerful API, it is quite low-level and takes a lot of time and effort:

• No validation of raw SQL queries at compile time.
• When changing the data schema, you need to manually update the affected SQL queries. This process can be lengthy and error prone.
• You need to write a bunch of boilerplate code for converting between SQL and Java data model objects.

Room takes on all these responsibilities, providing a level of abstraction over SQLite.

Database, Entity, and DAO

The Room library has three main components:

• An entity represents data for a single database row and is created using an annotated Java data model object. Each Entity is stored in its own table.
• DAO (Data Access Object) defines methods that access a database, using annotations to bind SQL to each method.
• A database is a single database custodian that uses annotations to determine the list of entities and the version of the database. Class content defines a DAO list. Database is also the main way to access the connection to the database under the hood.

To use Room, you need to annotate Java objects that you want to store as entities, create a database containing these entities, and define a DAO class with SQL code to access and modify tables in the database.

 @Entity public class User { @PrimaryKey private int uid; private String name; // Getters and Setters - required for Room public int getUid() { return uid; } public String getName() { return name; } public void setUid(int uid) { this.uid = uid; } public void setName(String name) { this.name = name; } } @Dao public interface UserDao { @Query("SELECT * FROM user") List getAll(); @Insert void insertAll(User... users); } @Database(entities = {User.class}, version = 1) public abstract class AppDatabase extends RoomDatabase { public abstract UserDao userDao(); } 

Application Architecture Guide

Architecture Components are designed for individual use, but they are most effective when they are used in an efficient application architecture.
Today, we are launching the Application Architecture Guide , which shows how to build robust, modular, and testable applications using Architecture Components. This guide serves three main purposes:

• Defines principles that are suitable for developing Android applications.
• Describes the architecture of an application that works on these principles.
• Shows how to implement this architecture using Architecture Components.

We recommend that all developers who have to deal with these problems, read the "Guide"; even if you are happily married to your current architecture, you will find useful guidelines and tips in the Guide.

This is just the beginning.

We're going to stubbornly and continue to develop new parts of the Architecture Components to make it easier for Android developers to make a conscious choice of options when designing their application architecture. We encourage you to try out the previews and leave feedback about our work, since we are all in the same boat here to make the development of sustainable applications easier and more fun. Learn more about Android architecture here:

• https://codelabs.developers.google.com/codelabs/android-lifecycles
• https://codelabs.developers.google.com/codelabs/android-persistence
• https://developer.android.com/topic/libraries/architecture/guide.html