A few things that have worked for me:

• Use /context or /status to see where you currently are.

• Use /statusline to add context and more information to the bottom of your terminal

• /compact often, in both Codex and Claude Code

• Start new conversations frequently (like one per bugfix). Use the /new or /clear command

• Keep a small AGENTS.md/CLAUDE.md file. Avoid repeating instructions.

• Use fewer and smaller MCPs, skills and subagents. Every skill and subagent you have are injected into the initial prompt, inflating context. MCPs are loaded on-demand, but descriptions are still sent for the model to decide. By 3-4 turns you're already exceeding the optimal window. I have seen people use 20+ MCPs! Don't do that. Think about what needs to be scoped to the user vs the project.

• Spawn subagents. They give a small, concise results to your main agent, preventing context inflation. Also better retrieval! Most agents spawn them without your intervention.

Bottom Sheets have become ubiquitous in Mobile design across Android and iOS. If you’re using Jetpack Compose, you’ll likely implement them using either the ModalBottomSheet or the BottomSheetScaffold. The former is more used in my experience, so further references to the bottom sheets in this article will mean ModalBottomSheet. We’ll be using the Material 3 implementation for the component.

Assume a scenario where we want to display a bottom sheet, and upon some action, show a custom alert message at the top of the screen. This alert should appear on top of the sheet, but it’s not as trivial as it may seem. Let’s start with the custom alert.

Custom Alert

I find the default Snackbar available in Material 3 to be quite restrictive. This is why we’ll design our own, using a Popup composable. It’s part of the Compose UI package and is available with or without Material implementation. From the docs,

A popup is a floating container that appears on top of the current activity It is especially useful for non-modal UI surfaces that remain hidden until they are needed, for example floating menus like Cut/Copy/Paste.

This seems suitable for our use case. Let’s make a custom alert that appears on the top, displays some text, and disappears after 2 seconds. We can use the following code for this purpose.

@OptIn(ExperimentalComposeUiApi::class)
@Composable
private fun Content() {
    var showAlert by remember { mutableStateOf("") }

    Box(
        modifier = Modifier
            .fillMaxSize()
            .background(Color(0x55242424))
    ) {
        Button(
            onClick = { showAlert = "Hello, world!" },
            modifier = Modifier.align(Alignment.Center)
        ) {
            Text("Click me!")
        }
    }

    Popup(
        alignment = Alignment.TopCenter,
        properties = PopupProperties(
            dismissOnClickOutside = false,
            dismissOnBackPress = false,
            usePlatformDefaultWidth = false
        )
    ) {
        AnimatedVisibility(
            modifier = Modifier.fillMaxWidth(),
            visible = showAlert.isNotBlank(),
            enter = expandVertically(),
            exit = shrinkVertically()
        ) {
            LaunchedEffect(Unit) {
                delay(2000)
                showAlert = ""
            }

            Alert(message = showAlert)
        }
    }
}

@Composable
private fun Alert(message: String) {
    Text(
        text = message,
        modifier = Modifier
            .fillMaxWidth()
            .padding(horizontal = 32.dp)
            .shadow(5.dp)
            .background(Color.White)
            .padding(vertical = 16.dp),
        textAlign = TextAlign.Center
    )
}

This results in the following UI being drawn:

Good enough. Now, we can move on to the Bottom Sheet.

The Bottom Sheet

Let’s create a bottom sheet that asks a user for their name and shows them a welcome alert.

@OptIn(ExperimentalComposeUiApi::class)
@Composable
private fun Content() {
    var showSheet by remember { mutableStateOf(false) }

    if (showSheet) {
        NameSheet(
            onDismiss = { showSheet = false },
            onNameInput = { name ->
                // TODO show alert
            }
        )
    }

    Box(
        modifier = Modifier
            .fillMaxSize()
            .background(Color(0x55242424))
    ) {
        Button(
            onClick = { showSheet = true },
            modifier = Modifier.align(Alignment.Center)
        ) {
            Text("Show Sheet")
        }
    }
}

@OptIn(ExperimentalMaterial3Api::class)
@Composable
private fun NameSheet(
    onDismiss: () -> Unit,
    onNameInput: (String) -> Unit
) {
    ModalBottomSheet(
        onDismissRequest = onDismiss
    ) {
        var name by remember { mutableStateOf("") }
        OutlinedTextField(
            value = name,
            onValueChange = { name = it },
            label = { Text("Hi!, What's your name?") },
            placeholder = { Text("John Doe") },
            modifier = Modifier
                .fillMaxWidth()
                .padding(horizontal = 16.dp)
                .padding(bottom = 8.dp),
            keyboardOptions = KeyboardOptions(
                keyboardType = KeyboardType.Text,
                imeAction = ImeAction.Done
            ),
            keyboardActions = KeyboardActions(
                onDone = { onNameInput(name) }
            ),
            singleLine = true
        )
    }
}

Upon rendering, we find that the UI can be a bit better. The scrims don’t draw correctly on the system bar, and the navigation bar insets are not being consumed by the sheet. This is not ideal since apps on Android 15 draw content edge-to-edge.

This is a bug in the earlier versions of Material3. A fix was published in May with the release of Version 1.3.0-alpha06 of Material 3 for Compose. Since 1.3.0 stable is available now, we will use that:

implementation("androidx.compose.material3:material3:1.3.0")

Just switching the library version fixes the issue, and we get this now:

Now, we just need to show the alert when the user inputs their name and hits the done IME action.

Displaying the Alert with Bottom Sheet open

Let’s now use the following code to display an alert when a user inputs their name and hits the done button on the keyboard.

@Composable
private fun Content() {
    var showAlert by remember { mutableStateOf("") }
    var showSheet by remember { mutableStateOf(false) }

    if (showSheet) {
        NameSheet(
            onDismiss = { showSheet = false },
            onNameInput = { name ->
                showAlert = "Hello, $name!"
            }
        )
    }

    Box(
        modifier = Modifier
            .fillMaxSize()
            .background(Color(0x55242424))
    ) {
        Button(
            onClick = { showSheet = true },
            modifier = Modifier.align(Alignment.Center)
        ) {
            Text("Show Sheet")
        }
    }

    Popup(
        alignment = Alignment.TopCenter,
        properties = PopupProperties(
            dismissOnClickOutside = false,
            dismissOnBackPress = false,
            usePlatformDefaultWidth = false
        )
    ) {
        AnimatedVisibility(
            modifier = Modifier.fillMaxWidth(),
            visible = showAlert.isNotBlank(),
            enter = expandVertically(),
            exit = shrinkVertically()
        ) {
            LaunchedEffect(Unit) {
                delay(2000)
                showAlert = ""
            }

            Alert(message = showAlert)
        }
    }
}

@Composable
private fun Alert(message: String) {
    Text(
        text = message,
        modifier = Modifier
            .fillMaxWidth()
            .padding(horizontal = 32.dp)
            .shadow(5.dp)
            .background(Color.White)
            .padding(vertical = 16.dp),
        textAlign = TextAlign.Center
    )
}

@OptIn(ExperimentalMaterial3Api::class)
@Composable
private fun NameSheet(
    onDismiss: () -> Unit,
    onNameInput: (String) -> Unit
) {
    ModalBottomSheet(
        onDismissRequest = onDismiss
    ) {
        var name by remember { mutableStateOf("") }
        OutlinedTextField(
            value = name,
            onValueChange = { name = it },
            label = { Text("Hi!, What's your name?") },
            placeholder = { Text("John Doe") },
            modifier = Modifier
                .fillMaxWidth()
                .padding(horizontal = 16.dp)
                .padding(bottom = 8.dp),
            keyboardOptions = KeyboardOptions(
                keyboardType = KeyboardType.Text,
                imeAction = ImeAction.Done
            ),
            keyboardActions = KeyboardActions(
                onDone = { onNameInput(name) }
            ),
            singleLine = true
        )
    }
}

Let’s see the output:

We notice that the popup is rendered behind the Bottom Sheet’s scrim. This happens because the current implementation of the Bottom Sheet uses Dialog as the base component, which has a higher z-index. We can see the commit here:

This is not the best UX, and we ideally want to draw the alert on top of the Bottom Sheet. Two solutions come to mind:

Potential Solution: Popup inside BottomSheet content

If we draw the Popup inside the Bottom Sheet’s content, it’ll be inside the Dialog in which the Bottom Sheet is displayed and will render on top of it. Let’s modify our code:

@Composable
private fun Content() {
    var showSheet by remember { mutableStateOf(false) }

    if (showSheet) {
        NameSheet(onDismiss = { showSheet = false },)
    }

    Box(
        modifier = Modifier
            .fillMaxSize()
            .background(Color(0x55242424))
    ) {
        Button(
            onClick = { showSheet = true },
            modifier = Modifier.align(Alignment.Center)
        ) {
            Text("Show Sheet")
        }
    }
}

@Composable
private fun Alert(message: String) {
    Text(
        text = message,
        modifier = Modifier
            .fillMaxWidth()
            .padding(horizontal = 32.dp)
            .shadow(5.dp)
            .background(Color.White)
            .padding(vertical = 16.dp),
        textAlign = TextAlign.Center
    )
}

@OptIn(ExperimentalMaterial3Api::class)
@Composable
private fun NameSheet(
    onDismiss: () -> Unit,
) {
    var showAlert by remember { mutableStateOf("") }

    ModalBottomSheet(
        onDismissRequest = onDismiss
    ) {
        var name by remember { mutableStateOf("") }
        OutlinedTextField(
            value = name,
            onValueChange = { name = it },
            label = { Text("Hi!, What's your name?") },
            placeholder = { Text("John Doe") },
            modifier = Modifier
                .fillMaxWidth()
                .padding(horizontal = 16.dp)
                .padding(bottom = 8.dp),
            keyboardOptions = KeyboardOptions(
                keyboardType = KeyboardType.Text,
                imeAction = ImeAction.Done
            ),
            keyboardActions = KeyboardActions(
                onDone = { showAlert = "Hello, $name!" }
            ),
            singleLine = true
        )

        Popup(
            alignment = Alignment.TopCenter,
            properties = PopupProperties(
                dismissOnClickOutside = false,
                dismissOnBackPress = false,
                usePlatformDefaultWidth = false
            )
        ) {
            AnimatedVisibility(
                modifier = Modifier.fillMaxWidth(),
                visible = showAlert.isNotBlank(),
                enter = expandVertically(),
                exit = shrinkVertically()
            ) {
                LaunchedEffect(Unit) {
                    delay(2000)
                    showAlert = ""
                }

                Alert(message = showAlert)
            }
        }
    }
}

This doesn’t quite work as intended, because now the Popup has the same container size as the Bottom Sheet, and does not render at the top of the screen (unless the Bottom Sheet is at full height):

Actual Solution: Using dialog to display the alert

This is a workaround I came up with recently: Instead of using a Popup to display the alert, we’ll switch to a Dialog to render it on top of the sheet. This is a bit more complicated since

• Dialogs intercept any clicks on views beneath them, so as long as the alert is visible, the user will not be able to interact with the UI. To solve this issue, we set some WindowManager flags to make the dialog not focusable, resulting in it allowing click passthrough.

• The dialog cannot be a persistent part of the UI like the Popup. It must be added to the tree after the sheet so that it obtains a higher z-index.

Let’s look at code that implements both of these scenarios:

@Composable
private fun Content() {
    var showAlert by remember { mutableStateOf("") }
    var showSheet by remember { mutableStateOf(false) }

    if (showSheet) {
        NameSheet(
            onDismiss = { showSheet = false },
            onNameInput = { name ->
                showAlert = "Hello, $name!"
            }
        )
    }

    // Screen content
    Box(
        modifier = Modifier
            .fillMaxSize()
            .background(Color(0x55242424))
    ) {
        Button(
            onClick = { showSheet = true },
            modifier = Modifier.align(Alignment.Center)
        ) {
            Text("Show Sheet")
        }
    }

    if (showAlert.isNotBlank()) {
        Alert(showAlert) { showAlert = "" }
    }
}

@Composable
private fun Alert(
    message: String,
    onDismiss: () -> Unit
) {
    Dialog(
        onDismissRequest = onDismiss,
        properties = DialogProperties(
            dismissOnClickOutside = false,
            dismissOnBackPress = false,
            usePlatformDefaultWidth = false
        )
    ) {
        (LocalView.current.parent as DialogWindowProvider).window.apply {
            setDimAmount(0f)
            addFlags(WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE)
            addFlags(WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE)
        }

        AnimatedVisibility(
            modifier = Modifier
                .fillMaxSize()
                .padding(top = 8.dp)
                .padding(horizontal = 16.dp)
                .wrapContentHeight(Alignment.Top),
            visible = message.isNotBlank(),
            enter = expandVertically(),
            exit = shrinkVertically()
        ) {
            LaunchedEffect(Unit) {
                delay(2000)
                onDismiss()
            }

            Text(
                text = message,
                modifier = Modifier
                    .fillMaxWidth()
                    .padding(horizontal = 32.dp)
                    .shadow(5.dp)
                    .background(Color.White)
                    .padding(vertical = 16.dp),
                textAlign = TextAlign.Center
            )
        }
    }
}

@OptIn(ExperimentalMaterial3Api::class)
@Composable
private fun NameSheet(
    onDismiss: () -> Unit,
    onNameInput: (String) -> Unit
) {
    ModalBottomSheet(
        onDismissRequest = onDismiss
    ) {
        var name by remember { mutableStateOf("") }
        OutlinedTextField(
            value = name,
            onValueChange = { name = it },
            label = { Text("Hi!, What's your name?") },
            placeholder = { Text("John Doe") },
            modifier = Modifier
                .fillMaxWidth()
                .padding(horizontal = 16.dp)
                .padding(bottom = 8.dp),
            keyboardOptions = KeyboardOptions(
                keyboardType = KeyboardType.Text,
                imeAction = ImeAction.Done
            ),
            keyboardActions = KeyboardActions(
                onDone = { onNameInput(name) }
            ),
            singleLine = true
        )
    }
}

Since this is relatively complex, let’s walk over some bits that require further elucidation:

•     if (showAlert.isNotBlank()) {
          Alert(showAlert) { showAlert = "" }
      }
  

  Earlier, our Popup was a consistent part of the UI tree, but as explained above, the dialog needs to be added after the sheet for it to appear higher.

•     (LocalView.current.parent as DialogWindowProvider).window.apply {
          setDimAmount(0f)
          addFlags(WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE)
          addFlags(WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE)
      }
  

  Since we need to change the window properties, we obtain an instance through the DialogWindowProvider interface. Then, we set the dim amount to 0, so that the Dialog doesn’t draw any shadow behind it. Additionally, we set two layout flags that make the dialog not touchable or focusable, causing it to pass clicks to views beneath it, allowing interaction with the UI as long as the alert is visible.

•     AnimatedVisibility(
          modifier = Modifier
              .fillMaxSize()
              .padding(top = 8.dp)
              .padding(horizontal = 16.dp)
              .wrapContentHeight(Alignment.Top),
  

  Since there isn’t a direct and easy method to provide the position of a dialog, we instead measure the content to take up the entire screen, and then only draw in the area that is required. Essentially, we’re actually rendering the dialog over all of the screen space, but only the alert is visible since we wrap it to the height of the content, which is the Text. This can be extended to have Images, Icons, etc.

This implementation outputs the intended behavior:

This largely satisfies the requirement we stated at the start of the article, and can be used as the global snackbar at the root of your app in conjunction with a CompositionLocal to provide access to the Snackbar stream. To read how you can do that, consult this post:

Thanks for reading, any feedback is welcome!

Extension Functions

In Kotlin, Extension functions have proven to be an extremely useful feature. They can be used to extend the functionality of a class without inheriting it, and prove extremely useful when you have to define utility methods.

Say you wanted to write a utility method that reverses an integer. You could write something like this:

fun reverse(number: Int): Int {
    var sum = 0
    var num = number
    while (num != 0) {
        sum = (sum * 10) + (num % 10)
        num /= 10
    }
    return sum
}

println(reverse(12345))

With extension functions, you can define an additional method on the Int the class itself, and call that on any integer you'd like:

fun Int.reverse(): Int {
    var sum = 0
    var num = this
    while (num != 0) {
        sum = (sum * 10) + (num % 10)
        num /= 10
    }
    return sum
}

println(12345.reverse())

When we're using Extension Functions, the object that it is being called upon is called the receiver.

Limitation: Single Receiver

With extension functions, we can only use a single receiver at a time. There are some use cases that warrant the usage of 2 or more receivers.

As an example, consider the case where we're using StateFlow instead of LiveData to make the UI reactive to state change. The correct method to collect a StateFlow in a Fragment looks like this:

viewLifecycleOwner.lifecycleScope.launch {
    repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.state.collect {
            binding.toolbar.text = it.titleText
            // ...
        }
    }
}

This is rather verbose, and if the pattern is being used in several places, you'd obviously like to convert this to a utility function that'd make things simpler. A very simple definition is presented below:

fun Fragment.collectStateFlow(body: suspend CoroutineScope.() -> Unit) {
    viewLifecycleOwner.lifecycleScope.launch {
        repeatOnLifecycle(Lifecycle.State.STARTED) {
            body()
        }
    }
}

// In Fragment
collectStateFlow {
    viewModel.state.collect {
        binding.toolbar.text = it.titleText
        // ...
    }
}

What if we wanted to take this a step further, and eliminate the additional line to collect the StateFlow too? We can define an extension function on Flow or StateFlow that can collect emissions while handling the lifecycle under the hood. Here's where we run into a problem. If we define an extension function on StateFlow, it can only receive the StateFlow. In other words, only methods that can be called on a StateFlow will be inside the function, since it'll have the context of the StateFlow it has been called on. Hence, we'll have to pass the Fragment as an argument to the function:

fun <T> StateFlow<T>.collectWithLifecycle(fragment: Fragment, block: (T) -> Unit) {
    fragment.viewLifecycleOwner.lifecycleScope.launch {
        fragment.repeatOnLifecycle(Lifecycle.State.CREATED) {
            this@collectWithLifecycle.collect {
                block(it)
            }
        }
    }
}

// In Fragment
viewModel.state.collectWithLifecycle(this) {
    binding.toolbar.text = it.titleText
    // ...
}

Now that's neat. Looks a lot like the observe method of a LiveData right?

Context Receivers

Being programmers, we have a bad habit of trying to write clever code, so your mind naturally wonders: What if we could have the Fragment context just be implicitly available in the function body? That'd be great. And that's exactly where Context Receivers help us. For a good explanation of how they work, see this. In short, using context receiver syntax, we can have as many receivers for our function as we'd like, meaning we can get any scope we want. Consider this example:

class A {
    val x = 10
}

class B {
    val y = 20
}

context(A, B)
fun printValues() { 
    println(x)
    println(y)
}

fun main() {
    A().apply {
        with(B()) {
            printValues()
        }
    }
}

No need to pass arguments. We can access x and y inside printValues since when we call it, contexts of both classes A, and B are available, and that's seemingly transferred to our method.

Best version of our code using Context Receivers

To use Context Receivers on Android, add this to the kotlinOptions block in your app-level build.gradle file:

freeCompilerArgs = ["-Xcontext-receivers"]

// Overall
kotlinOptions {
    jvmTarget = '1.8'
    freeCompilerArgs = ["-Xcontext-receivers"]
}

Additionally, you need to be using Kotlin 1.6.20 or higher.

Once we've enabled the feature, we can write a utility method like this:

context(Fragment)
fun <T> StateFlow<T>.collectWithLifecycle(block: (T) -> Unit) {
    viewLifecycleOwner.lifecycleScope.launch {
        repeatOnLifecycle(Lifecycle.State.CREATED) {
            this@collectWithLifecycle.collect {
                block(it)
            }
        }
    }
}

// In Fragment
viewModel.state.collectWithLifecycle {
    binding.toolbar.text = it.titleText
    // ...
}

This eliminates all boilerplate we need to write while collecting a StateFlow.

Tip: Instead of StateFlow<T>, use Flow<T> to use with all Flow derivates such as SharedFlow and StateFlow.

---

Tip: To use with Activity, replace Fragment with Activity as the receiver in the code, and remove viewLifecycleOwner since it's not necessary with an Activity.

---

Tip: Compose already has an API for this. See here.

Arrivederci!

Integrating Google maps into Android apps has been somewhat of a tough nut to crack for developers. With the advent of Jetpack Compose for building native UI on Android, the Google Maps team announced a Map SDK for Compose, available here. However, it is only a piece of the puzzle.

The SDK helps with drawing the map on the screen and gives you a very featureful GoogleMap composable with tons of customization, but if you are looking to build a full-fledged address selection screen akin to Ola, Uber, or Swiggy, you may need to integrate several APIs in addition to this.

The two most important are:

1. Places API, used to facilitate autocomplete and provide details for a place on the map.

   

2. Geocoding API, used to convert between lat-long coordinates and the textual address for a point.

Let's walk through their implementation.

Our Goal

We will build a Map screen where users can select their current location. They can do so either by moving the marker to their desired location or by searching for a place in the TextField. The finished screen will look like this:

Let's get started.

1. Google Maps Platform

To use the Google Maps platform, you must create a Google Cloud project, link it to a billing account, and enable the Google Maps SDK for Android.

At the time of writing, Google Maps provides all projects with $200 credit that recurs monthly. That means that you likely won't be paying anything until you have a lot of users. Your billing account will only be charged if you spend more than $200 in a month.

To do so, follow these steps:

1. Create a Google Cloud Project and/or enable Maps SDK for Android, Places API, and Geocoding API. Extensive instructions and direct links are available here

2. Obtain an API key by following the instructions here. This API key will be used to authenticate your app with the Google Maps service.

   It's recommended to restrict the API key to your app by following the instructions in the doc. This prevents misuse of your API key if it's leaked.

3. Set up your app to use the Google Maps platform, and specify the API key in the manifest. Instructions here.

4. By now, you should've added your API key to your local.properties name MAPS_API_KEY. We'll need the key later for interacting with the Places API, so create a buildConfigField for it. In your app-level build.gradle, add the following code inside the defaultConfig block:

    Properties properties = new Properties()
    if (rootProject.file("local.properties").exists()) {
        properties.load(
                rootProject
                .file("local.properties")
                .newDataInputStream()
        )
    }
   
    buildConfigField(
        "String",
        "MAPS_API_KEY",
        properties.getProperty("MAPS_API_KEY")
    )
   

   This will create a new BuildConfig field from the key that you have defined in your local.properties file, which can be used anywhere in the app by referencing BuildConfig.MAPS_API_KEY.

2. GoogleMap Composable

To display a Google Map in your Compose-based Android app, you can use the SDK for compose. It wraps an AndroidView under the hood and gives you several good abstractions that'll help you write idiomatic Compose code. Instructions on integrating the SDK are provided via the README of the project.

We want our map to initially be focused on the user's current location. To obtain the current location, we'll need

1. ACCESS_FINE_LOCATION permission

2. Location enabled in the settings

To represent all these states, we can construct a sealed class:

sealed class LocationState {
    object NoPermission: LocationState()
    object LocationDisabled: LocationState()
    object LocationLoading: LocationState()
    data class LocationAvailable(val location: LatLng): LocationState()
    object Error: LocationState()
}

This is an extremely simplified version. A production app will have more complex state interactions.

Now, we'll build our ViewModel for the screen, which will act as the state holder, containing an instance of the above-defined sealed class. It'll also be responsible for fetching and updating the current location. To do so, we'll use the FusedLocationProviderClient. You can read more about it here. Currently, our ViewModel looks like this:

class LocationViewModel : ViewModel() {
    lateinit var fusedLocationClient: FusedLocationProviderClient

    var locationState by mutableStateOf<LocationState>(LocationState.NoPermission)

    @SuppressLint("MissingPermission")
    fun getCurrentLocation() {
        locationState = LocationState.LocationLoading
        fusedLocationClient
            .getCurrentLocation(Priority.PRIORITY_HIGH_ACCURACY, null)
            .addOnSuccessListener { location ->
                locationState = if (location == null && locationState !is LocationState.LocationAvailable) {
                    LocationState.Error
                } else {
                    LocationState.LocationAvailable(LatLng(location.latitude, location.longitude))
                }
            }
    }
}

Note that the fusedLocationClient is a lateinit object, so we'll need to instantiate it in the fragment's onCreate:

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    viewModel.fusedLocationClient = LocationServices.getFusedLocationProviderClient(requireActivity())
}

Now, let's define a couple of self-explanatory utility functions in the fragment (they can also be made extension functions or stored separately in a util file with the activity being an argument):

private fun requestLocationEnable() {
    activity?.let {
        val locationRequest = LocationRequest.create()
        val builder = LocationSettingsRequest
            .Builder()
            .addLocationRequest(locationRequest)
        val task = LocationServices
            .getSettingsClient(it)
            .checkLocationSettings(builder.build())
            .addOnSuccessListener {
                if (it.locationSettingsStates?.isLocationPresent == true) {
                    viewModel.getCurrentLocation()
                }
            }
            .addOnFailureListener {
                if (it is ResolvableApiException) {
                    try {
                        it.startResolutionForResult(requireActivity(), 999)
                    } catch (e : IntentSender.SendIntentException) {
                        e.printStackTrace()
                    }
                }
            }

    }
}

private fun locationEnabled(): Boolean {
    val locationManager = requireActivity().getSystemService(Context.LOCATION_SERVICE) as LocationManager
    return LocationManagerCompat.isLocationEnabled(locationManager)
}

With our states and utility methods defined, we finally move to our composable. We can use the Permissions Library from the Accompanist collection to request location permission.

val locationPermissionState = rememberMultiplePermissionsState(
    listOf(
        Manifest.permission.ACCESS_COARSE_LOCATION,
        Manifest.permission.ACCESS_FINE_LOCATION
    )
)

Then we can add a LaunchedEffect to update the state when the permission state changes. If they are granted, we check for the location is enabled, and if that's also enabled, we ask the ViewModel to get the current location.

LaunchedEffect(locationPermissionState.allPermissionsGranted) {
    if (locationPermissionState.allPermissionsGranted) {
        if (locationEnabled()) {
            viewModel.getCurrentLocation()
        } else {
            viewModel.locationState = LocationState.LocationDisabled
        }
    }
}

Lastly, we define what UI will be rendered on basis of the location state:

AnimatedContent(
    viewModel.locationState
) { state ->
    when (state) {
        is LocationState.NoPermission -> {
            Column {
                Text("We need location permission to continue")
                Button(onClick = { locationPermissionState.launchMultiplePermissionRequest() }) {
                    Text("Request permission")
                }
            }
        }
        is LocationState.LocationDisabled -> {
            Column {
                Text("We need location to continue")
                Button(onClick = { requestLocationEnable() }) {
                    Text("Enable location")
                }
            }
        }
        is LocationState.LocationLoading -> {
            Text("Loading Map")
        }
        is LocationState.Error -> {
            Column {
                Text("Error fetching your location")
                Button(onClick = { viewModel.getCurrentLocation() }) {
                    Text("Retry")
                }
            }
        }
        is LocationState.LocationAvailable -> {
            val cameraPositionState = rememberCameraPositionState {
                position = CameraPosition.fromLatLngZoom(state.location, 15f)
            }
            val mapUiSettings by remember { mutableStateOf(MapUiSettings()) }
            val mapProperties by remember { mutableStateOf(MapProperties(isMyLocationEnabled = true)) }

            GoogleMap(
                modifier = Modifier.fillMaxSize(),
                cameraPositionState = cameraPositionState,
                uiSettings = mapUiSettings,
                properties = mapProperties
            )
        }
    }
}

In the GoogleMap composable, we can see that it fills the entire screen and takes a Camera Position State, which is responsible for what the user sees on the screen. In our code, the position is set to the user's location that's been obtained through the fusedLocationProvider. It also takes a MapUiSettings object, where you can tweak the visibility of elements like zoom buttons and my location button. Additionally, in MapProperties you can define attributes like the map type, style, and whether the user location is enabled.

Our complete fragment looks like this at the moment:

class LocationFragment : Fragment() {

    private val viewModel by viewModels<LocationViewModel>()

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View? {
        return ComposeView(requireContext()).apply {
            setViewCompositionStrategy(ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed)
            setContent {
                LocationScreen()
            }
        }
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        viewModel.fusedLocationClient = LocationServices.getFusedLocationProviderClient(requireActivity())
    }

    @OptIn(ExperimentalPermissionsApi::class, ExperimentalAnimationApi::class)
    @Composable
    fun LocationScreen(modifier: Modifier = Modifier) {
        val locationPermissionState = rememberMultiplePermissionsState(
            listOf(
                Manifest.permission.ACCESS_COARSE_LOCATION,
                Manifest.permission.ACCESS_FINE_LOCATION
            )
        )

        LaunchedEffect(locationPermissionState.allPermissionsGranted) {
            if (locationPermissionState.allPermissionsGranted) {
                if (locationEnabled()) {
                    viewModel.getCurrentLocation()
                } else {
                    viewModel.locationState = LocationState.LocationDisabled
                }
            }
        }

        AnimatedContent(
            viewModel.locationState
        ) { state ->
            when (state) {
                is LocationState.NoPermission -> {
                    Column {
                        Text("We need location permission to continue")
                        Button(onClick = { locationPermissionState.launchMultiplePermissionRequest() }) {
                            Text("Request permission")
                        }
                    }
                }
                is LocationState.LocationDisabled -> {
                    Column {
                        Text("We need location to continue")
                        Button(onClick = { requestLocationEnable() }) {
                            Text("Enable location")
                        }
                    }
                }
                is LocationState.LocationLoading -> {
                    Text("Loading Map")
                }
                is LocationState.Error -> {
                    Column {
                        Text("Error fetching your location")
                        Button(onClick = { viewModel.getCurrentLocation() }) {
                            Text("Retry")
                        }
                    }
                }
                is LocationState.LocationAvailable -> {
                    val cameraPositionState = rememberCameraPositionState {
                        position = CameraPosition.fromLatLngZoom(state.location, 15f)
                    }
                    val mapUiSettings by remember { mutableStateOf(MapUiSettings()) }
                    val mapProperties by remember { mutableStateOf(MapProperties(isMyLocationEnabled = true)) }

                    GoogleMap(
                        modifier = Modifier.fillMaxSize(),
                        cameraPositionState = cameraPositionState,
                        uiSettings = mapUiSettings,
                        properties = mapProperties
                    )
                }
            }
        }
    }

    private fun locationEnabled(): Boolean {
        val locationManager = requireActivity().getSystemService(Context.LOCATION_SERVICE) as LocationManager
        return LocationManagerCompat.isLocationEnabled(locationManager)
    }

    private fun requestLocationEnable() {
        activity?.let {
            val locationRequest = LocationRequest.create()
            val builder = LocationSettingsRequest
                .Builder()
                .addLocationRequest(locationRequest)
            val task = LocationServices
                .getSettingsClient(it)
                .checkLocationSettings(builder.build())
                .addOnSuccessListener {
                    if (it.locationSettingsStates?.isLocationPresent == true) {
                        viewModel.getCurrentLocation()
                    }
                }
                .addOnFailureListener {
                    if (it is ResolvableApiException) {
                        try {
                            it.startResolutionForResult(requireActivity(), 999)
                        } catch (e : IntentSender.SendIntentException) {
                            e.printStackTrace()
                        }
                    }
                }

        }
    }
}

And our app looks like this:

Let's add a marker

The GoogleMap composable has a content parameter, so we can pass it more composables that it'll render on the surface. One such Composable is Marker. Here's how you can use it:

GoogleMap(
    modifier = Modifier.fillMaxSize(),
    cameraPositionState = cameraPositionState,
    uiSettings = mapUiSettings,
    properties = mapProperties
) {
    Marker(
        state = rememberMarkerState(position = state.location)
    )
}

This code emits a marker that's always centered on the map since it uses the map's camera position to derive its own position. The user can move the map to center the marker anywhere they'd like. You can also add attributes like title, snippets and even configure onClick behavior.

3. Places API

We use the Places API to provide autocomplete in textfields. Our intention is to achieve UI like this:

Here, the user can search for any place and select a result from the autocomplete. Upon selection, the map moves to the place as well.

Prerequisites:

To use the places API, first ensure it's enabled in the Google Cloud Console.

Afterward, add this library to your app-level build.gradle:

dependencies {
    implementation 'com.google.android.libraries.places:places:3.0.0'
}

That's it, we're now ready to use the Places API.

It's time to add a TextField to our composable so that the user can search for places. We can add one to the bottom of the map using a Box. See the code below:

Box(
    modifier = Modifier.fillMaxSize()
) {
    GoogleMap(
        modifier = Modifier.fillMaxSize(),
        cameraPositionState = cameraPositionState,
        uiSettings = mapUiSettings,
        properties = mapProperties,
        onMapClick = {
            scope.launch {
                cameraPositionState.animate(CameraUpdateFactory.newLatLng(it))
            }
        }
    )

    Surface(
        modifier = Modifier
            .align(Alignment.BottomCenter)
            .padding(8.dp)
            .fillMaxWidth(),
        color = Color.White,
        shape = RoundedCornerShape(8.dp)
    ) {
        Column(
            modifier = Modifier
                .padding(16.dp),
            horizontalAlignment = Alignment.CenterHorizontally
        ) {
            var text by remember { mutableStateOf("") }

            AnimatedVisibility(
                viewModel.locationAutofill.isNotEmpty(),
                modifier = Modifier
                    .fillMaxWidth()
                    .padding(8.dp)
            ) {
                LazyColumn(
                    verticalArrangement = Arrangement.spacedBy(8.dp)
                ) {
                    items(viewModel.locationAutofill) {
                        Row(
                            modifier = Modifier
                                .fillMaxWidth()
                                .padding(16.dp)
                                .clickWithRipple {
                                    text = it.address
                                    viewModel.locationAutofill.clear()
                                    viewModel.getCoordinates(it)
                                }
                        ) {
                            Text(it.address)
                        }
                    }
                }
                Spacer(Modifier.height(16.dp))
            }
            OutlinedTextField(
                value = text,
                onValueChange = {
                    text = it
                    viewModel.searchPlaces(it)
                },
                modifier = Modifier
                    .fillMaxWidth()
                    .padding(8.dp)
            )
        }
    }
}

We add a surface towards the bottom of the map, and use a column to position a textfield. There's a LazyColumn above that which appears when there are autofill results.

To handle places autocomplete results, we construct a data class. It contains a full address and a place ID, which we can use to obtain the lat-long for the place.

data class AutocompleteResult(
    val address: String,
    val placeId: String
)

Then, we use a SnapshotStateList, which is a state-aware list that'll store any autofill results that are made available via the search.

val locationAutofill = mutableStateListOf<AutocompleteResult>()

Now, whenever the user inputs a query, the searchPlaces method in the ViewModel is called:

private var job: Job? = null

fun searchPlaces(query: String) {
    job?.cancel()
    locationAutofill.clear()
    job = viewModelScope.launch {
        val request = FindAutocompletePredictionsRequest
            .builder()
            .setQuery(query)
            .build()
        placesClient
            .findAutocompletePredictions(request)
            .addOnSuccessListener { response ->
                locationAutofill += response.autocompletePredictions.map {
                    AutocompleteResult(
                        it.getFullText(null).toString(),
                        it.placeId
                    )
                }
            }
            .addOnFailureListener {
                it.printStackTrace()
                println(it.cause)
                println(it.message)
            }
    }
}

Notice the use of a CoroutineJob to handle debouncing. Since this method is called every time the user inputs a new character in the field, it can be called quite often, resulting in numerous expensive searches. To reduce the amount, we perform the whole operation inside a Coroutine, which is canceled whenever the method is called. This ensures that the method is called only for the last input character.

The API has several filters like country, location, and radius available which you can use to optimize your results.

When autocomplete results are available, the SnapshotStateList is updated with them, and the changes are immediately reflected in the UI. Now, to handle movement to the place on which the user has clicked, we define a new state object called currentLatLang.

var currentLatLong by mutableStateOf(LatLng(0.0, 0.0))

In our composable, we have a LaunchedEffect that's triggered everytime this state updates. It executes a camera movement:

LaunchedEffect(viewModel.currentLatLong) {
    cameraPositionState.animate(CameraUpdateFactory.newLatLng(viewModel.currentLatLong))
}

Now, to update this state object, we call the getCoordinates method. Remember, in our autocomplete results, we have a place ID, not coordinates. To get the lat-long for a place ID, we can use this code:

fun getCoordinates(result: AutocompleteResult) {
        val placeFields = listOf(Place.Field.LAT_LNG)
        val request = FetchPlaceRequest.newInstance(result.placeId, placeFields)
        placesClient.fetchPlace(request)
            .addOnSuccessListener {
                if (it != null) {
                    currentLatLong = it.place.latLng!!
                }
            }
            .addOnFailureListener {
                it.printStackTrace()
            }
    }

So, as soon as the user selects an autocomplete result in the UI, this method is called and executes an update in the map's camera position. We have successfully implemented the Places Autocomplete API and integrated it with our GoogleMap. yay!

4. Reverse Geocoding API

Now we need to handle the last use-case where the address in the textfield should update whenever the marker is moved. To do this, we use the process of Reverse Geocoding, where we convert lat-long coordinates to an address.

Handling this case is sufficiently trivial. First, we move the text state variable that's used by the TextField to the ViewModel. Once that's done, let's add a LaunchedEffect that'll tell us when the camera position has changed:

LaunchedEffect(cameraPositionState.isMoving) {
    if (!cameraPositionState.isMoving) {
        viewModel.getAddress(cameraPositionState.position.target)
    }
}

This effect is triggered everytime the camera settles down after moving. In our ViewModel, we simply use the Geocoding API to produce an address:

fun getAddress(latLng: LatLng) {
        viewModelScope.launch {
            val address = geoCoder.getFromLocation(latLng.latitude, latLng.longitude, 1)
            text = address?.get(0)?.getAddressLine(0).toString()
        }
    }

Since text is the state variable for the TextField, changing it results in the UI being updated as well. And with that, we've achieved all our goals.

End Result

Otherwise, see here

Final Words and Code

We have successfully built the screen as per the stated goal. There may be rough edges and bugs throughout the code, it's meant to be used as a sample of how to implement these features and integrate them with one another.

After a little bit of cleanup, the codes look like below:

I hope this article was helpful to you. Consider leaving a thumbs up if you liked it.

I had some free time on my hands this morning so I decided to work on an issue for my app Transactions. The issue was to add a recurring notification feature that would remind the users of the app to log their transactions for the day.

So, I did some research, and decided to use one of two ways:

1. Firebase Cloud Messaging (the easy way)

Firebase Cloud Messaging is a service that allows you to send notifications or data payload to your Android, iOS, or Web app. Sending background notifications (which only work when your app is in the background) is fairly easy. You can either use the firebase admin-sdk or the notification composer in the Firebase Console to send a notification with an optional payload (image, or key-value pairs) to a target token, a topic that the client device subscribed to, or to all the users of the app altogether. When the app is in the background, the notification appears in the system tray, and tapping it launches the app. It's extremely simple to set up a recurring notification as well, you just have to change the frequency.

For Transactions, I simply added the SDK dependencies to my build.gradle file, ran the app, exited the app (so that it's in the background, foreground notifications work very differently), and used the notification composer to send a test notification. Once that worked, I set up a recurring notification for 10 PM daily.

FCM also allows you to modify your notifications on the go, so that's an added advantage. But, I wanted some more features out of this:

• Users should be able to change the default reminder time of 10 PM to a time that they'd prefer

• Users should be able to opt out of this feature if they want to.

While the second feature could've been implemented by having the app register or deregister from a daily-reminder topic in the FCM, the first one would require either cloud functions or a suitable backend, and I wanted to keep this implementation on-device. So, I moved to the second option.

2. WorkManager with Periodic work requests

I'd taken a codelab earlier that taught how to set up notifications with WorkManager. Albeit it was focused on immediate one-time requests, I was aware that WorkManager had the facility of Deferred, Periodic work requests that could execute repeatedly at a fixed interval. I could add some initial delay to this to get the behavior that I wanted.

I started out by setting up a NotificationHelper Kotlin singleton object, whose purpose was to create the notification channel (required on Android 8+), the PendingIntent that'd launch the app when the notification was tapped, and the notification itself.

NotificationHandler

object NotificationHandler {
    private const val CHANNEL_ID = "transactions_reminder_channel"

    fun createReminderNotification(context: Context) {
        //  No back-stack when launched
        val intent = Intent(context, MainActivity::class.java).apply {
            flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TASK
        }
        val pendingIntent = PendingIntent.getActivity(context, 0, intent,
            if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) PendingIntent.FLAG_IMMUTABLE
            else PendingIntent.FLAG_UPDATE_CURRENT)

        createNotificationChannel(context) // This won't create a new channel everytime, safe to call

        val builder = NotificationCompat.Builder(context, CHANNEL_ID)
            .setSmallIcon(R.mipmap.ic_launcher_round)
            .setContentTitle("Remember to add your transactions!")
            .setContentText("Logging your transactions daily can help you manage your finances better.")
            .setPriority(NotificationCompat.PRIORITY_HIGH)
            .setContentIntent(pendingIntent) // For launching the MainActivity
            .setAutoCancel(true) // Remove notification when tapped
            .setVisibility(VISIBILITY_PUBLIC) // Show on lock screen

        with(NotificationManagerCompat.from(context)) {
            notify(1, builder.build())
        }
    }

    /**
     * Required on Android O+
     */
    private fun createNotificationChannel(context: Context) {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            val name = "Daily Reminders"
            val descriptionText = "This channel sends daily reminders to add your transactions"
            val importance = NotificationManager.IMPORTANCE_HIGH
            val channel = NotificationChannel(CHANNEL_ID, name, importance).apply {
                description = descriptionText
            }
            // Register the channel with the system
            val notificationManager: NotificationManager =
                context.getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager
            notificationManager.createNotificationChannel(channel)
        }
    }
}

I'd planned for the createReminderNotification method to be called from the Worker when it was invoked. So, I started writing the implementation for the WorkManager. Before we look at the code, this is what WorkManager is, according to the AndroidX team:

WorkManager is the recommended solution for persistent work. Work is persistent when it remains scheduled through app restarts and system reboots. Because most background processing is best accomplished through persistent work, WorkManager is the primary recommended API for background processing.

WorkManager abstracts away the myriads of background processing APIs that Android has, including FirebaseJobDispatcher, GcmNetworkManager, and Job Scheduler. It provides one single surface, which then delegates work to these APIs depending on the context and the API level. These are the type of Work requests that WorkManager supports:

Its features cannot be described in a single article, so I hope the code and the comments will be able to convey the meaning of what's happening. To start with WorkManager, we add this dependency to our build.gradle (for Kotlin):

implementation "androidx.work:work-runtime-ktx:2.7.1"

ReminderNotificationWorker

These are requests that run at a fixed interval of TimeUnit, such as Days, Hours, Minutes, etc. One important thing to note here is that WorkManager doesn't guarantee that a Work will be executed at the set time. It may be delayed due to battery optimizations and such, but it does guarantee that the Work will be executed, sooner or later. I started out by extending the Worker class to create a new Worker whose doWork() method is executed by the WorkManager when it's fired.

class ReminderNotificationWorker(private val appContext: Context, workerParameters: WorkerParameters) : Worker(appContext, workerParameters) {
    override fun doWork(): Result {
        NotificationHandler.createReminderNotification(appContext)
        return Result.success()
    }
}

Whenever the ReminderNotificationWorker is executed, it creates a new reminder notification. I didn't include any error handling here, which I plan on adding some time later.

After that, I defined a static, or as Kotlin likes to call it, companion object method, called schedule, which takes in a Context, and the time at which the notification should be generated daily. This method also handles some cases like when the user selects a time that's before the current time, it delays the first firing until the next day. That may sound easy, but it was surprisingly complex to implement manually, and I resorted to the Calendar class in the end.

companion object {

        /**
         * @param hourOfDay the hour at which daily reminder notification should appear [0-23]
         * @param minute the minute at which daily reminder notification should appear [0-59]
         */
        fun schedule(appContext: Context, hourOfDay: Int, minute: Int) {
            log("Reminder scheduling request received for $hourOfDay:$minute")
            val now = Calendar.getInstance()
            val target = Calendar.getInstance().apply {
                set(Calendar.HOUR_OF_DAY, hourOfDay)
                set(Calendar.MINUTE, minute)
            }

            if (target.before(now)) {
                target.add(Calendar.DAY_OF_YEAR, 1)
            }

            log("Scheduling reminder notification for ${target.timeInMillis - System.currentTimeMillis()} ms from now")

            val notificationRequest = PeriodicWorkRequestBuilder<ReminderNotificationWorker>(24, TimeUnit.HOURS)
                .addTag(TAG_REMINDER_WORKER)
                .setInitialDelay(target.timeInMillis - System.currentTimeMillis(), TimeUnit.MILLISECONDS).build()
            WorkManager.getInstance(appContext)
                .enqueueUniquePeriodicWork(
                "reminder_notification_work",
                ExistingPeriodicWorkPolicy.REPLACE,
                notificationRequest
            )
        }
    }

We use UniquePeriodicWork to ensure that there's ever only one instance of our ReminderNotificationWorker in existence since I didn't want to annoy the user with improper notifications. The tag is used later to identify and cancel all the Work requests should the user choose to opt out. I realized I'd need to handle the user preferences at this point, so I wrote a SharedPreferences helper class that'd help us interact with the SharedPreferences key-value store that Android provides.

PreferenceStore

class PreferenceStore(context: Context) {
    private val sharedPref: SharedPreferences = context.getSharedPreferences("transactions_shared_pref", Context.MODE_PRIVATE)

    /**
     * @return the hour of the day in which the reminder should be shown, default is 22, if canceled -1
     * @return the minute at which the reminder should be shown, default is 0, if canceled -1
     */
    fun getReminderTime(): Pair<Int, Int> {
        return Pair(
            sharedPref.getInt(SHARED_PREF_REMINDER_HOUR, 22),
            sharedPref.getInt(SHARED_PREF_REMINDER_MINUTE, 0)
        )
    }

    fun setReminderTime(hour: Int, minute: Int) {
        sharedPref.edit {
            putInt(SHARED_PREF_REMINDER_HOUR, hour)
            putInt(SHARED_PREF_REMINDER_MINUTE, minute)
        }
    }

    fun cancelReminder() {
        sharedPref.edit {
            putInt(SHARED_PREF_REMINDER_HOUR, -1)
            putInt(SHARED_PREF_REMINDER_MINUTE, -1)
        }
    }

    fun isDefaultReminderSet() = sharedPref.getBoolean("is_default_reminder_set", false)

    fun saveDefaultReminderIsSet() {
        sharedPref.edit { putBoolean("is_default_reminder_set", true) }
    }
}

When the app is launched for the first time, we set the default reminder at 10 PM, which is then customizable by the user. I probably could have removed some redundant methods at the bottom, but couldn't find a feasible solution. Now, let's move to the ViewModel.

MainViewModel

class MainViewModel(application: Application) : AndroidViewModel(application) {

    private val app = application
    private val prefStore = PreferenceStore(application)

    fun scheduleReminderNotification(hourOfDay: Int, minute: Int) {
        prefStore.setReminderTime(hourOfDay, minute)
        ReminderNotificationWorker.schedule(app, hourOfDay, minute)
    }

    fun getReminderTime() = prefStore.getReminderTime()

    fun cancelReminderNotification() {
        log("Cancelling reminder notification")
        prefStore.cancelReminder()
        WorkManager.getInstance(app).cancelAllWorkByTag(TAG_REMINDER_WORKER)
    }

    /**
     * This sets the default time at the first launch of the app
     */
    private fun checkAndSetDefaultReminder() {
        if (!prefStore.isDefaultReminderSet()) {
            scheduleReminderNotification(DEFAULT_REMINDER_HOUR, DEFAULT_REMINDER_MINUTE)
            prefStore.saveDefaultReminderIsSet()
        }
    }

We extend the AndroidViewModel class, since the application instance, or rather the Context, is needed for initializing the database instance and the shared preferences store, as well as the WorkManager. I plan on adding Dependency Injection using Hilt to the app soon, which would eliminate the need for this. In our ViewModel, the checkAndSetDefaultReminder method is called every time the ViewModel is initialized. This is alright for now (or is it? :p) since we use only a single ViewModel shared across fragments because of Transactions being a relatively small app, but it'll soon be migrated to a more appropriate place like the Application class. The intent of the other methods should be clear enough by the names. Now, let's look at the BottomSheetDialogFragment that allows the user to configure notifications:

NotificationsBottomSheet

class NotificationsBottomSheet : BottomSheetDialogFragment() {
    private lateinit var binding: FragmentNotificationsBottomSheetBinding
    private val viewModel by viewModels<MainViewModel>()

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View? {
        binding = FragmentNotificationsBottomSheetBinding.inflate(inflater, container, false)
        return binding.root
    }

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)

        setInitial()

        binding.checkboxReminder.setOnCheckedChangeListener { buttonView, isChecked ->
            if (isChecked) {
                // Was previously removed by user, now user wants to re-enable.
                viewModel.scheduleReminderNotification(DEFAULT_REMINDER_HOUR, DEFAULT_REMINDER_MINUTE)
                binding.textViewReminderTime.isEnabled = true
                binding.textViewReminderTime.text = get12HourTime(DEFAULT_REMINDER_HOUR, DEFAULT_REMINDER_MINUTE)
            } else {
                viewModel.cancelReminderNotification()
                binding.textViewReminderTime.isEnabled = false
                binding.textViewReminderTime.text = "Not set"
            }
        }

        binding.textViewReminderTime.setOnClickListener {
            val time = viewModel.getReminderTime()

            val picker = MaterialTimePicker.Builder()
                .setTimeFormat(TimeFormat.CLOCK_12H)
                .setHour(time.first)
                .setMinute(time.second)
                .setTitleText("Select Reminder Time")
                .build()
            picker.show(parentFragmentManager, "notification-time-picker")

            picker.addOnPositiveButtonClickListener {
                val hour = picker.hour
                val minute = picker.minute
                viewModel.scheduleReminderNotification(hour, minute)
                val newTime = viewModel.getReminderTime()
                binding.textViewReminderTime.text = get12HourTime(newTime.first, newTime.second)
            }
        }
    }

    private fun setInitial() {
        val setTime = viewModel.getReminderTime()
        if (setTime.first == -1 || setTime.second == -1 ) {
            binding.checkboxReminder.isChecked = false
            binding.textViewReminderTime.isEnabled = false
            binding.textViewReminderTime.text = "Not set"
        } else {
            binding.checkboxReminder.isChecked = true
            binding.textViewReminderTime.isEnabled = true
            binding.textViewReminderTime.text = get12HourTime(setTime.first, setTime.second)
        }
    }
}

Initial values are fetched and set from the Preferences. The user can enable or disable the notifications by clicking on the checkbox. Time can be configured by tapping the text and defaulting to the value of 10 PM. We use the Material TimePicker widget to allow the user to select time easily, and it's also super simple to implement, compared to a separate TimerPickerDialog, which is used elsewhere in the app.

At a fixed interval of every 24 hours, the ReminderNotificationWorker is triggered by the WorkManager. The worker, in turn, creates a notification (this being the Work, tapping which takes the user directly to the app. This allows us to implement the features required above, while also keeping the implementation on the device, by leveraging the awesome AndroidX library that is WorkManager.

Transactions is available on the Play Store, and the full source code is available on GitHub. Leave a thumbs up if you liked the article. Cheers!

Let's get some context about Transactions to understand the problem better

Transactions use Room ORM under the hood. It's an abstraction layer over the SQLite library and allows you to simplify your database operations on Android

In a typical addition flow in Transactions, the user adds a transaction through the add transaction fragment, which gets parsed and inserted into the database. Then, Room emits a new list of transactions through a Kotlin Flow, which is an observable data type that Room supports natively. So, a typical get query looks like this:

@Query("SELECT * FROM `transactions`")
fun getAllTransactions(): Flow<List<Transaction>>

This method emits a new list whenever there's a change in the database. This flow is collected in the ViewModel, which then dispatches the list to the UI controller, that is the fragment. The fragment then submits this list to a DiffUtil based RecyclerView adapter, which efficiently updates the list with the differences along with providing the default animations.

The challenge: Incremental Sorting and Filtering

I wanted to implement incremental sorting and filtering in the app. To understand it better, let's say that I only want to see transactions that are labeled as income. On top of that, I only want to see those transactions which carry an amount greater than 500, and then sort those by time. This gives us the pseudo-query

Show me all transactions that are income and which carry an amount greater than 500 ordered by time

Now, the problem with this incremental filtering approach is that each filter needs to stack on top of the other. How do we implement this?

Solution 1: Do filtering on Kotlin lists

We of course have the option to get a list of all transactions from the database, and then repeatedly apply the .filter { } or the .sort() method on the resultant lists, but that doesn't seem too efficient. After all, that's what SQL is for. Not using it would be a mistake in this scenario, so I moved to the other choice.

Solution 2: Write custom DAO methods for every combination

The problem with this approach is that this is extremely repetitive, error-prone and the number of queries that are needed to be saved grows exponentially with every new parameter, which is not scalable at all.

Solution 3: Find a way to feed the list back a custom SQL view, and then apply filtering on the view incrementally.

The problem with this approach is that you have to write a lot of SQLite code bypassing Room, which is incredibly complex for a small project like this.

My Solution: Build Query in Runtime

I found that SQL provides an annotation that allows you to execute a custom raw SQL query and observer the resultant. The syntax looks like this:

@RawQuery(observedEntities = [Transaction::class])
fun customTransactionQuery(query: SupportSQLiteQuery): Flow<List<Transaction>>

So, now our DAO method takes in a custom query, runs it, and provides us an observable Kotlin Flow (or LiveData) which will update every time there's a change in the queried view. So, now the challenge was to generate the SQL query dynamically based on the filtering parameters that the user has selected at any given instant. To do that, I wrote a QueryBuilder class.

The QueryBuilder

So, I first listed out all the possible choices for any particular filter through the use of enums. For example, a Sort Choices enum looked like this:

enum class SortByChoices(val readableString: String) {
    AMOUNT_HIGHEST_FIRST("Highest Amount First"),
    AMOUNT_LOWEST_FIRST("Lowest Amount First"),
    TIME_EARLIEST_FIRST("Earliest Transaction First"),
    TIME_NEWEST_FIRST("Latest Transaction First"),
    UNSPECIFIED("Default Order")
}

The enum takes in a constructor, which is the readable string that can be displayed to a user. To use the QueryBuilder, you have to create an object and call its builder methods that set the value of these parameters. A typical set method looks like this:

fun setFilterType(filterTypeChoice: FilterByTypeChoices): QueryBuilder {
        if (filterTypeChoice != FilterByTypeChoices.UNSPECIFIED) {
            this.filterTypeChoice = filterTypeChoice
            this.filterEnabled = true
        }
        return this
    }

So, you specified the values of these choices, and then called the build() method on the QueryBuilder instance. Now, the build method walks over each of the parameter values and generates the SQL query piece by piece. The query generator for Type Filter is shown below:

// Type filter
        if (filterTypeChoice != FilterByTypeChoices.UNSPECIFIED) {
            if (previousFilterExists) query.append(" AND")
            query.append(" isExpense")
            val typeIsExpense = when (filterTypeChoice) {
                FilterByTypeChoices.EXPENSE -> "= 1"
                FilterByTypeChoices.INCOME -> "= 0"
                else -> ""
            }
            query.append(" $typeIsExpense")
            previousFilterExists = true
        }

In the end, the builder returns a SimpleSQLiteQuery object, like this:

return SimpleSQLiteQuery(query.toString())

This query object is then received by the caller and sent to the DAO for execution. Since the DAO gives us an observable, any updates to the queried dataset are updated in the UI automatically.

Once I was done writing the Builder, I wrote a bunch of plain old JUnit4 tests to check if the generated queries were the expected ones. A sample test:

    @Test
    fun query_filter_amount_greater_and_type_income_and_medium_digital_and_sort_by_time_oldest() {
        val query = QueryBuilder()
            .setFilterAmount(FilterByAmountChoices.GREATER_THAN, 100)
            .setFilterType(FilterByTypeChoices.INCOME)
            .setFilterMedium(FilterByMediumChoices.DIGITAL)
            .setSortingChoice(SortByChoices.TIME_EARLIEST_FIRST)
            .build()
        assertEquals("SELECT * FROM `transaction` WHERE amount >= 100 AND isExpense = 0 AND isDigital = 1 ORDER BY timestamp ASC", query.sql)
    }

Now, in the UI, whenever any of the filter parameters are changed, a new Query is built and executed:

/**
     * Generates an SQL query from the current configuration and executes it through Room.
     * An observable flow is returned, updates whenever there's a change in the database
     */
    private fun executeConfig() {
        val query = QueryBuilder()
            .setFilterAmount(QueryConfig.filterAmountChoice, QueryConfig.filterAmountValue)
            .setFilterType(QueryConfig.filterTypeChoice)
            .setFilterMedium(QueryConfig.filterMediumChoice)
            .setSortingChoice(QueryConfig.sortChoice)
            .build()
        viewModelScope.launch {
            db.transactionDao().customTransactionQuery(query).collect {
                transactions.value = it
            }
        }
    }

This allows us to efficiently generate our SQL queries dynamically and handle any number of filter parameters in linear code complexity.

Transactions has a simple philosophy inspired by Alex Chiou and Rahul Pandey: In a side-project, build only a few features, but build them well. The entire source code is available on GitHub: https://github.com/sanskar10100/Transactions

This is what the app looks like now:

Transactions is available on the Play Store as well. Install it from: https://play.google.com/store/apps/details?id=dev.sanskar.transactions (At the time of writing the incremental filtering update is still in beta, so it may require some time to show up on your device).

After you've received the confirmation for the student developer pack, head over to https://get.tech and find a domain you like. During checkout, just authorize with your GitHub account to get the license for free for a year.

Setting up the custom domain

After you get the domain, you'll be redirected to the console. It'll look something like this:

Open up the list of orders, and navigate to your recently availed domain name. It'll look something like this:

Now, to connect your GitHub pages website to this domain, you need to head over to this document: https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site

The document is a little complex, so in short, you'd want to follow these steps to link your domain name to the GitHub Pages server:

• Find the DNS Console
• Add a CNAME record. Put www in the name field, and your GitHub pages domain in the value field. Leave the TTL at default. After configuring, your CNAME should look like this:
• Add a total of 4 A records from the same panel. In all A records, put the hostname as @ or www. Leave the TTL at default. In the destination IPv4 addresses, put the following 4 IP addresses sequentially (one IP address in one record):

  185.199.108.153
  185.199.109.153
  185.199.110.153
  185.199.111.153
  

Each of your A records should look like this: When you're done, you should have this list: Note: These IP addresses may have changed. Consult this page for the latest addresses.

• It may take some time (up to 72 hours) for the new DNS to propagate. Head over to your GitHub page settings, and add your custom domain. If GitHub can verify your domain, you're all set up, and can now use your custom domain. If not, then you're gonna have to come back later.

To Obtain the free SSL certificate from CloudFare

1. Sign up for a Cloudflare account.
2. Register your custom domain, as below:
3. Now you will have to use CloudFare's nameserver for your domain. Cloudflare will provide you with 2 auto-generated nameservers for your domain. Copy them.
4. Head over to the domain management console, and open up the nameservers option:
5. Update the first two nameservers with the ones provided by CloudFare, and delete the rest:
6. After you've updated the nameserver, it may take up to 4 hours for you to receive a mail from CloudFare about successful website addition. Once that's done, open up the Cloudflare console once more, and head over to the SSL section.
7. Enable Full SSL/TLS
8. Enforce HTTPS from GitHub Pages settings:

That's it! You just connected your free for 1 year .tech custom domain to your GitHub pages site and got a free universal SSL certificate!

Users can even drag the shortcuts outside to your home screen as demoed below:

This has been available since Android Nougat (Android 7.1). Even if your app has a lower minSdkVersion (Around Lollipop or even lower), you can set an attribute tools:targetApi="n_mr1" in the shortcuts.xml that we'll define soon.

Static Shortcuts

In this article, we're gonna look at static shortcuts only, which are basically intents that open up different activities in your app. I'll also offer the solution that I used for my fragment-centric app. There are also dynamic shortcuts that apps like WhatsApp and Telegram use which change with time - they won't be covered here. For more information, consider checking the official docs: App Shortcuts

How to add a static shortcut?

Create an Android Resource Directory under res and name it xml

Add a new XML Resource File under xml with the name shortcuts

A newly generated shortcuts.xml appears. Replace it with this XML:

<shortcuts xmlns:tools="http://schemas.android.com/tools"
    xmlns:android="http://schemas.android.com/apk/res/android">
    <shortcut
        android:shortcutId="your_id_here"
        android:enabled="true"
        android:icon="your_icon_drawable_here"
        android:shortcutShortLabel="your_string_resource_label_here"
        android:shortcutLongLabel="your_string_resource_long_label_here"
        tools:targetApi="n_mr1">
        <intent
            android:action="some_action_name"
            android:targetPackage="your.package.name" 
            android:targetClass="activity.package.name" />
    </shortcut>
    <!-- More Shortcut Tags -->
</shortcuts>

Here is a screenshot of mine:

Add your shortcut meta-data under the host or target activity tag in your AndroidManifests.xml like this:

Optional: If you're using fragment centric architecture

If you're using a single activity with multiple fragments or similar architecture in your app, just match the intent action attribute inside your host activity with the one you specified in shortcuts.xml, like this:

when (intent.action) {
           // If intent action matches, navigate to that fragment.
            "shortcut_add_transaction" -> navController.navigate(HomeFragmentDirections.actionHomeFragmentToAddTransactionFragment())
}

And Ta-Da! You just added an app shortcut! Now users can easily access top destinations in your app, right from the launcher.