A Developer’s Take On Google IO Day 2-Part 1

Day two of this wonderful conference. A beautiful, high-70’s day. In this post, I am going to recap some of the talks I attended with key takeaways for Android developers in two parts. The list of talks I visited today:

Part 1

Architecture Components — Solving The Lifecycle Problem

Android Wear: What’s new & Best Practices

What’s New In the Android Support Library

Architecture Components with Room

Part 2

Introduction to Android Instant Apps

What’s New in Android Design Tools-New features and tools for rapid UI development

Android Instant Apps Best Practices Fireside Chat

Speeding up your Android Gradle Builds

Android Fireside Chat

Architecture Components — Solving The Lifecycle Problem

As I mentioned yesterday, this talk focused on the LiveData,LifecycleObserver, and ViewModel classes.

LiveData provides a RXJava-style construct that is fully lifecycle aware (and future integration into the support library). What this means it will auto-dispose itself when the android Activity or Fragment is destroyed:

public class LocationLiveData extends LiveData<Location> {
    private static LocationLiveData sInstance;
    private LocationManager locationManager;

    @MainThread
    public static LocationLiveData get(Context context) {
        if (sInstance == null) {
            sInstance = new LocationLiveData(context.getApplicationContext());
        }
        return sInstance;
    }

    private SimpleLocationListener listener = new SimpleLocationListener() {
        @Override
        public void onLocationChanged(Location location) {
            setValue(location);
        }
    };

    private LocationLiveData(Context context) {
        locationManager = (LocationManager) context.getSystemService(
                Context.LOCATION_SERVICE);
    }

    @Override
    protected void onActive() {
    locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 0, 0, listener);
    }

    @Override
    protected void onInactive() {
        locationManager.removeUpdates(listener);
    }
}

This comes from their example on the developer website. onActive() gets called when at least one observer gets registered on the LiveData class. onInActive() is called when the last observer is removed. They use location updates as a good example of how LiveData helps to ensure that some fundamental android developer pains are addressed in a standard way:

No Memory Leaks: Since LiveData binds to an Activity or Fragment lifecycle, it cleans itself up when its no longer used.

No crashes due to stopped Activities: During inactive states of the parent lifecycle observer, changes to LiveData are not sent over until the parent goes back into an active state (i.e. Resumed or Started).

Up to date data: When a screen is active again, observers receive the latest up to date data based on current state of the LifecycleOwner.

Configuration Changes: When an Activity restores itself from configuration changes, any previously bound observer will get it’s last data state.

Manual Lifecyle Handling out-the-window: The fragment or UI layer observes data when it wants to. Automatic handling for subscriptions and observers means happier developers.

We get all of this without having to use or learn RX in a standard way. The team behind this will also add conversion mechanisms into RXJava so you integrate into this seamlessly.

Android Wear: What’s new & Best Practices

In this talk they walked us through some of the new changes coming to Android Wear.

1. Android O: apps on wear will be even more restricted in background usage for location. Wear apps not actively open will have all of its services killed and only way to survive process death is using foreground services.
2. Complications API: They added API support for text and image drawables for having them properly sized and positioned on different watch faces. This is to replace custom implementations that could get quite complex.
3. Android Wear Support Library: Android wear’s UI components are getting open-source into the support library so the main material design components are standardized.
4. They provided stats and advice when building apps that need to sync data in the BG or run in the BG: Batch updates on WIFI once a day for large datasets. Only do periodical updates when the app is open. When app is open but idle, use ambient display mode. There is much more to help keep battery life at a maximum.

What’s New In the Android Support Library

This talk broke down some of the more major changes an improvements coming to Android Support Library v26.

1. Native Fonts as xml resource or downloadable asset. Previously we had to either use custom TextView or DataBinding to properly include different fonts in our app. It took them long enough to address and fix this issue. Also, more interestingly they are supporting shared fonts, which go through Google Play Services! So instead of multiple apps bundling font resources with their APK, we can download them securely and easily when the app needs them. Also on top of that, you can access over 800+ Google Fonts from their shared repository and with a couple of clicks in Android Studio, start using them automatically. No more bundling or fussing with designers as long as they use a standard font, it becomes much easier.

Not the best photo, but it diagrammed out how shared fonts work.

You can specify these new downloadable fonts in xml and use them accordingly!

2. PreferenceDataStore essentially allows you to override how preferences get stored and where they go. So you can share a common interface with standard preferences and do things like store them in the cloud somewhere.

3. Animation Updates: Have new SpringAnimation and FlingAnimation classes.

4. SVG Updates: Support for nesting SVG objects into animated vectors and more conversion improvements especially for pathData vector attribute.

5. Emoji Support Library: Messaging apps with MinSDK 19+can take advantage of forward compatibility with emojis user send to each other. This means that when your friend or family member on an iPhone or higher Android version sends you a newer emoji, EmojiCompat handles the work of rendering the image for you. You don’t need to update the app to get newest emojis. If you don’t use Play Services, you can used the bundled version, which requires manual updates.

Architecture Components with Room

Room, a new SQLite Database ORM made by Google aims to reduce a lot of boilerplate for SQLite and provide developers with a great library for Android to use.

They provided a slide that mentioned other solutions. Shout out to my library, DBFlow!!

Some of the highlights of the features include:

1. Compile-time validation for SQLite queries using annotation processing.
2. You define “Retrofit-esque” interfaces into your data that it uses to generate code for. You can embed values passed into functions by using the :name operator in queries. Cleaner than using annotations.
3. Embedded Objects: You can embed the fields of another object into your table by “flattening” it. This is a great idea, and something at one point in time was going to implement for DBFlow, but did not finish it. Time to finish it!
4. No Relationships: It discourages relationships and forces you to use Join statements, which is not all that bad of an idea. I always get questions in DBFlow about problems or issues with ForeignKey or @OneToMany collections.
5. Observability: It knows the kind of queries you have and can, based on what your queries contain, update data based on those changes. So when you update a User.firstName with value of “Andrew”, if you define a query that relies on that User.firstName, it will update observers into that specific value automatically! Kind of neat.
6. Testability: You can test the DB by using in-memory databases easily and so it doesn’t write to disk. Also, it has a migration helper class that allows you to test migration versions automatically. Otherwise if you simply increment database version with a change, it auto-clears your database for you.
7. Missing features: No async transactions support, however RXJava2 Flowable seems to work. No SQLite wrapper language. Not sure if that’s a “missing” feature as they plan (they mentioned something like this) on adding support in Android Studio for SQL validation checks while you type queries. No caching. Unless they didn’t cover it, caching can have data issues and that’s probably why they don’t have it. Lazy Cursor support is missing so that models are only converted as their used. I can see combining LiveData with the use of that Cursor to automatically close it.

Next post, I will continue the rest of the exciting Day 2 of the conference.