Dispatch Issue #12
Hello Friends. This is JetpackCompose.app's Dispatch, the newsletter that boils down everything that's happening in #AndroidDev, so you can sound smart to your friends!
This is Issue # 12 so let's get right to it 🚀
🕵🏻♂️ Insider Insight
Want to give your LLM of choice context about your entire codebase without tediously copying files one by one? Here's a brilliant hack: replace github with gitingest in any GitHub repository URL!
For example:
https://github.com/airbnb/Showkasebecomes:
https://gitingest.com/airbnb/ShowkaseGitingest gives you the entire repo as a single string that you can paste into ChatGPT, Claude, or your LLM of choice. It's perfect for when you need to ask questions about a codebase or get help understanding how different components interact.
Gitingest gives you a single string that represents you entire github repository. It has a role to play until entire codebase awareness is available natively in Gemini for Android Studio.
Gitingest gives you a single string that represents you entire github repository. It has a role to play until entire codebase awareness is available natively in Gemini for Android Studio.
This is incredibly useful when you need to:
- Get a high-level understanding of an unfamiliar codebase
- Find specific implementation details without cloning and searching locally
- Ask for explanations of complex code patterns across the repository
- Generate documentation and README for poorly documented projects
- Identify potential issues or improvement opportunities that span across a large number of files
Of course, this comes with the obvious caveat that you should only do this with code you're comfortable sharing with third-party AI services. Your company's proprietary codebase probably shouldn't be fed into public LLMs, but for open source projects or personal code, this is a massive time-saver!
The reason this is so relevant for the Android ecosystem is because the current state of Android Studio AI tooling doesn't make it easy to inject the entire codebase and that's what separates it other IDEs like Cursor that have all the hype these days.
And while, I absolutely expect this gap to go away over the next few months, a solution like gitingest does have a really high utility based on how things stand today for the Android development ecosystem.
I'll use this opportunity to also give a shoutout to a couple guys who are trying to build the Cursor for Android - Firebender . They've been hard at work and I admire their hustle so want to give them some credit because their agent does have access to the entire codebase (among other things). Jetbrains also have an agent that they offer called Junie but it's currently behind a waitlist.
🍾 Pop Quiz (and also WTFacts)
Which code snippet out of the two below is more performant?
Option A
class Element {
@JvmField var start = 0
@JvmField var end = 0
// Imagine there are 20 other Int properties here
....
....
}Option B
class Element {
@JvmField var begin = 0
@JvmField var end = 0
// Imagine there are 20 other Int properties here
}This is how the Element class ends up being used in practice for the purpose of this sample.
// Pre-populated list of Element
val elements = listOf<Element>(...)
for (element in elements) {
// or element.begin if you choose Option B
val start = element.start
val end = element.end
sum += end - start
}Find the answer in a section below ⬇️
📣 Personal Update
In the previous issue of this newsletter, I reached out to a few Android experts and asked them all an important question -
Where do you see Android Development in three years, and how do you think developers should prepare for that future?
It'll be an understatement to say that the lineup was stacked. The crew of experts shared a bunch of fun hot-takes, insights, wishes and predictions. It's a particularly interesting time for the Android ecosystem so I was really curious to hear all the diverse perspectives.
The reason this is relevant is because it was the topic we anchored on as part of the latest episode of the Fragmented Podcast. I was honored to hang out with my friend Kaushik to discuss the future of Android and just shoot the breeze. We covered a lot of ground on the episode so I encourage you to give it a listen.
There was one question in particular that Kaushik asked which I thought was worth sharing here-
Are there some opinions that you think were not covered by anyone, that you'd want to put out there?
Here are some of my raw notes that I put together and published to answer this question. I figured I'll just share them here as well since I think they might be interesting to some of my readers. I highly recommend giving the episode a listen to get the full context.
😆 Dev Delight
🤔 Interesting tid-bits
"Swift on Android" is gaining momentum
I recently learnt about "Swift on Android" which is an effort to enable running Swift code on Android devices 🤯 Apparently there's a community working-group forming to unify fragmented efforts. They're focusing on improving features such as concurrency support, library compatibility, and debugging experiences. While I'm personally very skeptical about adding yet another cross-platform solution to our already fragmented ecosystem (Flutter, React Native, KMP, etc.), it's interesting to see Swift expanding beyond Apple's walled garden. Sometimes I wonder how much progress we could've made if instead of creating yet another framework, we decided to just grab a pint of beer, figure out the one framework that we mostly believe in and spent all our collective energy in improving that solution. Oh well, I suspect this will remain a pipe dream of mine 🤔
Compose Multiplatform Previews confusion might finally be getting addressed
Currently, there are three different Preview annotations that one needs to deal with in Compose Multiplatform land, which is about as clear as a Gradle error message 🤭
androidx.compose.ui.tooling.preview.Previewfor androidMainandroidx.compose.desktop.ui.tooling.preview.Previewfor desktopMainorg.jetbrains.compose.ui.tooling.preview.Previewfor commonMain
The good news is that there's movement on supporting the commonMain Preview annotation in both IDEA and Android Studio. This matters because my tiny brain can't deal with cognitive load that doesn't need to exist. This consolidation was shipped as part of the IntelliJ IDEA 2025.1 EAP 2 build so go install it and go waste that brain energy on something else 😂
True "Hot Reload" for Compose has reached alpha status
In a previous edition of the newsletter, I mentioned this project that Jetbrains was working on. It's exciting to see it gaining traction and funding. While the implementation is still quite manual (as expected for an alpha), this could be a game-changer for Compose development workflows. The current approach of using @Preview in Jetpack Compose is helpful but doesn't match the immediacy of true hot reload. Check out the project at github.com/JetBrains/compose-hot-reload and consider giving feedback as this evolves.
🙌🏻 Subscriber Wins
I want this newsletter to be a space where we highlight and celebrate your successes. Today's shout-out goes to Sebastian, who recently had his talk accepted for the Android Makers conference in Paris. Huge congratulations 👏🏻
If you have a win you'd like to share (or know of somebody else who should be highlighted here), please please please let me know 🙏🏻 — I'd love to feature more stories and cheer on the achievements of the Android community. I feel like we don't do enough of this and want to use this space to move the needle on this front. You can simply email to get in touch and share.
🍾 Pop Quiz: Solution
The answer to that question is: Option B
Naming your variables begin and end (as opposed to start and end) results in more performant code, based on how it was being used in the example 🤯
// Option B
class Element {
@JvmField var begin = 0
@JvmField var end = 0
// Imagine there are 20 other Int properties here
}
// Usage
// Pre-populated list of Element
val elements = listOf<Element>(...)
for (element in elements) {
val begin = element.begin
val end = element.end
sum += end - begin
}I know this sounds bonkers, as it rightly should. This was the subject of a blog post that Romain Guy wrote about to describe this surprising behavior.
The key insight in that blogpost was that ART (Android Runtime) organizes fields in memory based on:
- Type groups (larger types like Long/Double come first)
- Alphabetical order within each type group
Since all the properties in our example were Int properties, ART chooses to arrange all the variables in alphabetical order. When fields are accessed together but end up far apart in memory (due to their ordering), you get cache misses that significantly impact performance.
Hence when the variables that were closer in alphabetic order (begin/end vs start/end) were accessed together, it resulted in more performant code (40% faster as per Romain's code profiling for that example).
Indeed, naming things is hard.
🦄 How you can help?
👉🏻 If you enjoyed this newsletter, I'd greatly appreciate it if you could share it with your peers and friends. Your support helps me reach more Android developers and grow our community. Writing this newsletter takes time and effort, and it truly makes my day when I see it shared within your network. Consider tweeting about it or sharing it in your team's Slack workspace. Thank you!
👉🏻 If you find this newsletter or any of my other free websites or open source contributions useful, consider supporting my work 🙏🏻
👉🏻 Get my Maker OS Notion Template that I use to run my life on Notion. If you are into productivity, you will appreciate it! Here's a quick preview of what it looks like—
On that note, here's hoping that your bugs are minor and your compilations are error free.
