DEV Community: Luis Mierez

Infinite LazyColumn in Jetpack Compose

Luis Mierez — Wed, 09 Jun 2021 05:45:04 +0000

Displaying a list of content is one of the most common things that we are required to add to our apps and in my experience the lists are more often than not required to have some sort of pagination. This is a fairly common pattern where we only fetch the items needed at the time. The way we handle that is to show a list with a number of items (say 20) and as the user reaches the end of those first 20 items, we fetch the next 20 items.

In our app we have an implementation of RecyclerView.OnScrollListener where we check if we are close to the end of the list and trigger a loadMore callback. Now that we are moving to compose I wanted to find a way to do the same pattern and came up with this:

Works similar to our old RecyclerView implementation but now in compose! Let me explain what is going on.

First the parameters:

listState: LazyListState as the name implies is the state of the list, which you can get by calling val listState = rememberLazyListState(). This state has all the info that we need to observe to create our infinite loading list. It can also be used to control the list, but we aren't using that in here. REMEMBER: This same listState needs to be passed to the LazyColumn

buffer: Int = 2 This tells our InfiniteListHandler how many items BEFORE we get to the end of the list to call the onLoadMore function. This is technically not needed, but it makes the infinite loading more seamless, since we can control when to fetch new data and we don't need to show a loading indicator at the end of the list.

onLoadMore: () -> Unit This function will get called once the user reaches the load more threshold.

Now to our logic. It's fairly straightforward: we want to call the onLoadMore function when the last visible item on the list is within the threshold of our total items in the list minus our buffer. For example:
If we have a list with 20 items, we have a buffer of 4, and with our test device we can see 6 items at a time. As the user scrolls the last visible item index will keep getting higher and higher until it reaches 16, which is our threshold of the last item index (20) minus our buffer (4). At which point the onLoadMore will get called and we can fetch and load the next 20 items. Then our list will have 40 items and we will fetch more items once the last visible item index reaches 36, totalItems(40) - buffer(4). And so on until we have no more items to show.

We can write this in code like:

val loadMore = remember {
        derivedStateOf {
            val layoutInfo = listState.layoutInfo
            val totalItemsNumber = layoutInfo.totalItemsCount
            val lastVisibleItemIndex = (layoutInfo.visibleItemsInfo.lastOrNull()?.index ?: 0) + 1

            lastVisibleItemIndex > (totalItemsNumber - buffer)
        }
    }

We use a remembered derived state to minimize unnecessary compositions. See derivedStateOf for more info.

But inside we use the listState to get the totalItemsNumber and the lastVisibleItemIndex which we add 1 to, to make it match the total count. We then check that lastVisibleItemIndex is greater than our totalItemsNumber minus our buffer.

There is one last thing that we need to get this working, and that is that we need to observe changes to the loadMore State. We do that like so:

LaunchedEffect(loadMore) {
        snapshotFlow { loadMore.value }
            .distinctUntilChanged()
            .collect {
                onLoadMore()
            }
    }

We now have a fully working InfiniteListHandler that will notify you whenever you are at the end of the list, or close to it depending on your buffer. And to use it you can do something like:

Happy Composing!

Simple Android Studio Live Template for Serialized Name

Luis Mierez — Tue, 18 May 2021 23:11:21 +0000

Most times when building an application we have to talk to some back end service we do not control. That back end service might use a different naming scheme than what we use in Kotlin/Java. In comes the @SerializedName from the Gson library (or @Json from Moshi) to the rescue. It allows us to tell our deserializer where to look for the fields. However that means that we have to write some extra code in our objects since we have to add that @SerializedName annotation to each field that has a different naming scheme.

Let's look at the poke api as an example. The Poke Api has a endpoint to get info on berries. That object looks like:

{
  "id": 1,
  "name": "cheri",
  "growth_time": 3,
  "max_harvest": 5,
  "natural_gift_power": 60,
  "size": 20,
  "smoothness": 25,
  "soil_dryness": 15,
  "firmness": {
    "name": "soft",
    "url": "https://pokeapi.co/api/v2/berry-firmness/2/"
  },
  "flavors": [
    {
      "potency": 10,
      "flavor": {
        "name": "spicy",
        "url": "https://pokeapi.co/api/v2/berry-flavor/1/"
      }
    }
  ],
  "item": {
    "name": "cheri-berry",
    "url": "https://pokeapi.co/api/v2/item/126/"
  },
  "natural_gift_type": {
    "name": "fire",
    "url": "https://pokeapi.co/api/v2/type/10/"
  }
}

Which as you can see has a couple of fields that use underscores. When making that object in our code we'll have to add a lot of the SerializedName annotation. Since I'm lazy and didn't want to have to copy that a bunch of time I created a Live Template that does most of the heavy lifting.

To create a Live Template you need to go to Preferences -> Editor -> Live Templates. In there you'll see all the Live Templates you currently have in the app. For our case, we want to add one for kotlin so go to the kotlin group, hit the + button and then hit Live Template.

Once you create the Live Template now it's time to fill it with what we want it to do. We should give it a good abbreviation since that is how we'll call our Live Template from our code.

I like the abbreviation sername for SerializedName so we'll go with that. You can see in the image above that it's giving you a warning that there is no applicable context so hit Define and let's select the drop down for kotlin, and select class and object declaration. This context is where we can call this live template from, in our case we only want to call it from a kotlin class when declaring an object.

Now to the cool part of Live Templates. In the Template Text input box, we'll write this

@com.google.gson.annotations.SerializedName("$PARAM$") val $PARAM1$: $END$

Let's run through this line to explain it.
Live Templates are smart enough to auto import your dependencies if they aren't there already, but for that to work we need to give it the full path with the @ at the front.
The $PARAM$ means that it is inputted by the user. Same with $PARAM1$ .
$END$ is a special case which tells Live Template where to put the cursor once you are done.

Once we write that, hit the Edit Variables button to add some more settings.

The $PARAM1$ field will read from the $PARAM$ since we want to copy the name from the back end service. However, we want to change the text to be camel case.

Once we add that we are done! To see it in action, create a new class and when adding an object that needs the @SerializedName annotation, type sername and you'll see how it automatically adds everything. Happy coding!

Find your Stack

Luis Mierez — Sun, 24 Jan 2021 05:13:52 +0000

We recently had to debug some old (very very old) code because of some new issues arising from it. One of the things we were investigating was whether the code was starting activities in the wrong order due to a race condition. So we had to debug our activity stack. We quickly realized that there was no easy way to debug that from android studio. Then we turned to the trusty adb which this command:

adb shell dumpsys activity activities

The dumpsys activity activities command gives you a ton of info about the current activities. But we only care about the activities related to our app, so we pipe the output to grep package.name.
This still gives us a little too much into if you just want to look at the activity stack, so we pipe output again to grep Hist to only get the activity stack. The full command ends up looking something like this:

adb shell dumpsys activity activities | grep package.name | grep Hist

This works well if you want a snapshot of the current activity stack, but doesn't really help if you want to continuously log the activity stack. This is where we turned to the watch command. This command is not on mac by default so you have to install it through brew like brew install watch. The watch command runs a command at whatever interval you want.
With watch installed your full command turns into something like:

watch -n 0.1 "adb shell dumpsys activity activities | grep package.name | grep Hist"

The -n flag sets the time interval at which we run our adb command. So this means run the command every .1 secs.
This ended up working perfectly and we were able to continuously debug our activity stack and figure out if there was some problem there. Turns out the activity stack was fine but this helped us rule out what and pointed us in the right direction to eventually fix the issue.