https://kotlinlang.org logo
Join Slack
Powered by
What is the whole Remote Compose about? <https://g...
# compose
j
r
It's a Compose API that can be used to generate documents that can be played back in a remote viewer. Those documents have some amount of interactivity (animations, layouts, click callbacks)
👀 7
K 1
j
I know the words, but I don't understand 😄 What is a document in this context? What is a remote viewer? Is it connected to anything like RemoteViews? Or, what usecase do you envision for this? 🙂 It wasn't announced, was it?
r
A document is just a binary blob, so something that can be sent over the network, or saved to disk, etc. A remote viewer is a viewer able to read and render those documents, which doesn't have to be in your app
👍 1
👍🏾 2
nice spin 1
RemoteViews are different because they let you send instructions to views hosted in another process. This comes with limitations like not being able to do custom drawing. Remote Compose can send drawing instructions for instance
💡 2
s
so it's similar to server-side rendering?
r
Kind of but yeah
👍 1
d
I feel like it's more client-side rendering and server-side composing... 😊
👍 2
s
I see... Seems awesome.
r
@Didier Villevalois The name server-side rendering always felt silly to me. I guess it depends what you mean by rendering. Having worked on UI toolkit and graphics pipeline, it means putting pixels on screen. But to a lot of folks (mostly Web I guess), it's defining the UI from data. We need better vocabulary 😂
K 11
☝️ 2
☝🏾 1
a
I see that remote-core is in java, any plans on making this multiplatform?
r
You'd have to ask Google folks, I don't work there anymore 😄
(but since it's "just" a document format, a viewer could be implemented in anything)
s
If I understand this correctly, then in a distant future, it could be possible for this to replace RemoteViews, then? App Widgets could, for example, essentially just be remote viewers, and we'd be able to send documents to them, instead of having Glance convert our Compose code to RemoteView stuff (with all of the limitations that brings)?
r
s
404. :'(
Screenshot_20251030-225358.png
j
This is only thing I found (yeah, broken link for me as well)
r
a
I was about to start implementing something like this so I’m very glad to have found it before starting to work on it. I see it’s Android only but having iOS compatibility would make a lot of sense for a server-driven UI solution, any plan to port it to Compose Multiplatform?
r
There's nothing about it that's Android specific afaik. @Nicolas Roard can tell you more
a
Might be my mistake but I just didn’t see any other platform declared in the Gradle files.
r
There's no other platform available at the moment (although there's a desktop player I think) but my point is that the format isn't Android specific
👍 1
👆 2
n
@sindrenm we actually added a way to create a RemoteView by passing it a RemoteCompose binary document in Baklava -- so you can write RC based widgets.
😱 1
@Antoine Lamy I designed it to not be Android specific, although the current implementation is only for Android (we have to start somewhere!). Keep in mind there's two sides of the coin here: 1/ creating a doc 2/ playing it. For #1 we have two libraries, one lower-level, "creation", which you can already use elsewhere than android (e.g. server side -- though it does need a jvm as there's some java), and a compose library "creation-compose" which is for now android only (all the dev is now happening in the androidx repo). #1 is java/kotlin (for... Reasons) but we are thinking about moving to pure kotlin for kmp at some point, and it actually wouldn't be too much work to write a creation lib in a different language (John Hoford is toying with a python version for instance). For #2, the player, in principle you could write it for different platforms, though in practice you will likely need skia-like capabilities (paths operations) and some text layout capabilities, but otherwise nothing too crazy (I originally wrote a C++ version using skia and filament that I was running on my mac). IMHO totally doable on iOS, it's just that we don't have the bandwidth to do it at the moment more than it would be impossible. It definitely would be cool.
a
Got it, thanks for your detailed answer. While having the ability to create docs from other platforms would be nice, the most important piece for me would be to have the player available on other platforms, minimally iOS. Since Compose on iOS is built on top of Skiko (Sia wrapper), do you think the two platforms could share the same implementation or there is too much low level Android specific stuff in the current implementation?
n
There's a couple of caveats -- on one hand I have a version of the player that runs on compose desktop, and we now also have a player implemented as a composable in addition to the Android view player. So, the plan is to make the compose player lib we have to be a CMP lib, merging those two implementations. But... This isn't a ton of code, actually; they both use the same underlying java library that provides the actual bulk of the runtime, all they do is providing an adapter layer to a draw engine (canvas). So we would also need to convert that lib (remote-compose-core) to kotlin in order to use the Compose on iOS path. In some ways, totally doable... but we unfortunately also need to keep the java implementation around for the android platform, so for now not a priority. We are also looking at possible other paths to bring an iOS player, but again, not a priority at the moment (maybe more likely around H2 2026?)
Fundamentally, I think it's likely we'll end up with multiple player implementations, and that put the actual burden not so much on writing those players than it is on making sure the players fully implement the specification, particularly as we continue to evolve it. We have some plans for validation testing to support that, but there's quite a bit more work to do there.
r
@Nicolas Roard that said someone motivated shouldn't have too much of a hard time converting the Java library to Kotlin right? 😀
n
Yup that's the easy part basically
Making sure things stay in sync is more the problem
(could also go with from scratch conversion every big release, but eh,...)
g
@Antoine Lamy because you mentioned server-driven ui rendering, I think this article would be interesting for you https://proandroiddev.com/remotecompose-another-paradigm-for-server-driven-ui-in-jetpack-compose-92186619ba8f
a
@gildor Thank you, that's what brought me here in the first place 🙂
👍 1
@Nicolas Roard Very cool to hear that a CMP lib (or another player lib) might be coming. From quickly peeking at the code, both 
remote-core
and 
remote-player-core
would need to be ported in order to run in non-JVM environments (in part at least), which makes the creation of an entirely new lib a little more complex to maintain over time if I'm getting this right. From what I've seen so far, if someone were to migrate these two modules over to Kotlin and substitute the main JVM dependencies to perhaps 
kotlinx-io
and 
kotlinx-datetime
, what would be stopping Android from using this implementation as well? The 
remote-player-view
module could probably stay as a Java and Android only module. I thought the Kotlin-Java interop was good enough to not be constrained by the language in a scenario like this. BTW, is there a place where this desktop player might be available?
Also, is there a dedicated channel we could use to discuss about this? Not sure growing this thread indefinitely is scalable and it might be a little too specific for the big "compose" umbrella. 😅
n
yeah, exactly as you say -- basically for non-JVM you'd need to port remote-player-core (super tiny, so easy) and remote-core (...bit more work). The port itself wouldn't be a particularly big deal if it was a one-time thing, but unfortunately, in order to use remote compose for android widgets, the implementation has to be in java (because of constraints on android-platform), not just remote-player-view. So the issue is more around maintenance. As time goes by, we should be doing less churn in remote-core, and this would help make it more doable (similarly, we are putting in place some infra for conformance testing that would also help maintaining different implementations). No dedicated channel on this slack but if there's interest it might make sense to create one.
gratitude thank you 1
a
Does Remote Compose support theming similar to MaterialTheme in Jetpack Compose? If not, what’s the recommended approach to handle theming (colors, typography, shapes) in Remote Compose?
3125 Views
Open in Slack
PreviousNext
Powered by