This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/ravage5d on 2025-02-22 19:22:46+00:00.

I'm currently learning Jetpack Compose. I have been an Android App Developer for the last two years. but the problem is that every company I've been to had their Android app written by some interns and the code looked worse than a dogshit (so even after 2 yoe on paper, I consider myself newbie in Android dev).

Now I've got a chance to start a project from scratch (basically rewriting the existing app). so I'm thinking I should use all latest frameworks, patterns and libs. I've decided build this with KMM. So I'm learning JC.

I checked out this sample JC app by android team. I'm stunned to look at their code, I mean it is just two screen app and the amount of complexities this app has (only on 'mobile' module) is just too much imo. you can run it to see yourself (requires java 17)

So is this how a production ready app looks now a days? question to devs who are working in a top/reputed company - what do you guys think of this? your/your company's code looks like that too?

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/timusus on 2025-02-21 11:30:03+00:00.

After updating KSP, Hilt and some other plugins on various projects recently, I keep running into weird and hard to track down build time errors, that have cost me hours, and maybe even days.

Build errors can be really difficult to track down, because each project's build is so unique - there's a chance you're the first to encounter each problem. The stack traces are often deep in some plugin, and rarely provide meaningful information you can act on, so you're stuck guessing, upgrading random dependencies and hoping, or abandoning your plugin update altogether.

I discovered that there's a solution - declaring all your plugins in the root level build.gradle file.

This post dives a little deeper into that, explaining why this helps.

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/Competitive_Twist575 on 2025-02-21 10:11:42+00:00.

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/sf2tlv on 2025-02-20 12:59:08+00:00.

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/Competitive_Twist575 on 2025-02-17 09:23:27+00:00.

This used to be one of my favorite libraries back in the day. Unfortunately, it's no longer working and is no longer supported. I created a replica using Compose Multiplatform, which supports all platforms at once and also added image support

you can test the live demo here: https://mejdi14.github.io/KMP-Liquid-Slider

or check the source code: https://github.com/mejdi14/KMP-Liquid-Slider

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/H3x0n on 2025-02-20 09:25:13+00:00.

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/Competitive_Twist575 on 2025-02-20 08:40:55+00:00.

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/Fearcoder_ on 2025-02-19 11:43:49+00:00.

Hey everyone,

I'm new to Kotlin and looking for guidance on designing UI for Android apps. I've heard about Jetpack Compose, but I'm wondering:

• Is Jetpack Compose the only UI framework available, or are there better alternatives?
• What’s the best approach to designing UI in Kotlin for a beginner?
• Which resources would you recommend for learning Kotlin UI development?

I’d really appreciate any tips or advice! Thanks in advance.

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/biomatic-1992 on 2025-02-18 14:39:22+00:00.

Hi there! 👋

I have open sourced my app a while ago, however, recently I have finished rewriting it to Jetpack Compose using my own solution to handle navigation in between screens.

Maybe it will be useful to you architecture-wise:

Will appreciate Github stars as a thank you! ❤️

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/SweetStrawberry4U on 2025-02-19 03:01:26+00:00.

The Problem Statement:

The submission:

Needless to say, rejected.

All the more reason to avoid take-home assessments to begin with ? Irrespective how desperately one needs a job ?

Edit ( After 2 hours and 8 comments ): ban / boycott / abscond take-home assessments !!

Let this post be a testament that - no two engineers think alike, design alike, follow the same naming conventions, review code alike. for someone something is more than adequate. for someone else something is always missing. there are standards and guidelines, but perceptions still differ. needless to say, people are more mindful about reviewing code of an employed colleague-at-work, while take-home assessment submissions are open for nit-picking and harsh rejections.

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/Warm-Falcon-3575 on 2025-02-18 10:11:21+00:00.

Hey all!

I've had a bit of a torrid time the last few weeks trying to find an accurate way of TV detecting and in the end got so frustrated with false positives and the like that I decided to build one that is completely Permission Free and actually WORKS!

It's on GitHub at and is fully MIT (about the closest I could get to Old School Public Domain!)

Hopefully what was my frustration across multiple TV devices and configurations, and the problem of fragmentation, will prevent you getting caught with the same.

Take it, use it, play with it. Even shout me out if you feel like it. No pressure. :)

Enjoy!

deVYNEL

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/Successful-Tap3743 on 2025-02-17 07:51:25+00:00.

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/vim_c on 2025-02-16 12:05:17+00:00.

I'm looking for effective methods to protect my APK files from reverse engineering. I know that decompiling and modifying APKs is relatively easy with tools like JADX and ApkTool, so I want to make it as difficult as possible for attackers.

So far, I've considered:

• Code obfuscation (e.g., ProGuard, R8)
• Encrypting sensitive strings and assets
• Implementing root/jailbreak detection
• Checking for debuggers and emulators
• Server-side logic to minimize critical code in the APK

Are there any other techniques you recommend?

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/BreakfastMaterial878 on 2025-02-15 14:41:08+00:00.

Hi Guys!

As we all know Firebase Dynamic Links is shutting down this August 2025.

Several client apps we built and support will be impacted by this.

Looked at alternatives like Branch, Adjust, Appsflyer but man look at their pricing! Also these are more of attribution platforms and don't provide the deeplink service as a standalone feature.

Also checked a few platforms our community folks have recently built but all of them missed a crucial feature, Deferred Deep Linking. This functionality ensures that after a user installs the app from the store, they are seamlessly redirected to the intended content upon first launch.

So finally building a new SaaS platform, Chottu.Link, aiming to make it a seamless drop-in replacement for Dynamic Links.

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/Objective-Display249 on 2025-02-16 08:34:42+00:00.

As someone new to Android Dev from React Native, I never saw such confusing and poor documentation in my life. But still managing to cope with it! The only good thing is, after started to work with this, all other documentations from other languages and frameworks feels so easy. 😂

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/eygraber on 2025-02-14 01:47:22+00:00.

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/BinaryFingerCX on 2025-02-13 17:29:17+00:00.

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/TypeProjection on 2025-02-12 16:53:50+00:00.

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/AbhijitMogaveera on 2025-02-11 14:53:41+00:00.

Hey folks 👋, I would like to share my recent side project which is an attempt to clone Youtube music Sliding panel layout

Source code link Github Link, Please give it star if you liked it

Demo

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/Kotzilla_Koin on 2025-02-10 16:22:44+00:00.

Hey Koin community,

Based on feedback already received from you lot about wanting better dependency visualization and earlier configuration validation, Arnaud has developed a Koin plugin for Android Studio and IntelliJ.

It shows your dependency graph in a tree view and helps catch potential issues during development rather than at runtime. You can navigate between dependencies using gutter icons, and there's some basic performance monitoring included. Here's Arnaud explaining it

A couple of super kind & super early users have tried it out and so far it feels promising"Super useful to navigate the dependency declarations" - u/MattiaRoccaforte "Amazing! Finally, I can easily configure DI without runtime class missing issues" - u/MirzamehdiKarimov

Since this is still in beta, we'd really appreciate any feedback, good or bad, or suggestions. You can find it on the JetBrains Marketplace if you'd like to try it out.

Thanks for taking a look.

And thank you for all the thoughtful feedback we've received so far, you know who you are.

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/bitter-cognac on 2025-02-10 23:14:20+00:00.

• Part 1 — The Single Responsibility Principle (SRP)

The importance of "one reason to change" illustrated through real-world payment processing scenarios.

• Part 2 — Open/Closed (OCP)

Uncover the art of making systems truly extensible with hands-on OTP validation examples.

• Part 3 — Liskov Substitution (LSP)

Master the concept of behavioral consistency with clear Kotlin demonstrations using List/MutableList.

• Part 4 — Interface Segregation (ISP)

Understand the power of concise interfaces through the evolution of MouseListener.

• Part 5 — Dependency Inversion (DIP)

Explore how DIP seamlessly integrates into full Clean Architecture with tested patterns.

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/shproteg on 2025-02-10 08:45:34+00:00.

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/thewritingwallah on 2025-02-07 14:11:26+00:00.

Hey fellow devs 👋

I wanted to share our latest deep dive (Dec 2024) on Jetpack Compose composition patterns.

Here's a common challenge we tackle—handling UI variations without ending up in **"if-else hell"**:

kotlin // The problematic way - "if-else hell"  Composable  fun UserProfile(...) { Column(...) { // Strong coupling between components if (isSelf) { ... } if (isPremiumMember) { ... } if (shouldShowEmail) { ... } else { ... } } }

A Better Approach: Compound Component Pattern

Composable  fun UserProfile( user: User, content:  Composable  UserProfileScope.() -> Unit, ) { val scope = remember { DefaultUserProfileScope(user) } Column { // Common UI elements ProfileImage() Name() // Flexible content area with shared state scope.content() } } // Usage - Mix and match components as needed  Composable  fun SelfProfile(user: User) { UserProfile(user) { Bio() EditButtons() } }

The article dives deep into two patterns we've found particularly useful:

• Slot pattern (like Material's TopAppBar)
• Compound Component pattern (sharing state through scope)

We've used these extensively in our Video SDK ( ) for flexible UI customization. But perhaps most interestingly, we found that sometimes a bit of duplication is better than forcing reuse through complex patterns.

Would love to hear your thoughts.

How do you handle component reuse vs. separation in your Compose projects?

🔗 Full article:

[Disclosure: I work at Stream]

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/DBSmiley on 2025-02-06 14:53:21+00:00.

Hey all,

I'm a CS Professor teaching a mobile dev class, and I'm teaching native Android dev and Flutter as two frameworks - I start with native dev, then look at multiplatform dev with Flutter (though considering switching to KMP for cross-platform, but I kind of like that there's a paradigm shift between Android and Flutter).

Specifically on native Android dev, I find paradigms change quickly. Hell, when I first taught it, I was using Java with XML layouts (don't worry, I'm using Compose - Kotlin is the bestest language ever). I only teach this class once a year, and unfortunately I just don't have the time/space to practice "real" Android development at scale since I typically have 4 courses with an average of 200+ students a year. I try to teach the best practices I see

When I looked a year ago, most places I saw said something akin to "Navigation sucks, I still use Intents and multiple-activities", but more and more tutorials and dev videos I see seem to be using Navigation these days.

My question is, if you, knowing what you know now, which would you generally encourage newer developers to focus on?

1. "Activity per screen" + Intent-driven navigation

2. Navigation with Single Activity Architecture

Which would you generally recommend now? I end up covering intents anyways with Services/Intent-filters, etc. but within an single application with multiple "screens", which would you generally recommend teaching?

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/androiddev by /u/ekinsdrow on 2025-02-05 10:40:08+00:00.