Jetpack Compose simplifies UI development, but when combined with Hilt and Compose Preview, it exposes a subtle architectural challenge that many teams encounter in real projects.
This article explains:
the real problem
why it happens
why some “clean” solutions fail
the production-safe solution
whether this approach is industry-standard
The problem
In a typical Compose screen, it’s tempting to write:
@Composable
fun Screen(
vm: MyViewModel = hiltViewModel()
)
This works perfectly at runtime, but crashes in Compose Preview with errors like:
java.lang.NoSuchMethodException: MyViewModel.<init>()
Why this happens
Compose Preview:
When hiltViewModel() is invoked in Preview, Compose attempts to instantiate the ViewModel using a no-arg constructor, which Hilt ViewModels intentionally do not have.
This is expected behavior.
Why common fixes are wrong
Some common (but incorrect) workarounds:
These approaches:
The correct mental model
Compose Preview is not runtime.
Therefore:
Hilt must never be invoked in Preview
UI must not depend on concrete ViewModel implementations
ViewModel creation must be explicit, not inferred
The solution is abstraction + explicit wiring.
Step 1: define a ViewModel contract (interface)
Instead of exposing a concrete ViewModel, define what the UI actually needs.
interface Step1ViewModel {
suspend fun submit(
locale: String,
selectedState: OnboardingState
): Result<Unit>
}
Why this matters
Step 2: implement the real Hilt ViewModel
@HiltViewModel
class Step1ViewModelImpl @Inject constructor(
private val repository: Repository
) : ViewModel(), Step1ViewModel {
override suspend fun submit(
locale: String,
selectedState: OnboardingState
): Result<Unit> = withContext(Dispatchers.IO) {
val response = repository.submit(locale, selectedState)
if (response.isSuccessful) {
Result.success(Unit)
} else {
Result.failure(response.error)
}
}
}
Why return Result
Step 3: create a fake ViewModel for Preview
class FakeStep1ViewModel : ViewModel(), Step1ViewModel {
override suspend fun submit(
locale: String,
selectedState: OnboardingState
): Result<Unit> {
return Result.success(Unit)
}
}
The fake ViewModel:
The tempting abstraction — and why it failed
A common next step is to introduce a helper that tries to “automatically” choose between a fake ViewModel and a Hilt ViewModel based on Preview detection.
While this looks clean, it introduces a serious problem:
Preview detection relies on tooling signals
tooling signals are not runtime guarantees
fake ViewModels can leak into real app execution
behavior becomes non-deterministic and hard to debug
This approach hides a critical architectural decision behind a helper function.
The key realization
Preview is a build-time concern, not a runtime concern.
Runtime code should never guess whether it is running in Preview.
Once this is accepted, the correct solution becomes obvious.
The production-safe architecture
The rule
A composable must not decide how its ViewModel is constructed.
That responsibility belongs to the caller.
Pure UI composable (no DI knowledge)
@Composable
fun Step1Screen(
vm: Step1ViewModel
) {
}
Runtime wiring (NavHost / Activity)
composable("step1") {
Step1Screen(
vm = hiltViewModel<Step1ViewModelImpl>()
)
}
Preview wiring (explicit fake)
@Preview(showBackground = true)
@Composable
fun Step1ScreenPreview() {
AppTheme {
Step1Screen(
vm = FakeStep1ViewModel()
)
}
}
No guessing.
No inspection flags.
No runtime ambiguity.
Is this a standard production approach?
Yes.
This pattern aligns with:
Why this scales in production
✔ Separation of concerns
UI depends on interfaces, not DI frameworks
✔ Testability
Fake ViewModels work in unit and UI tests
✔ Stability
No reflection hacks, no no-arg constructor abuse
✔ Maintainability
Clear boundaries and explicit ownership
Conclusion
Compose Preview is not runtime
Hilt ViewModels must not be invoked implicitly
UI should depend on interfaces
Fake ViewModels belong to Preview and tests
ViewModel creation must be explicit and controlled
If a composable needs a ViewModel, it should never decide how that ViewModel is constructed — only what it can do.
That’s it for today. Happy coding…
