In 2021 I wrote a bit about Jetpack Compose’s support for autofill. At the time the APIs were pretty clunky to use. Back then you needed to wrap your composable in an AutofillNode, manually add it to a autofill node tree, and manage updating your text field’s state yourself.
Compose UI 1.8.0 introduces new autofill APIs that address many of these shortcomings. The new APIs are more concise and make it easier to support autofill with Jetpack Compose.
Continue reading ›TransactionTooLargeException can be a difficult crash to fix on Android. For developers who haven’t had the joy of troubleshooting TransactionTooLargeException before, here’s an overview:
When your Activity is going into the background onSaveInstanceState() is your application’s opportunity to persist any transient state to a Bundle. This is useful for maintaining state that would otherwise be lost, such as text a user has entered
into a text field. Ultimately this results in a Binder transaction - one of Android’s primary tools for inter-process communication (IPC). This allows Android to save your bundled state outside of your process so if your process is killed you can restore that state later.
Binder transactions come with a limitation. The transaction buffer (which is shared across your entire process) is capped at 1MB. While the documented cap is 1MB, it appears that in practice the OS will TransactionTooLargeException when your application attempts to save more than 500KB.
Beacuse of this limitation, Google suggests saving no more than 50kb of data total. That includes saved view state, anything you explicitly save in onSaveInstanceState(), and Fragment arguments.
ViewModels often contain application state that we may want to persist to our application’s saved instance state. AndroidX offers a “Saved State module for ViewModel” (lifecycle-viewmodel-savedstate) that gives ViewModels an API for doing just that. Simply add a SavedStateHandle argument to your ViewModel’s constructor, and the default ViewModel provider will take care of hooking up the state saving and restoring mechanisms.
When using a ViewModel with a Fragment, that Fragment’s arguments are included in the SavedStateHandle by default, giving you easy access to fragment arguments in your ViewModel.
There’s a catch here - your Fragment is going to save its arguments already, and the SavedStateHandle is going to save all of its contents separately. That means that we are going to end up with a duplicate copy of the Fragment arguments: one in the Fragment’s saved state and one in the SavedStateHandle’s state.
This generally isn’t a problem if you are only including very small amounts of data in your Fragment arguments such as a string or two. However if your Fragment is already putting too much data or large objects into the arguments this will multiply the impact of those arguments.
Continue reading ›Check out the slides below from my talk on Semantics in Jetpack Compose for the Twin Cities Kotlin User Group, or watch the recording here
[!CAUTION] This post is out of date. Compose UI 1.8.0 (released in April 2025) brought signifcant improvements to autofill, replacing most of the APIs described here. You can read about those changes here.
Autofill is one of my favorite features to come to Android in recent years. I never want to manually type in my address and credit card information again. Autofill makes filling out forms an absolute breeze!
With Jetpack Compose on the horizon I’ve been seeing a lot of questions around how to support autofill in Jetpack Compose. Yes, autofill is supported in Compose, and here’s how you use it!
Continue reading ›Jetpack Compose alpha 9 introduced an accessibility change that I’m personally excited about. We can now specify a “role” semantic for our Composables that accessibility services can use to provide more context to users. This context can be important to help a visually impaired user understand how their actions will affect your application for interactable elements.
A great example is an element that allows the user to select from a list of options. Visually impaired users may not have an obvious way to tell whether that element behaves like a checkbox (multiple options are selectable) or a radio button (only one option is selectable at a time). The new role property is intended to convey that type of information.
Continue reading ›
