Posted by Dan Galpin (@dagalpin), Developer Relations EngineerToday marks the final track for Android Developer Summit: the Platform Track, focused on developer features and guidance around Android 13. With your help, we're making the platform more private and secure, more personal, and more capable than ever. Tune into the livestream and watch the full playlist on YouTube! And if you’ve got any burning questions, be sure to Tweet them using #AskAndroid; at the end of our livestream, we’ll be assembling the Android experts to help answer them live; tune in at 12:30PM to see if we answer your question live! Here are the top 3 takeaways from the Platform track, and be sure to watch the full Platform session playlist on YouTube:
Posted by Daniel Galpin (@dagalpin), Developer Relations Engineer
On Monday, November 14, we kick off the final of three tracks for Android Dev Summit with the Platform track! This track includes almost 20 talks focused on developer features and guidance around Android 13, and how, together with your help, we're making the platform more private and secure, more personal, and more capable than ever. We dropped information on the livestream agenda, technical talks, and speakers — so start planning your schedule!
Here’s what to expect on November 14th:
Get ready for all things platform! We’re kicking the livestream off at 9:00 AM PT on November 14th on YouTube and developer.android.com, where you’ll be able to watch almost 20 sessions, with talks such as:
Migrate your Apps to Android 13
Foster User Trust by Adopting Privacy-respecting Permission Workflows
Building for a Multilingual World
Improving Your Social Experience Quality with Android Camera
And at approximately 12:30 PM PST, we’ll be hosting a live Q&A – #AskAndroid - so you can get your burning platform questions answered live by the team who built Android. Post your questions to Twitter or comment in the YouTube livestream using #AskAndroid for a chance to have your questions answered on the livestream.
Check out our previous tracks: Modern Android Development and Form Factors.
Posted by Diana Wong, Product Manager, AndroidLarge screen devices like foldables and tablets mean your users have more screen to interact with. But they also can make it more difficult for those users to reach certain parts of their screen. Reachability, or what parts of the screen users can comfortably reach without stretching or adjusting their grip, is an important factor in user experience and accessibility and can help you decide where to place your app’s UI elements.
UI Elements on Large Screens
Large screens, such as tablets and foldables, are not always held and engaged with the same way as a smaller device like a phone. In the image below, you can see an example of how easily users can reach each area of a tablet with a width greater than nine inches.
The green area is easy for the majority of users to reach, the yellow and orange areas are only reachable for some users, and the red area is most difficult for users to reach. Within the red area, a user may need to adjust their grip or stretch to reach UI elements. It is important to consider how reachable each of your UI elements are to provide your users with the most optimal experiences.
Reachability isn’t “one size fits all”
Reachability can be impacted by a number of factors. First, device size can change what areas are reachable; larger devices mean it will be more difficult for users to reach the center of the screen. Another factor impacting reachability is the task a user is executing as users may hold their device in different ways for tasks like taking a photo versus using the keyboard. Hand size, measured from base of the wrist to the tip of the middle finger, can also affect how much of the device a user can reach. For example, take a look at the hand size data below. For tablets with a diagonal size greater than nine inches, users with hands larger than the US average can reach significantly more of the screen than users with hands smaller than average.
Additionally, how users hold their device changes depending on device orientation. As shown in the images below, devices used in portrait mode versus landscape impact the areas a user can comfortably reach.
Finally, mostly due to screen size, foldable devices show some slightly different reachability patterns. Because they often have smaller screens than tablets, it is easier to reach the center of the device. However, the general pattern holds when it comes to reachability. When unfolded, the average user cannot reach the top 25% of the screen on a foldable device.
The DOs and DON’Ts of Large Screen Reachability
Reachability may vary by user, but there are some guidelines that can help your users’ large screen app experience. We have found that placing UI elements in the corners can be less than optimal. UI elements that are too close to the edges are going to be more likely to interact with user grip.Additionally, our reachability data shows that elements too close to the corners or edges of the device can be more difficult to reach, especially when a user is holding the device with both hands.
Now that you’ve learned all about reachability and the factors that impact it, here’s what you need to remember when building or updated an app for large screens:
DO: Limit interactions on the top 25% of the screen
The upper quarter of the screen can be hard to reach without changing one's grip.
DONT: Place critical and frequently used elements close to the screen's bottom edge and corners
Placing essential interactive elements too close to the bottom edge of the screen makes it more difficult for some users, particularly those with larger hands, to reach.
Posted by Diana Wong, Product ManagerLast month, we kicked off the first part of Android Dev Summit, and later this week comes the second session track: Form Factors! In this track, we’ll bring you through all things Android form factors, including the API, tooling, and design guidance needed to help make your app look great on Android watches, tablets, TVs and more. We dropped information on the livestream agenda, technical talks, and speakers — so start planning your schedule!
Here’s what to expect on November 9th:
Get ready for all things form factors! We’re kicking the livestream off at 1:00 PM GMT on November 9th on YouTube and developer.android.com, where you’ll be able to watch over 20 sessions and check out the latest announcements on building for different form factors, with talks such as:
Build Better UIs Across Form Factors with Android Studio
Deep Dive into Wear OS App Architecture
Do's and Don'ts: Mindset for Optimizing Apps for Large Screens
And to wrap the livestream up, at 4:20 PM GMT, we’ll be hosting a live Q&A – #AskAndroid - so you can get your burning form factors questions answered live by the team who built Android. Post your questions to Twitter or comment in the YouTube livestream using #AskAndroid, for a chance to have your questions answered on the livestream.
There’s more to come!
There is even more to get excited for as the Android Dev Summit continues later this month with the Platform track. On November 14, we’re broadcasting our Platform technical talks where you’ll learn about the latest innovations and updates to the Android platform. You’ll be able to watch talks such as Android 13: Migrate your apps, Presenting a high-quality media experience for all users, and Migrating to Billing Library 5 and more flexible subscriptions on Google Play. Get a sneak peak at all the Platform talks here.
Learn why Lyft plans to shift entirely to Compose for future feature development
Lyft, one of the largest ride-sharing companies in the U.S., is practically synonymous with one-tap transportation. Lyft has far outgrown its ride-hailing beginnings to now include everything from delivery services to additional modes of transportation such as bikes and scooters. With more than 50 million downloads on Google Play, Lyft’s engineers are always exploring new ways to streamline the product's features and functionality to improve the user experience.
To keep up with the modern trends in mobile development, multiple teams at Lyft used Jetpack Compose to replace some of their legacy frameworks, reduce boilerplate code, and streamline their workflow. They also used it for feature rollouts and have benefited from the implementation.
Less code, easier UI feature rollouts
Lyft engineers adopted Compose for a UI overhaul and used a plugin framework that allowed developers to break down features into self-contained reusable modules. “Over 90% of all new feature code is now developed in Compose,” said Anton Tananaev, staff Android engineer at Lyft. This is in large part because Compose makes implementing new features a faster—and easier—process for engineers.
Lyft has a unified design across its web and mobile apps as well as a Figma library of components, making it quick and easy to develop new UI features using those building blocks. Lyft's internal UI framework, called Lyft Product Language (LPL), allows them to easily use their unified design system across Android, iOS, and the web. The LPL includes common UI components, like visual elements within the app, and more complex panels and dialogs. To ensure Lyft’s riders and drivers have the best user experience, this design system is implemented individually on each platform. Compose is built with the flexibility to support Material Design, custom design systems, and everything in between, so Lyft was able to easily build these UI components to meet their custom visual requirements. On top of that, using Compose instead of views has dramatically decreased the lines of code required. A button component on the Lyft app has gone from around 800 lines of code across three files plus 17 different XML files down to a single Kotlin file with 300 lines of code. They were able to reduce the lines of code by nearly two-thirds of what was needed with Views!
The team that’s working on the server-driven UI framework at Lyft also adopted Compose. Current systems only support static API response, but one key reason Lyft engineers prefer Compose is because it supports dynamic UI changes from the backend. Compose will automatically detect changes, so no additional client code is required to support dynamic content.
A welcome improvement for engineers
Moving over to Compose allowed Lyft to increase developer productivity and velocity. Not only do developers need to write less code in Compose than with Views, they find it easier to understand and maintain, and faster to ship any needed changes. This translates to more time developing new features for Lyft drivers and riders, and less time fixing old features.
Lyft created their own unidirectional architecture, splitting the aspects of a UI into multiple pieces. That means they can pass the state needed for a UI independently of the actions to perform all while still taking advantage of other technologies used throughout their code like RxJava. Lyft's previous plugin system required several files with a lot of boilerplate code just to create a basic reusable component, but with Compose it can be a single file or even a simple Composable function in some cases.
Developers at Lyft like Compose so much that nearly all new features are being developed in Compose, and they see it as the future of Android. Even in job interviews, Android engineer candidates show excitement at the possibility of using Compose and see it as a key indicator that Lyft is keeping current with modern Android technologies.
Migrating to an easier-to-manage codebase
Compose is fully interoperable with Views, so developers can build UI with as much or as little Compose as they’d like. The Lyft team enjoyed using Compose so much, however, that the engineers plan on migrating to Compose for nearly all of their features and are working on a plan to officially deprecate any new XML layouts so they can continue taking advantage of the benefits across the different parts of the app.
“Compose is clearly the future of Android development, so the sooner we transition the better,” said Anton, “It requires less code, and it’s easier to understand and maintain.”
ZEPETO is a 3D social universe built by NAVER Z with more than 300 million users in over 200 countries. Those users can create unique avatars, foster friendships, and explore virtual realms of their own design. ZEPETO commits itself to creating spaces that prioritize the user’s experience. For its engineers, that meant making the switch to Jetpack Compose, Android’s modern toolkit for building native UI.
Embracing Jetpack Compose
ZEPETO was originally designed and developed using Views, Unity and OpenGL, but today 20% of the UI originally written in Views has been rewritten with Jetpack Compose. ZEPETO’s developers began to sequentially integrate the toolkit knowing it would resolve a number of recurring engineering friction points. With the Views system, implementing custom UI with some specific shapes, such as sliders or switches, required implementing the onDraw method with a Canvas. Jetpack Compose allows ZEPETO’s developers to implement these types of UI in Kotlin without needing to implement custom classes, simplifying the process and eliminating the extra steps required.
Cleaning up the codebase
With Jetpack Compose, ZEPETO’s developers rewrote complex UI features. They built a design system that helped organize fonts and sizes in a more intuitive way, improving maintainability, efficiency, and the UX. “Using Compose, we rewrote parts of the app where the UI is relatively complex and various business logics exist, such as the character shop, gift giving, and face decoration,” said Android Developer Hojung Kim. In places like the pager and grid areas of the character shop, Composable functions helped reduce the amount of code by more than 10%.
The ZEPETO team decided to migrate its common dialog components to Compose too. This enabled its engineers to use the desired type of dialog needed throughout all parts of the app. “Each element of the common dialog can now be made into a component, making it possible to create a common dialog, just like assembling a Lego,” said Juhyung Park, Android Developer at ZEPETO. Modularizing the code allowed the engineers to implement commonly used app components much faster than before. By migrating these dialog components, the team was able to clean up 1600+ lines of code, making it much more readable, understandable, and significantly easier to maintain.
Refining the developer experience
Jetpack Compose drastically increased the efficiency of previewing, developing, and implementing UI by allowing developers to reuse and share UI elements. ZEPETO developers have already created more than 230 preview functions to effortlessly test and debug features across the application.
It was also relatively easy for the team to learn how to use Jetpack Compose. “It doesn’t take long for developers familiar with the existing Android View system to reach a level where they can use Compose in actual practice,” said Hojung.
Moving forward with Compose
The ZEPETO team is motivated by Google’s increasing support for Jetpack Compose as it’s clear Compose is a huge priority for Google. They’re excited about how Google is integrating more Android APIs with Compose, and are looking forward to further development of the toolkit.
Several of ZEPETO’s features are now built with Jetpack Compose alongside the graphics built with Unity and OpenGL, such as the character shop, video and photo editors, and dialog components, but the team doesn’t plan to stop there. Given the improvements they’ve seen with development speed, code maintenance, and code reduction, they’ll continue migrating existing screens and building new features with Compose. “In the long run,” finished Hojung, “more than 80% of the UI will be written with Compose,” with the remaining UI and graphics with Unity and OpenGL.