Maps Compose

Cover Page

DUE Wed, 04/02, 2 pm

The goals of this lab are threefold: first, to introduce you to Android’s LocationServices and SensorManager APIs. Second, to introduce you to asynchronous event stream as implemented as Kotlin’s Flow. And third, to integrate Google Maps API with the Chatter app.

In the map-augmented Chatter app, we will add a Map View. On the map, there will be one or more markers. Each marker represents a posted chatt. If you click on a marker, it will display the poster’s username, message, timestamp, and their geodata, consisting of their geolocation and velocity (compass-point facing and movement speed), captured at the time the chatt was posted. If a chatt was posted with the user’s geodata, the timeline now shows the chatt with a location icon. Clicking this icon brings user to the MapView with the chatt’s posted location marked on the map.

We will also implement a swiping gesture to allow users to switch from the main timeline view to the map view. When a user swipes left to transition from the timeline view to the map view, the current trove of retrieved chatts will each be displayed as an individual marker. From the map view, users can not post a chatt; they can only return to the timeline view. Once a user posts a chatt, they also can only return to the timeline view, not the map view. User also cannot initiate a new retrieval of chatts in the map view.

Expected behavior

Post a new chatt and view chatts on Google Maps:

Preparing your GitHub repo

• On your laptop, navigate to YOUR_LABSFOLDER/
• Unzip your chatter.zip that you created as part of the audio lab
• Rename the newly unzipped chatter folder maps
• Remove your maps’s .gradle directory by running on a shell window:

  laptop$ cd YOUR_LABSFOLDER/maps/composeChatter
  laptop$ rm -rf .gradle
  

• Push your local YOUR_LABSFOLDER/ repo to GitHub and make sure there’re no git issues

  <summary>git push</summary>
  

  • Open GitHub Desktop and click on Current Repository on the top left of the interface
  • Click on your 441 GitHub repo
  • Add Summary to your changes and click Commit to master (or Commit to main)
  • Since you have pushed your back end code, you’ll have to click Pull Origin to synch up the repo on your laptop
  • Finally click on Push Origin to push changes to GitHub

Go to the GitHub website to confirm that your folders follow this structure outline:

  441
    |-- # files and folders from other labs . . .
    |-- maps    
        |-- composeChatter
            |-- app
            |-- gradle
    |-- # files and folders from other labs . . .            

Adding resources

Add a string constant to /app/res/values/strings.xml:

    <string name="map">Map</string>

As in the previous lab, we’ll collect all globally visible extensions in one file. Create a new Kotlin file called Extensions.kt and put the same toast() extension to Context from the previous lab in it.

Part I: Converting ChattStore to use Channel and Actor

ChattStore

In the Chatter lab we used Java’s synchronized() to limit the number of backend retrieval to one per frontend. In this lab, we make isRetrieving an actor. Kotlin actor is very rudimentary and is deprecated, but it does give us a chance to work with Channel and CompleteableDeferred types.

First add the following line to your build.gradle (Module:):

android {
    // . . .
    kotlinOptions {
        // . . .
        // so that compiler won't complain about our use of `actor`
        freeCompilerArgs += listOf("-Xopt-in=androidx.compose.material3.ExperimentalMaterial3Api",
        "-Xopt-in=kotlinx.coroutines.ObsoleteCoroutinesApi"
        )
    }
    // . . .
}

Then in the ChattStore file, add the following class:

class Bool(val initial: Boolean) {
    val scope = CoroutineScope(EmptyCoroutineContext) // inherit parent's coroutineContext

    sealed interface Actions
    object Toggle: Actions
    data class ExchangeDef(val new: Boolean, var exchanged: CompletableDeferred<Boolean>): Actions
    data class ExchangeChn(val new: Boolean, var exchanged: SendChannel<Boolean>): Actions

    private val _actor = scope.actor<Actions> {
        var bool = initial

        for (act in channel) { // iterate over incoming channel messages
            when (act) {
                is Toggle -> bool = !bool
                // swap variables without temp
                // https://www.geeksforgeeks.org/how-to-write-swap-function-in-kotlin-using-the-also-function/               
                is ExchangeDef -> act.exchanged.complete(bool.also { bool = act.new })
                is ExchangeChn -> act.exchanged.send(bool.also { bool = act.new })
            }
        }
    }

    fun toggle() { scope.launch { _actor.send(Toggle) } }
    suspend fun exchange(new: Boolean): Boolean {
        // if Deferred
        val exchanged = CompletableDeferred<Boolean>()
        _actor.send(ExchangeDef(new, exchanged))
        return exchanged.await()

        /* if Channel
        val exchanged = Channel<Boolean>()
        _actor.send(ExchangeChn(new, exchanged))
        return exchanged.receive()
        */
    }

    protected fun finalize() { scope.cancel() }
}

Then in object ChattStore, replace the property isRetrieving with:

    private var isRetrieving = Bool(false)

Replace the signature of getChatts() with:

    suspend fun getChatts() {

and in getChatts(), replace the code:

        synchronized(this) {
            if (isRetrieving) {
                return
            }
            isRetrieving = true
        }

with:

        if (isRetrieving.exchange(true)) return

and replace the two occurrences of:

                synchronized(this) {
                    isRetrieving = false
                }

with:

                isRetrieving.toggle()

Calling getChatts()

In MainActivity replace the call to getChatts() with:

        lifecycleScope.launch { getChatts() }

Moving on to MainView, add the following before Scaffold(:

    val scope = rememberCoroutineScope()

and replace the call to getChatts() with:

                scope.launch { getChatts() }

Finally in PostView, replace the call to getChatts() with:

                    // must survive both viewModelScope and coroutineScope
                    CoroutineScope(EmptyCoroutineContext).launch { getChatts() }

Part II: Chatter with GoogleMaps and location tracking

Add the following line to your build.gradle (Module:):

dependencies {
    // . . .
    implementation("androidx.lifecycle:lifecycle-runtime-compose:2.6.1")
    implementation("com.google.android.gms:play-services-location:21.0.1")
}

Requesting permission

To get user’s location, we must first request user’s permission. In your AndroidManifest.xml file, find android.permisssion.INTERNET and add the following lines right below it:

    <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
    <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
    <uses-permission android:name="android.permission.HIGH_SAMPLING_RATE_SENSORS"
        tools:ignore="HighSamplingRate" />

“Fine” location uses GPS, WiFi, and cell-tower localization to determine device’s location. “Coarse” location uses only WiFi and/or cell-tower localization, with city-block level accuracy.

Inside the <application block, above android:networkSecurityConfig line, add:

        android:enableOnBackInvokedCallback="true"

This allows us to specify BackHandler() later.

Next, follow up the permission tag added to AndroidManifest.xml above with code in the onCreate() method of your MainActivity to prompt user for access permission.

Location Manager

We first go through the details about how to get user’s geolocation information (latitude (lat), longitude (lon), and velocity data (facing and speed)). We want to receive continuous updates of the phone’s location and bearing. Android’s location and sensor APIs still rely on callbacks to deliver updates to the app. We use callbackFlow to convert the callback to into a Kotlin Flow of updates. Conceptually, understanding Flow, its use and its generation using callbackFlow, is the most technical aspect of this lab.

Create a Kotlin file and name it LocManager. Next create a LocManager class. Since we have requested user permission to access fine location in MainActivity, we tell Android Studio to ignore the “MissingPermission” error for this class.

@SuppressLint("MissingPermission")
class LocManager(context: Context) {
    val locManager = LocationServices.getFusedLocationProviderClient(context)
    private val sensorManager = context.getSystemService(Context.SENSOR_SERVICE) as SensorManager
}

Inside the class we create an instance of Android’s FusedLocationProvider client as locManager and obtain the SensorManager from Android’s system service as sensorManager.

We now use the callback mechanism of FusedLocationProvider to yield an event stream of location updates using callbackFlow. We store the latest location reading in the observable state location, which is settable only internally and which we immediately initialize with the user’s current location. Add the following extension function to FusedLocationProviderClient in your LocManager class:

    var location: State<Location> = mutableStateOf(Location(""))
        private set

    init {
        LocationServices.getFusedLocationProviderClient(context)
            .getCurrentLocation(Priority.PRIORITY_HIGH_ACCURACY, CancellationTokenSource().token)
            .addOnCompleteListener {
                if (it.isSuccessful) {
                    location = mutableStateOf(it.result)
                } else {
                    Log.e("LocManager: getFusedLocation", it.exception.toString())
                }
            }
    }

    private fun FusedLocationProviderClient.locationFlow() = callbackFlow<Location> {
        val locationFlow = object: LocationCallback() {
            override fun onLocationResult(result: LocationResult) {
                for (item in result.locations) {
                    trySend(item)
                }
            }
        }

        locManager.requestLocationUpdates(
            LocationRequest.Builder(5000)
                .setPriority(PRIORITY_HIGH_ACCURACY)
                .build(),
            locationFlow,
            Looper.getMainLooper()
        ).addOnFailureListener { error ->
            Log.e("locationFlow", error.localizedMessage ?: "listener registration failed")
            close(error) // in case of error, close the Flow
        }

        awaitClose {
            removeLocationUpdates(locationFlow)
        }
    }.buffer(1, BufferOverflow.DROP_OLDEST) // same as .conflate() or .buffer(Channel.CONFLATED)

The extension function creates a Flow of Location events. It then creates the callback function onLocationResult that emits its argument (a new location result) as the next event in the flow. The callback is encapsulated in a LocationCallback object, as required by the FusedLocationProvider API, and stored in the variable locationFlow. The function then registers this callback object by calling requestLocationUpdates of the API, which also starts the location updates. When the flow is closed, the function removes the callback registration from FusedLocationProvider. In creating the callbackFlow, we set it to buffer only the latest update if updates arrive faster than we can read them (the default behavior is to suspend the emitter if a default buffer of size 64 is full, by specifying BufferOverflow.DROP_OLDEST the emitter becomes non-spending and the default capacity of non-suspending buffer is 1).

With each location update, we also get a speed update from the device. We add a computed property to read the latest speed. Since this property is read as a snapshot when a user posts a chatt, we don’t need it to be observable, i.e., changes to it do not need to be propagated to the rest of the app. Add the following code to your LocManager class:

    val speed: String
        get() = when (location.value.speed) {
            in 0.5..<5.0 -> "walking"
            in 5.0..<7.0 -> "running"
            in 7.0..<13.0 -> "cycling"
            in 13.0..<90.0 -> "driving"
            in 90.0..<139.0 -> "in train"
            in 139.0..<225.0 -> "flying"
            else -> "resting"
        }

Next we create two more flows, to read the accelerometer and geomagnetometer updates from the device. We store the latest reading of the accelerometer in the observable state gravity and that of the geomagnetometer in geomagnetic. Since both types of these sensors can be accessed using the same sensor API, we only need one flow creation extension function to the SensorManager:

    private lateinit var gravity: State<FloatArray>
    private lateinit var geomagnetic: State<FloatArray>

    private fun SensorManager.sensorFlow(sensorType: Int) = callbackFlow<FloatArray> {
        val sensorFlow = object: SensorEventCallback() {
            override fun onSensorChanged(event: SensorEvent) {
                trySend(event.values)
            }
        }

        sensorManager.registerListener(sensorFlow, getDefaultSensor(sensorType), 5000000)

        awaitClose {
            sensorManager.unregisterListener(sensorFlow)
        }
    }.conflate()

To start retrieving location and sensor updates from the device, we provide a startUpdates() composable. This must be a composable function since it calls collectAsStateWithLifecycle(), which is a composable function:

    @Composable
    fun startUpdatesWithLifecycle() {
        location = locManager.locationFlow()
            .collectAsStateWithLifecycle(location.value)
        gravity = sensorManager.sensorFlow(TYPE_ACCELEROMETER)
            .collectAsStateWithLifecycle(FloatArray(3))
        geomagnetic = sensorManager.sensorFlow(TYPE_MAGNETIC_FIELD)
            .collectAsStateWithLifecycle(FloatArray(3))
    }

The composable collectAsStateWithLifecycle automatically closes the flow when the composable is terminated and restarts collection across recompositions and device configuration changes.

The results from the accelerometer and geomagneticmeter together allows us to compute the bearing of the device. Next we add a property to store bearing updates and a computed property that returns the bearing in a human-friendly magnetic heading (as opposed to true north) compass direction. Add the following code to your LocManager class:

    private val compass = arrayOf("North", "NE", "East", "SE", "South", "SW", "West", "NW", "North")
    private val R = FloatArray(9)
    private val I = FloatArray(9)
    private val orientation = FloatArray(3)

    val compassHeading: String
        get() {
            if (::gravity.isInitialized && ::geomagnetic.isInitialized) {
                if (SensorManager.getRotationMatrix(R, I, gravity.value, geomagnetic.value)) {
                    SensorManager.getOrientation(R, orientation)
                    val declination: Double = GeomagneticField(
                        location.value.latitude.toFloat(),
                        location.value.longitude.toFloat(),
                        location.value.altitude.toFloat(),
                        location.value.time
                    ).declination.toDouble()

                    // the 3 elements of orientation: azimuth, pitch, and roll,
                    // true north bearing is azimuth = orientation[0], in rad;
                    // convert to degree and magnetic heading (- declination)
                    val magneticHeading = (Math.toDegrees(orientation[0].toDouble()) - declination + 360.0).rem(360.0)
                    val index = (magneticHeading / 45.0).roundToInt()
                    return compass[index]
                }
            }
            return "unknown"
        }

Accessing the Location Manager

If LocManager is a singleton, we can access it globally as with ChattStore. Unfortunately on Android, it is not simple to create a singleton object that takes arguments in its construction. So instead, we’re going to create an instance of LocManager in a ViewModel. Add the following code to your MainActivity.kt, outside the MainActivity class:

class LocationViewModel: ViewModel() {  // Provider.Factory
    lateinit var locManager: LocManager

    fun initLocManager(applicationContext: Context) {
        if (!::locManager.isInitialized) { // don't reinitialize on orientation change
            locManager = LocManager(applicationContext)
        }
    }
}

Then to your MainActivity class, add the following viewModel property as we did in the audio lab:

    private val viewModel: LocationViewModel by viewModels()

and initialize its locManager in the onCreate() function, right before the call to initQueue():

        viewModel.initLocManager(applicationContext)

We need to read location and bearing updates in PostView. Google Maps has its own mechanism to start and stop location and heading updates and does not need to read our flows. Pass viewModel.locManager to PostView in your NavHost in MainActivity:

                composable("PostView") {
                    PostView(viewModel.locManager)
                }

For your PostView definition, add locManager: LocManager as its parameter:

@Composable
fun PostView(locManager: LocManager) { 
    // . . . 
}

In your PostView, call startUpdatesWithLifecycle() right before the Scaffold composable:

    locManager.startUpdatesWithLifecycle()

Since startUpdatesWithLifecycle() must be a composable (see above), it must be called from a composable and not as a side-effect.

        Text("${locManager.location.value.latitude}, ${locManager.location.value.longitude}, ${locManager.speed}, ${locManager.compassHeading}")

Posting and displaying geodata

We can now obtain the user’s lat/lon and bearing from Android’s location provider and sensor services. To post this geodata information with each chatt and later to display it on a map, we first need to update our Chatter backend and API.

If you haven’t modified your back end to handle geodata, please go ahead and do so now:

• Maps Back End

Once you’ve updated your back end, return here to continue work on your front end.

Chatt

We add a new stored property geodata to the Chatt class to hold the geodata associated with each chatt:

class Chatt(var username: String? = null,
            var message: String? = null,
            var id: UUID? = null,
            var timestamp: String? = null,
            var altRow: Boolean = true,
            var geodata: GeoData? = null)

GeoData

Create a new GeoData class to store the additional geodata. Let’s put our new GeoData class in a new GeoData.kt file:

class GeoData(var lat: Double = 0.0, var lon: Double = 0.0, var place: String = "",
              var facing: String = "unknown", var speed: String = "unkown")

Reverse geocoding

In addition to the lat/lon information, we use Android’s Geocoder to perform reverse-geocoding to obtain a more familiar place name from the lat/lon information. Add the following methods to your GeoData class:

    private suspend fun reverseGeocodeLocation(context: Context) = suspendCoroutine { cont ->
        Geocoder(context, Locale.getDefault()).getFromLocation(lat, lon, 1,
            object: Geocoder.GeocodeListener {
                override fun onError(errorMessage: String?) {}
                override fun onGeocode(addresses: List<Address>) {
                    cont.resume(addresses)
                }
            })
    }

    suspend fun setPlace(context: Context) {
        val geolocs = reverseGeocodeLocation(context)
        place = if (geolocs.isNotEmpty()) {
            geolocs[0].locality ?: geolocs[0].subAdminArea ?: geolocs[0].adminArea ?: geolocs[0].countryName ?: "Place unknown"
        } else { "Place unknown" }
    }

We will call setPlace() before posting a chatt to compute and include the place name in the posted chatt. We have made setPlace() a suspending function so that we can convert Geocoder.getFromLocation() into another suspending function reverseGeocodeLocation, allowing us to wait for the call to complete before proceeding further (otherwise the completion handler to getFromLocation() will be executed asynchronously at some undeterminate time).

To present the geodata in a nicely formatted string, add the following computed property to your GeoData class. We will use this property to display the geodata information to the user.

    val postedFrom: AnnotatedString
        get() = buildAnnotatedString {
            // https://developer.android.com/reference/kotlin/androidx/compose/ui/text/SpanStyle
            // "Posted from $place while facing $facing moving at $speed speed."
            append("Posted from ")
            pushStyle(SpanStyle(color = DarkGreen, fontWeight = FontWeight.Bold))
            append(place)
            pop()
            append(" while facing ")
            pushStyle(SpanStyle(color = DarkGreen, fontWeight = FontWeight.Bold))
            append(facing)
            pop()
            append(" moving at ")
            pushStyle(SpanStyle(color = DarkGreen, fontWeight = FontWeight.Bold))
            append(speed)
            pop()
            append(" speed.")
            toAnnotatedString()
        }

Post chatt with geodata

To post chatt with the poster’s place name in its geodata, add the following variable to your SubmitButton() in PostView:

        val viewModel: LocationViewModel = viewModel()

and replace the whole onClick block of the IconButton() in SubmitButton() with:

                isEnabled = false
                val geodata = GeoData(lat = locManager.location.value.latitude,
                    lon = locManager.location.value.longitude,
                    facing = locManager.compassHeading, speed = locManager.speed)
                viewModel.viewModelScope.launch {
                    geodata.setPlace(context)
                    postChatt(Chatt(username, message, geodata = geodata))  {
                        getChatts()
                    }
                    withContext(Dispatchers.Main) {
                        navController.popBackStack()
                    }
                }

We launch the suspending function setPlace() in the CoroutineScope of LocationViewModel.viewModelScope and wait for its completion before posting the chatt with the geodata. We call navController.popBackStack() after the call to postChatt() returned (but network posting may not have completed). Popping the navigation stack modifies the UI and must be done on the main thread.

Next update postChatt() in ChattStore.kt to pass along the geodata. Here’s the updated top part of postChatt():

    fun postChatt(chatt: Chatt, completion: () -> Unit) {
        val geoObj = chatt.geodata?.run{ JSONArray(listOf(lat, lon, place, facing, speed)) }

        val jsonObj = mapOf(
            "username" to chatt.username,
            "message" to chatt.message,
            "geodata" to geoObj?.toString()
        )
        // ...

Staying in the postChatt() method, find the declaration of postRequest and replace postchatt with postmaps in the url construction.

We are now ready to retrieve chatts from the back end.

getChatts()

Again, find the declaration of getRequest and replace getchatts with getmaps in the url construction.

To construct Chatt objects from retrieved JSON data, we modify the getChatts() function in the ChattStore class. Find the if (chattEntry.length() == nFields) { block in getChatts() and replace the content of the if block with:

                        val geoArr = if (chattEntry[4] == JSONObject.NULL) null else JSONArray(chattEntry[4] as String)
                        _chatts.add(Chatt(username = chattEntry[0].toString(),
                            message = chattEntry[1].toString(),
                            id = UUID.fromString(chattEntry[2].toString()),
                            timestamp = chattEntry[3].toString(),
                            altRow = idx % 2 == 0,
                            geodata = geoArr?.let { GeoData(
                                lat = it[0].toString().toDouble(),
                                lon = it[1].toString().toDouble(),
                                place = it[2].toString(),
                                facing = it[3].toString(),
                                speed = it[4].toString()
                            )}
                        ))

Each string array returned by the back end represents a single chatt. The fifth entry in each string array, chattEntry[4], contains the string holding an “inner” array of geodata. If this string is not JSONObject.Null, we convert it into a JSONArray and construct a GeoData using elements of this array to initialize the GeoData. We then use this GeoData instance, along with the other elements of the “outer” array, to construct a Chatt.

Displaying geodata on timeline

Before we look at how to display geodata information on a map, let’s display it on the chatt timeline, to confirm that we are posting and retrieving the correct information. Inside your ChattListRow composable, update it by moving the existing code:

        chatt.message?.let { Text(it, fontSize = 17.sp, modifier = Modifier.padding(4.dp, 10.dp, 4.dp, 10.dp).fillMaxWidth(.8f)) }

inside a Column {} block and the add the following line under the display of message inside this new Column block:

                chatt.geodata?.let { Text(it.postedFrom, fontSize = 17.sp, modifier = Modifier.padding(4.dp, 10.dp, 4.dp, 10.dp).fillMaxWidth(.8f)) }

With these changes, you should now be able to post a chatt with geodata information and display the geodata alongside retrieved chatts. Try it out. If your facing information on device continues to be “unknown”, move and turn around a bit with the device so that the sensors will note a change in location and facing.

Google Maps

Get API key

1. To display geodata associated with chatts on a map, we first must obtain a Google Maps API key:

   Step 1.Set up your project and click on the big blue Go to the project selector page button.

   Step 2. Enable APIs or SDKs, click on the big blue Enable the Maps SDK for Android button.

   Step 3. Get an API Key and follow the big blue Go to the Credentials page button (you will need a gmail address, not a umich email address, to set up a Google Cloud Console account).

   DO NOT follow the rest of the instructions on the page. STOP at Add the API Key to your app. Follow the instructions below instead.

   The Google API website is reconfigured very frequently. The instructions here have been through at least 4 reconfigurations of the site. If what you see on the site is so totally different from the description here that you can’t make your way through it, please let the teaching staff know.

2. Optional: set restrictions on your API key before using it in production (i.e., not necessary for this lab): create an Android-restricted and API-restricted API key for your project.

   SHA-1 fingerprint

   To get your SHA-1 signing certificate:

   On macOS on Terminal, enter:

   laptop$ keytool -v -list -keystore ~/.android/debug.keystore -alias androiddebugkey -storepass android -keypass android
   

   On Windows PowerShell, enter:

   PS laptop> keytool -v -list -keystore ~\.android\debug.keystore -alias androiddebugkey -storepass android -keypass android
   

   Don't have keytool or Java Runtime?

   On macOS, if keytool complains that operation couldn’t be completed because it is unable to locate a Java Runtime, download and install it from www.java.com.

   To install keytool on Windows natively, you can follow the instructions on “How to fix keytool is not recognized as an internal or external command” [thanks to Konstantin Kovalchuk (F21)].

   If you’re using WSL as terminal but run Android Studio as a Windows application instead of a Linux application, you must point keytool to /mnt/c/users/<YOUR_WINDOWS_USERNAME>/.android/debug.keystore.

   If you don’t have keytool installed on WSL, you can install it with [thanks to David Wegsman F21]:

     laptop$ sudo apt install openjdk-17-jre-headless
   

   You should see amongst the output three lines that start like this:

   Certificate fingerprints:
            SHA1: XX:XX:XX:...:XX
            SHA256: YY:YY:YY:...:YY
   

   Cut and paste the SHA1 certificate to the Google API Console. Click CREATE.

3. Make a copy of the resulting API key and put a copy of your API key in your AndroidManifest.xml. The com.google.android.geo.API_KEY meta-data block in your AndroidManifest.xml should look like:

           <meta-data
               android:name="com.google.android.geo.API_KEY"
               android:value="AIz..." />
   

   where AIz... should be replaced with your API key. This is not the most secure way of storing your API key, but it makes it easier for us to grade your lab.

4. Add the following dependency to build.gradle (Module:):

    dependencies {
        // . . .
        implementation("com.google.android.gms:play-services-maps:18.2.0")
        implementation("com.google.maps.android:maps-compose:2.11.5")
    }
   

MapView

We support two ways to view the geodata on a map:

1. viewing the posting location of a single chatt, and
2. viewing the posting locations of all retrieved chatts with a swipe-left gesture.

Previously in the audio lab we specified a Boolean argument to pass to a navigation target. Unfortunately passing argument to navigation target is limited to basic and parcelable/serializable types. Instead, the recommended way to pass complex data type while navigating is through a ViewModel. We use a selected property in LocationViewModel to determine whether a chatt has been selected for display. If no single chatt has been so selected, we display the locations of all chatts in the chatts array. In your definition of LocationViewModel in MainActivity.kt, add the following property:

    var selected = SelectedChatt()

and add the definition of the SelectedChatt class:

class SelectedChatt(var chatt: Chatt? = null)

Next create a new Kotlin file and name it MapView. Put the following MapView composable in the file:

@Composable
fun MapView(locManager: LocManager, selected: SelectedChatt) {
    val navController = LocalNavHostController.current

    val cameraPosition = selected.chatt?.geodata?.let {
        LatLng(it.lat, it.lon)
    } ?: LatLng(locManager.location.value.latitude,
        locManager.location.value.longitude)

    GoogleMap(
        modifier = Modifier.fillMaxSize(),
        cameraPositionState = rememberCameraPositionState {
            position = CameraPosition.Builder().target(cameraPosition).zoom(18f).tilt(60f).build()
        }
    ) {
        selected.chatt?.let { chatt ->
            MarkerInfoWindow(
                state = MarkerState(position = cameraPosition),
                infoWindowAnchor = Offset(2f,2.85f)
            ) {
                InfoWindow(chatt)
            }
        } ?: run {
            chatts.forEach { chatt ->
                chatt.geodata?.let { geodata ->
                    MarkerInfoWindow(
                        state = MarkerState(position = LatLng(geodata.lat, geodata.lon)),
                        infoWindowAnchor = Offset(2f,2.85f)
                    ) {
                        InfoWindow(chatt)
                    }
                }
            }
        }
    }
}

To the composable GoogleMap, we pass in a cameraPositionState that specifies the coordinates (lat/lon) the camera is pointing at, the zoom level (distance and height), and tilt (angle) of the camera. If we are displaying a single chatt (selected.chatt is not null), we position the camera to point at the location the chatt was posted from. Otherwise, we position the camera to point at the user’s current location. By using rememberCameraPositionState{}, we let the camera position be saved across recompositions and GoogleMap() will automatically center the map at the camera position.

You can optionally control whether:

1. to display the map as a satellite image, with or without geographic data overlay,
2. to add a button to center on the user’s location,
3. to display a compass on the map, or
4. to add a scale control

by adding the following arguments in the call to GoogleMap():

    GoogleMap(
        modifier = Modifier.fillMaxSize(),
        properties = MapProperties(mapType = MapType.HYBRID, isMyLocationEnabled = true),
        uiSettings = MapUiSettings(compassEnabled = true, mapToolbarEnabled = false),
        // . . .
    ) {}

To allow user to navigate back to MainView, add the following code inside your MapView composable, right after the call to GoogleMap():

    IconButton(
        onClick = {
            navController.popBackStack(navController.graph.startDestinationId, false, false)
        },
        colors = IconButtonDefaults.iconButtonColors(
            containerColor = Color.White.copy(alpha = 0.6f,)),
        modifier = Modifier.offset(x = 8.dp, y = 50.dp)
    ) {
        Icon(Icons.AutoMirrored.Filled.ArrowBack,
            contentDescription = stringResource(R.string.back),
            tint = Color.DarkGray.copy(alpha=0.9f),
            modifier = Modifier.scale(1.25f)
        )
    }

    BackHandler(true) {
        navController.popBackStack(navController.graph.startDestinationId, false, false)
    }

On the map, each chatt is represented by a marker, displayed at the coordinates (lat/lon) the chatt was posted from. When the user taps on a chatt’s marker, an annotation is displayed at the coordinates of the marker. We’ll use the following information window to display the annotation:

@Composable
fun InfoWindow(chatt: Chatt) {
    Column(modifier = Modifier.padding(4.dp, 0.dp, 4.dp, 0.dp)
        .background(color = Color.LightGray.copy(alpha = 0.8f))) {
        Row(horizontalArrangement = Arrangement.SpaceBetween, modifier=Modifier.fillMaxWidth(.8f)) {
            chatt.username?.let { Text(it, fontSize = 16.sp, modifier = Modifier.padding(4.dp, 0.dp, 4.dp, 0.dp)) }
            chatt.timestamp?.let { Text(it, fontSize = 12.sp, textAlign = TextAlign.End, modifier = Modifier.padding(4.dp, 0.dp, 4.dp, 0.dp)) }
        }
        chatt.message?.let { Text(it, fontSize = 14.sp, modifier = Modifier.padding(4.dp, 2.dp, 4.dp, 0.dp).fillMaxWidth(.8f)) }
        chatt.geodata?.let { Text(it.postedFrom, fontSize = 12.sp, modifier = Modifier.padding(4.dp, 4.dp, 4.dp, 0.dp).fillMaxWidth(.8f)) }
    }
}

Swipe left to view the geodata of all chatts

First in the NavHost block in MainActivity, add MapView as a navigation destination:

                composable("MapView") {
                    MapView(viewModel.locManager, viewModel.selected)
                }

To recognize a swipe left gesture in MainView, add the following modifier argument to your call to Scaffold():

    Scaffold(
        modifier = Modifier.scrollable(
            orientation = Orientation.Horizontal,
            state = rememberScrollableState { delta ->
                when {
                    delta < 0 -> {
                        selected.chatt = null
                        navController.navigate("MapView")
                    }
                    else -> {}
                }
                delta
            }),
        // . . .
    )

Prior to navigating to MapView, we set selected.chatt to null to indicate that we want to display on the map all chatts in the chatts array, instead of displaying just an individual selected chatt.

Viewing the geodata of a single chatt

To enable user to view the poster location of a single chatt, we add a “map” button to each chatt in the MainView timeline, similar to how we added an “audio” button in the audio lab.

We first need to pass the container for the selected chatt to MainView when navigating to it. In your NavHost block in MainActivity, modify the MainView navigation destination to read:

                composable("MainView") {
                    MainView(viewModel.selected)
                }

For your MainView definition, add selected as its parameter:

@Composable
fun MainView(selected: SelectedChatt) { 
    // . . .
}

To actually display the selected chatt, we need to further pass it to ChattListRow(). Modify your call to ChattListRow() to:

                    ChattListRow(it, selected)

and add selected as a parameter to the definition of ChattListRow():

@Composable
fun ChattListRow(selected: SelectedChatt) {
    val navController = LocalNavHostController.current

    // . . .
}

Here we also retrieved a copy of the NavHostController from its CompositionLocal so that we can navigate to MapView to display the selected chatt.

To recap, by the end of this lab, if you tap on the map button associated with each chatt, you will see a map centered and zoomed in on the poster’s location, with a marker at the location. Swiping left on MainView will bring you to the map view with all retrieved chatts shown as markers on the map and the map centered and zoomed in on the user’s current location. In both cases, tapping the button that looks like a bull’s eye target should pan and zoom onto the user’s current location.

Simulating locations

To use the Android emulator to simulate your location, follow the instructions in our Getting Started with Android Development.

To simulate location on device, there are multiple apps in the Google Playstore that allows you to set fake GPS location at the same time you have Chatter running. For example, both “Fake GPS Location” developed by “Lexa” and “Fake GPS” by “ByteRev” have no ads. Once you’ve installed the app, go to Settings > System > Developer options > Select mock location app and select the app. In the app, search for the desired simulated location and tap the play button. When you post a chatt, or when you view all chatts, the user’s current location should be the simulated location. You can go back to the fake GPS app to select a different simulated location and it should automatically be reflected in Chatter without restarting. Tap the pause or stop button in the fake GPS app to stop simulating location.

Submission guidelines

We will only grade files committed to the master or main branch. If you use multiple branches, please merge them all to the master/main branch for submission.

Ensure that you have completed the back-end part and have pushed your changes to your back-end code to your 441 GitHub repo.

Push your signin lab folder to your GitHub repo as set up at the start of this spec.

Go to the GitHub website to confirm that your front-end files have been uploaded to your GitHub repo under the folder signin. Confirm that your repo has a folder structure outline similar to the following. If your folder structure is not as outlined, our script will not pick up your submission, you will get ZERO point, and you will further have problems getting started on latter labs. There could be other files or folders in your local folder not listed below, don’t delete them. As long as you have installed the course .gitignore as per the instructions in Preparing GitHub for EECS 441 Labs, only files needed for grading will be pushed to GitHub.

  441
    |-- # files and folders from other labs . . .
    |-- maps
        |-- debug.keystore       
        |-- composeChatter
            |-- app
            |-- gradle
    |-- # files and folders from other labs . . .            

Review your information on the Lab Links sheet. If you’ve changed your teaming arrangement from previous lab’s, please update your entry. If you’re using a different GitHub repo from previous lab’s, invite eecs441staff@umich.edu to your new GitHub repo and update your entry.

References

• Simplifying APIs with Coroutines and Flow
• 7 Useful Ways to create Flow in Kotlin
• Consuming Flows Safely in Jetpack Compose
• Get Started With Google Maps
• Compose for the Maps SDK for Android Now Available
• MarkerInfoWindow
• Getting City Name of Current Position
• Android Location Providers
• How do I get the current GPS location programmatically in Android?
• FusedLocationProviderClient doesn’t have bearing data, note rad to degree conversion
• Gestures in Jetpack Compose: The Basics

Array and JSON

• Java convert a Json string to an array
• Convert normal Java Array or ArrayList to Json Array in android
• How to initialize list in Kotlin
• Difference between List and Array types in Kotlin
• Kotlin when: A switch with Superpowers

Appendix: imports