Learn how to make a simple jump-on-click animation in Jetpack Compose that can be applied to any Composable. We are going to write a modifier and a state class that encapsulate the logic so applying it will be as easy as:

Text(
    text = "🍿",
    fontSize = 96.sp,
    modifier = modifier
        .jumpOnClick(rememberJumpAnimationState(onClick = onClick))
)

As always with Compose there are many ways to achieve the same end result, this is my current version, let’s get after it!

The Modifier

Not a lot of magic in here. We make the Composable clickable using the interactionSource that is provided by the state. The reason for not setting onClick in here is that we want the click to be registered when the animation is coming to an end instead of when the click happens. Why? Well if you react to the click immediately and navigate a way you will miss most of the animation 😉

fun Modifier.jumpOnClick(
    state: JumpAnimationState
) = this then Modifier
    .clickable(
        interactionSource = state.interactionSource,
        indication = null,
        onClick = { /* this is handled in the state */ },
    )
    .graphicsLayer {
        transformOrigin = TransformOrigin(
            pivotFractionX = 0.5f,
            pivotFractionY = 1.0f,
        )
        scaleY = state.scale.value
        translationY = state.translation.value * size.height
    }

In graphicsLayer { ... } we apply the scale and translation coming from the state, scale directly and translation based on the current height. The only noteworthy thing in this block is that we change transformOrigin to be the in the bottom-center of the Composable. This means that when you apply the scale, the top will be the part moving while the bottom remains in place, mimicking the Composable standing on the ground.

Creating the state

I’ve wrapped creating, remembering and hooking up the state in a function to make it reusable. JumpAnimationState is responsible for actually executing the animation and in this step we create the state and forward InteractionSource events to it so it can react on user interactions.

@Composable
fun rememberJumpAnimationState(
    onClick: () -> Unit,
    scope: CoroutineScope = rememberCoroutineScope(),
    interactionSource: MutableInteractionSource = remember { MutableInteractionSource() },
): JumpAnimationState {
    val state = remember(scope, interactionSource) {
        JumpAnimationState(
            scope = scope,
            interactionSource = interactionSource,
        )
    }

    val onClickLambda by rememberUpdatedState(onClick)
    LaunchedEffect(interactionSource) {
        interactionSource.interactions.collect { interaction ->
            when (interaction) {
                is PressInteraction.Press -> state.onPress()
                is PressInteraction.Release -> state.onRelease(onClickLambda)
                is PressInteraction.Cancel -> state.onCancel()
            }
        }
    }

    return state
}

Animations using coroutines

It’s time to make the animations but first a quick refresher on how to define animations with coroutines:

• Animations invoked in the same CoroutineScope run in sequence

coroutineScope { 
    // these run in sequence
    scale.animateTo(...)
    translation.animateTo(...)
}

• Animations launched in the same CoroutineScope run in parallel

coroutineScope {
    // these run in parallel
    launch { scale.animateTo(...) }
    launch { translation.animateTo(...) }
}

• The above can be mixed and matched to orchestrate more complex animations

coroutineScope {
    // this run first and when done...
    scale.animateTo(...)

    // ...both outer launch blocks run in parallel
    launch {
        // these run in sequence
        scale.animateTo(...)
        scale.animateTo(...)
    }
    launch {
       // these run in parallel
       launch { translation.animateTo(...) }
       launch { translation.animateTo(...) }
    }
}

Remember that a CoroutineScope and launch block is not left until all of it’s child jobs have completed, which means that when running animations in parallel the longest one will dictate how long it takes for that block to finish.

Performing a jump

Here is the full code for the state and the animations. Below the code block there is a more detailed explanation of each function.

@Stable
class JumpAnimationState(
    val interactionSource: MutableInteractionSource,
    val scope: CoroutineScope,
) {
    private var animation: Job? = null

    val scale = Animatable(initialValue = 1f)
    val translation = Animatable(initialValue = 0f)

    fun onPress() = launchAnimation {
        scale.snapTo(defaultScale)
        translation.snapTo(defaultTranslation)

        scale.animateTo(pressedScale, defaultSpring)
    }

    fun onRelease(invokeOnCompletion: () -> Unit) = launchAnimation {
        // ensure it's fully compressed if the user just quickly tapped
        scale.animateTo(pressedScale, defaultSpring)

        launch {
            // restore the scale
            scale.animateTo(defaultScale, releaseScaleSpring)
        }

        launch {
            // up like a sun...
            translation.animateTo(launchTranslation, launchTranslationSpring)

            // ...down like a pancake
            var isSquishing = false
            translation.animateTo(defaultTranslation, returnTranslationSpring) {
                val hitTheGround = value >= defaultTranslation
                if (hitTheGround && !isSquishing) {
                    isSquishing = true
                    invokeOnCompletion()
                    // Add a small squish on impact
                    launch {
                        scale.animateTo(squishScale, defaultSpring)
                        scale.animateTo(defaultScale, defaultSpring)
                    }
                }
            }
        }
    }

    fun onCancel() = launchAnimation {
        scale.snapTo(defaultScale)
        translation.snapTo(defaultTranslation)
    }

    private fun launchAnimation(block: suspend CoroutineScope.() -> Unit) {
        animation?.cancel()
        animation = scope.launch(block = block)
    }
}

private const val defaultScale = 1f
private const val pressedScale = 0.6f
private const val squishScale = 0.88f
private const val defaultTranslation = 0f
private const val launchTranslation = -0.8f
private val defaultSpring = spring<Float>()
private val releaseScaleSpring = spring<Float>(
    stiffness = Spring.StiffnessMedium,
    dampingRatio = 0.55f
)
private val launchTranslationSpring = spring<Float>(
    dampingRatio = Spring.DampingRatioNoBouncy,
    stiffness = Spring.StiffnessMediumLow,
)
private val returnTranslationSpring = spring<Float>(
    dampingRatio = 0.65f,
    stiffness = 140f,
)

launchAnimation

All the animations are running on the CoroutineScope that is provided to the state. If we get a new event while one animation is already running (like with fast taps) then we want to cancel the current animation and process the new event.

onPress

This function has two responsibilities, reset scale and translation to their default values and then animate the scale to the pressed state.

onRelease

First makes sure that the scale has actually reached its pressed state, for a quick tap we still want it to be fully pressed before launch. Second we launch two animations in parallel, one responsible for restoring the scale to its default value and one that update the translation to go up in the air and fall down. On the way down we add a callback that is updated on each animation frame to check when the translation is back on the ground and add a small squish at the end. Why not just run the squish after the translation? As the translation is based on a spring it actually overshoots and bounce a tiny bit at the bottom and we want to perform the squish the first time we hit the ground, not when the spring has come to a rest.

onCancel

The interaction was for some reason cancelled, restore default scale and translation.

Constants and Springs

These values must be backed up by all kinds of maths and science right? Sure, the science of “trial and error until it looks good”. Feel free to tweak these to fit your design and use case.

Wrapping up

All that remains now is to draw up some cute emojis, apply the modifier and tap away:

Text(
    text = "🍿",
    fontSize = 96.sp,
    modifier = modifier
        .jumpOnClick(rememberJumpAnimationState(onClick = onClick))
)

That’s all there is to it, the code for this project can be found on Github:

GitHub - patrick-elmquist/Demo-ComposeJumpAnimation: Code for a future blog post

Have a good one 👋

Teaching a Composable to jump was originally published in Flat Pack Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you want to learn how to create your own custom “Slide to Unlock” slider in Jetpack Compose, then this is the right place to be. We will cover a good way to make a slider that can easily be customised and reused. In the IKEA app we use a component like this when the user is claiming a Family Reward, functioning both as a confirmation to claim the reward and a loading state when the network request is being made:

For the impatient developer 👨‍💻

Now if you’re the kind of developer (like myself) that just want to see a gif of the end result and go straight for the final code, here’s a link to the demo project over on Github

https://github.com/patrick-elmquist/Demo-SlideToUnlock

Let’s break it down

The component we’re building consists of three parts

• The track, the container and background
  – Transitions between two colors as the thumb moves
• The thumb, the button the user slide
  – Has an idle and loading state and snaps to either side of the track
• A hint, the text shown within the track
  – Fades out as the thumb moves

Lets start of with something small, like a…

Thumb 👍

The thumb itself is a rather simple component. Based on a parameter representing loading, it can be in one of two states: Normal or Loading.

Apart from that we only have to expose a Modifier to allow the parent to position it.

@Composable
fun Thumb(
    isLoading: Boolean,
    modifier: Modifier = Modifier,
) {
    Box(
        modifier = modifier
            .size(Thumb.Size)
            .background(color = Color.White, shape = CircleShape)
            .padding(8.dp),
    ) {
        if (isLoading) {
            CircularProgressIndicator(
                modifier = Modifier.padding(2.dp),
                color = Color.Black,
                strokeWidth = 2.dp
            )
        } else {
            Image(
                painter = painterResource(R.drawable.arrow_right),
                contentDescription = null,
            )
        }
    }
}

With that out of the way let’s add something for the thumb to move along.

Track 🛤️

The track functions as a container for the thumb and hint and is responsible for recognising the sliding gesture. As the thumb moves along the track the background color is interpolated from black to yellow.

enum class Anchor { Start, End }

@Composable
fun Track(
    swipeState: SwipeableState<Anchor>,
    swipeFraction: Float,
    enabled: Boolean,
    modifier: Modifier = Modifier,
    content: @Composable (BoxScope.() -> Unit),
) {
    val density = LocalDensity.current
    var fullWidth by remember { mutableStateOf(0) }

    val startOfTrackPx = 0f
    val endOfTrackPx = remember(fullWidth) {
        with(density) { 
            fullWidth - (2 * Track.HorizontalPadding + Thumb.Size).toPx()
        }
    }

    val snapThreshold = 0.8f
    val thresholds = { from: Anchor, _: Anchor ->
        if (from == Anchor.Start) {
            FractionalThreshold(snapThreshold)
        } else {
            FractionalThreshold(1f - snapThreshold)
        }
    }

    val backgroundColor by remember(swipeFraction) {
        derivedStateOf { calculateTrackColor(swipeFraction) }
    }

    Box(
        modifier = modifier
            .onSizeChanged { fullWidth = it.width }
            .height(56.dp)
            .fillMaxWidth()
            .swipeable(
                enabled = enabled,
                state = swipeState,
                orientation = Orientation.Horizontal,
                anchors = mapOf(
                    startOfTrackPx to Anchor.Start,
                    endOfTrackPx to Anchor.End,
                ),
                thresholds = thresholds,
                velocityThreshold = Track.VelocityThreshold,
            )
            .background(
                color = backgroundColor,
                shape = RoundedCornerShape(percent = 50),
            )
            .padding(
                PaddingValues(
                    horizontal = Track.HorizontalPadding,
                    vertical = 8.dp,
                )
            ),
        content = content,
    )
}

Background color

The color is calculated using linear interpolation based on the swipeFraction, a float in the range 0f-1f representing how far the thumb have travelled along the track.

val AlmostBlack = Color(0xFF111111)
val Yellow = Color(0xFFFFDB00)

fun calculateTrackColor(swipeFraction: Float): Color {
    val endOfColorChangeFraction = 0.4f
    val fraction = (swipeFraction / endOfColorChangeFraction).coerceIn(0f..1f)
    return lerp(AlmostBlack, Yellow, fraction)
}

In short this is a standard linear interpolation with the slight change that we want our interpolation to reach it’s end value faster. In this case we want the color to be fully active (yellow) when the thumb has reached 40% of the track, which is why we use endOfColorChangeFraction = 0.4f to adjust the input before running it through the color interpolation.

Snapping

We’ll be using the .swipable() modifier to have the component snap to the start or the end of the track. To get it up and running there are a couple of things that need to be defined:

Anchors
You need to define a kind of object to represent the snapping points together with pixel values describing what point of the track corresponds to which snapping point. In this example we define an enum class to represent the start and end anchors and then we use the full width of the track to calculate endOfTrackPx , accounting for any space used up by the thumb or padding.

enum class Anchor { Start, End }

val startOfTrackPx = 0f
val endOfTrackPx = remember(fullWidth) {
    with(density) { fullWidth - (2 * Track.HorizontalPadding + Thumb.Size).toPx() }
}

val anchors = mapOf(
    startOfTrackPx to Anchor.Start,
    endOfTrackPx to Anchor.End,
),

Thresholds
How much of the track must the user swipe before letting go for the component to snap in either of the states. This can just be an arbitrary value in the range[0,1] but it’s worth mentioning that it’s applied based on the point you are moving from. So in this example we want 0.8f to be the threshold when going from left to right and 0.2f when going from right to left

val snapThreshold = 0.8f
val thresholds = { from: Anchor, _: Anchor ->
    if (from == Anchor.Start) {
        FractionalThreshold(snapThreshold)
    } else {
        FractionalThreshold(1f - snapThreshold)
    }
}

Velocity threshold
Is a value that determines how easy or hard it should be to trigger the component with a small but quick fling. For this you can use a default value provided by SwipeableDefaults.VelocityThreshold , personally I’ve found that to be a bit to sensitive and have opted to take that value x10 but your milage may vary.

Hint 💬

The hint is just a Text with a function call to turn the swipeFraction into a faded text color.

@Composable
fun Hint(
    text: String,
    swipeFraction: Float,
    modifier: Modifier = Modifier,
) {
    val hintTextColor by remember(swipeFraction) {
        derivedStateOf { calculateHintTextColor(swipeFraction) }
    }

    Text(
        text = text,
        color = hintTextColor,
        style = MaterialTheme.typography.titleSmall,
        modifier = modifier
    )
}

fun calculateHintTextColor(swipeFraction: Float): Color {
    val endOfFadeFraction = 0.35f
    val fraction = (swipeFraction / endOfFadeFraction).coerceIn(0f..1f)
    return lerp(Color.White, Color.White.copy(alpha = 0f), fraction)
}

Why fade using text color and not Modifier.alpha()? Both work fine. I tend to change alpha with color instead of a Component/View out of old habit as it historically have been better for performance and it should still apply in Compose.

Just like with the track color we linearly interpolate the color and make it fully transparent when the thumb has reached 35% of the track.

Assembling the parts

@Composable
fun SlideToUnlock(
    isLoading: Boolean,
    onUnlockRequested: () -> Unit,
    modifier: Modifier = Modifier,
) {
    val hapticFeedback = LocalHapticFeedback.current
    val swipeState = rememberSwipeableState(
        initialValue = if (isLoading) Anchor.End else Anchor.Start,
        confirmStateChange = { anchor ->
            if (anchor == Anchor.End) {
                hapticFeedback.performHapticFeedback(HapticFeedbackType.LongPress)
                onUnlockRequested()
            }
            true
        }
    )

    val swipeFraction by remember {
        derivedStateOf { calculateSwipeFraction(swipeState.progress) }
    }

    LaunchedEffect(isLoading) {
        swipeState.animateTo(if (isLoading) Anchor.End else Anchor.Start)
    }

    Track(
        swipeState = swipeState,
        swipeFraction = swipeFraction,
        enabled = !isLoading,
        modifier = modifier,
    ) {
        Hint(
            text = "Swipe to unlock reward",
            swipeFraction = swipeFraction,
            modifier = Modifier
                .align(Alignment.Center)
                .padding(PaddingValues(horizontal = Thumb.Size + 8.dp)),
        )

        Thumb(
            isLoading = isLoading,
            modifier = Modifier.offset {
                IntOffset(swipeState.offset.value.roundToInt(), 0)
            },
        )
    }
}

Swipe fraction
For the swipeFraction one already exists in SwipeProgress#fraction, however it’s always relative to the anchor the interaction started from.

// The thumb is moving...
Anchor                     Anchor
  A ------------ (Thumb) --- B

// if it started from A
fraction = 0.75f

// if it started from B
fraction = -0.25f

But we want a value between [0,1] that’s always relative to the start, so we need a function that check the origin of the interaction and, if necessary, invert the fraction. This means that in the example above the value will always be 0.75f

fun calculateSwipeFraction(progress: SwipeProgress<Anchor>): Float {
    val atAnchor = progress.from == progress.to
    val fromStart = progress.from == Anchor.Start
    return if (atAnchor) {
        if (fromStart) 0f else 1f
    } else {
        if (fromStart) progress.fraction else 1f - progress.fraction
    }
}

Haptic feedback
You can add a small vibration when the user successfully triggered the slider by providing a lambda to confirmStateChange and check for the end state.

val hapticFeedback = LocalHapticFeedback.current
val swipeState = rememberSwipeableState(
    initialValue = if (isLoading) Anchor.End else Anchor.Start,
    confirmStateChange = { anchor ->
        if (anchor == Anchor.End) {
            hapticFeedback.performHapticFeedback(HapticFeedbackType.LongPress)
            onUnlockRequested()
        }
        true
    }
)

With that in place we have everything in place to use the component. If you followed along this far you should now have something looking like this:

Wrap up

That’s all there is to it. Again the demo code can be found on Github:

https://github.com/patrick-elmquist/Demo-SlideToUnlock

If you enjoy this kind of post like once a year or so, considering following me here and/or on Github. Thanks for reading and have a good one! 👋

Behind the scenes

As I was about to wrap up this blog post I noticed that a bunch of the APIs, in true Compose fashion, are being deprecated in alpha versions, where the .swipable(...) modifier and related classes are being replaced by .anchoredDraggable(...). As I wanted the article to be as up to date as possible I rewrote the examples with the new APIs, however when doing so I ran into a number of issues that I suspect is due to bugs in the alpha version. So this is why the article is covering APIs that are about to be phased out. Either way, the new classes may have different names but they are used in a very similar fashion so it should still be useful :)

Make a simple “Slide to unlock” in Jetpack Compose was originally published in Flat Pack Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Quickly scroll to the top of a list

Learn how to smooth scroll to the top of a RecyclerView in constant time no matter the number of items.

What’s the issue?

In the IKEA app we have product lists that tend to be rather long, some categories contain 1000+ items. When a filter is applied to a category we want to first scroll to the top of the list before applying the filter as the content will change. If the user has only scrolled down a couple of products this is not a problem, we can just use the built-in smooth scroll of the RecyclerView. However if the user has scrolled down say 100+ items, the scroll duration will quickly start to turn into a bad user experience. Just have a look at the example below where the user is scrolling past 125 items:

Using the default smooth scroll it take a little over 5 seconds to scroll past 125 items. As it’s using a LinearSmoothScroller under the hood the time it takes will grow linearly like:

// list.smoothScrollToPosition(0)

#Items    Smooth scroll
125       5s
250       10s
500       20s

As the distance becomes longer the user experience quickly degrades as it takes longer and longer to reach the top. Already 5 seconds is stretching what the user should have to wait for such a trivial action, 10 and 20 seconds is just horrible. From here there are two obvious paths for solving the time issue:

• Use list.scrollToPosition(0) which results in an instant scroll to the top without any animation. This solves the time issue but is not a smooth experience for the user.
• Create a subclass of LinearSmoothScroller that modify the scroll speed to meet a certain max time. For a medium size list of items this works pretty well, but for a long list the scroll speed will be so fast that it will start looking like the scroll is lagging and make the UI look janky. This is a bit hard to capture in a low quality gif but try cranking up the speed for a long list and it will be easy to spot.

So what to do?

Instead of adjusting the speed or smoothness to scroll past all items, let’s just scroll past a number of items that we have time for. Let’s define a threshold N that’s the maximum number of items we are willing to scroll past, then instantly scroll the list to N and smooth scroll from there. Something like this:

N = max items to scroll past

if number of items to scroll is < N
    use regular smooth scroll
else 
    make a jump to item N from the top
    use regular smooth scroll from N

So for a long list, this is what it would look like in practice:

The jump to N is done in a single frame and then the regular smooth scroll is started from N to the top. Basically the solution is to cheat, if the desired number of items can’t be scrolled within the desired time window, just ignore a part of the list and scroll whatever amount there’s time for. This is what it looks like in practice:

The time it takes to scroll the list of 125 items went down from 5 to 1.1 seconds. What is important to note is that it will remain at 1.1s even if the number of items is doubled or quadrupled as it will always just scroll the top N items of the list.

// list.smoothScrollToPosition(0)
//   vs
// list.quickScrollToTop()

#Items    Smooth scroll    Quick scroll
125       5s               1.1s
250       10s              1.1s
500       20s              1.1s

But hey now, hold on! That jump, won’t it be visible to the user? When looking real close at the screen recording it’s possible to spot the content change right as the scroll start, however it’s only noticeable when actively looking for it. The key for this to work well is that the colours of the items and the background look similar throughout the list, so the jump will be passed off as the scroll just starting and the previously visible items have just been scrolled away.

Enough talk, where’s the code?

With the end result demoed, time for some code. To be re-usable in multiple places it’s added as an extension function to RecyclerView and looks like this:

What’s happening here?

1. First, this is based on using a LinearLayoutManager or one of its subclasses likeGridLayoutManager, so we check for the proper type of layout manager.
2. We create the SmoothScroller to use. It’s hardcoded to the index 0 for the top of the list and applies a speedFactor that allows the caller to control the speed of the scroll. This is not strictly needed but is a nice way to be able to fine tune the visual experience for different scenarios.
3. We check if the list is scrolled down more than the provided threshold of items. If so we perform a jump to the threshold location and wait a frame for everything to be laid out and measured before continuing.
4. Start the smooth scroll with the custom scroller.

That’s all that’s needed for it to work.

LinearLayoutManager vs GridLayoutManager

Worth noting is that jumpThreshold will assume that the list is a single column as no special handling for grids have been added to keep it simple, so for a grid just pass in:

jumpThreshold = rowsToScroll x columnsPerRow

Why suspend function?

Now what’s the reason for using a suspend function? It’s purely based on preference. For the implementation there’s nothing stopping replacing awaitFrame() with doOnPreDraw/doOnNextLayout callbacks and have a regular function. However using coroutines and suspend functions allows for simple and declarative usage like:

viewLifecycleOwner.lifecycleScope.launch {
    // scroll to top
    list.quickScrollToTop()

    // wait for scroll to end
    awaitScrollEnd()

    // make changes to the top of the screen
    animateHeaderChange()
    applyNewFilters()
}

Wrapping up

That’s all there is to it. Of course this can be improved further, allowing to scroll to the bottom or middle of the list or add better built-in support for grids, but that’s left as an exercise to the reader 😉 Have a good one 👋

Quickly scroll to the top of a RecyclerView was originally published in Flat Pack Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

A while back I wrote an introduction tutorial on how to add more depth to common lists by adding a parallax effect when scrolling. Now a couple of years later I’m adding a Part 2 too it, showing a more advanced example of what you can achieve by adding parallax to both the foreground and background of the list item.

Series

• Part 1: Add extra depth to your list using parallax
• Part 2: More ways to add parallax to your RecyclerView

What got me to do this blog post was when I stumbled upon this concept by Hero on Dribbble:

I really liked the card transition and granted this post is not a 1:1, pixel perfect implementation it’s clear that more than a little inspiration have been drawn from the concept, so kudos to Hero (link) for the design.

Before we begin

As this is more of a ‘Part 2’ follow up post, I’d recommend checking out the previous post for a more in depth presentation on how everything works, as this post will mainly showcase new ways to apply the same concept.

Add extra depth to your list using parallax

With that out of the way, lets begin!

Enable parallax

Most of the magic will be in the ViewHolder, so to start of let’s define a skeleton that support parallax:

We define parallaxOffset as a property, make sure it’s within the allowed range of [-1.0,1.0] and call the applyParallax() function when the value is changed. With this property defined we can now add a ScrollListener to our RecyclerView that calculates the offset for each ViewHolder and update the value:

The card layout

Now that the skeleton for parallax is added, it’s time to create our card. This is what the layout looks like:

Create background parallax

To simplify what can easily become a hot mess of factors, scales and translations, we’ll look at the implementations for the background and text separately. First we are gonna focus on the background parallax, this is what we’re aiming for:

Basically as the card is scrolled one way, the background image moves at a slower rate in the opposite direction, which creates a nice, smooth movement.

In bind() we scale the ImageView as we will be translating it and need some extra content, the parent CardView will take care of clipping the image to the correct size when the scale is to large. It may look a bit complicated but all we do is to make sure that the image has the same width as the parent RecyclerView.

In applyParallax() we separate the parallaxOffset into a direction and an absolute distance. Those values are then used to calculate the alpha and translation. We use a FloatEvaluator to calculate the linear interpolation between alpha values.

When it comes to the constants there’s really no magic, just change the values to something between 0-1 that you feel looks good.

Add text parallax

Now let’s move over to the slightly more complicated text parallax. This is the result we’re aiming for:

To showcase what’s possible we’re applying a slightly different movement depending on if the list is scrolling left or right. Anyway here’s the code (the background code have been omitted by … for this):

We now use a new set of constants and a LinearOutSlowInInterpolator to calculate translations for each text field.

Together with the background parallax you should now have something looking like this:

Link to the complete ViewHolder implementation can be found here: CardViewHolder.kt

Wrapping up

That’s all there is to it. It’s a simple and powerful way of adding more life into the user interaction. The full implementation of this demo can be found on my Github.

Demo code:

GitHub - patrick-elmquist/Demo-RecyclerViewParallaxPart2: Demo code for a future blog post

And again, if you haven’t checked out Part 1 in the series, I recommend having a look at it to get some more explanation around how it all works:

Add extra depth to your list using parallax

That’s all for this time, have a good one!

A while back I started getting into custom mechanical keyboards and the QMK firmware, a really fun side project. One issue I’ve faced since starting to create my own keymaps and custom functionality is that all my code have been living inside the massive qmk_firmware repository which means some extra headache when rebasing to get the latest features. This was especially clear recently when trying to rebase on the latest master branch after having cherry-picked a couple of PRs that were now merged. What I would like is to separate my code from the rest of the firmware, since I never change anything outside of my own folders anyway.

To sort this out I’d seen people use separate repositories for their custom code and symlink it when building. Having no experience whatsoever with that kind of black magic I started googling “QMK keymap separate repo” and to my surprise I couldn’t find any blog posts about it. So now that I’ve finally taken the time to set it up for myself, I thought I’d share the steps (it was a lot easier than I thought). What we’ll be doing is to create a new repository, add QMK as a submodule and create a make file handling the symlinks and build steps.

Update 2024

QMK now has support for external userspace
https://docs.qmk.fm/newbs_external_userspace

While I have only tried it out briefly, this is most likely a better way of doing things going forward as you don’t need error prone submodules and symlinks.

As an example, here is my repo with my common code and the configs for my Ferris Sweep: https://github.com/patrick-elmquist/qmk_userspace

First off, here’s a link to my ‘keymaps’ repository on Github, it’s what you will end up with when following the steps below:

GitHub - patrick-elmquist/qmk-keymaps: A user repository with my keymaps for QMK keyboards.

After following a discussion in #keymap-ideas on the SplitKB Discord, I ended up using the following repo as a template for how to set it up:

GitHub - grasegger/kyria-layout

Since I have more than one keyboard and a user space folder in qmk_firmware I needed to make some adjustments for it to suit my needs. These are the steps I went through:

Create a new Git repository and add QMK as a submodule

We don’t want to commit the build output to the repo, so add a .gitignore file with the following:

Update March 2023:
Do NOT name your repository (or at least the folder you clone into) keymapsas a recent change to QMK can make the builds fail with the following error:

qmk_firmware ❯ qmk compile -kb dz60 -km default
Ψ Compiling keymap with gmake --jobs=1 dz60:default


QMK Firmware 0.20.0
make: *** No rule to make target 'dz60:default'. Stop.
|
| QMK's make format is:
|     make keyboard_folder:keymap_folder[:target]
|
| Where `keyboard_folder` is the path to the keyboard relative to
| `qmk_firmware/keyboards/`, and `keymap_folder` is the name of the
| keymap folder under that board's `keymaps/` directory.
|
| Examples:
|     keyboards/dz60, keyboards/dz60/keymaps/default
|       -> make dz60:default
|       -> qmk compile -kb dz60 -km default
|     keyboards/planck/rev6, keyboards/planck/keymaps/default
|       -> make planck/rev6:default:flash
|       -> qmk flash -kb planck/rev6 -km default
|

QMK look for a folder called keymaps to find the provided keymap to compile and it seems having the repo folder called the same can cause conflicts.

Add folder structure

Now lets create the folder structure. In the qmk_firware repo I had keymaps for Lily58, Kyria and have common code for both in a user space folder. So this is this is the structure I use in the new repository:

keymaps/
 + kyria/ 
 + lily58/
 + user/
 | .gitignore
 ` .gitmodules 

Now transfer any files you already have inqmk_firmware/keyboards/<keyboard>/keymaps/ and qmk_firmaware/users/<user> folders to their new location. Note: if you’re transferring files to the user folder it assumes that you have already set up your user space with the correct files. If you haven’t, you can find a guide for how to do it here. Fore me the structure looked something like this after:

keymaps/
 + kyria/
 |  | keymap.c
 |  | config.h
 |  `rules.mk
 | 
 + lily58/
 |  | keymap.c
 |  | config.h
 |  `rules.mk
 |
 + user/
 |  | <user>.c
 |  | <user>.h
 |  ` ... more user files
 |
 | .gitignore
 ` .gitmodules

Create Makefile

When you’re done there’s only one more thing to do, and that’s to configure a Makefile to setup the symlinks and build the firmware. I should mention that prior to this I’ve never written a make file, so there might be better ways to do this, but I wanted to make it easy to add more boards.

Note: the Makefile assumes that the QMK CLI is installed.
Now we are pretty much done, to build, just go into the main folder and run:

Wrapping up

That’s all I had to do to set it up. It’s been working great, I love to have the code separate from the main repo and also closer together making it easier to navigate while developing.

Do you think the standard BottomNavigationView component is a bit boring and want to spice it up? In this post I’ll show you how easy it is to add a custom indicator and have it animate between positions.

What we’ll be doing

• Extend BottomNavigationView
• Draw an indicator using the Canvas APIs
• Listen to item selection and move the indicator accordingly
• Animate the movement and also add a scale up/down animation

Before we start, even though all code you need is included below, you can find a sample project over on my Github page:

patrick-elmquist/Demo-BottomNavigationIndicator

Show me the code

So let’s first have a look at the class we’re implementing and then go through what it does.

Let’s break it down.

Animate the position

This function is the meat and potatoes of the class, this is where we calculate the next position of the indicator and start the animation to move it in place. We start off by cancelling any running animation. Next we make sure that we can find a view for the given id. fromCenterX is stored outside the animation to get a start value used for an interpolation inside the animation update block.

The animation can be done in several ways. In this example I’ve decided to have it animate between the scale values since there are three of them (current scale > large > default) and interpolate the translation based on the animatedFraction, a value between 0.0-1.0 representing how far into the animation duration we are.

The code itself if pretty straight forward, we calculate the new position and use it together with the new scale value to update the indicator bounds.

distanceTravelled vs scale
The distance is always measured from the center of the view so that the scale won't play into it.

Item1               Item2
    (=x=)
  |---|                
         (===x===)
  |----------|
                 (=x=)
  |----------------|

Indicator bounds
The bounds are defined as positions within the parent, so we use the travelled distance and the new width to define the left and right values.

distanceTravelled
       |
 (=====x=====)
 |---width---|

left  = dT - width/2
right = dT + width/2

Duration
The animation duration is a calculated value and depends on the distance the indicator has to travel. Why complicate things? It makes sense that an animation between two neighbour items should be faster than the animation between the two items furthest apart, otherwise either the short movement will fell sluggish or the long movement will barely be noticeable.

So that’s the idea, however the implementation and values are completely arbitrary and mainly depend on what type of animation you’re doing and what interpolator you’re using. In this case, using a LinearOutSlowInInterpolator, having half the max duration be controlled by the distance felt like a good split.

Item1               Item2
  O
  |-------------------|
      distanceToMove

base     = 300L
variable = 300L
duration = base + variable * distanceToMove / parentWidth

Drawing the indicator

By default the BottomNavigationView won’t call onDraw, so instead we put the drawing command in dispatchDraw. The command is simple, draw a rounded rect with the bounds of the indicator and with a corner radius that’s half the height of the indicator. This gives the indicator a pill shape while moving and a circle when it’s still.

That’s it

Just use this new class instead of the BottomNavigationView in your layout and you’re good to go.

That’s all for this time, have a good one!

Add an animated indicator to your BottomNavigationView was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

The base for the example will be a RecyclerView, configured with a horizontal LinearLayoutManager, and we’ll be using a ScrollListener to create the parallax effect.

Example code

All code from the example below can be found at my Github page:

patrick-elmquist/Demo-RecyclerViewParallax

and the demo app is available for download here: APK@Github

Set up the RecyclerView

First, we need a data class to represent the list items. We can represent a TV show with a simple model class, containing a title, description and an image:

Second, we need a list adapter for Show items. Nothing fancy here, the adapter delegates the view binding to the ViewHolder:

Now let’s configure our RecyclerView:

The first two lines are basic — we create and add an adapter and make the list horizontal.

At the third line, we attach a PagerSnapHelper to the RecyclerView. The PagerSnapHelper is part of the RecyclerView library and makes the list behave like a ViewPager, where one view is always snapped to the center of the screen. So if you scroll halfway between two views and let go, the list will automatically center the closest view.

The last row calls setupParallaxScrollListener(), a function that configures the parallax effect. However, for it to make sense, we first need a list item…

Create a ViewHolder

This image shows what the item view will look like. We have a title and description text, and we show the Show image as both a thumbnail and the background.

To create the item, we define item_show.xml as below. Note that most of the styling has been removed for brevity (the full implementation can be found here).

With the layout done, we need a ViewHolder for the RecyclerView. Most of the implementation is pretty basic: we take in a Show item and bind the text and image to the view. We also add an extra property called offset, which is responsible for adding the parallax effect.

Let’s step through the offset setter:

field = v.coerceIn(-1f, 1f)

The offset is relative to the view width, and needs to be limited to the range of [-1.0..1.0] or else the views will be moved too far off the screen.

val direction = if (field < 0) -1f else 1f

The offset sign determines which direction the views will move in. A value less than 0 means that the views will move to the left, and a value greater will move to the right.

interpolator.getInterpolation(abs(field))

Here we define how the parallax views should be moved. To understand what this does, we first need to understand what an interpolator is. An interpolator is simply a function that takes an input value and transforms it into another value. In the animation below there’s the red ball, which is a linear function, and the purple ball which is an easing function.

As you can see, they start and end in the same place, but the path in between is different. When a user scroll a view with its finger, the view moves as a linear function (red ball), which means that the view will follow the user’s finger. Adding a parallax effect means that you want some of the views to deviate from the finger position and move at another pace, but end up in the same place as the rest of the views. To achieve this, you can transform the linear scroll input by passing it to an easing function and apply the result to some of the views, making them move like the purple ball, while the rest of the views move like the red one.

Input    Easing    Output
 0.0       ->       0.0
 0.1       ->       0.02
 0.2       ->       0.07
 0.3       ->       0.14
 0.4       ->       0.22
 0.5       ->       0.33
 0.6       ->       0.44
 0.7       ->       0.56
 0.8       ->       0.70
 0.9       ->       0.84
 1.0       ->       1.0

The reason for sending abs(field) to the interpolator is that it expects a value between 0 and 1, and will cap any negative value to 0. So we remove the sign of the input and re-apply it as a direction later on.

direction * interpolatedValue * itemView.measuredWidth

Let’s break it down:

• direction - Determines if the view will move to the left or right.
• interpolatedValue - A value in the range [0.0..1.0] that determines how far the view should be moved, relative to the item view’s width.
• itemView.measuredWidth - The width of the item root view.

Now, the only part left is to apply the new translation to the views that should move at a different pace. This is done by changing the translationX properties for the title, description and thumbnail.

The ParallaxScrollListener

Here’s the meat and potatoes of the parallax effect: let’s first have a look at the code and then step through it.

The code is based on the fact that our list item is as wide as the RecyclerView. This means that there will be (at most) two visible items at the screen at any given time.

Here’s what’s happening:

1. Get the RecyclerView scroll offset, i.e. the total number of pixels that it’s scrolled from its start position.
2. Next we want to calculate an offset factor between [0.0..1.0], indicating how far the current item view has been scrolled (0.0 being not scrolled at all and 1.0 being entirely off screen). To do this we take the scroll offset and use the modulo operator to get the remainder, which in this case represent how many pixels the current view is scrolled. To get the fraction we then just have to divide the remainder with the width of the RecyclerView.
3. Find the first visible ViewHolder in the LayoutManager and apply the offset to the ShowViewHolder.
4. Find the last visible ViewHolder in the same way, however, for this case we need to add an extra check. There are two items on the screen while scrolling, however, if the view is snapped to the center, findFirst and findLast will find the same item, causing the offset to be updated twice. To prevent this, just check that the position of the first and last item differ before updating the offset.

And that’s all there is to it. You now have a list with a fancy parallax effect.

Wrapping up

So there you have it, the basics for adding some spice to a simple list. Remember, this is just one example of what you can do. To further customize the transition, use the offset provided in this example and play around with other view properties like:

• Translation X,Y,Z
• Scale X,Y
• Alpha
• Tint color (tip: use ArgbEvaluator to tween colors)

That’s all for this time, have a good one!