More in Mobile Dev — page 62
AndroidX Test: The Standard Android Testing Toolkit
AndroidX Test offers a unified API for all Android testing, from local unit tests to on-device UI automation. It's the standard for building robust, testable apps. The footgun: accidentally bundling test-only dependencies into your production APK.
Instrumentation Tests: Testing on a Real Android Device
Instrumentation tests are like test-driving your app on a real device or emulator. They verify code that depends on the Android framework, like UI interactions or sensor access.
Truth: Fluent Assertions for Clearer Tests
Truth makes tests read like English: `assertThat(actual).is...`. It provides clearer assertions than standard JUnit, with far more helpful failure messages, especially for collections. The main footgun is a potential Guava dependency conflict.
JUnit on Android: Fast, Local Unit Tests
JUnit on Android runs tests directly on your local machine's JVM, not a device, making them extremely fast. Use it for business logic and ViewModels that don't touch Android APIs. The footgun is trying to access framework code like `Context`, which will fail.
The Testing Pyramid: Fast Feedback, Low Cost
The Testing Pyramid guides test suite structure: a wide base of fast unit tests, a smaller middle of integration tests, and a tiny top of slow UI tests. This model is key for Android's local, instrumented, and UI tests. The footgun is inverting it.
Handler and Looper: Android's Threading Backbone
A Looper is a worker that endlessly processes a queue of tasks for a thread. A Handler is how you give that worker a new task from another thread, like updating the UI. The footgun is blocking the main thread's Looper, which freezes your app.
JobScheduler: Efficient, Deferrable Background Tasks
Think of JobScheduler as Android's smart alarm for tasks. You specify conditions like 'Wi-Fi only' or 'charging,' and the OS runs your job efficiently to save battery. Use it for deferrable work like data syncs. Footgun: It's not for exact timing.
Expedited Work: High-Priority Background Tasks in Android
Expedited work is for important, short tasks that must run quickly. It gets higher priority than regular background work without requiring a persistent notification. Use it for sending messages or saving notes.
AlarmManager: Scheduling Precise Future Tasks in Android
AlarmManager is Android's system-wide alarm clock for your app, letting you run code at a specific time, even if your app is closed. Use it for time-sensitive tasks like calendar notifications. The footgun: alarms are wiped on reboot and must be re-registered.
IntentService: Queued Background Work (Deprecated)
IntentService was a simple tool for running background tasks sequentially. You sent it work as an Intent, it processed it on a worker thread, and shut down when done. It's now deprecated; use WorkManager for modern background jobs.
AsyncTask: The Deprecated Way to Do Background Work
AsyncTask was Android's original tool for short background tasks that update the UI. It was used for simple network requests or disk I/O. It's fully deprecated due to memory leaks and lifecycle issues; use Kotlin Coroutines instead.
Threads: Your App's Second Pair of Hands
A thread is a separate path of execution for background work, keeping your app's UI responsive. It's used for long tasks like network calls or disk I/O. The main footgun is trying to update the UI from a background thread, which will crash your app.
Testing with Hilt: Swapping Dependencies for Isolation
Hilt testing swaps real app components for fakes, isolating your code under test without manual setup. It's used in UI and unit tests to replace production dependencies like network clients with test doubles.
@HiltViewModel: Simplified ViewModel Injection
@HiltViewModel automates creating ViewModels with dependencies. Instead of writing custom factories, just annotate the ViewModel and its constructor. It's the standard for injecting dependencies like repositories into ViewModels in a Hilt-powered Android app.
@HiltAndroidApp: The Entry Point for Hilt DI
@HiltAndroidApp is the main power switch for Hilt dependency injection. You place it on your Application class to trigger code generation and create the top-level dependency container.
Dependency Injection: Your Objects Shouldn't Create Their Own Helpers
Instead of creating its own helpers (like a network client), an object receives them from an outside source. This is crucial for building testable Android apps, as it lets you swap a real `UserRepository` with a fake one during tests.
OkHttp Caching: Beyond Simple Hits and Misses
OkHttp's cache acts like a browser's, saving network trips by storing responses on disk. It handles not just full hits and misses, but also validates stale data with the server. Use it for repeatable requests.
Certificate Pinning: Trusting Only Your Own Servers
Certificate pinning hardcodes your server's public key hash into your app, rejecting any other certificate. This prevents man-in-the-middle attacks from compromised CAs. The footgun: if the server certificate changes, your app breaks until you update the pin.
Moshi: Modern JSON for Kotlin & Android
Moshi is a modern JSON library that maps JSON strings to your Kotlin/Java objects. It's a translator between API text and your app's data classes, built with Kotlin-first features. The footgun: Kotlin classes require Moshi's codegen or reflection adapter.
Handling API State with a Sealed Class Wrapper
Treat API calls as states, not just data. A sealed class wrapper (`Success`, `Error`, `Loading`) models these states for your UI. Use this with Retrofit to show spinners or errors without crashing. The footgun: don't scatter try-catch blocks; centralize them.