Android Developer Relations Engineer @ Google, opinions are my own.
When not working with insets, I also like to write code testing code-writing code.
| GitHub | https://github.com/alexvanyo |
| Website | https://alex.vanyo.dev |
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:
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
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
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.
Code with the Italians 🤌
Matt