Forem: Trinadh Thatakula

🚀 Jetpack Compose + AdMob Made Easy: Modern, Reusable Kotlin Composables for Android Developers

Trinadh Thatakula — Mon, 21 Jul 2025 05:41:58 +0000

Bringing Google AdMob ads into your Jetpack Compose app doesn’t have to be a struggle. I’ve assembled a suite of reusable, straightforward composable functions to help you quickly integrate Banner, Adaptive Banner, Collapsible Banner, Interstitial, and Native Ads—all with the modern, declarative style of Compose and best practices for MVVM.

Check out the original Gist for copy-paste code! Here’s a practical, dive-right-in guide for your next Android project.

Why Compose Your Ads This Way?

Uncluttered, Idiomatic Kotlin: Pure Jetpack Compose, leveraging state and side effects.
Reusable & Modular: Just drop the composable you need into any screen.
Best Practices Baked In: Lifecycle awareness, error handling, and MVVM-friendly APIs.
Ready for Production: Supports all major AdMob formats and follows Google’s latest SDK updates.

🛠 Prerequisites

Android app using Jetpack Compose
Google AdMob account + registered app & ad unit IDs
Your AdMob App ID in AndroidManifest.xml:

<manifest>
    <application>
        <!-- Sample AdMob App ID: ca-app-pub-3940256099942544~3347511713 -->
        <meta-data
            android:name="com.google.android.gms.ads.APPLICATION_ID"
            android:value="YOUR_ADMOB_APP_ID"/>
    </application>
</manifest>

📦 Dependencies

Add Google Mobile Ads SDK to your build.gradle:

implementation("com.google.android.gms:play-services-ads:23.0.0")

🖼️ Banner, Adaptive, & Collapsible Ads

Composable functions for flexible ad placement:

@Composable
fun AdMobBanner(
    unitIdRes: Int,
    adSize: AdSize = AdSize.FULL_BANNER,
    modifier: Modifier = Modifier
) { /* ... */ }

@Composable
fun AdMobAdaptiveBanner(
    unitIdRes: Int,
    margin: Dp = 0.dp,
    /* ... */
) { /* ... */ }

@Composable
fun AdMobCollapsableBanner(
    unitIdRes: Int,
    adSize: AdSize = AdSize.FULL_BANNER,
    collapseDirection: CollapseDirection = CollapseDirection.TOP,
    /* ... */
) { /* ... */ }

🕹 Interstitial Ads (Full-Screen)

Integrate rewarding ad breaks with a simple loader and callback flow:

fun Activity.loadFullScreenAd(
    unitIdRes: Int,
    onAdLoaded: (InterstitialAd) -> Unit,
    onAdFailedToLoad: (LoadAdError) -> Unit,
    onAdDismissed: () -> Unit
)

Load the ad after the previous one is dismissed for smooth user experience.

🦄 Native Ads

For a more custom look, use the composable that auto-loads and lays out the ad components:

@Composable
fun NativeAdComposable(
    adUnitId: String,
    modifier: Modifier = Modifier
)

Tip: To bind native ad views correctly, define IDs in res/values/ids.xml:

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <item type="id" name="ad_headline" />
    <item type="id" name="ad_body" />
    <item type="id" name="ad_call_to_action" />
    <item type="id" name="ad_media" />
    <item type="id" name="ad_icon" />
</resources>

🧩 Usage Example

Compose a sample ad screen in seconds:

@Composable
fun AdScreen() {
    val context = LocalContext.current as Activity
    var interstitialAd by remember { mutableStateOf(null) }
    // Load and display ads...
    AdMobAdaptiveBanner(unitIdRes = R.string.your_banner_ad_unit_id)
    NativeAdComposable(adUnitId = stringResource(R.string.your_native_ad_unit_id))
    Button(onClick = { interstitialAd?.show(context) }, enabled = interstitialAd != null) {
        Text("Show Interstitial Ad")
    }
}

⚡ Pro Tips & Considerations

Use Test IDs during development to avoid violating AdMob policies.
Strategic Placement: Don’t overwhelm users—show interstitial ads only at natural app transitions.
Handle Errors Gracefully: Hide ad containers or swap in placeholders if loading fails.
Lifecycle-aware: Release resources as shown.

📚 Full Code & Deep Dives

See the full Gist for all code.
Tweak, contribute, and ask questions in the comments!

Compose modern, clean mobile apps and monetize faster—happy coding! 🎉

Did you find this helpful, or want to see support for rewarded ads? Let me know in the comments!

[1] https://gist.github.com/trinadhthatakula/e4db4a7219f6ef6d066e109015edc44e

Android UI: Jetpack Compose vs. Views - The Definitive Shift (And What It Means For You)

Trinadh Thatakula — Wed, 11 Jun 2025 14:51:15 +0000

Hey folks! 👋 Let's talk Android UI.

If you're building Android apps, you've undoubtedly felt the ground shifting beneath your feet. Google has made it crystal clear: Jetpack Compose is the new default.

This isn't just another UI toolkit; it's a fundamental paradigm shift from the imperative, XML-based Views to a declarative, state-based development model. What does that actually mean for us as developers?

🚀 The Power of Declarative UI & Boilerplate Annihilation

With Compose, we describe what our UI should look like based on its current state, and the framework efficiently handles all the rendering and updates. This is a game-changer for developer productivity.

Think about the sheer volume of boilerplate code we've traditionally written:

No more findViewById()! Seriously, that alone is a win.
Gone are the days of manually inflating complex XML layouts.
Repetitive setOnClickListener and other event listeners? A thing of the past.
Building RecyclerView adapters with cumbersome ViewHolder patterns becomes vastly simpler.
Programmatically updating UI elements (text, visibility, colors) based on state changes is now inherent to the design.
Complex custom View hierarchies are often replaced by simpler, more composable functions.

This declarative approach means significantly less code, faster iteration cycles, and ultimately, cleaner and more maintainable codebases. It's about focusing on the intent of your UI, not the mechanics of its construction.

🤔 The Nuance of Maturity

While Compose is incredibly powerful and exciting, it's also a rapidly evolving ecosystem. Some developers have reported friction points, particularly concerning:

Navigation Library: It can be complex, sometimes leading to reliance on third-party solutions.
Tooling Stability: Features like previews, while revolutionary, can occasionally be inconsistent.
Component Completeness: While Material 3 is robust, some specific components might require custom implementations or workarounds.

This "maturity gap" is something the community and Google are actively addressing, but it's an important consideration for real-world projects.

📊 Performance Deep Dive

The performance story is nuanced.

APK Size & Build Times: While there's an initial overhead when introducing Compose to an existing project, a full migration generally leads to reduced APK size and faster build times.

Runtime Performance: Compose shines with dynamic and animation-rich UIs, thanks to its "smart recompositions" that only update necessary parts. However, for highly static and memory-sensitive UIs, traditional XML Views can sometimes be more efficient in terms of consistent CPU usage and lower memory footprint. It's about choosing the right tool for the right job.

🏛️ The Enduring Legacy of Views

So, will Android development completely shift to Compose, and what happens to Views?

The answer is, the traditional View system is not being deprecated. It remains crucial for:

Vast Legacy Codebases: Rewriting established enterprise apps from scratch is rarely feasible.
3rd Party SDK Integration: Many SDKs don't yet offer mature Compose-friendly solutions.
Specific UI Needs: For very static or extremely memory-sensitive UIs, XML can still hold an advantage.

Google understands this, which is why robust interoperability is a cornerstone of Compose. You can seamlessly embed Compose UI into existing View hierarchies (ComposeView) and even integrate traditional Views or Fragments within a Compose UI (AndroidView).

🗺️ Charting the Course: A Phased Migration

The future is not a disruptive rewrite, but a phased, strategic migration.

New Features in Compose: Start building all new screens and features with Compose.
Convert High-Value Screens: Prioritize migrating dynamic or complex UIs where Compose excels.
Build a Shared UI Library: Create reusable Compose components to ensure consistency.
Gradually Replace Old Views: Use a bottom-up approach to replace simpler Views over time.

This approach minimizes risk, allows teams to learn and adapt, and ensures that your applications remain future-ready across the diverse Android ecosystem, including phones, foldables, tablets, and more.

What are your thoughts on this evolving landscape? Have you started your Compose journey? What challenges or successes have you encountered?

Share your experiences and tips in the comments below! 👇