@commonsguy @gakisstylianos the slot lifecycle issue is a really tricky one. The next release of https://github.com/slackhq/compose-lints will have a new lint rule that should warn against some cases like this one which will lead to losing state.

Random PSA for anyone commonizing Compose code and utilizing lint checks like the built-in ones and https://github.com/slackhq/compose-lints.

Without extra work, those checks won't apply to common sources, so stuff that you thought lint would catch might have slipped through.

The extra configuration needed, based on AndroidX's setup and https://github.com/slackhq/slack-gradle-plugin:

https://github.com/alexvanyo/composelife/pull/2038

#JetpackCompose #AndroidDev

🚀 Tune in for Episode 125 on https://cwti.link/twitch as Alex Vanyo and Ian Clifton from Google dive into design, large screens, and Material3! Don't miss these expert insights! #AndroidDev #MaterialDesign

@gakisstylianos Because the configuration values depended on the insets, a lot of strange edge cases show up, especially around almost square windows.

It has been possible that Configuration.orientation is portrait, but Configuration.screenWidthDp > Configuration.screenHeightDp.

It's also been possible that rotating a device would always report a landscape Configuration.orientation.

This will affect qualified resource resolution, but it should be in an overall positive way.

Android 15 will have a tweak to Configuration values that is a great long-term change, especially in combination with edge-to-edge.

Previously, the Configuration's values were smaller than the overall window size by an amount of insets.

Once an app targets API 35 in Android 15, those values will now more closely match the actual window size, and include the space that is taken up by insets.

https://developer.android.com/about/versions/15/behavior-changes-15#stable-configuration

#AndroidDev

Circles and stars are great and all, but sometimes designs call for a shape that can create an aperioidic tiling.

With this new change to androidx graphics-shapes, you can create a shape from the hat-turtle continuum to get the einstein tile you need!
https://android-review.googlesource.com/c/platform/frameworks/support/+/3020721

#androiddev

@zachklipp at least now you can say you started a one-pager!

@alex_vanyo this is going to make it so much easier to test for accessibility!!

Size is my favorite one:

DeviceConfigurationOverride(
DeviceConfigurationOverride.ForcedSize(DpSize(1280.dp, 800.dp))
) {
MyScreen() // will be rendered in the space for 1280dp by 800dp without clipping
}

Through a bit of trickery by overriding the density, MyScreen() will be guaranteed to have 1280dp by 800dp space to render, regardless of the actual device size.

You can test layouts big and small on a single test device!

Want to test a component with an increased font scale?

DeviceConfigurationOverride(DeviceConfigurationOverride.FontScale(1.5f)) {
MyComponent()
}

Want to test a component in right-to-left?

DeviceConfigurationOverride(DeviceConfigurationOverride.LayoutDirection(LayoutDirection.Rtl)) {
MyComponent() // will be rendered with a right-to-left layout direction
}

New Compose testing API just dropped in 1.7.0-alpha01!

`DeviceConfigurationOverride` is the successor to accompanist/test-harness and allows locally overriding aspects of the device's configuration for @Composable content under test.

Font scale, font weight, dark mode, locale, layout direction, and size are all device-wide properties, so it's difficult to test for them (updating system settings from a test is not fun), but they're also super important to test for!

It's finally happening!

With the GitHub Actions runner releases this week (https://github.blog/2024-01-17-github-hosted-runners-double-the-power-for-open-source/) the default, non-large Linux runners now seem to all support KVM, which means you can replace using macOS runners to run emulators on CI by following these steps: https://github.blog/changelog/2023-02-23-hardware-accelerated-android-virtualization-on-actions-windows-and-linux-larger-hosted-runners/ (that blog refers to the large Linux runners specifically, but now those steps work on the non-large ones too!)

And as a bonus, the Linux ones appear to be way faster.

https://github.com/android/nowinandroid/pull/1158

#AndroidDev

📅 New Episode Alert! On Jan 31st, join us and @alex_vanyo, Android Dev Relations Engineer at Google, for a live session on enhancing our app with an expanding panel. Don't miss this hands-on experience! #AndroidAppDevelopment #TechTalks

🛠️ Exciting news! On the 31st, @alex_vanyo joins us for an in-depth live coding session. We're adding an expanding panel to our app and you can watch (and learn) how it's done! Set a reminder now. #CodingLive #AndroidExpertise

Starting 2024 by saying that I love love the testing APIs in Compose UI. They're so well written that I've rediscovered how enjoyable it is to write UI tests for my projects.

Whack-a-mole bugs are so fun to deal with.

A fix to one bug causes a different bug, fixing that causes another one, and then fixing that causes the first to show up again but in an ever-so-slightly different way that slips through the initial regression test...

Robolectric Native Graphics (through roborazzi) is also good. It hasn't been *super* stable in my experience with a couple of weird native crashes, is harder to set up and is slightly slower than paparazzi, but it's still absolutely better than having no tests.

If you're publishing a UI library, it's hard to trust your code if your project does not include screenshot tests.

Please spend an hour to set up paparazzi or something? It'll only take a few lines of code to prevent potential regressions for the rest of your project's lifetime.

https://cashapp.github.io/paparazzi/

By requiring a commit of the new version if anything changes, you can verify in code review if a newly added feature requirement is intentional (and as a bonus: it also outputs a lot more, like declared permissions!). With that, even if you currently don’t have unnecessary required features, you can avoid regressing availability which can result in a painful situation where users on some device are stuck on a version of the app if the new version is no longer compatible.