Previously at I/O 2018, Google announced App Bundles, a means to reduce the app install and download footprint for end users by only serving them the files and assets they needed. For example, downloading language specific resources or targeting the user’s screen density and serving only the assets that fit that resolution. This reduced the size of downloads by an average of 35% (when compared to a typical APK).
This year, Google detailed more features to be added to the App Bundle. Firstly, In-App Updates will allow developers to notify their users that an update is available for their app. This in itself is nothing new, however normally this would involve pushing the user out of your app and over to the Play store to update. With In-App Update, Google will provide a solution to keep your users in your app for the duration of the update. Users will either be directed into a managed flow that Google will handle or the developer can opt to implement deferred updating, which will download the update in the background and allow the user to decide when to update the app. All this while the user is still inside the app. Useful if you would like to inform a user of new features or critical updates!
Additional features announced include more filters for conditional delivery such as geographic location, minimum SDK, and device specific features. Useful for targeting locales or select devices. On Demand Delivery will allow developers to specify app features that can be installed or uninstalled. For example, the onboarding flow of your app could be removed once the user has successfully completed it, or a customer support feature could be downloaded and installed only when the user requests it. This can trim a lot of the code from your app that your typical user may never even engage with.
Lastly, Google are addressing the difficulty of testing App Bundles by adding Internal App Sharing. Currently App Bundles can be frustrating to test as they are non-executable, unlike an APK, and are managed by the Play Console. This makes getting test versions out problematic. Google are now providing the means to share your app internally and still retain all the benefits of App Bundles. The approach is similar to how Google Docs are shared out, by providing testers with a link to a testable version of your app. Google will also handle other headaches like version and build numbering and app signing to ensure it can be as simple as uploading a new test App Bundle and sharing out the link. Google were however quick to highlight that you’ll only see the true benefits of App Bundling if your app is modularized beforehand. A painful process if you’re already mid development!
Currently, the Android UI framework uses an imperative style of UI programming. Developers manually construct a full-functioned UI entity and later mutate it using methods and setters when the UI changes. Declarative UI patterns, by contrast, lets the developer describe the current UI state and leaves the transitioning to the framework.
As part of a talk on declarative UI patterns Google unveiled a new UI toolkit that they are currently experimenting with called Jetpack Compose. Compose came about from the UI team working on fixing and unbundling a lot of the Android UI toolkit. As a result (and aside from Compose) the UI toolkit will now be added to jetpack allowing for faster fixes and updates and no longer dependent on platform releases that could take a long time to reach end users (or never arrive for certain devices).
In addition to fixing and improving the current toolkit, Google wanted to revisit the UI toolkit and try to improve upon it for modern devices. The UI widgets and views have remained largely the same so this would be the first time Google would take a chance to review them. Compose seeks to unify view code and clarify state ownership and event handling. This is an attempt to both simplify view creation, custom views. This should also combat some widget behaviour where they update and own their own state and only inform of a change after the fact. It can be frustrating to then have to change the view state back.
To tackle all of this, Jetpack Compose introduces “composables”, or UI-as-a-function. When a composable is invoked a view is emitted into the hierarchy. No need to inflate a layout. No need to find views to bind. No need to update views later as they will be set to observe LiveData triggers and automatically recompose themselves. From Google developers themselves, if you are calling “get” on a view, you are doing it wrong. This will drastically reduce the amount of overhead and boilerplate that can go into UI development.
Compose is a completely new set of UI widgets that will work fine alongside existing UI widgets that Android developers will be familiar with. Compose will exist as a Kotlin compiler plugin that searches for specific annotations (such as, “@Composable”) on your functions.
Compose is still very early in development so it will be a long time before we see this in the wild. It does however mark a drastic change to the typical UI set up of code, layout xml, attributes, and styles that Android developers are accustomed to.
Camera development on Android platforms can be frustrating. The camera API is confusing, camera set up needs to be handled independently of the activity lifecycle, and let’s not even go into all the little quirks and differences (and bugs!) from device manufacturers. So, a welcome announcement came at an Android Camera talk.
In an effort to combat development difficulties related to the camera stack, Google has introduced CameraX. This new library will be part of Android Jetpack (this will be a running theme throughout I/O) and will smooth over camera API complexities that can stem from different OS flavours and inconsistency and latency across devices. From entry level to flagship.
Under the hood, CameraX will combine the current Camera2 API as well as the older legacy camera APIs into one simple and streamlined camera library. Google is opening an automated CameraX testing lab for developers to use. Developers can avail of this lab to test out their apps on real camera hardware and check for any inconsistency and latency on a range of devices. Google itself uses the testing lab to fix many device specific camera bugs and rolls those fixes into CameraX.
The new library should hide device specific quirks allowing CameraX to be used consistently and simply in your codebase. CameraX will also be lifecycle aware relieving a big pain point for camera developers as they will no longer have to deal with the camera state independent of the activity lifecycle.
Finally, CameraX will expose device specific camera features for 3rd party app developers to use, such as night mode and portrait mode. Meaning camera apps can get extra features right out of the CameraX box! CameraX has entered alpha and has already been deployed in many camera focused apps to great success.
As part of an update talk on Constraint Layout, Google presented a few features of their new Motion Layout view group allowing for very interesting animations. Developers can specify a start state and end state for the ViewGroup to animate linearly between the two. However, developers can also specify keyframes to allow for non linear interpolation between the start and end states.
View attributes can also be tweaked during state transition allowing widgets to change colour or rotate. Developers can also specify and tweak custom attributes to provide custom animations. Additionally, Motion Layout provide even further oomph by using keycycles to specify repetitive motion for views. Allowing animations like a pulse or bounce effect.
New additions to Motion Layout enable view animations to be driven by gesture, allowing for animations to be more interactive and not just fire-and-forget. Multistate behaviour manages animations between many states and interruption and recalculation of animations on the fly.
Finally a quick preview of the Motion Layout editor for Android Studio was shown off facilitating a more visual approach to designing and tweaking animations for Motion Layout. The editor is still very early in development so we are not likely to see it any time soon, but very interesting to see it up and running.
A small tidbit from a wide ranging talk on security and privacy improvements included this gem. Google are adding encryption APIs to Android Jetpack. Allowing developers to leverage encryption protocols for their apps and end users and also to stay on top of any bug fixes and developments.
The new security library will provide on-device file encryption, encryption of shared preferences and also API keys. The library is still in alpha but it looks promising and should help developers tackle the pain points of encryption and provide more secure options for their end users.
There are some really interesting features being added to our Android developer tool belts in the upcoming months (or maybe years!). It is great to see Google trying to make things easier and simpler so we can focus on making top notch apps!
We’re ready to start the conversation however best suits you - on the phone at
+353 (0)1 833 7392 or by email
