Content Providers & Broadcasts Flashcards
ANDROID › Components
- When do you actually need a ContentProvider, and what are the modern alternatives?
- Need one when sharing data with other apps, exposing search suggestions, feeding widgets, or backing a sync adapter / CursorAdapter. For in-app storage only, prefer Room, DataStore, or files. A provider's value is abstraction plus cross-app permission control.
- Break down the parts of a content URI like content://user_dictionary/words/4.
- Scheme content://, then the authority (user_dictionary) identifying the provider, a path (words) usually mapping to a table, and an optional ID (4) selecting a single row. ContentUris.withAppendedId builds the ID form.
- Which ContentResolver methods perform CRUD and what does each return?
- query() returns a Cursor, insert() returns the Uri of the new row, update() returns the Int count of rows changed, delete() returns the Int count of rows removed. getType() returns the MIME type for a URI.
- How do you prevent SQL injection in a provider selection clause?
- Use ? placeholders in the selection string and pass user values via the selectionArgs array, never string concatenation. The provider safely binds the args, neutralizing injection.
- Manifest-declared vs. context-registered broadcast receivers: when use each?
- Manifest receivers are registered at install and can wake the app even when not running, but since Android 8 most implicit broadcasts are blocked for them. Context-registered receivers live only while registered (tie to a lifecycle and unregister) and are preferred for app-active, implicit, or app-internal events.
- What changed for manifest-declared receivers in Android 8.0 (API 26)?
- Apps can no longer register manifest receivers for most implicit broadcasts. A few are exempt (e.g. ACTION_BOOT_COMPLETED, ACTION_LOCKED_BOOT_COMPLETED). Workaround: context-register while active or use WorkManager/JobScheduler.
- What is an ordered broadcast and what can each receiver do?
- sendOrderedBroadcast delivers to one receiver at a time in android:priority order. Each receiver can read/modify result data passed to the next, or call abortBroadcast() to stop further delivery. Normal sendBroadcast has no order and no aborting.
- Why must onReceive() be fast, and how do you do brief async work?
- onReceive() runs on the main thread and the system may kill the process once it returns, so blocking or spawning unmanaged threads is unsafe. Call goAsync() to get a PendingResult, do work on a background thread, then call finish() within ~10s; for longer work schedule WorkManager/JobScheduler.
- On Android 13+ (API 33), what is required when context-registering a receiver?
- You must pass an export flag: RECEIVER_EXPORTED to receive broadcasts from other apps/system, or RECEIVER_NOT_EXPORTED for app-internal only. Use ContextCompat.registerReceiver to supply it; omitting it throws on API 33+.