Badoo developers at Google I/O 2019

What Google I/O 2019 addressed: Android 10, AR-applications and much more

In this article I’ll share my thoughts on Google I/O 2019 that my colleagues and I attended recently (and Badoo were even mentioned in one of the talks). During the three days, there were more than 150 talks, lots of choice as you can see, but I really wanted to share with you feedback about the one that I visited and liked the most as an Android developer. Hopefully, this will make you want to check on several talks now available on the Google Developers channel. And for those who have never been there, I included some moments from the conference to help you to feel the atmosphere.

Day 0. Introduction

To attend the conference, you need to win in the lottery, which starts in February on the Google I/O site (announcements usually can be found in the news). However, winning doesn’t give you a ticket but rather the option to buy one for $1,150. There are also other programs that allow you to get a free ticket or one with a large discount, such as Code Jam. Students and university employees can purchase a much cheaper ticket for $375.

IT companies organise lots of pre-conference parties for participants. These types of parties are good places to meet other participants in informal surroundings. For example, we met an organiser of tech conferences in Europe and the development team making an app for travellers, App in the Air.

Another good thing about the way the conference was organised was that it took place under the slogan “No parking”. Google not only laid on free shuttle buses from all the most popular hotels in the area, but they also gave out promo codes for the Lyft taxi service (an American Uber competitor).

Here at Badoo five of our developers were among the lucky few who got their hands on these exclusive tickets. There were between 6 and 10 talks being given so we often split up to catch as many of them as possible.

Day 1

The first day of the conference opened with keynote presentations — one as a plenary session and a second targeted at developers.

A DJ and an AI DJ in the groove before the keynote presentations

Main news

The main keynote presentation covered various Google projects. Here are some news items:

• the company is continuing to develop Google Duplex, an AI assistant that can call and book an appointment at the hairdresser, or a table at a restaurant;
• Google Lens can analyse a restaurant bill and split it between friends;
• Google assistant will soon work offline and be significantly reduced in size, and audio messages in messenger apps and calls will be able to be displayed in text form on the screen using Live Relay.

Android 10 is going to have:

• more parental controls;
• a dark theme;
• improved support for folding devices;
• new navigation using gestures;
• improved sharing;
• new grouping of notifications by priority.

It was announced at the developer keynote that Kotlin will be the preferred programming language for Android developers. We chose Kotlin as the primary language for our apps 18 months ago. Looks like it was the right choice. Google presented a new library for Camera X, the new declarative UI Jetpack Compose (it’s still in pre-alpha stage but quite promising) and new possibilities for updating applications: developers can themselves request an update via the application interface.

During each presentation subtitles were generated in real time

Google advice on foldable devices

Recently, everyone has been talking about foldable devices. Although their market share has been pretty insignificant so far, applications have to be able to work with them.

The Google guys assured us that if you follow best practices, for example correctly handling screen rotation, then everything should work “out of the box”. For support for foldable devices the same mechanism is used as for multiple windows on tablets and Chrome OS. In addition to the existing android:maxAspectRatio, android:minAspectRatio will soon be available, designed to add limits to corresponding supported edges in the application. Google assured us that 2 inches (5.08 cm) will become the minimum display width for Android devices, starting with Android Q.

Several items that are worth checking out if you want to support for foldable devices within an application on folding and opening the device:

• the application needs to restore to the same state;
• the scroll position must be maintained;
• the keyboard focus must remain the same.

If you want Activity to change size, then the flag android:resizeableActivity=false can’t always help with this because the system can change the size of Activity or put it in a compatibility mode:

Compatibility mode

It now seems that there are very few users with folding devices, but the cost of such gadgets is fairly high and checking how an application works on them is highly recommended.

Modular apps: advantages and disadvantages

A lot of attention was given to modularity at the conference. The main advantages of modular apps are:

• tests can be launched selectively for those modules affected by changes in the current branch;
• you can isolate testing of different application functions; for example, at Badoo we have an application gallery in which all UI-elements are collected, and in development the application can be put together relatively quickly as they have a limited number of dependencies;
• the ability to add dynamic features: in the words of the presenters, 80% of users use 20% of an application’s functions, so most functions can be put into a dynamic module and downloaded later. Good candidates for this are: functions for expert users; paid features and the “about the app” screen. So, onboarding is not worth the effort for dynamic functions, as it will be shown to all users of the application.

Also, modular apps scale well for large numbers of developers — a really important consideration where teams are large teams that are growing fast.

Modular apps are not without their problems, however. For example, it’s not clear how to construct a database. There are three approaches:

• create one database for all modules;
• create a seperate database for each module;
• create one database for several modules that can be logically connected.

All approaches have their disadvantages but the guys from Google promise a bright future with Room. Here they want to maintain isolation of modules while supporting cross-module requests as well as modules with dynamic functions. Unfortunately, this is still not possible.

We have more than 170 modules in the Badoo application. We haven’t used dynamic features yet, but work with the other advantages and drawbacks of modular apps.

Day 2

The second day of the conference was really busy from beginning to end. The day ran from 08:30 until 20:00 with 90 talks altogether.

A typical auditorium: from empty to full in less than 10 minutes

New declarative UI

The Android system is now ten years old, and the current UI is getting pretty old as well. The old UI is rather difficult to support. For example, the View class has around 29,188 lines of code, including comments, and the AppCompact version has become cluttered with a multitude of hacks for different Android versions. Google developers have decided to create a UI framework that will come with the application and be fully detached from Android. The working name for the framework is Jetpack Compose.

Flutter, React, Litho and Vue.js have served as sources of inspiration for developers, so the new framework seems familiar in many ways. The basic idea is to provide UI reactivity to changes in the model where there is no logic for the UI.

The View hierarchy is presented in the form of functions, marked with the annotation @Composable. Framework uses Compiler Plugin for call interceptions for composable functions.

The Google team promises support of the new framework in old View hierarchies (using @GenerateView annotation), as well as preview in Android Studio and animation support.

Jetpack Compose is still not ready for use in production applications, but it’s already worth studying the principles of usage to get an idea of where Android development is heading.

Designing augmented reality applications

Google has prepared some guidelines for AR application design.

• All interface elements need to be on the AR stage and not on the device, as users pay no attention to the device when they are using AR.
• Avoid instances when the user has to move backwards, as this can result in injuries.
• If an AR experience is constructed within a city, be aware of potential hazards. For example, users should be warned concerning approaching pedestrian crossings and should be asked to put the device down.
• In the AR stage objects need to interact with real light, meaning shadows need to change on light alteration. ARCore provides data on lighting to enable virtual objects to be lit.
• AR objects should have the same properties as in real life. For example, a ball should bounce when it hits the floor.
• When the user moves an object far away, the touch zone of the object shouldn’t be decreased so that it can still be controlled comfortably
• The developer needs to explain carefully to the user that access to the device camera is required in order for the AR application to work.

More detailed information concerning how to design AR elements into an application can be found in this conference video.

Best practice for using text when developing Android applications

This talk covered the best practices for working with text and announced several changes to the new version of Android.

• Android Q will have hyphenation turned off;
• PrecomputedTextCompat helps to calculate the size of text prior to rendering. It should be noted that changing the script and other TextView parameters after transfer of parameters in PrecomputedTextCompat will no longer be possible;
• Styles which are applied to text (from the highest priority to the lowest):
  - Span,
  - View (e.g attributes in XML),
  - Style,
  - Default Style,
  - Theme,
  - Text Appearance.
• It will be possible to install fallbacks for scripts using Typeface.CustomFallbackBuilder. For example, if an application script is not supported in one of the languages, then another can be given as an alternative, as can scripts for emojis. Our application has been translated into more than 40 languages, so it’s important for the user to know how it will look if a basic script isn’t supported in one of them.
• Use android:imeOptions=“flagNoPersonalizedLearning” in EditText to prevent storage of words entered (for example, on entering a promo code).
• If you need to use two languages in an application you can use setImeHintLocales to tell the keyboard that you need another language. This would be useful for dictionary applications, of course, and other educational services.

One more piece of news. In the talk GIFs and More: Integrating Expression Search in Your App Google unveiled its API for using GIFs — Tenor (https://tenor.com/), an alternative to the well-known and long life Giphy. Badoo were one of the first to start using it and as a result we ended up on the speaker’s slide as an example of use. It’s nice to be recognised!

Our application featured in the Tenor presentation

Concert

At the end of the second day Google put on a concert including a performance from the Flaming Lips. I’d never heard of them, to be honest, but it seems they are pretty popular in the USA. Click here for a short clip of them in action.

Before the concert

Day 3

Day 3 was short. It was all over by 16:30. I spent most of my time talking to other attendees but a couple of talks are worth highlighting.

Some communication zones at the conference outlawed devices altogether

Motional Intelligence: Build Smarter Animations

Nik Butcher talked about creating animation to improve user experience in the reactive world. The problem stems from the fact that View objects have no state in a reactive application, while the animation does.

Good animation should meet three criteria:

• reentrant: the animation can be cancelled and relaunched;
• continuous: the animation must not jump from one state to another;
• smooth: the animation should change speed/direction of movement gradually.

How this can be achieved:

• on start, an animation should only have an end value (where it should end); for the given beginning value the animation can jump from one state to another. This can happen if launch is vis a button and the user presses it several times;
• cancel old animation before starting a new one (sometimes this is already done inside Android SDK; for example, ViewPropertyAnimator received from View#animate cancels the previous animation for the animated property);
• use Spring Animation; here animations move in line with the laws of physics meaning “smooth” and “continuous” are achieved more easily. So, if an object is moving from point A to point B, and the team acts to move it to point C, when Spring Animation is used the object will change movement direction smoothly;
• use <animated-selector> to add animation in Drawable; to avoid transfers between all possible states you can apply an intermediate state (for example, a loading state) and transfer through this.

Most will agree that video is worth a thousand words, so here’s the video of the talk.

Benchmarking

Jetpack Benchmark Library for testing application performance is in the alpha version. The library enables code performance to be measured with virtually no errors, as well as integration with Android Studio.

Points to remember during development of performance tests using Jetpack Benchmark Library:

• collecting measurements on an emulator is unreliable, while warnings help;
• ProGuard/R8 must be turned on in order to measure performance correctly;
• the device must have a sufficient level of battery charge to avoid test results being affected by a low battery level;
• a module containing productivity tests must have the parameter “debuggable=false”;
• it’s not worth comparing test results across different devices, as they can differ significantly.

Conclusion

The Badoo team with one of the Google developers

Google I/O is definitely worth the visit. In an atmosphere like this you can find interesting engineering solutions and hear plenty of inspiring stories over a cup of tea. For example, take the one about the guys at VKontakte (ВКонтакте) who thought up a secret “dark theme” idea and rolled it out just to users asking the question “Where’s the dark theme?”; then at the other end of the earth there are the developers from Tinder fighting spam and pornographic content; and then the App in the Air team that carries out automatic check in for flights. You also get to meet the Google folk who are creating the instruments we use and to ask relevant questions.

Overall, a conference on such a level is not just a load of presentations but it’s also about sharing experiences with a lot of very interesting people.