Accessing user's current location

📖 Theory

The app that wanted to know where you are

FestConnect Mobile has a nice feature idea: show the fest venues NEAREST to the user. That needs the phone's LOCATION.

But location is deeply personal, so Android does not just hand it over. The app must DECLARE that it needs location, ASK the user at runtime, and get their explicit CONSENT, and gracefully accept 'no'. This lesson covers accessing the user's current location the correct, privacy-respecting way. The technical part is short; the PERMISSION part is the real lesson, and it reflects the UX-and-trust principles you met in BCA402-02.

📖 Theory

Permissions: declare, then request at runtime

Location is a dangerous (sensitive) permission, so accessing it takes two steps:

• declare it in the manifest: ACCESS_FINE_LOCATION (precise, GPS) or ACCESS_COARSE_LOCATION (approximate, network-based)
• request it at RUNTIME (required since Android 6.0): show the user a permission dialog they can GRANT or DENY

You must CHECK whether permission is granted (ContextCompat.checkSelfPermission) before using location, and if not, request it, and handle a DENIAL gracefully (the feature simply will not work, and the app should degrade nicely, not crash). Declaring alone is not enough on modern Android; the user's runtime consent is mandatory for sensitive permissions.

⌨️ Practical

Check/request permission, then get location

// 1. Manifest declares ACCESS_FINE_LOCATION

// 2. Check at runtime; request if not granted
fun ensureLocationPermission() {
    if (ContextCompat.checkSelfPermission(this,
            Manifest.permission.ACCESS_FINE_LOCATION)
        != PackageManager.PERMISSION_GRANTED) {
        // Not granted: ask the user
        requestPermissions(
            arrayOf(Manifest.permission.ACCESS_FINE_LOCATION), 100)
    } else {
        getLocation()   // already granted
    }
}

// 3. Get the location (async, via Google Play Services)
fun getLocation() {
    val client = LocationServices.getFusedLocationProviderClient(this)
    client.lastLocation.addOnSuccessListener { loc ->
        if (loc != null) {
            val lat = loc.latitude
            val lng = loc.longitude   // use lat/lng to show nearby venues
        }
    }
}

📖 Theory

Getting the location, and coarse vs fine

The modern way to read location is the FusedLocationProviderClient (from Google Play Services), which combines GPS, wifi and network signals intelligently. client.lastLocation gives the last known Location (with latitude and longitude) via a callback, ASYNCHRONOUSLY, the result arrives later, not immediately.

Two precision levels:

• coarse (ACCESS_COARSE_LOCATION): approximate, network-based, less battery, good enough for 'which city/area'
• fine (ACCESS_FINE_LOCATION): precise, GPS, more battery, for exact positioning

Request only the precision you NEED: if FestConnect just wants the nearby CITY's venues, coarse suffices and respects the user's battery and privacy more than demanding fine GPS.

🧩 Quiz

What must an Android app do before it can access the user's current location?

1. Nothing; location is freely available to all apps
2. Declare the location permission in the manifest AND request it at runtime, checking the user granted it (and handle denial)
3. Only declare it in the manifest; that is sufficient
4. Only ask once when the app is installed

💭 Think first

Why runtime permissions matter for trust

Older Android granted all declared permissions at install time; modern Android asks at runtime, in context. Why is the runtime model better for users, connecting to BCA402-02's UX principles? Then tap.

⚠️ Watch out

Location traps

Declaring but not requesting at runtime: on modern Android you must request sensitive permissions at runtime, not just declare them.

Not handling denial: if the user says no, the feature must degrade gracefully, not crash.

Assuming location is instant: it arrives asynchronously via a callback; handle the result there, and the null case.

Demanding fine when coarse suffices: request only the precision you need (battery, privacy, trust).

Not explaining why: tell the user why you need location, in context; it improves grant rates and trust.

📖 Theory

Location done; one device power left

FestConnect Mobile can find the user's location, with their consent, to show nearby venues. The final device feature, and the last technical lesson of the unit, is the CAMERA: capturing an image using the device camera via an implicit intent to the camera app. Then Unit 4 turns to the IKS Lilavati mathematics. The app gains its last capability, then the subject's mathematics unit.

✅ Summary

Key takeaways

• Location is a sensitive (dangerous) permission: the app must declare it in the manifest AND request it at runtime.
• Declare ACCESS_FINE_LOCATION (precise, GPS) or ACCESS_COARSE_LOCATION (approximate, network); request only the precision needed.
• Runtime (since Android 6.0): check ContextCompat.checkSelfPermission, request if not granted, handle denial gracefully.
• Get location with FusedLocationProviderClient (Google Play Services); lastLocation gives a Location (latitude/longitude) asynchronously.
• The result is a callback (async) and may be null; handle both.
• Runtime, in-context permissions respect user trust and control (BCA402-02 UX): explain why, degrade gracefully if denied.
• Memory hook: declare + request at runtime + check granted + handle 'no'; location is the user's to give.