If we say we are doing Declarative Programming ......

# compose-wear

[Ash]

If we say we are doing Declarative Programming ... shouldn't the code be the same for both round and square but the Composable does the correct layout for the device?

So we should not need this if statement.

These should both just be Row and each WearOS device doing the correct rendering ...

if (LocalConfiguration.current.isScreenRound) {
    CurvedRow(
 } else {
    Row(

This does not feel like Declarative to me ??? 🤷🏽

[Ash]

For SwiftUI my code exactly the same for iOS / Mac / iPad / etc ... Like exactly the same ...

[yschimke]

I believe it is a deliberate and debated design decision following https://developer.android.com/jetpack/compose/layouts/material#content-slots.

Material Components that support inner content (text labels, icons, etc.) tend to offer “slots” — generic lambdas that accept composable content — as well as public constants, like size and padding, to support laying out inner content to match Material specifications.

Which is why it's four generic lambdas, as opposed to a label as a String, or a TimeTextLabel that builds either, or only leading text. In compose you can make your own custom component that takes a String label and wrap TimeText. This api can be simplified to a String via your own simple @Composable wrapper, but the simpler version can't be expanded to handle more diverse content.

I completely agreed with your view when I first used it, now having compared it to the rest of Compose and Wear Compose, I have come to like the decision they made.

[Chris Sinco [G]]

This article might help: https://developer.android.com/jetpack/compose/mental-model it's not exactly big D-Declarative Programming in the historical sense…

[Chris Sinco [G]]

As to code being exactly across form factors in SwiftUI, we could have taken that approach with Compose which in some places we do like Text, Row/Column/Box, etc and some places where we chose to be explicit. For example, with Wear you can still have the need for a curved and non-curved Row depending where it is on the interface, i.e. near the edge…

[yschimke]

I like the fact the the compose TimeText could be used to host something like a curved sparklines graph if you are motivated enough to write one.

[Ash]

Thank you both for all the education ... believe over time both will evolve and converge ... only time will tell

Yes, we wrapped Row with the likes of ...
if (LocalConfiguration.current.isScreenRound) {

so we just call Row and it always does the correct thing. As we get more complex foldable devices our developers just call Row and the correct thing always happens.

[Ash]

We want our Developers to be Designers and just declare what they want and it will happen ...

The just say Menu and on very device / every configuration the menu is correct for that device and configuration ... 😀

[Sergio Sancho]

The main obstacle to unifying/auto-switching is that CurvedRow/Text is hard to do, and it doesn't support many of the thing that Row/Text do (modifiers and styles).

[Chris Sinco [G]]

For controls like Button or Menu, that is not as difficult to declare once and then it just works depending on form factor. Though I'd still argue people will want to change the position of the menu based on the scenario, e.g. larger screen.

For layout primitives like Row, I'm not sure that can easily be generalized based on form factor. I think developers will still have to make a choice about the exact behavior they want based on screen size and context.

Also keep in mind which I think is obvious is that Apple device fragmentation is minimal compared to Android. For example, we already have differing opinions about foldables with Samsung and Microsoft so building a UI toolkit that just works based on form factor / does the correct thing isn't the most tenable at this time.