Theory
A photo, without building a camera
FestConnect Mobile wants users to add a profile photo, or snap a picture at an event. That needs the CAMERA.
Just like sharing (the implicit-intent lesson), you do NOT build a camera into your app. Instead, you ASK the device's existing CAMERA app to take the photo and hand it back. This is the same cooperate-with-other-apps philosophy: reuse capable apps rather than reinventing them. This final technical lesson covers capturing an image with MediaStore.ACTION_IMAGE_CAPTURE, launching the camera and receiving the result, completing FestConnect Mobile's device features.
Theory
ACTION_IMAGE_CAPTURE: reuse the camera app
To take a photo, fire an implicit intent with the action MediaStore.ACTION_IMAGE_CAPTURE. This launches the device's camera app; the user takes the picture, and the RESULT comes back to YOUR activity.
Because you expect something BACK (the photo), you launch it EXPECTING A RESULT:
- historically
startActivityForResult(...)withonActivityResult(...) - modern Android uses the Activity Result APIs (
registerForActivityResult), cleaner and recommended
The captured image comes back either as a small THUMBNAIL bitmap in the result's extras (under the key "data"), or, for a FULL-SIZE image, you tell the camera WHERE to save it via EXTRA_OUTPUT (a file URI, provided through a FileProvider on modern Android). It is the implicit-intent pattern again: your app triggers a capability, the camera app performs it, the result returns.
Practical
Launch the camera and receive the photo
// Modern approach: register a launcher for the camera result
val cameraLauncher = registerForActivityResult(
ActivityResultContracts.StartActivityForResult()
) { result ->
if (result.resultCode == Activity.RESULT_OK) {
// A thumbnail comes back in the extras under "data":
val photo = result.data?.extras?.get("data") as? Bitmap
// ... show or save the photo
}
}
fun takePhoto() {
// Implicit intent: ask the device's camera app to capture an image
val intent = Intent(MediaStore.ACTION_IMAGE_CAPTURE)
cameraLauncher.launch(intent) // launch, result returns to the callback
}
// For a full-size image, add EXTRA_OUTPUT with a FileProvider URI.
Quiz
What is the simplest way for FestConnect Mobile to let a user take a photo?
- Build a full camera interface inside the app from scratch
- Fire an implicit intent with MediaStore.ACTION_IMAGE_CAPTURE to launch the device's camera app, and receive the photo back as a result
- It is impossible to access the camera
- Copy a photo from the internet
Show the answer
Fire an implicit intent with MediaStore.ACTION_IMAGE_CAPTURE to launch the device's camera app, and receive the photo back as a result
The simplest, standard approach is to fire an IMPLICIT intent with MediaStore.ACTION_IMAGE_CAPTURE, which launches the device's existing camera app; the user takes the photo and the result returns to your activity (via the Activity Result APIs or the older onActivityResult). This reuses the capable camera app rather than reinventing it, the same cooperate-with-other-apps pattern as sharing. Option A (building a camera from scratch) is enormous, error-prone work that duplicates what the device already does well, only needed for advanced custom-camera cases. Option C is false. Option D misses the point entirely (capturing, not downloading). Reuse the camera app via ACTION_IMAGE_CAPTURE and handle the returned image.
Think first
The pattern behind camera AND sharing
Both sharing (earlier lesson) and taking a photo use implicit intents to hand a task to another app. What general Android design principle does this reveal? Then tap.
Show the answer
The principle is REUSE CAPABLE APPS THROUGH IMPLICIT INTENTS rather than reinventing features. Android is designed so apps expose CAPABILITIES (a camera app can capture images; a browser can view URLs; a messaging app can send text), and other apps INVOKE those capabilities via implicit intents, letting the system connect them. So instead of every app building its own camera, browser, or share sheet, apps COOPERATE: FestConnect fires ACTION_IMAGE_CAPTURE and the user's chosen camera app does the work, then returns the result. Benefits: far less code (you do not build a camera), a consistent experience (the user's familiar camera app), automatic support for whatever apps the user has, and separation of concerns. This is a hallmark of good Android development: your app focuses on ITS job (managing events) and delegates specialised tasks (photos, sharing, viewing) to apps built for them. Compose the device's capabilities; do not duplicate them.
Watch out
Camera-capture traps
Building a camera unnecessarily: for a simple photo, use ACTION_IMAGE_CAPTURE and the camera app.
Ignoring the result code: check RESULT_OK before using the photo (the user may cancel).
Thumbnail vs full image: the extras "data" gives a small thumbnail; for full-size, use EXTRA_OUTPUT + a FileProvider URI.
FileProvider on modern Android: passing a raw file URI can crash on newer Android; use a FileProvider.
No camera app: rare, but robust apps handle the case where no camera app exists.
Theory
Unit 3 complete: a full mobile app
FestConnect Mobile in Kotlin is now feature-complete: it parses JSON from a server, navigates multiple screens with intents, shares and opens URLs, stores data in SQLite, and uses location and the camera, a real, data-driven, device-aware Android app. That is the mobile-development arc. Unit 4 is separate: the Indian Knowledge System mathematics from the Lilavati, studied factually, the same mathematics unit shared with BCA503-01. The app is built; the IKS unit stands apart.
Summary
Key takeaways
- To take a photo, fire an implicit intent with MediaStore.ACTION_IMAGE_CAPTURE, launching the device's camera app.
- You launch it expecting a RESULT: modern Android uses the Activity Result APIs (registerForActivityResult); older code used startActivityForResult/onActivityResult.
- A thumbnail bitmap returns in the result extras under "data"; for a full-size image, provide EXTRA_OUTPUT (a file URI via FileProvider).
- Check RESULT_OK before using the photo (the user may cancel).
- This reuses the camera app rather than building one: the same implicit-intent, cooperate-with-other-apps pattern as sharing.
- General principle: invoke other apps' capabilities via implicit intents instead of duplicating them.
- Memory hook: ACTION_IMAGE_CAPTURE asks the camera app; the photo comes back as a result.