Android Unplugged

  Inter-process communication (IPC) in Android is how different apps and system components talk to each other safely, even though each runs in its own isolated Linux process. Android achieves this with a kernel driver called Binder, wrapped in familiar APIs like Intents, Services, ContentProviders, AIDL, and Messenger.​ 1. Story first: apartments and the intercom Imagine every Android app as a separate apartment in a high-security building. Each apartment (process) has: Its own space (memory). Its own keys (UID/permissions). No direct access to other apartments. Yet, apps need to talk: Food-delivery app → asks Google Maps for routes. Camera app → sends photos to the gallery. Music app → asks the system if it can play over an ongoing call. Whenever this conversation crosses apartment boundaries (processes), you are doing IPC. Binder is the building’s intercom system that connects apartments and the building’s control room (system services).​ You already use IPC whenever you: St...

  We all must have used SharedViewModel in Fragment based navigation using activityViewModels(). But now… what if our app is built in 100% Jetpack Compose? No fragments, No FragmentManager, No ViewModelStoreOwner. So… if we have 2 basic authentication screens LoginScreen and RegisterScreen, how can we share viewmodel/state across composables? 👇🏻 // Inside any Composable screen val parentEntry = remember(navController) { navController.getBackStackEntry( "auth_graph" ) // Your navGraph route } val viewModel: SharedViewModel = viewModel(parentEntry) Now both LoginScreen() and RegisterScreen() inside auth_graph can share the same SharedViewModel. ❤️ 💡 Why this matters If we’re building multi-step flows (Auth, Checkout, Onboarding), this keeps our architecture clean, and state scoped. Checkout the Git Repo from here… https://github.com/dev-vikas-soni/compose-shared-view-model If you enjoyed the article and would like to show your support, be sure to: 👏 Applaud for the story...

           D id you ever think, what happens when you install your app in your Android device, it shows INSTALLING for fraction of second and app get opens. What happens exactly behiend the scene? Found Interesting???? Cool !!! let’s clear all the doubt in this blog. You would have definetely read the buzz words JIT(Just-in-time) and AOT(Ahead of time) at many ocassions. We’ll dig it down in details in this article, stay tuned…. Android apps run on Android Runtime (ART) , which replaced Dalvik since Android 5.0 (Lollipop). ART supports both JIT (Just-In-Time) Compilation and AOT (Ahead-Of-Time) Compilation to improve performance and efficiency. JIT (Just-In-Time) Compilation How it Works: Compiles bytecode into native machine code at runtime (when the app is executed). Stores frequently used methods in memory to speed up subsequent executions. Advantages: Faster app installation because it doesn’t require full compilation beforehand. Reduces s...

      Jetpack Compose offers a declarative approach to building UIs in Android. However, like any UI framework, optimization is key to achieving smooth performance and a great user experience. This detailed guide expands on the provided checklist, offering in-depth explanations and practical code examples for each optimization technique. I. Core Principles: Laying the Foundation for Performance Use Stable Types:  Compose relies on stable types to efficiently track changes and minimize recompositions. A stable type guarantees that if two instances of the type are equal according to  equals() , they will always be equal. Using unstable types can force unnecessary recompositions.   // Stable data class (recommended) data   class   User ( val  name: String,  val  age:  Int ) // Unstable list (avoid directly in Compose state) // Use SnapshotStateList instead val users = remember { mutableStateListOf<User>() } // Cor...