Android &amp; Kotlin

Recomposition: Smart UI Updates in Compose

Recomposition is how Compose redraws your UI. It intelligently re-runs only the functions whose state has changed, avoiding a full screen refresh. This is triggered automatically when a State object that a composable reads is updated.

Lazy Layouts: Compose's Answer to Efficient Lists

Lazy layouts in Jetpack Compose render only the list items visible on screen, avoiding memory crashes from large datasets. Use them for long lists like feeds or galleries, but remember to provide a key to prevent UI glitches when data changes.

Theming in Compose: Style from a Single Source

Theming in Compose is like a CSS stylesheet for your app. You define colors, typography, and shapes once in a central Theme composable, and it cascades down. Use it for light/dark modes and brand consistency.

Navigation in Compose

Navigation in Compose treats screens as state. You define a graph of composables, each with a string 'route', and navigate by changing the current route. It's ideal for single-activity apps.

Using Android Views in Compose (and Vice Versa)

AndroidView and ComposeView are bridges for gradual UI migration. Use them to embed classic Views in Compose screens or vice versa, like for a MapView. The footgun is managing state and lifecycles across the two different UI paradigms, which can lead to bugs.

Compose Side-Effects: Escaping the Pure Function

Compose functions should be pure, but apps must interact with the world. Side-effect APIs are controlled escape hatches to run non-UI code, like network calls or showing Toasts, from within a composable's lifecycle. The footgun is calling this logic directly.

CompositionLocal: Implicitly Pass Data Down the UI Tree

CompositionLocal is like CSS inheritance for your UI tree, letting you pass data down implicitly without parameter drilling. It's ideal for ambient data like theming or localization. The footgun is overusing it, which makes components harder to test.

Compose UI Testing: Find Nodes, Assert State, Perform Actions

Compose UI tests treat your UI as a node tree. You find nodes by properties (like text or a test tag), assert their state (e.g., 'is displayed'), and perform actions like clicks. Use it to verify composables react correctly to state changes or user input.

Android's UI Layer: Displaying Data, Handling Events

The UI layer is what users see and touch. It displays app data on screen and sends user input like taps to your business logic. It's used in every screen, from login forms to media players.

Repository Pattern: Your App's Single Source of Truth

The Repository Pattern acts as a mediator for your app's data, fetching from sources like a network or database. Use it to separate your UI from data-fetching logic, like caching. The footgun is putting business logic here; it's for data operations only.

Android's Domain Layer: Your Business Logic's Home

The Domain Layer is an optional buffer between your UI and data layers, housing reusable business logic. Use it for complex logic or simple rules shared by multiple screens, keeping your ViewModels lean. The footgun is overusing it for every simple data fetch.

Deep Linking with Android's Navigation Component

Deep linking with the Navigation Component treats app screens like URL-addressable pages. It's for handling push notifications or web links that go to specific content.

Navigation Safe Args: Type-Safe Navigation in Android

Navigation Safe Args generates code to prevent runtime crashes when passing data between Android screens. It replaces error-prone Bundle manipulation with type-safe classes. Use it to pass user IDs or item details. The footgun: don't pass large objects.

Room Entity: Your Database Table as a Kotlin Class

A Room Entity is a data class that maps to a database table; each object is a row, each property a column. Use it to define your local SQLite schema in Android. The footgun: forgetting the @PrimaryKey annotation, which is required for Room to manage.

Room DAO: Your App's Type-Safe SQL Interface

A Room DAO is an interface that translates your method calls into SQL queries. It's how your Android app's code talks to its local database without writing boilerplate. The footgun is putting business logic in a DAO; it should only access data.

Room Database: SQL Made Simple on Android

Room is an abstraction layer over SQLite that lets you work with Kotlin/Java objects, not raw SQL. It's the standard for local data persistence in Android, like caching network data.

Preferences DataStore: The Safe SharedPreferences

Preferences DataStore is Android's modern way to save simple key-value data. It uses Kotlin's Flow to read data asynchronously, preventing UI freezes. Use it for user settings, but remember you can't read values synchronously like with SharedPreferences.

Room Type Converters: Teach Your Database New Tricks

Room Type Converters are translators for your database, teaching it to store types it doesn't natively understand, like Date. They let you persist simple objects by converting them to primitives like Long. The footgun is faking object relations with them.

Room Database Migrations: Evolving Your Schema Safely

A Room migration is a renovation plan for your database. When you change your schema, you provide SQL instructions to upgrade existing user data without loss, preventing crashes on app updates. The footgun is forgetting to increment the database version.