Alex Vanyo

I've converted my side project to Navigation 3 (or at least, a similar close fork of Navigation 3), which you can try out on the web here! alex.vanyo.dev/composelife Two more complex scene ideas I've been playing around with: A SceneStrategy wrapping another SceneStrategy, and derived entry lists.

One technique to solve this is to not have the detail in the underlying backstack state at first, and derive an entry list with a "transient" detail entry at larger window sizes. Only when you actually navigate to that entry does the entry get "realized" and get added to the underlying backstack.

I've converted my side project to Navigation 3 (or at least, a similar close fork of Navigation 3), which you can try out on the web here! alex.vanyo.dev/composelife Two more complex scene ideas I've been playing around with: A SceneStrategy wrapping another SceneStrategy, and derived entry lists.

Idea 1: I have a list-detail setup for my settings, but if there's even more space available, I want the entire list-detail setup to be in a dialog. I can do that by creating a custom DialogSceneStrategy that wraps my other scene strategies, and having the DialogScene wrap an arbitrary Scene:

Anyone have a lint rule that warns against doing with(dispatchers.IO) because you almost certainly wanted withContext(dispatchers.IO) instead? Asking for someone who did something silly: github.com/alexvanyo/co...

A response to the section on "How Can I Determine the Size and Position of Descendants of Peers?" Using onGloballyPositioned (or onSizeChanged, or similar modifiers) like this is a quick way to get yourself into trouble with layouts that take multiple frames to resolve that can flash or look janky.

This video from last year goes into a lot more detail about the problem space here, along with some examples of how to approach different problems: www.youtube.com/watch?v=PUxt...

A response to the section on "How Can I Determine the Size and Position of Descendants of Peers?" Using onGloballyPositioned (or onSizeChanged, or similar modifiers) like this is a quick way to get yourself into trouble with layouts that take multiple frames to resolve that can flash or look janky.

This can also wreck havoc on animations - maybe they can cover up some of the jankiness, but animations need to have a consistent view of the layout as it animates at each point in time. Shared element transitions don't really work if the shared element disappears completely for a frame.

A response to the section on "How Can I Determine the Size and Position of Descendants of Peers?" Using onGloballyPositioned (or onSizeChanged, or similar modifiers) like this is a quick way to get yourself into trouble with layouts that take multiple frames to resolve that can flash or look janky.

When you have composition being driven by information that you can only get in a later phase, like measurement, layout or drawing, the first composition can't be correct! This means that the first frame might be blank, or components might jump around as you get more info.

It was great to see both familiar faces and new ones at #dcnyc25 last week - especially to see how everyone's figuring out what #AndroidDev will look like with the new tools are moving at a blistering speed. The slides for my talk are available here: alex.vanyo.dev/talks/configurationchanges

Some are a lot trickier to handle directly - and it's pretty easy to write code that works assuming that recreation happens. Opting out of recreation is also a promise that new code works properly with updating in-place when the configuration changes.

It was great to see both familiar faces and new ones at #dcnyc25 last week - especially to see how everyone's figuring out what #AndroidDev will look like with the new tools are moving at a blistering speed. The slides for my talk are available here: alex.vanyo.dev/talks/configurationchanges

TL;DR: if you know the promise you are making, you can opt-out of Activity recreation via android:configChanges. The golden rule to do so properly in Compose is to have everything using configuration depend on a snapshot-state-backed source for it, like LocalConfiguration and LocalResources.

It was great to see both familiar faces and new ones at #dcnyc25 last week - especially to see how everyone's figuring out what #AndroidDev will look like with the new tools are moving at a blistering speed. The slides for my talk are available here: alex.vanyo.dev/talks/configurationchanges

Scenes! If there's only one concept to call out for Navigation 3, it's scenes. The abstraction layer allows showing multiple panes at a time, and in different ways. It's the integration hook that integrates Navigation3 with ListDetailPaneScaffold in a flexible, satisfying way.

After figuring out how to make the coordinates work, it's so satisfying to use a live-updating drag and drop that previews where the dropped content will go.

Some quirks: writing automated tests for this was hard since the drag and drop is done at the system level. I found a super hacky way to do so by interleaving normal Compose testing utilities and raw MotionEvents injected with UiAutomation.

Days since confusing myself with different frames of references and coordinate systems in Compose: 0

At minimum, you have a screen coordinate space (which is almost never what you want to use), a window coordinate space, and a Compose root coordinate space. Each of those can be measured in dps or pixels, and sometimes it matters if those pixels are integers or floats.