They don't (as of Jan 2022) host the @Preview Jetpack Compose code in a your MainActivity when Preview-ing items in Android Studio.

This means you can walk up the context.baseContext tree to determine if you're in your app's MainActivity class or another app's top-level activity class. My top-level activity is called MainActivity, so:

fun Context.findMainActivityOrNull(): MainActivity?{
  var context = this
  while (context is ContextWrapper) {
    if (context is MainActivity) return context
    context = context.baseContext
  }
  return null
}

This makes it so I can avoid setting the status bar color when in preview, that way it doesn't crash the preview trying to do that.

You call the above function like this:

context.findMainActivityOrNull() //when in a non-@Composable area

If you're in a @Composable function, then you should be able to go:

LocalContext.current.findMainActivityOrNull()

You can get fancy and wrap the misbehaving class up in an adapter to be neat and tidy about it, or just check if the result of the above is null when working around a few issues.

I usually do this by calling LocalInspectionMode.current to know if I'm in preview mode. It returns true if in preview mode.

Here's what the documentation says about LocalInspectionMode:

Inspectable mode CompositionLocal. True if the composition is composed inside an Inspectable component.

This will violate the functional paradigm of a composable function. It should be stateless and will not care if its running in preview mode or in an actual app or else, you will encounter unexpected bugs in the future when the app gets very large to manage.

You should try to refactor or restructure your composable so that it will only depend on the string directly as a parameter. The preview mode can send a hardcoded string for this composable but for your actual app, you can call that function that returns the proper string (which uses some objects).

More about "Thinking in Compose" here