Posted by Posted by The Android Developers Team
Todoist is the world’s top task and time management app, empowering over 30 million people to organize, plan, and collaborate on projects big and small. As a company, Todoist is committed to creating more fulfilling ways for its users to work and live—which includes access to its app across all devices.
That’s why Todoist developers adopted Compose for Wear OS to completely rebuild its app for wearables. This new UI toolkit gives developers the same easy-to-use suite that Android has made available for other devices, allowing for efficient, manageable app development.
Developers at Todoist already had experience with Jetpack Compose for Android mobile, which allowed them to quickly familiarize themselves with Compose for Wear OS. “When the new Wear design language and Compose for Wear OS were announced, we were thrilled,” said Rastislav Vaško, head of Android for Todoist. “It gave us new motivation and an opportunity to invest in the future of the platform.”
As with Jetpack Compose for mobile, developers can integrate customizable components directly from the Compose for Wear OS toolkit, allowing them to write code and implement design requirements much faster than with the View-based layouts they used previously. With the available documentation and hands-on guidance from the Compose for Wear OS codelab, they were able to translate their prior toolkit knowledge to the wearable platform.
“Compose for Wear OS had almost everything we needed to create our layouts,” said Rastislav. “Swipe-dismiss, TimeText, and ScalingLazyList were all components that worked very well out of the box for us, while still allowing us to make a recognizable and distinct app.” For features that were not yet available in the toolkit, the Todoist team used Google’s Horologist—a group of open-source libraries which provide Wear OS developers with features that are commonly required by developers but not yet available. From there, they used the Compose Layout Library to incorporate the fade away modifier that matched the native design guidelines.
Compose for Wear OS simplifies UI development for Wear OS, letting engineers create complex screens that are both readable and maintainable because of its rich Kotlin syntax and modern declarative approach. This was a significant benefit for the production of the new Todoist application, enabling developers to achieve more in less time.
The central focus of the overhaul was to redesign all screens and interactions to conform with the latest Material Design for Wear OS. Using Compose for Wear OS, Todoist developers shifted away from WearableDrawerLayout in favor of a flatter app structure. This switch followed Material Design for Wear OS guidance and modernized the application’s layout.
Todoist developers designed each screen specifically for Wear OS devices, removing unnecessary elements that complicated the user experience.
“For wearables, we’re always thinking about what we can leave out, to keep only streamlined, focused, and quick interactions,” Rastislav said. Compose for Wear OS helped the Todoist team tremendously with both development and design, allowing them to introduce maintainable implementation while providing a consistent user experience.
"Since we rebuilt our app with Compose for Wear OS, Todoist’s growth rate of installations on Google Play increased by 50%."
The developers at Todoist rapidly and efficiently created a refreshed application for Wear OS using Jetpack Compose. The modern tooling; intuitive APIs; and host of resources, documentation, and samples made for a smooth design and development process that required less code and accelerated the delivery of a new, functional user experience.
Since the app was revamped, the growth rate for Todoist installs on Google Play has increased 50%, and the team has received positive feedback from internal teams and on social media.
The team at Todoist is looking forward to discovering what else Compose for Wear OS can do for its application. They saw the refresh as an investment in the future of wearables and are excited for the additional opportunities and feature offerings provided by devices running Wear OS 3.
Todoist completely rebuilt and redesigned its Wear OS application with Compose for Wear OS, improving both the user and developer experience.
Learn more about Jetpack Compose for Wear OS:
Posted by Wojtek Kaliciński, Boris Farber, Android Developer Relations Engineers, and Xavier Ducrohet, Android Studio Tech Lead
To improve build speed and provide stable APIs, the Transform APIs will be removed in Android Gradle plugin (AGP) version 8.0. Most use cases have replacement APIs which are available starting from AGP version 7.2. Read on for more details.
The Android developer community's top request has been to improve build speed while making sure Android Gradle plugin (AGP) has a solid, stable, and well supported API.
To improve build speed starting from AGP 7.2, we have stabilized the Artifacts API and updated the Instrumentation API. For common use cases, these APIs replace the Transform APIs, which cause longer build times and are gone in AGP 8.0.
This article walks you through transitioning off the Transform APIs, whether you're working on a Gradle plugin or an application.
To improve build times, we split Transform's functionality into the following APIs that are optimized for common use cases:
For examples of how to use the replacement APIs see the Transform API update note, and our Gradle recipes.
Make sure that you update your plugins to be AGP 8.0 compliant before updating your app to AGP 8.0. If the relevant plugins are not compliant, please create a bug that includes a link to this post and send it to the plugin authors.
Several commonly used plugins have already migrated to use these new APIs, including the Hilt Gradle plugin.
If your use case is not covered by any of the new APIs, please file a bug.
We encourage you to get started with making your plugins compatible with the new AGP APIs. Getting started now means that you have enough time to familiarize yourself with the APIs, share your feedback and then upgrade your dependencies and plugins.
Posted by Yasmine Evjen, Community Lead, Android Developer Relations Android Dev Summit is back, and this year, we’re coming to you! Whether you’re tuning in online or–for the first time since 2019–joining in person at locations around the world, we can’t wait to see you! It’s your opportunity to learn from the source, about building excellent apps across devices.
Posted by The Android Developers Team
Outdooractive, Europe’s largest outdoor platform, provides trail maps and information to a global community of more than 12 million nature enthusiasts. As a platform focused on helping users plan and navigate their outdoor adventures, Outdooractive has long viewed wearable devices like smart watches as essential to the growth of their app. Users value wearables as navigation tools and activity trackers, so when Google reached out with Android’s new UI toolkit, Compose for Wear OS, Outdooractive’s developers jumped on the opportunity to improve their app for this growing market.
The application overhaul quickly showed the benefits of Compose for Wear OS. It cut development time by an estimated 30% for Outdooractive’s developers, accelerating their ability to create streamlined user interfaces. “What would have taken us days now takes us hours,” said Liam Hargreaves, the Senior Project Manager of Outdooractive.
Having a modern code base and increasing the development speed helped make the UI code more intuitive for the developers to read and write, allowing for faster prototyping in the design phase and more fluid collaboration. This helped the developers create a more convenient experience for users.
Outdooractive’s app strives to deliver accurate information in real time to the users’ wearable devices, including turn-by-turn navigation, trail conditions, and weather updates.
“Our app has a relatively complex set of interactions,” said Liam. “Each of these needs to be kept simple, quick, easy to access, and clearly presented — all whilst our customer could be standing on a hillside or in a storm or wearing winter hiking gear and gloves!”
New features in Compose for Wear OS helped the Outdooractive developers create a higher quality app experience for users on the go. The Chip component significantly improved the process for creating lists and allowed developers to use pre-built design elements, saving the team days of work. ScalingLazyColumn also optimized the creation of scrolling screens without the need for RecyclerView or ScrollView.
The developers were also excited by how easy it was to use the AnimatedVisibility component because it allowed them to animate functions that they previously didn’t have time for. The team especially appreciated how Compose for Wear OS made it much easier to present different UI states to the user by communicating “loading” or “error” conditions more clearly.
"Compose makes the UI code more intuitive to write and read, allowing us to prototype faster in the design phase and also collaborate better on the code."
Since implementing Compose for Wear OS, Outdooractive’s users have spent more time on wearable devices doing things they normally would have done on their phones, such as navigating hiking routes — a key UI goal that Compose for Wear OS helped the developers to achieve.
“We see wearables as a critical part of our product and market strategy — and the reaction from our users is extremely positive,” Liam said.
Outdooractive’s developers used another Android Wear OS capability called Health Services to implement fitness tracking features such as heart rate monitoring into the app by leveraging on-device sensors to offer an experience unique to wearable devices. Health Services on Wear OS automizes the configuration of all health- and fitness-related sensors; collects their data; and calculates metrics such as heart rate, distance traveled, and pace, making it easy for developers to implement sophisticated app features while also maximizing battery life. With Health Services and Compose for Wear OS, Outdooractive’s developers plan to further expand the app’s offerings that are made possible by body sensors.
Outdooractive’s streamlined process shows just how easy Compose for Wear OS makes application development because it gives developers the flexibility to experiment with different layouts without increasing development overhead.
Liam had clear advice for other developers considering using Compose for Wear OS: “Fully embrace it.”
Jetpack Compose for Wear OS helps build more engaging user experiences for wearable devices.
To get a first look, watch the Wear OS talk from Google I/O or try the Compose for Wear OS codelab to start learning now.
Posted by Rakesh Iyer, Staff Software Engineer and Leland Rechis, Group Product Manager
We are upgrading the Speech Services by Google speech engine in a big way, providing clearer, more natural voices. All 421 voices in 67 languages have been upgraded with a new voice model and synthesizer.
If you already use TTS and the Speech Services by Google engine, there is nothing to do – everything will happen behind the scenes as your users will have automatically downloaded the latest update. We’ve seen a significant side by side quality increase with this change, particularly in respects to clarity and naturalness.
With this upgrade we will also be changing the default voice in en-US to one that is built using fresher speaker data, which alongside our new stack, results in a drastic improvement. If your users have not selected a system voice, and you rely on system defaults, they will hear a slightly different speaker. You can hear the difference below
Speaker change and upgrade for EN-US
Sample Current Speaker
Sample Upgraded Speaker
Speaker upgrades in a few other languages
Current
Upgraded
HI-IN
PT-BR
ES-US
This update will be rolling out to all 64 bit Android devices via the Google Play Store over the next few weeks as a part of the Speech Services by Google apk. If you are concerned your users have not updated this yet, you can check for the minimum version code ,210390644 on the package com.google.android.tts.
If you haven't used TTS in your projects yet, or haven’t given your users the ability to choose a voice within your app, it's fairly straightforward, and easy to experiment with. We’ve included some sample code to get you started.
Here’s an example of how to set up voice synthesis, get a list of voices, and set a specific voice. We finally send a simple utterance to the synthesizer.
class MainActivity : AppCompatActivity() { companion object { private const val TAG = "TextToSpeechSample" } private lateinit var tts: TextToSpeech private val progressListener: UtteranceProgressListener = object : UtteranceProgressListener() { override fun onStart(utteranceId: String) { Log.d(TAG, "Started utterance $utteranceId") } override fun onDone(utteranceId: String) { Log.d(TAG, "Done with utterance $utteranceId") } override fun onError(utteranceId: String?) {} } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) val onInitListener = TextToSpeech.OnInitListener { tts.setOnUtteranceProgressListener(progressListener) tts.voice = tts.voices.find { it.name == "en-us-x-iog-local" } ?: tts.defaultVoice tts.speak("1 2 3", TextToSpeech.QUEUE_ADD, Bundle(), "utteranceId") } tts = TextToSpeech(this, onInitListener) } override fun onDestroy() { tts.shutdown() super.onDestroy() }}
Posted by Niharika Arora, Developer Relations Engineer
Building for Android Go involves paying special attention to performance optimizations and resource usage.
In part-1 of this blog, we discussed why developers should consider building for Android Go, some tips on optimizing the app memory and identified the standard approach to follow while fixing performance issues. In this blog, we will talk about the other vitals to pay attention to while building apps for Android Go.
Improving app startup time requires a deep understanding of things that affect it.
Move the tasks from UI thread to background thread
If there are tasks which are taking longer and blocking the main thread, try to move them to a background thread or prefer using WorkManager.
Lazy load third party libraries. A lot of libraries do have on demand initialization or disabling auto init options.
Identify and measure these transactions to understand :
Users often avoid downloading apps that seem too large, particularly in emerging markets where devices connect to spotty 2G and 3G networks with low bandwidth speed or work on pay-by-the-byte plans.
a. Don’t translate internal-only UI strings. Mark them as translatable = “false”.
b. Remove unused alternative resources: You can use the Android Gradle plugin's resConfigs property to remove alternative resource files that your app does not need. if you are using a library that includes language resources (such as AppCompat or Google Play Services), then your app includes all translated language strings for the messages in those libraries whether the rest of your app is translated to the same languages or not. If you'd like to keep only the languages that your app officially supports, you can specify those languages using the resConfig property. Any resources for languages not specified are removed.
The following snippet shows how to limit your language resources to just English and French
android { defaultConfig { ... resConfigs "en", "fr" }}
You can read more here.c. Don’t translate what doesn’t need translation: If the string does not participate in a UI, it should not be translated. Strings for the purpose of debugging, exception messages, URLs and so on should be string literals in code, not resources. i. Don’t translate what’s not shown to the user anywayIt’s possible to have a String resource that’s practically never shown to the user, but is still strongly referenced. One example is in your <activity>, if you have an android:label set and referencing a String resource but the Activity’s label is never actually shown (e.g. it’s not a launcher Activity and it doesn’t have an app bar that shows its own label). d. Don’t translate URLs: Consider this example:
You can read more here.
c. Don’t translate what doesn’t need translation: If the string does not participate in a UI, it should not be translated. Strings for the purpose of debugging, exception messages, URLs and so on should be string literals in code, not resources.
i. Don’t translate what’s not shown to the user anyway
It’s possible to have a String resource that’s practically never shown to the user, but is still strongly referenced. One example is in your <activity>, if you have an android:label set and referencing a String resource but the Activity’s label is never actually shown (e.g. it’s not a launcher Activity and it doesn’t have an app bar that shows its own label).
d. Don’t translate URLs: Consider this example:
<string name="car_frx_device_incompatible_sol_message">This device doesn\'t support Android Auto.\n<a href="https://support.google.com/androidauto/answer/6395843">Learn more</a></string>
<string name="car_frx_device_incompatible_sol_message">
This device doesn\'t support Android Auto.\n
<a href="https://support.google.com/androidauto/answer/6395843">Learn more</a>
</string>
You may recognize < and > - these are escape characters for “<” and “>”. They’re needed here because if you were to put an <a> tag inside a <string> tag, then the Android resource compiler would just drop them (as it does with all tags it doesn’t recognize). However, this means that you’re translating the HTML tags and the URL to 78 languages. Totally unnecessary. Instead, remove the part with HTML:
You may recognize < and > - these are escape characters for “<” and “>”. They’re needed here because if you were to put an <a> tag inside a <string> tag, then the Android resource compiler would just drop them (as it does with all tags it doesn’t recognize).
However, this means that you’re translating the HTML tags and the URL to 78 languages. Totally unnecessary.
Instead, remove the part with HTML:
<string name="car_frx_device_incompatible_sol_message">This device doesn\'t support Android Auto.</string>
This device doesn\'t support Android Auto.
Note we don’t define a separate string for “Learn more”, because it’s a common string. To produce the HTML snippet for the link, we define "<a href="https://support.google.com/androidauto/answer/6395843>%s</a>" as a string literals in code, and then drop the value of “Learn more” from resources into the format specifier.
e. Inline untranslated strings: By specifying strings in strings.xml you can leverage the Android framework to automatically change the actual value used at runtime based on the current configuration (e.g. based on the current locale, show a localized value for the string).
f. Remove duplicate strings: If you have the same string multiple times as a literal in code (“Hello World”), it will be shared across all instances. But resources don’t work this way - if you have an identical string under a different name then unless both are translated identically across 78 languages (unlikely) you’ll end up with duplicates.
Don’t have duplicate strings!
g. Don’t have separate strings for ALL CAPS or Title Case: Android has built-in support for case mutations.
Use android:capitalize (since API level 1). If set, specifies that this TextView has a textual input method and should automatically capitalize what the user types. The default is "none".
Posted by Marcus Leal, Product Manager, Google Play
Over the years, Android has evolved to support more devices such as watches, tablets, TVs, and even cars. Apps and games are a critical part of this ecosystem as they power many of the unique digital experiences that we all enjoy and rely on. As a way to make it easier for users to find your great apps across all Android devices, we are making changes to the Google Play Store, enabling users to more easily discover and install apps on other devices directly from their phone.
We recently introduced three updates to the Play Store phone app that will help your users’ devices work better together: homepages for non-phone devices, a device search filter, and the ability to remotely install an app to another device.
Users with a Wear OS watch, Android TV OS, or car with Android Automotive can navigate to the Play Store “Other devices” page on their phone app to see app and game recommendations, and editorials tailored to their non-phone devices.
Users can use the device filters to easily find apps and games optimized for their Wear watch, Android TV, or Android Auto-enabled devices.
These changes were designed to give developers new opportunities to showcase their multi-device app experiences, driving more engagement across the Android ecosystem.
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
%20(1).png)
%20(1).png)
