@xxfast This is a weak area at the moment, the limitations had me frustrated for some time. Here's what you need to do: • First, make sure you are only defining

@Preview

s from your top-level Application modules, for either Android or Desktop. You can try to do it from library projects or submodules, and some stuff might work if you import extra dependencies; but it's unsupported and gets ugly (ref: this thread). • Secondly; import the

compose.preview

and

compose.uitooling

dependencies for Android and Desktop as you would expect to; but for the Android top-level project you must apply a Gradle Dependency Substitution to 'deeply' replace all the JetBrains preview dependencies with the Google ones, for it to work with Android Studio properly. By 'deeply', I mean the replacement will affect all transitive dependencies as well. Just directly depending on the Google one won't work; you'll get duplicate class errors. I will fetch you a code snippet for the dependency substitution...

do you mean

compose.preview

?

Where:

Versions.Compose.JetBrainsMultiplatform

= e.g.

1.0.0-alpha4-build331

Versions.Compose.GoogleAndroid

=

1.0.1

I see - thanks @darkmoon_uk 🙌 will give that a go

The limitation that you can only put

@Preview

in the top-level module is painful in the common-case that you want to build a component library in it's own module... you would want the `@Preview`s to live alongside the components, but this is not directly possible right now 👎 As a compromise; I still define

@Composable

functions intended as previews in the component library module, just without their

@Preview

annotation, then expose them with the

@Preview

from the top level module e.g: Component Library Module (the preview implementation)

@Composable
fun MyButton_Preview() {
    MyButton(...)
}

Top-level Application Module (just proxy the preview, adding annotation)

@Preview
@Composable
fun MyButton() = MyButton_Preview()

yeah - i have a

:login

feature module that targets ios, jvm, android, js while

:login:ui

is a sub-module that only targets jvm and android. I wish i can just define my composable previews in the

commonMain

of

:login:ui

and keep the components and their previews together

You can play around with split panes in the IDE to make the code and preview visible at the same time... the Code / Split / Design won't be useful now because of the need to keep the Preview in a different module.

didn’t seem to work on my first try - i placed these in a feature submodule

:login:ui

kotlin {
  android {
    compilations.all {
      kotlinOptions {
        jvmTarget = "1.8"
      }
    }

    // Part of workaround to transitively enforce Google Preview/Tooling while JetBrains' is broken
    configurations.all {
      resolutionStrategy {
        dependencySubstitution {
          substitute(module("org.jetbrains.compose.ui:ui-tooling-preview:${Jetbrains.Versions.composeMultiplatform}"))
            .using(module("androidx.compose.ui:ui-tooling:${AndroidX.Versions.compose}"))
          substitute(module("org.jetbrains.compose.ui:ui-tooling-preview:${Jetbrains.Versions.composeMultiplatform}"))
            .using(module("androidx.compose.ui:ui-tooling-preview:${AndroidX.Versions.compose}"))
        }
      }
    }
  }
  ..
}

As mentioned, the dependency substitution should go in your Application (Top-Level) module, not in a sub-module.

ah i see

👌 It's there, but that grey-boxed

ComposeViewAdapter

message is actually the error state expected when the dependency substitution isn't applied.

ah my bad - let me give that a try

@Igor Demin is this something every project should be doing? Re: deep dependency substitution

@Igor Demin is this something every project should be doing? Re: deep dependency substitution

Only as a workaround. Either Android Studio doesn't work with the artifacts published by maven coordinates other than

androidx.compose.ui:ui-tooling-preview

Or our

org.jetbrains.compose.ui:ui-tooling-preview-android

is broken. We currently investigate a possibility of not publishing our own android artifacts and reusing the already published

androidx.compose

artifacts. After that this issue will no longer be relevant.

Is there a ticket/issue raised regarding this on compose-jb?

I haven't found any

Created: https://github.com/JetBrains/compose-jb/issues/1143