How to create custom modifiers in Jetpack Compose with Modifier.Node

Untangling Side-Effects in Jetpack Compose I just came across an excellent article on ProAndroidDev about side-effects in Jetpack Compose, and it’s a must-read for anyone building Compose apps. At first glance, “side-effects” might sound like a programming buzzword — but in Compose, they’re a crucial concept when you go beyond pure UI rendering: A side-effect is something your UI triggers that reaches beyond just emitting composables (for example: navigation, showing snackbars, launching coroutines). Because Compose can recompose unexpectedly, managing side-effects in a controlled, lifecycle-aware way is essential to avoid bugs or unintended behavior. The article walks through the core Compose “effect APIs” you’ll want to know (and use correctly): - LaunchedEffect — launch a coroutine when a key changes when a coroutine first launched. - DisposableEffect — perform cleanup logic when composable leaves composition - rememberUpdatedState — keep references fresh in long-running effects - produceState, derivedStateOf — bridge non-Compose state or derived transformations - sideEffect : when publishing composition state on non-compose code with every recomposition(after every successful recomposition) - snapShot : when you want to convert the compose state into flow (better when using operators) What stood out to me: You should ideally keep composable functions side-effect free. When effects are needed, encapsulate them in the right effect scope so they run predictably. This resonates strongly with the Compose philosophy: your UI layer focuses on declaring state → UI, while side-effects live in structured scopes you control. If you’ve wrestled with unexpected behavior due to recomposition or lifecycle — this piece will help you make your Compose code more robust, readable, and bug-resistant. Read it here: 🔗 Side-effects in Jetpack Compose — ProAndroidDev https://lnkd.in/djsUNF_b #android #developer #kotlin #jetpack #compose #sideEffects #ProAndroidDev

🎯 The Holy Trinity of Modern Android Architecture: MVVM (Model-View-ViewModel)
 → Perfect for Jetpack Compose integration
 → Lifecycle-aware ViewModels survive configuration changes
 → LiveData/StateFlow creates reactive UIs
 → Google’s recommended approach for most apps MVI (Model-View-Intent)
 → Unidirectional data flow = predictable state
 → Single source of truth eliminates bugs
 → Perfect for complex UI interactions
 → State machines make debugging a breeze Clean Architecture
 → Domain layer keeps business logic pure
 → Repository pattern abstracts data sources
 → Use cases encapsulate specific functionalities
 → Testable, maintainable, scalable by design 🚀 2025 Architecture Trends: ✓ Modular Architecture - Break monoliths into manageable modules
 ✓ Jetpack Compose - Declarative UI with state-driven approach ✓ Kotlin Coroutines - Async operations made simple
 ✓ Room + Flow - Reactive local data persistence
 ✓ Dependency Injection - Hilt simplifies object creation 💡 Pro Tips for Architecture Success: 1. Separation of Concerns - Each layer has ONE responsibility 2. Dependency Inversion - Depend on abstractions, not concretions 3. State Management - Centralize UI state for consistency 4. Testing Strategy - Architecture should enable easy unit testing 5. Future-Proofing - Design for change, not just current requirements The Reality Check:
 Bad architecture is like building a house on sand - it looks fine until the storms hit. Good architecture is your insurance policy against technical debt, team scaling issues, and that dreaded 2 AM production bug! 🐛 #AndroidDev #MobileArchitecture #CleanArchitecture #MVVM #MVI #JetpackCompose #Kotlin #SoftwareEngineering #TechLeadership #AndroidDevelopment

To successfully build products and get maximum out of LLMs the iterative smallest possible code in one go is the best approach. Why? Ideas evolve in our head as we think more about them and immerse ourselves. Often the best move occurs in our head once we have made the move. In case of LLMs if we give it a macro task and expect it to do everything using best practices it will end up generating great looking 10k+ lines of code. Now this is a booby trap regardless of it works or not. If it works, you will end up building mode on top of something you don't fully comprehend or have bandwidth to do so and if it doesn't work the LLM would start biting its own tail resulting into "ohh yeah lemme fix it, it should work now" "wait yeah you are right, I overlooked, lemme try again" Instead of asking it to create Uber from scratch, and letting the LLM internally run a prompt like "what are technical tenants of typical uber kind of app looks like" and then generate database schema, ci cd pipeline, a web app and code for Android, ios and all the platforms out there, start with "help me define key features of an uber app". if it's your own novel product idea, then skip this step and make a list of mutually exclusive features/functions/background-jobs. Now revisit this list and remove whatever is not needed on day 1. Revisit it and remove whatever you won't need for next 3 months. Now define your design taste as well as code structuring/framework related taste. On the framework side, keep it as simple as possible. Something you can manually change if needed. You can independently chat with llm chat-bot to come up with this. I used "help me define the design language, vibe, philosophy behind apple cupertino design system " and put the long manual in the markdown file after removing redundant or something which I didn't like or didn't want. Now revisit our minimal product laundry list, and referencing that discussion with any LLM bot to come up with mutually exclusive units/components. For the web I prefer vanilla Web components defined using typescript. PS: given these units do need to communicate with each other eventually, define a pattern behind how they will communicate with each other. Just like design taste, keep it in a markdown file. Now generate all the units/components, one by one by attaching your design taste as well as inter component interaction pattern. If you want your debugging life easier, you can ask it to generate simple views to quickly review if the unit/component is working or not. if it's not working, you can try again in fresh context, fix the minor bugs manually. This way you can scale your LLM driven development while staying in control of code quality, product*development* scalability (ps: don't confuse with runtime performance or scalability, that would require a totally different thought process and more thinking at your end). Thanks Saif Khan for the motivation for this post. Wrote it omw to office. Das auto!!

🚀 Excited to share my latest project: SimpleRecipe! 🍳 I built a full-stack recipe app using modern web technologies, and I’d love to give you a peek under the hood. 🔹 Backend: Built with Python (Flask) and deployed on Render. Uses CORS to securely communicate with the frontend. Database stores recipe details, ingredients, preparation time, and images. 🔹 Frontend: Developed using React and deployed on Vercel. Fetches data from the backend API dynamically using environment variables (REACT_APP_API_URL) to switch between local development and production. Components include: recipe list, recipe detail view, and a form to add new recipes. Adding a recipe: User fills out the form with title, description, ingredients, preparation time, and image URL. Frontend sends a POST request to the backend API. Backend validates and saves the recipe in the database. Frontend updates the list automatically to show the new recipe. Supports seamless user interaction with real-time API calls. 🔹 Workflow Highlights: Local development uses localhost:8000 for backend and localhost:3000 for frontend. Production deployment points the frontend to the Render backend API, ensuring users always see the latest data. Careful configuration of environment variables and CORS ensures secure and smooth communication between frontend and backend. This project was a great exercise in deploying full-stack apps, managing environment configurations, handling cross-origin requests, and building a responsive, mobile-friendly UI. Check it out here: https://lnkd.in/gzRMXmUn #FullStack #React #Flask #WebDevelopment #Vercel #Render #EnvironmentVariables #APIDevelopment #CORS #ProjectShowcase #CRUD #AddRecipe

We all know hooks are popular, but here’s what most people don’t really talk about when comparing them to class components: Hooks let you write components as plain functions. No this confusion, no super keyword. Everything just works, and your code feels lighter. You can create custom hooks to reuse logic across multiple components without relying on higher-order components or complicated prop-drilling. Want the same behavior in five components? One hook is enough. useEffect replaces componentDidMount, componentDidUpdate, and componentWillUnmount. Instead of jumping between multiple methods, you have one place to handle all side effects, which makes your logic way easier to follow. useState and useReducer give you clean, predictable state management right inside your function components. No huge constructors, no binding every method. Your state is right where it belongs. One of the best parts is you don’t have to deal with this at all. Classes require binding functions to this, which can easily break and confuse you. Hooks remove that headache completely. Hooks encourage splitting logic into small, reusable pieces instead of huge files. Instead of a 200-line class, you can write a few focused hooks that each handle one thing. It makes your code readable and easy to maintain. Performance optimization becomes simple. Using useMemo or useCallback is straightforward and local to where it’s needed. You no longer have to figure out complicated class-based workarounds to avoid unnecessary re-renders. Side effects are transparent. With classes, side effects can be scattered across different lifecycle methods. Hooks bring all side effects together in useEffect, making it easy to reason about your app’s behavior. Finally, hooks are future-ready. React is moving towards function components and hooks as the default. Learning them now prepares you for modern React features like concurrent mode and server components. At the end of the day, hooks aren’t just a new syntax. They completely change how you structure, reuse, and think about React apps. Once you start using them, it’s hard to go back to classes.

“It’s compiling, so I’m safe… right?” Years ago, I co-authored a blog post on architecting a BLE SDK. From that work, one habit stuck: make misuse difficult and correct use effortless. 💡 Today, at most, type-driven design plays an important role in building offline-capable POS and airline retail solutions. The payoff: • Fewer bugs: types make invalid states impossible. ✅ • Clearer APIs: types act as live documentation, reducing ambiguity. ✅ • Safer changes: compiler-guided refactoring makes large updates predictable. ✅ 🔗 Full article: https://lnkd.in/dKupjCpC 🔗 A command‑queue approach to BLE operations: https://lnkd.in/dTfHk9KJ

Migrating from Activities & Fragments to Jetpack Compose For years, Android UIs were built with XML layouts + Activities/Fragments. While powerful, they often led to: ⚠️ Boilerplate code ⚠️ Complex lifecycle management ⚠️ Fragment transactions that were error-prone ⚠️ UI + Logic tightly coupled 👉 That’s where Jetpack Compose changes the game. ✅ Why Compose is the better choice: Declarative UI: Just describe the UI for a given state, and Compose handles the rest. No more manual view updates. Less boilerplate: You don’t need findViewById(), XML inflation, or fragment transactions. Easier state management: Works seamlessly with Kotlin flows, coroutines, and ViewModels. Faster development: Preview, Hot Reload, and easy theming save hours of effort. Scalable architecture: Clean separation of UI and business logic. 💡 Example: Instead of juggling multiple XMLs and FragmentManagers, a single @Composable function can represent the entire screen’s UI in a readable and testable way. 👉 Migrating to Compose means building modern, scalable, and maintainable apps. It’s not just a UI framework—it’s the future of Android development. #AndroidDevelopment #AndroidDevelopers #AndroidCompose #JetpackCompose #AndroidUI #AndroidTips #MobileDevelopment #AppDevelopment #Kotlin #SoftwareEngineering #CleanArchitecture #UIUX

I have created something unique for Mastering Backend users. Let me explain. - Now you can build real-world backend project and run it inside MB. - You can interact with our terminal, install things, and run commands. - You can write and execute your codes while taking a course Next Steps: - We are adding a dedicated Frontend that will integrate with the API you're developing. - Adding Kap AI to help you with development - Working on the UI to make it smooth to code with. Ask me how I built this, and I will explain.

🚀 Just published a new article on building a scalable mock architecture for frontend development using MSW (Mock Service Worker). In this post, I break down a clean, modular structure using four layers: 🔹 Factories for static data 🔹 Generators for dynamic and logical data 🔹 Services for backend-like operations 🔹 Handlers for connecting everything through API routes I also used an Uber-like app example (Users, Drivers, Wallet, Rides, etc.) to show how this architecture can simulate real-world logic while staying flexible, testable, and maintainable. 👉 Read the full article: https://lnkd.in/dnd-qbbm #frontenddevelopment #MSW #webdevelopment #mockdata #testing #javascript #react #architecture #developers

I used to write 6 lines for something that needed just one. Refactor your code like this : As devs, we often face the same problem: checking if an element exists in an array. Let’s say you’re building a shopping cart 🛒and you want to check if a specific item is already inside. Here’s how I used to do it 👇 let cart = ["Laptop", "Mouse", "Keyboard", "Monitor", "Webcam", "USB Hub", "External Hard Drive", "Desk Lamp", "Office Chair", "Notebook", "Pen", "Headphones", "Microphone", "Smartphone", "Charger", "Tablet", "Printer", "Router", "HDMI Cable", "Mouse Pad", "Power Bank", "Flash Drive", "Graphic Tablet"]; let found = false; for (let item of cart) { if (item === "Laptop") { found = true; } } console.log(found); // true It works. ✅ But it’s long, repetitive, and harder to maintain. Then I discovered this one-liner 👇 let found = cart.includes("Laptop"); console.log(found); // true Same output. Same time complexity. Same space complexity. But way more readable and maintainable. 📊 Code Complexity Comparison Both versions have the same time and space complexity — O(n) and O(1) respectively. But .includes() wins where it really matters: ✅ Lower cyclomatic complexity (1 vs 2) ✅ Cleaner and easier to read ✅ Far more maintainable 💬 The Lesson as Junior Dev: Clean code isn’t just about making it work : it’s about making it simpler, clearer, and easier to maintain. Fewer lines, same power. That’s what clean code looks like. ✨ Follow for more Tipps!