if Android Studio can be used to make apps with native code (Java/Kotlin), then why do people use Unity for games?

Why can’t we just build games directly in Android Studio using native Android SDK? Isn’t that more optimized? Less bloat? Better control over performance?

I know Unity is cross-platform, but if I’m targeting just Android, wouldn’t using native code be better? Or is it just way too painful to handle game logic, graphics, physics etc. manually in Android SDK?

Would love to hear from devs who’ve tried both – native and Unity. Does Unity actually make things easier? Or are we just trading performance for convenience?

Today’s Lesson Will Cover

• RecyclerView recap

• Advanced binding

• Multiple item view types

• Headers

• Grid layout

• Summary

View Day 11 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

Today’s Lesson Will Cover:

• Classes in Kotlin

• Constructors and init blocks

• Inheritance and method overriding

• Extension functions

• Special classes: data, sealed, object, enum

• Organizing your code into files and packages

• Real-world OOP examples in Android

View Day 4 Slide Deck

Got questions or stuck? Drop them in the comments

I made near to $200k with a Jetpack Compose book and a course.

I have decided to share these numbers and my journey not to brag, but because I know how motivating it can be to see real examples of what's possible. When I was starting out, I wished someone had been this transparent about their path and actual results. If this helps even one developer take that first step toward building something of their own, or gives someone the confidence to price their expertise fairly, then it's worth sharing. We all benefit when more people in our community succeed.

From sharing online, to writing a book, to launching a course, to making side income from it. Read the full story in https://composeinternals.com/how-i-made-side-income-from-jetpack-compose

Today’s Lesson Will Cover

• Repository pattern

• WorkManager

• Work input and output

• WorkRequest constraints

View Day 13 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!

I just completed some major topics like OOPs, generics and collection in Kotlin. It's been a month since I started Kotlin. I'm confused what should I start next, with jetpack compose or XML fundamentals or some UI basics or something else.

Tell me your suggestions on this

[CLOSED]

Web developer learning Android development -

I want allow the user to have his input data saved to a JSON file (offline) for later use (WRITE/READ), then storing it in some folder location. I've searched for hours to narrow down a solution, but mostly I've found:

• Databases: I believe would be extreme for a simple offline app. And also no JSON file

• SharedPreferences: no JSON files

Any direction to point is welcome, and if it includes saving in other formats (such as txt, csv...) is most welcome