This might be a dumb question... but one thing I'v...
# compose
c
This might be a dumb question... but one thing I've always wanted to have in android is like a completely flexible emulator height and width so that I can "check" that my designs and layouts work on a WIDE range of android phones. This is just something I'm used to with web dev. Load my site. And just drag the bottom right hand corner to expand and contract the window. Could compose-desktop be used for "stress" testing my layouts like I envision or does compose desktop do something differently and I shouldn't bank on the compose desktop to match what would actually happen on my android device?
k
Sounds like a good use case for the
@Preview
annotation: https://joebirch.co/android/exploring-jetpack-compose-preview-annotation/
c
Preview doesn't give you a real time drag handle though right?
k
hmm no it doesn’t. If that’s what you are looking for then I misunderstood the question.
e
look into freeform window mode - you might want to try that out on a tablet emulator
also Chrome OS (Android runtime) and Ubuntu (Anbox) both support running Android apps in native resizable windows
c
As far as I know, Chrome resizing is the same as android resizing... i.e. it doesn't actually resizing until you stop dragging the window resizer. So instead of like 100 resizes in a 1 sec span, you only get a resize event when you drop the handle.
c
Not a dumb question - we’ve heard this feedback from other developers as well. Especially those developing for tablet. We are actively looking at how to make the design time experience (Preview) have more responsive controls (akin to Chrome Dev Tools), as well as the runtime experience (Emulator).
c
Off hand, I think I would prefer the emulator but preview might be easier to implement. Anyway. Thanks for responding and confirming it's not just me. 😁
👍 1
c
Yes the infrastructure needed for Preview is there, just have to finalize the user flows. But for Emulator it will take a bit more engineering work.
👍 1
Update: there is the freeform emulator which is meant for ChromeOS where you run Android apps in a window. This gives you the testing experience you would get with manually resizing the frame the app sits in (like your Compose Desktop example).
🤯 1
Long-term though we are looking into making the emulator window itself resizable
c
Ah. Thanks. I thought the chrome window drag didn't actually resize until you let go of the drag handle.
Thanks @Chris Sinco [G] for following up. Circling back to my first question though "Could compose-desktop be used for "stress" testing my layouts like I envision or does compose desktop do something differently and I shouldn't bank on the compose desktop to match what would actually happen on my android device?" Any guidance there by chance? I suppose "it should match, but there could be bugs" is probably the answer, but I guess I just was curious if having my design system on desktop was a quick way to test my android components across all device shapes and sizes.
c
Ah I see. It’s a good question and I’m not entirely sure because of screen density and not being technically familiar with how Compose renders things on desktop versus Android. In theory, since many things are expressed in
.dp
ideally it should look the same. But I may be oversimplifying (though it’s also really nice if this just works). Maybe @jim or @Adam Powell has more thoughts.
c
Yeah. I was thinking like... Even if I have no plans to launch a desktop app... It might be valuable to just have a desktop module as a playground for components just to test how resizing works because that seems way simpler on desktop than Android.
c
For sure. I actually sometimes do the opposite where I use Android Studio Preview to hack on a Composable in isolation then copy-paste back into Compose Desktop since IntelliJ doesn’t have the preview tooling
j
The ability to test without an emulator is one of the very real motivations behind Compose for Desktop.  In theory, it should mostly work the way you would expect it to.  In fact, I'd go one step further and say that you should strive to abstract your widgets from your app/runtime, and testing with Compose for Desktop is a great way to verify you aren't introducing any unexpected dependencies.  So yes, do it! With regards to differences: Yes, they are technically different platforms, so some things might be slightly different.  For example, fonts tend to render slightly differently on different platforms (the exact same font can be different, just due to the way text shaping works, etc), so some minor differences are expected, but the vast majority of Compose (including layout) uses platform-independent Kotlin common code so these behaviors should be identical on Desktop+Android.  Honestly, the best answer is that you should feel comfortable using Desktop for development and then just do a last sanity-check on a real Android device to be sure it looks pixel perfect.
👍 2
c
Awesome. Looking forward to a little more maturity from compose desktop as right now, getting it integrated into an existing Android compose app has proven difficult. Mostly due to the fact that Android compose wants you to use latest everything, while latest everything for desktop compose doesn't fair well. Plan on giving it all another shot with AGP 7, Gradle 7, kotlin 1.5 and hopefully some compose updates after Google io.