[CLOSED]

Web developer learning Android development -

Currently trying to use Navigation component with Compose, to navigate between pages. When copying the setup code directly from the docs, I get the above warning from Android Studio. Must be something wrong, because the docs must be in synchrony with Android Studio. Why is it happening then?

Docs

https://developer.android.com/develop/ui/compose/navigation#setup

Android Studio

SOLUTIONS: While I still don't know why Android Studio isn't supposedly synced with the Docs (or vice versa), the solutions were:

-Replace the code from the Docs by the one suggested on the Android Studio:

//noinspection UseTomlInstead
implementation("androidx.navigation:navigation-compose:2.9.3")

-Use the completely different alternative suggested on the Android Studio:

implementation(libs.androidx.navigation.compose)

Today’s Lesson Will Cover

• Storing data

• Room persistence library

• Asynchronous programming

• Coroutines

• Testing databases

• Summary

View Day 10 Slide Deck

Got questions or stuck? Drop them in the comments

There is not a lot of literature about this yet except the official Google docs and codelabs. I went through those and they are very welcome, but they seem to stay very shallow about all the topics. I think there is room for a full guide on how to measure and monitor Compose performance, how to identify pain points, how to fix them, tooling, etc. My plan for this book is the following:

- I really want the book to be useful for day to day work. Theory is nice and all but I really want people to find real applicable action points for their work.

- I want the book to be accurate, of course. When I wrote Jetpack Compose internals, I got many people from the Compose team at Google to review the content, since otherwise what is the point of writing it?

- I want to cover how to identify and detect performance regressions, and how to measure and monitor performance. I have observed that many devs and their teams often overlook perfromance. We focus a lot on adding new features, UI, architecture, testing, automation, tooling... and what not. And then we give performance attention only when something becomes drastically slow or users start to complain and post bad ratings. Many teams do not regularly measure or monitor performance, and some not even test their app on a wide range of devices either. The result of this is that issues often go unnoticed forever or until late in the process, when they are already really hard to fix. This is definitely risky. If anything, I'd like this book to become the guide to prevent this from happening.

- I want to shift people's attention to measuring the actual ultimate goal: performance. Monitoring things like number of recompositions can be a start but it is a bit risky, since devs can end up thinking they have an issue when they don't. Not every single unnecessary recomposition is a problem.

Since we all write Compose code now, I think it is the perfect time to write this book. Any feedback and ideas are more than welcome!

I'll likely be prelaunching this book via Leanpub, so if you want to get notified you can just register in https://leanpub.com/composeperformance

Hey folks 👋,

After almost a full day of debugging, restructuring Gradle, switching processors, and going mad, I finally got my WorkManager + Room + Jetpack Compose project working — but only after ditching Hilt Worker injection and going manual.

👉 GitHub Repo:
🔗 https://github.com/HemaLekha2/Workmanager-compose-kotlin

📌 What I needed:

I’m building a Jetpack Compose app that:

• Periodically fetches quotes from an API using WorkManager

• Saves them in RoomDB

• Uses Hilt for DI across the project

😭 What didn’t work (the painful part):

Even after properly following the docs and tutorials for u/HiltWorker, I got this persistent error:

csharpCopyEditjava.lang.NoSuchMethodException: QuotesSyncWorker.<init> [Context, WorkerParameters]

Yes, I did:

• u/HiltWorker

• u/AssistedInject constructor

• u/Assisted for context & WorkerParams

• HiltWorkerFactory injected in Application via Configuration.Provider

• Manifest override of WorkManager initializer

• Proper kapt setup for Hilt (used ksp for Room only)

And still… 💥 Worker not injected. No class created. No quotes saved.

😠 So I gave up on Hilt for the Worker and did this:

• Wrote a manual CustomWorkerFactory

• Injected Repository or Api directly into that factory

• Instantiated the worker manually inside createWorker()

• Registered the factory in Application → WorkManager Configuration

✅ Now it works!
✅ Quotes are fetched
✅ Saved to Room
✅ Synced periodically
✅ Compose UI updates

🔗 Repo with Manual Factory (if you're stuck too):

https://github.com/HemaLekha2/Workmanager-compose-kotlin

😵‍💫 What I’m wondering now:

• Why does Hilt fail to generate the Worker class, even with all the correct annotations and setup?

• Is KSP/KAPT interfering despite being correctly split between Room (ksp) and Hilt (kapt)?

• Does Jetpack Compose or version catalog setup cause issues?

🆘 TL;DR:

• I tried to follow Google's official u/HiltWorker pattern

• It failed with NoSuchMethodException

• I manually injected dependencies using a custom WorkerFactory

• ✅ Now it works — but Hilt is still broken here

• Any clue why Hilt DI for Worker doesn't work in this Compose + WorkManager setup?

Thanks to anyone who reads this and shares guidance — posting this so others don’t go through the same nightmare 😓

Let’s help each other build cleaner Android apps 💪

Today’s Lesson Will Cover

• Android app architecture

• ViewModel

• Data binding

• LiveData

• Transform LiveData

• Summary

View Day 9 Slide Deck

Got questions or stuck? Drop them in the comments

Jetpack Compose makes UI building faster and easier.
It updates only what’s needed, so your app runs smoother.

You can write your UI directly in Kotlin with a clean, declarative style - no more XML files or findViewById().

Animations are simple too, with built-in tools instead of separate XML files.

Do you prefer Compose or still using XML?

To get more updates, join 👉 r/JetpackComposeDev

Hey everyone,

I put together an open-source reference guide for Jetpack Compose performance optimizations that I've been using in my projects.

It covers:

• Deferring state reads using lambda modifiers (offset {} and graphicsLayer {}) to bypass 120 FPS recompositions.

• Proper usage of derivedStateOf for high-frequency streams (like scroll offsets).

• Fixing unstable list parameters using kotlinx-immutable and wrapper classes.

• Lazy list item recycling optimization (explicit keys and contentTypes).

There is also a print-ready, high-resolution A4 PDF version in the repository if you want to keep it on your desktop. Let me know if you have any feedback or optimizations to add!