Google I/O this year ended last Thursday and many exciting things were unveiled both for the end user and for the Android Developer. There were a few things for developers to meet that could mean more hours per app, but for the most part, tons of APIs were rolled out that makes development easier for different parts of the system be it the camera, graphics, or just working with the XML in general.
Not to mention, Android Q Beta 3 is out along which builds on top of Beta 2 to bring these exciting new features. If you’re looking for a quick roundup of the new features we’ll be expecting in Android Q and Development APIs, let’s get started.
Photos stolen from The Verge
One of Android Q’s biggest changes comes in the form of the system-wide dark theme. All native UI elements will go into a dark theme and most apps by common practice should implement the same.
The Dark Theme is great for saving battery. In fact, when Battery Saver is switched on, Dark Theme switches on along with it.
If you’re worried about the extra work you’re going to have to put in your apps to meet this standard, worry not because the implementation is simple. According to the Developer page on it, all you need to do is set your app’s theme to inherit from a DayNight theme to be able to support Dark Theme when it’s on, and keep your app light when it’s not.
<style name="AppTheme" parent="Theme.AppCompat.DayNight">
This of course, only works if you followed standard material design practices to a T by avoiding hard-coded colors and using system-defined colors instead such as the following:
- ?android:attr/textColorPrimary – This is a general purpose text color. It is near-black in Light theme and near-white on Dark themes. It contains a disabled state.
- ?attr/colorControlNormal – A general-purpose icon color. It contains a disabled state.
If you have too many hard-coded colors though, there’s an alternate method without the DayNight theme which can do you the justice you need. This is called Force Dark and you can enable it by setting android:forceDarkAllowed=”true” in your app’s theme. Doing so will invert the colors of your app when Dark Theme is on.
You of course, would want to exclude some views like say, images to avoid getting some nasty results and this can be done by modifying their android:forceDarkAllowed attributes.
This is sort of a step up from the Digital Wellbeing feature which quite frankly I didn’t quite find useful. Focus Mode on the other hand prevents you from opening apps that may distract you from your work and kind of say “You don’t want to be using this app right now”.
For the developer, I don’t think this changes our work very much, except maybe for some niche cases. But it would be nice to see how it ties in with the other new features in Android Q like the next one down.
Now these ones are from Google I/O
Notifications are now separated into Priority and Gentle classifications. Priority notifications popup, make the little notification sound, they try to catch your attention while Gentle notifications quietly sit in your notifications panel. Priority classifications will also sit on top of Gentle notifications.
It’s best practice for us developers to set priority accordingly (as we were always able to when building a notification), however, users can still change the priority of notifications themselves so they always have the final say. Generally, priority notifications should be those like communications from other people or events and alarms.
I’m interested to see how this ties in with focus mode. Will priority notifications still ring? Will gentle notifications just go away altogether? Who knows?
Smart Reply Notifications
While we’re on the topic of notifications, this would be a good place to say smart replies are looking better than ever. Android Q will have machine learning built locally into it and this let’s the device read incoming messages and generate replies which you can send right from the notification.
Another neat bonus is it can detect potential intents that may be useful for the user, like letting the user open Maps when a location is detected. Good stuff.
Bubbles! We’ve all seen it in Messenger and other places like…. Messenger. They are now becoming an official extension of the Notifications API making it much easier for apps to implement.
notif.setBubbleMetadata( new Notification.BubbleMetadata.Builder() .setIcon(Icon.createWithAdaptiveBitmap(bitmap)) .setDesiredHeight(600) .setIntent(bubbleActivityIntent) .build() )
Nothing new here compared to how it was in Beta 2, other than maybe some minor optimizations that doesn’t really warrant mentioning. You’d have to ask the Google guys for that.
“This bad boy can fit so many icons” – Dan Sandler
This was sort of hinted at Beta 2 but now we get to see how it rounds up and this boy is looking slick! The sharing panel or shall I say “Share Sheet” loads faster than ever now that it doesn’t have to scan every single app for intents upon sharing but instead prepares for this in advance during a time it doesn’t need to hit your app’s performance.
Other features included in the new Share Sheet include Content Preview that supports image and text, and a Copy to Clipboard button which we’re all happy the team finally thought of. After all this time!
Officially Google I/O 2019’s most beautiful image
Fullscreen content seems to be the way smartphone design is pushing itself towards for “less system UI in the way of your beautiful content”. I’m not personally a fan of this trend, but they might change my mind.
So now we’re stripping away navigation bar that’s always been at the bottom of the screen, or at least, having the option for it not to be there. Instead, gestures will be the way a user navigates around their apps.
- Swiping away from the left or right of the screen will go back
- Swiping upwards from the bottom will act as a home button
- Swiping upwards from the bottom and holding it will open the recent apps
- Swiping horizontally along the bottom can be used to switch between apps
- Swiping diagonally from either bottom corner will trigger Google Assistant
I do like the way Android is taking this because we’ve always had gestures built into most of our devices that do pretty much this but nobody ever really pays any attention to them because they feel so unorthodox and inconsistent with each other. With a real universal implementation of this, and one that I’m sure would feel ‘right’ as it should, hopefully this actually goes somewhere.
Now what’s Tinder gonna do…
If you don’t know what Jetpack is, it’s a set of libraries that make Android development… kind of just easier in general by simplifying complex tasks, reducing boilerplate code and standardizing best practices. Jetpack comprises of the androidx package of libraries which you may or may not have come across.
Pushing further it looks like the Android Team want developers to utilize Jetpack as sort of a de facto way to do Android development evident with the changes they’ve implemented, listed below:
- Preferences are now deprecated and androidx.preference will be taking its place
- WorkManager (for easier background processing) and AndroidX Navigation are now stable
- SavedState for ViewModel and Benchmarking (improving app performance) alpha have been released
- Lifecycles, Livedata, and Room now with Coroutines
- CameraX released: a new camera-support library that works around device specific platform APIs
Jetpack Compose is a new UI toolkit that makes it easier to create new components without having to rely on an XML layout and this is done by writing components as functions like the Counter seen above, so need for any onClick listeners either so that’s a thing. To be honest, I don’t know what this implies. More concise code maybe, but I think Kotlin already fixed that for listeners.
I’m interested to see where the rest of the community takes this. Little do we know, it could be the next generation way to write UI elements.
Beyond even the minor stuff listed below, there even… minorer? Even more minor things like some processing updates with a new engine type thing or just small nitpicks that I didn’t bother including.
ANGLE on Vulkan
– OpenGL ES over Vulkan around since Beta 2
Settings and Connectivity
– Users can now toggle settings like WiFi state via a settings panel that pops up instead of having to leave your app
– Potential nulls are no enforced as errors instead of warnings
XML View Binding
<TextView android:id="@+id/my_text_view> -> binding.myTextView
– Bindings generated directly from XML layouts (similar to KotlinX in a way) which are null-safe and type-safe
– Apps can now check the thermal state of the device to adjust their power usage accordingly
Graphics Stuff (Render Nodes & Blend Modes)
– Blend Modes are a new replacement to PorterDuff Modes which includes new modes such as HARD_LIGHT and SOFT_LIGHT
– RenderNode is a new special canvas used internally by views that can change properties (e.g. alpha) of already rendered graphics without having to draw them again
– Hardware Renderer is what renders RenderNodes and can be used with them to control the light source for material shadows