Google I/O is a wrap. The conference celebrated product and platform innovations at Google. As part of the Google Developer Expert programme a group of us travelled to I/O and enjoyed learning together, here we want to share some of our top moments and sessions from the event.
This is just a snippet of what went on at Google I/O 2019, you can find a playlist of all the 177 sessions!
I’m always really interested to listen to talks about mobile accessibility—especially ones on Android. The content is usually pretty similar but I find it fascinating to experience the different approaches, emphases and take-aways.
This year, Phil Weaver, Qasid Sadiq and Isha Bobra presented what I think has been the most explicit guidance for Android app developers that I’ve ever seen.
Phil began with the introduction, and shared three simple principles:
- Make information visible
- Prefer simple, big controls
- Label images precisely and concisely
These cover a lot of cases: appropriately sized text, colour contrast and colour-blind safe palettes. It’s not just about making your information visible in the literal sense, but exposing it where it makes sense, e.g. adding captions to video content.
He followed with this diagram showing the interaction between a user and an app:
Rather than making app developers handle specialised use cases for each user, Phil showed an image which explained how accessibility services on Android were designed to serve as the user’s agent.
Instead of the app presenting information to users directly, app developers should ensure that they expose information to the system, which in turn will surface it to the user in the most appropriate fashion (e.g. on screen, audibly, with an external hardware device, etc.).
Google is working towards solving accessibility issues at scale. While we can definitely provide short-term workarounds for issues that we perceive in our apps, it would be more impactful if we raise an issue or bug so that they can work on improving the base case for all the developers who won’t be providing workarounds in their apps, leading to a more consistent user experience (over time).
Paul Blundell (Android GDE at Novoda)
Google I/O has three types of talks; hands on coding, developer deep dive and product sales pitches. This was the product sales pitch type. Most of the time that’s a bad thing (when you just want to know how to code the thing) but they’re really good talks for when you are exploring a new area and what to know the high level product concepts. This talk explained how the Google Assistant is coming to the car interface, hinting that it’ll likely consume Android Auto as it currently stands, and also explaining how original car manufacturers are starting to use Android for their infotainment systems.
This was interesting as it explained how car manufacturers are embracing a version of Android AOSP to run the infotainment in their cars. If you are familiar with Android Auto and how it is locked down to a specific subset of apps, Android Auto OS is no different – however each manufacturer can decide to share key information about the car. This is the cool thing! It’s the door opening to the unlocking of potential around showing climate controls, car speed and other information.
Watch this space, Google are on a mission for mass market share in the car space, they know the car manufacturers are screaming for a standardised platform to run infotainment, and if Google manage to pull it off, each car manufacturer could be running Android. If you are interested in this space (like me), it’s a good bet to start to learn more about AOSP, building your own Android fork and learning the subtleties of custom ROMS. (And an interesting side note, forking AOSP is exactly what the Android JetPack Compose team are asking you to do if you want a sneak peak of what they are up to…)
I really enjoyed the ‘community lounge’ at Google IO, this was a space for all the different collaborations Google gets involved in, to meet up and talk (GDG’s, GDE’s, Meetups, Udacity, etc). I noticed they had feedback posts, and having a peek inside they were raspberry pi’s and speaking to some Googlers there, they run AndroidThings, maybe there is hope for the platform yet. 😉
Edward Woollard (Android Engineer at Monzo Bank)
I’ll start this post off with two figures that may well peak your interest. If I said it was possible for you to potentially save 60% of the download size of your Android app, or increase successful install rates by 11% (due to your app taking up less disk space), would you then be keen to hear more? Google has continually been working on improving the Google Play Store in recent years and with that work, we’ve been brought some lovely new features to help us with delivering our app builds to users. So what new features are available, I hear you say? Well let me tell you; we now have in-app updates, conditional delivery, on-demand delivery and asset delivery.
Okay, so you don’t know what they are just yet. I’ll try and help by explaining more about what each of these are and how exactly they can benefit you, with a specific example per feature. Since asset delivery is for games, I’ll focus on the first three for now. One thing to note is that all of these new features build upon using app bundles which you should definitely check out if you haven’t already. They are now the official standard for how to ship Android apps through Google Play, but the essential difference is that Google now can handle APK generation and signing for you…you just provide the code.
First off we’ve now been blessed with in-app updates. Have you ever had a time where you’ve had to critically fix a bug and want to ensure all users have this latest app version, or maybe you’d like to retire an old version but are conscious of leaving those users in the lurch? Previously we’ve had to rely on users installing updates, whether that be manually or waiting for automatic updates to rollout, but the main issue still remains…we cannot guarantee that the user has that latest version before using the app in a particular session.
Now we have a first party solution to easily tell if there’s a new app version available, and if we so wish, require that new version is installed before the user can continue using the app, all without even visiting the Google Play Store. What’s more is that the solution I’ve just described is known as ‘immediate in-app updates’ but they’ve also provided ‘flexible’ ones too if you want to allow the user to update to the latest version inside the app whilst still being able to carry out other actions. Obviously in a lot of cases this is a nicer solution but inevitably leads to more work to provide a lovely experience for your users.
Next in the line up is conditional delivery. Lots of apps grow to a point where they start aiming at users from either different markets or maybe they have two separate user use cases, like Deliveroo riders and Deliveroo orders. You might quickly find that there are some features you don’t want to be shipped to a certain market or a specific portion of your users need a feature from your app and others don’t. We can now ship this feature to particular users if they meet certain criteria that we can define.
A great example that we could utilise within Monzo is that typically businesses use accounting software such as Xero. Integrating with this is extremely beneficial as it allows businesses to keep all of their transactions in one place so that they can deal with expenses etc. correctly. Your average consumer however does not need or even want this as a feature; therefore with conditional delivery, this would be stripped from the app for personal account users and would save them the total size of all the accounting integration flows available.
Moving on, we have on-demand delivery. Although similar to conditional delivery, on-demand delivery allows us to add and remove features of the app as and when we need to, rather than just provide or not provide them initially when the app is first installed. This allows us to not bulk the initial download of the app if we know that there is a large feature that most users don’t use regularly, if ever. Similarly, we could remove a feature on-demand. An example to tie this to Monzo would be the sign up flow.
Allowing users to sign up to a new bank account is inevitably going to be a large part of the app as there are a number of steps you simply can’t avoid, but it’s something they only have to do once. Once the user receives their card in the post, they are ready to start using Monzo as their bank and we could remove the whole sign up feature flow, saving a lot of extra space on our users’ phones.
It looks like Google is really doubling down on dynamic delivery of features and the use of app bundles. This is a big win for users as it encourages developers to ensure that every part of the app on a user’s phone is beneficial to them and them specifically, ultimately saving a lot of valuable disk space. We’ve really seen app bundles improve massively and it’s clear that they are heading in the right direction by promoting app modularisation to customise an app’s unique delivery status.
I’ve provided a small handful of examples above as to how these can be used within Monzo for certain use cases, but there are undoubtedly a ton more. Right now we are not using app bundles within Monzo but this looks like this could provide the push for us to fully get involved and start dynamically shipping features. Dynamic feature delivery will continue to become increasingly more useful, especially once we expand into other markets in the future, allowing us to only ship the relevant modules to each customer. This is an exciting start to customising app delivery and Google have said there’s much more coming soon. I’m looking forward to seeing what comes next!
Joe Birch (Android GDE at Buffer)
If you’ve ever used the Camera APIs on Android, you may have felt that they’ve never been the simplest thing to implement. There was originally the Camera API, which was deprecated in favour of the Camera2 API – this iteration aimed to provide developers with a better experience when dealing with camera APIs on Android. However, with this there was still a lot of boilerplate involved when using the camera API (even for simple use cases) and a lot of the difficulties still existed when it came to dealing with implementing camera features within Android applications. Luckily for us, the new CameraX API aims to alleviate these pain points for us by providing a simpler solution to camera feature development. Whilst, CameraX is built on top of the Camera2 API, it greatly simplifies the implementation process for minSDK 21 and above. In this article we’re going to dive into the first part of the CameraX API, learning what it is and how we can get started with it in our applications.
The CameraX library provides 3 implementations of what are known as use-cases. Each of these use cases aim to simplify the process of common camera feature implementations, these are:
- Preview – Used to prepare a view finder for the camera preview.
- Image Capture – Used for low latency image captures.
- Image Analysis – Used to perform analysis on images.
Each use case class takes some configuration in the form of a Config instance. This interface is used to define a common set of functionality that is used across each of the subclasses for each use case. If you jump into the source of the Config file, you’ll notice there is a lot of library specific definitions. A Config class is used to hold a collection of options and values which are used to represent the configuration details for the corresponding use case, you’ll manipulate these values through the use case class so don’t worry too much about what is contained within this Config interface.
For each use case that you wish to implement you will need to instantiate one of these Config classes, provide the desired options / values and then assign it to your use case. This configuration helps to make the camera features flexible and customisable, allowing us to optimise their uses within our applications.
Overall the CameraX library aims to create a consistent experience for both developers and users when it comes to cameras within application. It’s been a long wait on the Android platform and I definitely feel that this will change how we build and use cameras for the better.
I/O was a really inspiring event and sharing that learning with others allowed for more diversity in opinions and let us see and learn things from a perspective we might not have considered before.
This post is a collaboration and as such has been cross posted: