Jetpack Compose��� on the Desktop
The Awesome Android newsletter���s issue #201
pointed out a very interesting Gerrit entry related to Jetpack Compose, hinting
at a future desktop offering. This possibility is something that I have been
tracking for a few months now, so let���s explore what may be going on here.
Expecting Actual Code
When I was poring over the early dev builds of Jetpack Compose, I noticed
that some elements had commented-out expect and actual keywords. For example,
Canvas.kt
had commented-out expect keywords and
AndroidCanvas.kt
had commented-out actual keywords.
Those keywords are tied to Kotlin/Multiplatform (KMP for short).
In KMP, you have Kotlin code that can run across all platforms (Kotlin/Common).
That code can expect an API that, for any given platform, something else will supply
the actual implementation of that API. For example, you can have common Kotlin code
that will expect Android and iOS modules to implement the actual version of the expected
API, using platform-specific stuff to do so. This is a bit reminiscent of how your
main/ source set in an Android app can ���expect��� that each of your product flavors
have an ���actual��� implementation of some class (e.g., a strategy pattern implementation
tied to that flavor).
Since the keywords are commented out, we do not really need a KMP setup to be
able to build or use Compose. And there are fairly few occurrences of these
commented-out keywords, so this may have been just a form of documentation,
leveraging KMP keywords for showing the relationship between functions.
But, somebody was thinking about Compose on multiple platforms, at least to some level.
Android as API
We often say that our code depends upon Android. However, much of the time,
that is really shorthand for ���our code depends upon Android APIs���. We use android
classes and expect them to do what we want them to do. Exactly what those
implementations are and how they accomplish their aims usually is beyond what we
really care about as app developers.
As a result, as long as we satisfy the symbols that we reference and that the
compiler needs, exactly what sits behind those symbols is immaterial, so long as
our code works.
Android developers take advantage of that on a daily basis:
Your compileSdkVersion is used to identify a JAR containing all the public
symbols from the Android SDK. But the actual implementation of all the Java
methods is simply throw new RuntimeException("Stub!"). The real implementation
of Android is added to our classpath at runtime; the android.jar that we compile
against is not packaged in our APKs.
Robolectric, in the end, is an implementation of a slice of the Android SDK that
does not have any Android ties. Robolectric���s implementation gets used in unit
tests that run on the JVM, not on Android, allowing us to test a bit more of our
code than we might otherwise, while also allowing us to avoid having to roll our
own mocks of those android classes.
What That Gerrit Entry Shows
The main Gerrit link
from the Awesome Android newsletter represents a KMP project, targeting the JVM desktop.
In there, desktopMain/ is a source set for code that will be used for desktop apps.
And in that source set, we see class names that look an awful lot like a subset
of the Android SDK, such as android.content.Context and android.view.View.
The implementations of those classes look nothing like Android. For one, they are all
in Kotlin, and last I checked, the AOSP framework classes are still in Java.
And those classes implement a tiny subset of the real framework APIs. Right now, the
desktopMain/ implementation of Context, for example, is 43 lines of code���
including the copyright header comment. There are individual methods in the
real Context class that are longer than that.
The objective appears to be to satisfy the compiler to allow Compose code to build
an Android app, with class and function implementations that use desktop Java instead of Android.
The actual UI is rendered by a SkiaWindow, which relies on JetBrains��� Skija project,
which offers Skia bindings for Java. Skia is an open source
2D graphics library, one that powers rendering in Android, Chrome OS, and in browsers
like Chrome and Firefox.
So, at least at an experimental level, Google appears to be working on getting
Jetpack Compose to support desktop apps, as well as Android apps.
Implementing ���fake��� Android framework classes may be somewhat of a stop-gap.
If Google elects to take Jetpack Compose more fully into KMP, uncommenting
those expect and actual keywords and expanding upon them, then the desktop code would switch
to providing the actual API that Compose is trying to expect.
Of course, right now we have no idea if Google will ever bring this to fruition.
For all we know, this is just an experiment, one that will never see the light of
day (beyond blog posts like this one). We know that it is actively being worked on ���
one of the developers uploaded a new patchset while I was writing this post.
Regardless, implementing something like this is
likely to happen. I have seen other developers start to poke at this sort of thing,
and I considered doing it myself. It���s possible that all of those efforts will come
to naught as well, but there���s a decent chance that somebody will succeed.
If Jetpack
Compose becomes Google���s recommended UI approach for Android, having the ability to
also develop desktop apps from much of the same code base is a nice value-add, at minimum���
and possibly much more.
