Farewell, ViewPager. Hello, Epoxy Carousel.

Yolanda
Yolanda
Oct 21 · 5 min read

Dear ViewPager,

It’s not you. It’s me.

No. Actually, it’s you. It’s you and your inability to adapt to our children’s height. It’s you and your Fragments friends and your resistance to meeting some of my other friends. It’s you and all your boilerplate code.

This is what the end result should look like.
This is what the end result should look like.
This is what we’re going to be building.

In all honesty, the ViewPager has served me nicely over the years. But once I realized I could do everything the ViewPager does, using the RecyclerView (thank you, amit d4vidi for the inspiration), I wondered if I could take it to the next level by applying the same concepts to Epoxy’s Carousel.

Plus… Carousels make everyone happy!

Just look at them — they look so happy. Photo by ckturistando on Unsplash.

I’ve been using Epoxy — Airbnb’s Open Source Android library for building complex screens in a RecyclerView — for little over a year now and I can’t possibly see myself going back to writing all… that… boilerplate… code.

Don’t get me wrong, the RecyclerView is undoubtedly one of the most important components the Android framework has to offer. But I love how Epoxy makes it seem as if you were just playing with constructions blocks. And those construction blocks just fit perfectly within one another and yet can maintain their expression and individuality. It’s almost as if it works better than modern society.

But enough talk. How do we achieve this?

Oh, and I forgot to mention this will be done in Kotlin.


Building the views and adding them to the Carousel

(1) We can start by creating the ViewPager item’s layout.

<?xml version="1.0" encoding="utf-8"?>
<androidx.cardview.widget.CardView
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="wrap_content"
app:cardCornerRadius="8dp">

(2) Now we’ll have Epoxy generate our model classes. You can do this by annotating custom views, using Android Databinding or applying the View Holder pattern, whichever you prefer.

We’ll use the View Holder pattern in this example — it’s intuitive and reminisces to our happy times with the RecyclerView.

@EpoxyModelClass(layout = R.layout.model_item_view_pager)
abstract class ViewPagerItem
: EpoxyModelWithHolder<ViewPagerItem.Holder>() {

(3) And now we build our Carousel using the generated model class we just created. I believe it goes without saying, but they are generated *after* you build the code. And they are annotated by _.

override fun buildModels(data: ViewPagerData) {
carousel {
id("This is a ViewPager.")
hasFixedSize(true)
paddingRes(R.dimen.view_pager_item_padding)
models(data.items.mapIndexed { index, item ->
ViewPagerItem_
()
.id(item)
.title(item)
}
)
}
// TODO: TabLayout goes here. We'll get there...
}

And the RecyclerView’s ItemDecoration? Gone.

We can simply set the padding to our Carousel, and it will behave just like an ItemDecoration should, by adding even spaces between all the items.

Alright, now on to the part where I almost questioned this decision.


Where’s the TabLayout!?

Taking on Epoxy’s paradigm, the TabLayout is just… You might have guessed. Another construction block. Or a model class.

So we’re back at step (1): build the layout.

No, actually no. We could. But since our TabLayout is nothing more than a FrameLayout with some dynamically inflated children depending on the Carousel’s child count, we can simply build a model class using an annotated custom view.

This is step (2): have Epoxy generate the model class. See!? We managed to skip a step! Brilliant.

@ModelView(autoLayout = ModelView.Size.MATCH_WIDTH_WRAP_HEIGHT)
class TabLayout @JvmOverloads constructor(
context: Context, attrs: AttributeSet? = null, defStyleAttr: Int = 0
) : FrameLayout(context, attrs, defStyleAttr) {

As you can see, now our model class simply extends FrameLayout — our intended view root. We’re adding a wrapped content LinearLayout child to it, just so we can have our tabs centered on the screen. There are probably better ways to do this, but I cannot be bothered at this point. Where were we…?

On to step (3): build the TabLayout using the generated model class.

override fun buildModels(data: ViewPagerData) {
// ...
TabLayoutModel_()
.id("This is the ViewPager's TabLayout.")
.count(data.items.size)
.checked(data.visibleItemIndex)
.addTo(this)
}

Epoxy offers a couple of visibility callbacks we can attach to our models to interpret their visibility status. The only thing our TabLayout needs to know is which model is currently fully visible — so we’re going to attach the following callback to each ViewPager item model on our Carousel:

onVisibilityStateChanged { _, _, visibilityState ->
if (visibilityState == FOCUSED_VISIBLE) {
// This model just became fully visible.
}
}

Easy. Now the tricky part. If you run the code at this point, you’ll notice the callback is… never… called. Why, Airbnb Engineers? Why!?

Turns out to enable visibility events, you need to attach a visibility tracker to your RecyclerView, like this:

EpoxyVisibilityTracker().attach(recyclerView)

Seriously, I had to go to the depths of the internet to find this out.

Now, whenever our event is dispatched, we’ll update our TabLayout model to highlight the tab respective to the currently visible item.

That could be it. But if our initial idea was to replicate the ViewPager’s UX, we’re not quite there yet.


Oh, Snap!

Right now you’re able to easily fling through all the items. And that’s ok — depending on what you’re trying to achieve, but it doesn’t exactly “feel” right, especially if you’re building a pager with only a handful of pages.

Again, I had to dive deep into the confined depths of the internet (or maybe my Google-Fu is just weak) to find out that you can — very easily, I might add — change this behavior by doing:

Carousel.setDefaultGlobalSnapHelperFactory(
object : Carousel.SnapHelperFactory() {
override fun buildSnapHelper(context: Context?
): SnapHelper {
// Return anything!
// Anything you could ever possibly dream of!
})

We’re going with PagerSnapHelper, because, as you can tell by the name, it replicates the exact snapping experience the ViewPager offers.

If you’re feeling adventurous, check out this library by Android developer Rúben Sousa, which implements a bunch of snapping behaviors. Or go ahead and implement your own!


TL;DR: here’s the full source code. Happy coding!

The Startup

Medium's largest active publication, followed by +527K people. Follow to join our community.

Yolanda

Written by

Yolanda

Product Engineer. Surfer. Android developer. Solopreneur. Remote worker.

The Startup

Medium's largest active publication, followed by +527K people. Follow to join our community.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade