DEV Community: Eugene Zubkov

Custom view from scratch. Part III. Performance and optimisation.

Eugene Zubkov — Tue, 13 Jun 2023 15:21:58 +0000

Previously on “Custom view”…

We’ve added all the constituent parts of the chart, and started the app for the first time. But the chart disappeared. It’s as frustrating as creating a lovely painting, but not being able to show anyone to get that “WOW” effect!

So what now? First, we need to discover the reasons for this mysterious disappearance. Let’s go to the logcat and see what it says:

Shape too large to be rendered into a texture (18104x787, max=16384x16384)

This error message tells us that one of the shapes exceeds the maximum size of a texture that can possibly be rendered by a phone. This must be our chart. The size of a texture may vary depending on the device.

In our case, the chart was growing as it was getting new values. The larger the Path became, the more resource-intensive it was to render it. This resulted in it exceeding the texture size limit.

How is the Path linked with the texture?

This is the approximate path from calling canvas.drawPath, to drawing it. Most of it goes through Skia, a graphics library used inside Android.

You may notice that SkBitmapDevice is used at the end, demonstrating that the Path is drawn in Bitmap. This Bitmap is then loaded as a texture to the GPU and rendered there.

This leads to an obvious problem with the Path:

The larger the Path region, the larger the texture.

Now where can we go from here? There are a few options, but you should always figure out the most optimal solution for your needs. The most obvious solution is to use the minimum amount of data required for display. Alternatively, we could pay attention to the size of the occupied area rather than the complexity (this might be cheating a little bit…!). Another option still would be to re-use the Path, and if possible use rewind (however, the number of points has to remain constant). Finally, we could pre-fetch the chart in Bitmap. This should be done in a separate thread, so as not to block the current one.

Fixed-size chart

The chart continuously shifts to the left, but when a new value is added, we delete the last one and shift the chart to the right. Thus, we create the effect of continuous movement.

The main drawback of the Path is that the actual rendering to the texture is performed on the processor. Therefore, it’s reasonable to try rendering with primitives. However, you might encounter the problem of limiting hardware acceleration and the Canvas API. As I mentioned earlier, the drawVertices method used to fill the chart doesn’t support hardware acceleration and can only be used without it. It doesn’t work for us.

Let’s compare the two approaches — using the Path and the primitives. For visual clarity, I removed the fill and remove rounding effect.

This is what we get. On the left, the chart is drawn by calling the drawLines method from Canvas. On the right, the Path is used. As you can see, drawing with primitives is much lighter than Path. Therefore, I recommend drawing with primitives whenever possible.

There is still one way to improve performance, but also use Canvas. You need to implement rendering on Canvas in a separate thread. Two Views from the Android SDK come to the rescue — SurfaceView and TextureView. Let’s take a look at their differences and choose the one that would serve us better.

SurfaceView

The main drawback of SurfaceView is that a separate Window is created for It. This is good from the point of view of performance, but also puts some restrictions on building the user interface. For example, we cannot animate the View (as far it’s not a part of a view hierarchy).

SurfaceView works well when you need to stream a video or use OpenGL, but at the same time SurfaceView does not interact with other Views.

TextureView

TextureView doesn’t have the drawbacks of SurfaceView that I’ve mentioned, but its performance is lower. Usually, this isn’t a problem.

Since we need to use the chart component together with other UI elements, TextureView is the best choice for us.

Let’s take a look at the basic steps for configuring TextureView:

Create a View that is inherited from TextureView.
Implement the SurfaceTextureListener, which describes the TextureView lifecycle. Subscribe in onAttachedToWindow and unsubscribe in onDetachedFromWindow
Implement the dedicated rendering thread, which is the main advantage of TextureView over the regular View

SurfaceTextureListener

fun onSurfaceTextureSizeChanged(surface: SurfaceTexture, width: Int, height: Int) 

fun onSurfaceTextureUpdated(surface: SurfaceTexture)

fun onSurfaceTextureAvailable(surface: SurfaceTexture, width: Int, height: Int) 

fun onSurfaceTextureDestroyed(surface: SurfaceTexture)

This interface contains four methods. The name of each clearly indicates its purpose. In most cases, we only need the last two:

onSurfaceTextureAvailable, which tells us that SurfaceTexture is ready for use.
onSurfaceTextureDestroyed, which is called before terminating the SurfaceTexture.

In the simplest implementation, we need to save the reference to SurfaceTexture and start the rendering thread in the first method, reset the reference and stop the thread in the second method.

val surface = Surface(surfaceTexture)
while (true) {
    val canvas = surface.lockCanvas(null) ?: break

    delegate.onDraw(canvas) //delegate is an object which draws our chart

    try {
        surface.unlockCanvasAndPost(canvas)
    } catch (e: IllegalArgumentException) {
        break
    }
}

Let’s move on to creating the rendering thread. We’ll choose the simplest implementation. The code of the run method is shown in the snippet above. This is a step-by-step description of what happens there:

The surface is created based on SurfaceTexture.
An unending cycle. Here’s what happens inside this cycle:
- Get the canvas object from Surface.
- Draw on this canvas.
- Post the modified canvas to surface.
- The cycle may be interrupted if we couldn’t get the canvas or post it to Surface.
When finished, we release the created surface.

Things to keep in mind:

It takes a lot of effort to implement a thread-safe render, because the data for rendering will come from other threads.
As described earlier, you’ll need to control the lifecycle using SurfaceTextureListener.
It’s worth highlighting the issue of animation. Since rendering is performed in a separate thread, we don’t know the frame time. To find it, you need to use the SDK’s Choreographer feature. It coordinates all the work in the system related to animation, user input, and rendering. You can use the Choreographer either explicitly, or implicitly. You may apply higher-level abstractions of the ValueAnimator type, which is the preferred option.

For more information about TextureView, see the Grafika demo app that is stored in the Google repository on GitHub.

Launch our app with TextureView

We can enjoy this result primarily because the Path is rendered to the texture in a separate thread. As the Profiler shows, our work can be considered completed.

Take-away

It’s been a long ride through this Custom View tutorial! Check out Part 1 and Part 2. Now that we’re finished, let’s summarise the recommendations. What should you take into account when you work with canvas and the Path to create your own custom views?

Obviously, the less you do during rendering, the higher is the frame rate.
Don’t rush to complicate the rendering logic. In most cases, the Path of a fixed size is enough.
If you don’t use the Path, then give a preference to line, point, or rectangle primitives, since they don’t use the Path at the Skia level. For example, drawCircle uses the Path.
If you draw several primitives, group them by type and draw them together. This way, rendering will be faster.
Watch this video:

There you go! Now you’re ready to go and create your own custom views. Good luck!

Custom view from scratch. Part II. Canvas.

Eugene Zubkov — Tue, 13 Jun 2023 15:06:10 +0000

In Part I, I covered the basics of Custom View development. This time I want to tell you in detail how you can render a chart. Reach out for your artistic toolkit, and let’s add some detail and shade to your sketch!

This is our goal. Impressive, huh?

For starters, we’ll define the logical structure of our View. After that, we’ll move on to rendering, and look closer at each layer. I’ll show you how to debug the View and profile GPU rendering. And then — finally! — we’ll launch our app for the first time.

The logic of View

The View contains two objects — DataProvider and ChartRenderer. These two objects allow us to customise and test the chart flexibly. For example, you can implement a test configuration by using DataProvider with predefined values.

The DataProvider interface is presented by the two methods:

getHistoryData — gets the initial set of data,

observeNewData — subscribes to updates that determine how our chart will move.

While the ChartView is responsible for display and animation, the ChartRenderer contains the logic for chart drawing.

class ChartView @JvmOverloads constructor(
        context: Context,
        attrs: AttributeSet? = null,
        defStyleAttr: Int = 0
) : View(context, attrs, defStyleAttr) {
    lateinit var dataProvider: DataProvider
    lateinit var chartRenderer: ChartRenderer
    private var disposable: Disposable?

    override fun onAttachedToWindow() {
        super.onAttachedToWindow()
        chartRenderer.init(dataProvider.getHistoryData(15))
        disposable = dataProvider.observeNewData((1000 / SPEED).toLong())
                .subscribe(this::addValue)
    }

    override fun onDetachedFromWindow() {
        super.onDetachedFromWindow()
        disposable?.dispose()
    }

    fun addValue(value: Double) {

    } 
}

As you can see, we subscribe to changes in onAttachedToWindow and unsubscribe in onDetachedFromWindow. Of course, you may argue whether it’s reasonable to implement this logic inside the View. At Revolut, we do so for the sake of simplicity and clarity.

observeNewData in this example means Observable RxJava, but you may substitute it with any other technology used in your project.

If you want to publish your View, remember these key points:

Make sure you remove dependencies on third-party libraries.
Remove unnecessary logic. You can eliminate DataProvider as an entity because the View isn’t responsible for it. The end user should call the addValue, setValue and other methods instead, depending on the chart type.

Now let’s move on to the next step — rendering on Canvas.

Rendering on Canvas

First I have to say a few words about hardware acceleration here, and show you the coordinates grid. Then I’ll describe how layers are drawn. We’ll take a look at each layer separately — the background, the chart, the state marker, and the text.

Hardware acceleration. It’s 2023, and we‘ve forgotten about Android 4.4 now, right? This means that there should be no obstacles in the way of supporting hardware acceleration. However, this isn’t completely true. You still have to check with the Android documentation and see which functionality is supported when you apply acceleration.

The documentation contains a more detailed table than this one. As you can see, some capabilities are available only for Android 9 (28), and some are not available at all. For example, unfortunately drawVertices is unavailable, and it’s the only way to draw polygons without using Path.

Coordinates grid. This is another important thing that you really need to remember — the starting point is in the top left corner. Even I still forget about it sometimes!

Drawing layers (onDraw)

fun onDraw(canvas: Canvas) {
    canvas.drawPaint(backgroundPaint)

    stars.forEach { it.draw(canvas, skyPaint) }

    chartRenderer.draw(canvas, markerDotX, canvas.height.toFloat())

    drawCurrentValueMarker(canvas)
}

This is how the onDraw method works. It draws all the View layers one by one.

drawPaint — fills our Canvas with the colour defined in Paint.

Next, onDraw renders the sky (background) and the chart and finishes with the current state marker and text.

The background (drawCircle)

To draw each circle in the background, call the drawCircle method from Canvas.

canvas.drawCircle(x, y, radius, paint)

The parameters x, y, radius define the size and position of the circle. The Paint parameter defines the style, namely the colour in our case.

val paint = Paint(Paint.ANTI_ALIAS_FLAG).apply {
    color = Color.WHITE
    alpha = 20
}

You can optimise this part. If it suits your purpose for all your circles to have the same radius, you can use a primitive.

canvas.drawPoint(x, y, paint)

However, the dots are square by default, being 1px in size. To fix this, let’s write a separate sky Paint.

val skyPaint = Paint(Paint.ANTI_ALIAS_FLAG).apply {
    color = Color.WHITE
    alpha = 20
    strokeWidth = radius * 2
    strokeCap = Paint.Cap.ROUND
}

Note that the strokeWidth defines the dot diameter.

Define the Paint parameter outside of the onDraw method to make sure you don’t put too much load on the Garbage Collector (GC).

The next thing we want to make is a loopable background without creating new objects every time. Let’s apply some simple mechanics: when the circle has reached beyond the screen, we just place it back on screen in a random place within the red area. The circle always moves to the left. Thanks to this little lifehack, it looks as if the background is infinite.

interface Entity {
    fun onFrame(frameTimeMillis: Long, chartSpeed: Int)

    fun draw(canvas: Canvas, paint: Paint)
}

class SkyEntity(private val parent: View) : Entity {
    private var x = -1f
    private var y = 0f
    private var radius = 0f
    private var speed = 0f

    init {
        generateNewValues(true)
    }

    private fun generateNewValues(initial: Boolean) {
        speed = 6.dpToPx(parent) * (4 + Random.nextFloat())
        radius = 3.dpToPx(parent) * (1 + Random.nextFloat())

        val dx = if (initial) 0 else 1
        x = parent.width * (dx + Random.nextFloat())
        y = parent.height * Random.nextFloat()
    }

    override fun onFrame(frameTimeMillis: Long, chartSpeed: Int) {
        if (x < -radius) {
            generateNewValues(false)
        }
        x -= speed * (frameTimeMillis / 1_000f) * chartSpeed
    }

    override fun draw(canvas: Canvas, paint: Paint) {
        canvas.drawCircle(x, y, radius, paint)
    }
}

The chart line (ChartRenderer)

interface ChartRenderer {
    fun setValues(values: List<Double>)

    fun addValue(value: Double)

    fun onFrame(frameTimeMillis: Long, speed: Int)

    fun draw(canvas: Canvas, clipWidth: Int, clipHeight: Int)

    fun getChartItemByScreenX(x: Float): ChartItem
}

data class ChartItem(val y: Float, val value: Double)

The ChartRenderer interface uses 4 methods:

setValues — sets values to create the chart
onFrame — is called before rendering each frame
draw — draws the chart
getChartItemByScreenX — allows us to define the point on our chart and its value for the marker based on the X coordinate.

Now we’ll draw a chart using Paths. This process is iterative.

canvas.clipRect(0f, 0f, clipWidth, clipHeight)
canvas.translate(-offset, 0f)

canvas.drawPath(chartBackgroundPath, fillPaint)
canvas.drawPath(chartLinePath, linePaint)

The chart’s line and fill are each defined by a Path. There are several Paint styles you need to know:

STROKE is used to draw a line
FILL is used to colour an item0
FILL_AND_STROKE won’t draw a line with colour, as you might have expected. It’s a FILL style that takes into account the strokeWidth value

clipRect cuts the chart to the required width.

Now let’s smooth our step chart. For the line to run smoothly from one value to another, we need to make the line curvy. There are at least two ways to draw a curve in Path. The Bezier curve is the first and most flexible way to do it. Our second option could be a pathEffect parameter — or CornerPathEffect in our case — where we can specify the radius of the rounded angles.

paint.pathEffect = CornerPathEffect(10)

We use the Bezier curve, as it’s the most appropriate for our needs. Later, I’ll show you why the second option won’t work. To create the chart using the Bezier curve, you just need to write a small piece of simple code.

values.reduce { previous, current ->
    val deltaHeight = previous.toChartY() - current.toChartY()

    chartLinePath.rCubicTo((batchWidth * LINE_CURVE_FACTOR), 0f,
                           batchWidth - (batchWidth * LINE_CURVE_FACTOR), deltaHeight,
                           batchWidth, deltaHeight)

    current
}

Let’s take a closer look at the rCubicTo method. It uses 3 pairs of coordinates as the input — the first two pairs are coordinates of control points, and the third pair are the coordinates of the end point in the curved line. batchWidth — is a step in the graph, LINE_CURVE_FACTOR — is the extent of the smoothing (e.g. 0.5).

Now let’s see how smoothing works.

P0 is the starting point of the curve, Р3 is the end point. Р1 and Р2 are control points — you can move them to make the curve look how you want. You don’t have to provide absolute values here: ‘r’ in rCubicTo stands for ‘relative’, so the chart moves in relation to the previous coordinate values. Thus rCubicTo allows you to leave the starting point value undefined, because it can use the end point from the previous iteration.

override fun draw(canvas: Canvas, clipWidth: Float, clipHeight: Float) {
    canvas.save()

    canvas.clipRect(0f, 0f, clipWidth, clipHeight)
    canvas.translate(-offset, 0f)

    canvas.drawPath(chartBackgroundPath, fillPaint)
    canvas.drawPath(chartLinePath, linePaint)

    canvas.restore()
}

//invoked with a new data
private fun recreatePath() {
    val bottom = parent.height - parent.paddingBottom.toFloat()
    chartLinePath.rewind()
    chartLinePath.moveTo(-batchWidth, bottom)
    chartLinePath.rMoveTo(0f, -values.first().toChartY())

    values.reduce { previous, current ->
        val deltaHeight = previous.toChartY() - current.toChartY()

        chartLinePath.rCubicTo((batchWidth * LINE_CURVE_FACTOR), 0f,
                batchWidth - (batchWidth * LINE_CURVE_FACTOR), deltaHeight,
                batchWidth, deltaHeight)

        current
    }

    pathMeasure.setPath(chartLinePath, false)

    chartBackgroundPath.set(chartLinePath)
    chartBackgroundPath.rLineTo(0f, parent.height.toFloat())
    chartBackgroundPath.rLineTo(-batchWidth * (values.size - 1), 0f)
    chartBackgroundPath.close()
}

Let’s take a look at the chart now.

Okay, so what’s left?

The current state marker
The text

The marker

Since the marker must follow the chart change, we need to be able to determine the Y coordinate based on the constant X coordinate. To determine a point on an open Path, we’ll use PathMeasure. We need to specify our Path to initialise it.

paintMeasure.setPath(chartLinePath, false)
boolean getPosTab(float distance, float pos[], float tan[])

To determine the position, we call the method getPosTan — it accepts three parameters as input:

Distance — is the length of the contour from the beginning to our point.
Pos / Tan — are arrays where data about the point (its position and tangent) will be written. In our case, we can omit the third parameter.

So how do we get a point on the chart based on the screen coordinate X? Let’s try the binary search.

You might think that we can calculate the coordinate using the formula, because we know the following three factors:

How we build the curve
That we don’t have loops
The coordinates of all chart segments

However, it’s not that complicated. The binary search is simple, clear and universal.

We know that our point lies within a certain range. We take the average value and check its coordinates. If the X coordinate is too far from the required coordinate, then we should narrow the range by half and repeat until the required point is as close as possible.

The red dots and blue lines define the limits of our search range. The red dot in the middle is the coordinate we’re checking. The green dot indicates the point we’re looking for.

The first iteration shows that the point in question is pretty far from the center of the range. So we can reduce the range by half because we know that our point is on the right. In the second iteration, we find the value of the point. This algorithm is kind of rough, but it works.

private fun findYOnChart(x: Float): Float {
    val coordinates = floatArrayOf(0f, 0f)
    var rangeStart = 0f
    var rangeEnd = pathMeasure.length
    var midDistance: Float

    while (rangeStart.farFrom(rangeEnd, POINT_LOOKUP_TOLERANCE)) {
        midDistance = rangeStart + (rangeEnd - rangeStart) / 2
        pathMeasure.getPosTan(midDistance, coordinates, null)
        when {
            coordinates[0].closeTo(x, POINT_LOOKUP_TOLERANCE) -> return coordinates[1]
            coordinates[0] < x -> rangeStart = midDistance
            else -> rangeEnd = midDistance
        }
    }

    return coordinates[1]
}

Your code will look something like this. In the loop, we check all points until we find the necessary one, or until the range becomes minimal.

Why won’t CornerPathEffect work for us?

The answer is pretty simple. PathEffect is used at the rendering stage (this means that the input values are not transformed). PathMeasure uses data from Path.

On the screen, we see the smooth line of the chart, but it won’t be like this for PathMeasure. So we won’t be able to find a point on the graph.

Now we know how to position the graph, only the text is left.

The text (getTextBounds)

As you can see in the image, the text and the marker on its left are horizontally centered. Simply using canvas.drawText won’t give us this effect. For example, if we specify the Y coordinate which equals to the marker coordinate, we’ll get the following:

To get a better result, we need to know the text height. getTextBounds can help us out.

val textBounds = Rect()
...
textPaint.getTextBounds(valueText, 0, valueText.length, textBounds)
canvas.drawText(valueText, currentValueLabelOffset + smallDotRadius * 2f,
                view.height - currentValueLabelOffset + textBounds.height() * 0.5f - textBounds.bottom, textPaint)
view raw

This method returns the Rect-type object containing info on the text height. It’s also worth noting that different fonts may differ in other parameters too, not only height.

The bottom indent, for example — you have to take it into account when you centre the text.

Looks like we’ve done all the preparation work! I guess you want to start the app already — we’re almost there. One last thing — debugging.

Debugging & Profiling

To debug your View, it’s enough to turn on the profiling of the GPU renderer. It’ll be able to show all the performance issues. If you have concerns about the memory usage, then you should get the built-in profiler in the Android Studio.

Turn on profiling in the developers’ settings

A profiler looks like this image; a set of columns showing the processing time of each frame. The green line indicates the threshold value — if reached and exceeded, the frame is skipped. On the screens that refresh at the standard rate of 60 Hz, it takes about 16 ms to process a frame.

Note also that each column consists of coloured segments. They visualise which part of the renderer consumes most of the resources.

In Android documentation, you’ll find a description of each step. When we draw using onDraw, we’re only interested in the final few steps:

Draw. The onDraw method (and not just yours) affects this step. Long execution will cause problems.
Sync & Upload. Namely, loading the bitmaps and lists for GPU rendering. Issues arise because of a large amount of data and hardware limitations (for example, slow memory).
Command Issue. It’s responsible for calling OpenGL (or Vulkan) commands on the GPU. Calling more commands results in longer execution.
Swap Buffers. The final step where the CPU is waiting for the GPU to shut down. You can often see this problem if you are profiling on an emulator.

And another useful setting, which may help you optimize rendering, is the Overdraw Visualization. I won’t elaborate on this now, but just note that this setting helps you see which Views are drawn more than once per frame.

General recommendations on profiling

Prioritise using a real device over the emulator.
Check using different APIs.

I’ve singled out the 4 versions of Android that you might need to consider:

KitKat: I hope you don’t have to support this version. But if you do, just remember that rendering is performed in the UI thread here.
Lollipop: RenderThread was added to the system starting from this version.
Marshmallow: I’m not aware of its peculiarities, but various issues are associated with this version, so do your research and stay alert.
Oreo: The rendering pipeline was upgraded in this version eliminating the need to call invalidateRect.

Newer versions work just fine for us (yay!).

Now we’re ready to start our app. Let’s go.

First launch

Everything works as expected. However, the Profiler shows that the rendering of some frames takes more than 16 ms. Frames are skipped as a result, and we may notice some stuttering.

Later the chart becomes even slower.

In the end, it just disappears.

What happened? To find out, you’ll have to come back for the next and final part in this series. Stay tuned to learn about Performance and Optimisation!

Custom view from scratch. Part I.

Eugene Zubkov — Tue, 13 Jun 2023 14:12:37 +0000

In this series of articles I’ll tell you how to create a Custom View like an artist. I’ve prepared a creative task for you and we’ll do it together. In Part I, I’ll give you a succinct account of your options when you can’t use UI components from the standard Android SDK. Sorry, but I won’t let you touch the brushes during the first lesson. This time, we will consider the requirements, choose the approach, build the basic logic, and prepare our canvas. In the next part, we’ll get straight to the View drawing and optimisation. So get comfortable and focus on creating something unique.

Imagine you need to create a complex UI that contains multiple visual components. Something like this:

What do we have here?

Chart: A dynamic element, continuously receiving new values and changing accordingly. Charts can be used to show currency change online or data collected by some sensor.
Current state marker: This smoothly follows the changes in the chart.
Text: Showing current values.

The main feature of our Custom View is that the chart updates live as new values are added. Markers must change smoothly, and that means that View implementation won’t be easy.

In the Revolut app, we use these charts for things like screens showing currencies, trading, and analytics.

Ways of creating a non-standard component

This chart comprises visual components that you won’t find in the Android SDK. What options do you have when the standard components don’t behave the way you need them to, or they’re not optimised for your tasks?

Option 1. Customize the standard components. This is the most obvious and preferable way of solving the task unless you need to add some new logic.

Option 2. Use a Github library. This is a great option if you’ve found a good library.

Option 3. Inherit and extend. This allows you to add new logic by writing the code yourself. However, this is not the easiest way to solve our problem because many things that you may want to adjust have private or package-private access in the Android SDK API. If the package-private access method is used, you may place a new component within the same package as its parent — but you can hardly call this a beautiful solution.

Option 4. Inherit a View from a ViewGroup and inflate the layout you already use. This method works when you need to create a component with several simpler constituents. For example, a widget where you can enter the sum of money.

Option 5. Inherit from a View and create a widget from scratch. This is the method we’re going to use. It’s the most flexible, but the most difficult — it requires that you know the ins and outs.

What is the View and how does it work?

Every visual component of the UI is associated with a base parent View or with its child―so they all follow the same rules.

A View exists only in connection with an Activity/Fragment, and has its own lifecycle.

Inflating a View from an .xml file
Attaching the View to a ViewGroup
Defining the layout
Drawing
User interaction
Detaching from the screen

Now let’s take a look at each of the steps in detail.

Inflation

A View can be created from code or inflated from a layout XML file. Depending on your case, you should call the corresponding type of Constructor. We are inflating the View from XML, so our Constructor will look as follows:

public View(Context context,
            AttributeSet attrs,
            int defStyleAttr,
            int defStyleRes)

Here you specify the context through which your View can access the resources. Then add AttributeSet to use attributes specified in the XML file. You can use defStyleAttr to add a reference to a style resource that supplies default values for the View. If defStyleAttr is 0, or cannot be found in the theme, then the style is applied according to the resource ID set in defStyleRes.

This is how all this looks in Java

And in Kotlin

Pay attention that some Android views (e.g. TextView) may have different behaviour on different constructors and this simplifacation may break this.

E.g. this constructor of TextView passes default style but will never be called with @JvmOverloads trick:

public TextView(Context context, @Nullable AttributeSet attrs) {
    this(context, attrs, com.android.internal.R.attr.textViewStyle);
}

Specify custom attributes

First of all, add the declarable-style tag to your resources, and define each attribute by specifying its name and format. Usually the file with these values is called attrs.xml.

<declare-styleable name="CustomView">
    <attr name="circleRadius" format="dimension" />
    <attr name="circleLabel" format="string"/>
    <attr name="showLabel" format="boolean"/>
    <attr name="circleColor" format="color"/>
    <attr name="circleDrawable" format="reference"/>
    <attr name="circleColorType">
        <flag name="none" value="0" />
        <flag name="fill" value="1" />
        <flag name="stroke" value="2" />
        <flag name="fillStroke" value="3" />
    </attr>
</declare-styleable>

In the XML layout, these attributes will look as follows:

app:circleRadius="5dp"
app:circleDrawable="@drawable/ic_bell"
app:circleColorType="fillStroke"
…

Then you should use the obtainStyledAttributes(AttributeSet, int[], int, int) API to retrieve XML attributes at the construction of the View. Retrieved attributes will be used for drawing on canvas. You also have to remember to add recycle() to clear all the data associated with this TypedArray:

TypedArray a = c.obtainStyledAttributes(attrs, R.styleable.CustomLayoutLP);
            position = a.getInt(R.styleable.CustomLayoutLP_layout_position, position);
            a.recycle();

If you use the android-ktx set of Kotlin extensions, you don’t have to worry about recycling.

context.withStyledAttributes(attrs, R.styleable.YourCustomViewClass) {
    radius = getDimension(R.styleable.CustomView_circleRadius, fallback)
    showLabel= getDimension(R.styleable.CustomView_showName, fallback)
    colorType= getInteger(R.styleable.CustomView_colorType, colorType)
}

Finalizing inflation

After all the attributes have been inflated from XML, the onFinishInflate() method is called. It won’t be called if you create View programmatically.

Attaching the View to a ViewGroup

A ViewGroup is a special view that contains other views called children. The view group is the base class for layouts and views containers.

The onAttachedToWindow callback means that the view will be shown on the screen. Calling of onAttachedToWindow guarantees calling of onDetachedFromWindow at view termination. When you may need this callback? If you subscribe to events within the view, onDetachedFromWindow stops subscriptions when the view is not displayed anymore and thus frees up memory.

There’s a case when onAttachedToWindow is not called. Let’s take a step-by-step look at this case:

You defined the view within the xml layout referred to in the Activity’s setContentView.
You start the app. The Activity is created and the layout is inflated. Upon inflation, our view is created.
The finish() method is called for some reason in onCreate().
The Activity shuts down with onDestroy(). The view lifecycle never starts.

Why might this be frustrating? Imagine that the subscription to some events inside your view happened not in onAttachedToWindow, but in the constructor’s code or the onFinishInflate callback. The view lifecycle didn’t start, and the onDetachedFromWindow callback didn’t happen. Without onDetachedFromWindow, the subscription to changes won’t be terminated, leading to memory overload.

Preparing a canvas

Your next step is getting a Canvas object on which you can draw your view. To do this, you’ll need to override the onDraw() method of the View class. Here is what you need to know about onDraw.

The screen refreshes at the standard rate of 60 Hz, so we have about 16 ms per frame.
The onDraw callback is just one of the steps of the frame rendering, so we actually have less than 16 ms for onDraw.
The onDraw() method is invoked only when invalidate() is being called which does not happen every 16 ms.
A call to onDraw() is made on the main thread.

All this leads us to the following conclusions:

You cannot create objects within onDraw()- otherwise the Garbage Collector (GC) may get stuck. Further, you can’t draw until the GC method has executed, and its execution may take a long time in this case.
Calculation processes must be minimized to ensure the method runtime doesn’t take a long time.

While preparing our Canvas, we need to define what we’re going to draw. We have the following:

Dynamic background containing dozens of circles

Marker and text reflecting the current state

And the chart

The chart occupies the whole width of the screen. Our task requires that the chart has the right indent. We can do this by using Canvas.clipRect(left, top, right, bottom).

canvas.clipRect(0f, 0f, clipWidth, height)

returns the following result:

The red frame selects the area that will be sent to the function.

Now that you’ve learned what options are available when you can’t use standard Android SDK components, you’re ready to learn how to draw the chart. But that’s for another time!

In the next part, we’ll get straight to drawing the chart. We’ll learn how to specify the logic of display and animation, delve into hardware acceleration, learn to draw smooth lines, use profiling, and more. After the first start of the app with the new chart, we’ll single out a few performance problems — then I’ll show you the solutions.

Displaying images in Android app: maintainable, testable, painless. Part II

Eugene Zubkov — Tue, 13 Jun 2023 13:42:35 +0000

Previously we published the first part of this article about building maintainable and scalable system for displaying dozens of thousands of images in your Android app.

Part I contained the approach description and the delegates building instructions. The second part describes the transformation and testing processes and sums-up the results.

Please check the first part before you start reading. Let’s go.

Making transformations

Why do we need transformations? Let’s pretend that we have a contact’s (or a merchant’s) userpic uploaded from the web. The userpic can have any form and size, whilst in Revolut app, we need to display it round-shaped at 40 х 40 dp.

To set the model and make it behave accordingly let’s take UrlImage class as an example. Every image to be transformed should have relevant settings. We set it by creating TransformableImage interface with transformations property:

@Parcelize
data class UrlImage(
    val url: String,
    @DrawableRes val placeholder: Int? = null,
    @DrawableRes val errorIcon: Int? = null,
    override val transformations: ImageTransformations? = null
) : Image, TransformableImage

class UrlImagesDisplayDelegate() : ImageDisplayDelegate {
    override fun suitsFor(image: Image) = image is UrlImage

    override fun displayTo(image: Image, to: ImageView) {
      if (image !is UrlImage) throw IllegalStateException("UrlImagesDisplayDelegate displays only UrlImages")
      Glide.with(to.context).clear(to)

      Glide.with(to.context)
            .load(image.url)
            .apply(
                RequestOptions()
                    .error(image.errorIcon)
                    .placeholder(image.placeholder)
                    .applyImageTransformations(to.context.resources, image)
            )
            .into(to)
    }
}

The class may look like this:

@Parcelize
data class ImageTransformations(
    val rotation: Int? = null,
    val circle: Boolean = false,
    val square: Boolean = false,
    val centerCrop: Boolean = false,
    @Dimension(unit = Dimension.DP) val radiusDp: Int? = null,
    @Dimension(unit = Dimension.DP) val widthDp: Int? = null,
    @Dimension(unit = Dimension.DP) val heightDp: Int? = null
) : Parcelable

To display images, we use Glide. Naturally, all our transformations correspond to this library.

internal interface TransformableImage {
    val transformations: ImageTransformations?

    fun getGlideTransformsArray(resources: Resources): Array<Transformation<Bitmap>> {
        return mutableListOf<Transformation<Bitmap>>().apply {
            val widthDp = transformations?.widthDp
            val heightDp = transformations?.heightDp
            if (widthDp != null && heightDp != null) {
                add(
                    GlideScaleTransformation(
                        newWidth = UiUtils.dpToPx(resources, widthDp.toFloat()).toInt(),
                        newHeight = UiUtils.dpToPx(resources, heightDp.toFloat()).toInt()
                    )
                )
            } else {
                heightDp?.let { height ->
                    add(
                        GlideScaleTransformation
                            .withNewHeight(UiUtils.dpToPx(resources, height.toFloat()).toInt())
                    )
                }
                widthDp?.let { width ->
                    add(
                        GlideScaleTransformation
                            .withNewWidth(UiUtils.dpToPx(resources, width.toFloat()).toInt())
                    )
                }
            }

            transformations?.rotation?.let { rotation ->
                add(RotationTransformer(rotation))
            }
            if (transformations?.centerCrop == true) {
                add(CenterCrop())
            }
            if (transformations?.square == true) {
                add(SquareTransformation())
            }
            transformations?.radiusDp?.let { radius ->
                add(RoundedCorners(UiUtils.dpToPx(resources, radius.toFloat()).toInt()))
            }
            if (transformations?.circle == true) {
                add(CircleCrop())
            }
        }.toTypedArray()
    }
}

That’s how we create the transformations array.

To avoid extra work, mark the fields as nullable (this lets you implement only the needed transformations), and pay attention to the transformations’ order.

Imagine that we have a very large image we need to rotate, scale and crop into a circle. Let’s compare two scenarios:

//First
add(RotationTransformer(degrees = 90))
add(CircleCrop())
add(GlideScaleTransformation(width = 100))

//Second
add(GlideScaleTransformation(width = 100))
add(RotationTransformer(degrees = 90))
add(CircleCrop())

In the first one we start with image rotation, then crop it into a circle and only after that we scale it. In the second scenario, we start with scaling.

Obviously, the second one seems more reasonable, because rotating and cropping of a small image demand fewer hardware resources.

Earlier we created the array that we’ll pass to Glide when it displays an image by URL. Now we build an object RequestOptions and pass the array to the object. If we pass an empty array, Glide will fail. So it is mandatory to add a verification.

val options = RequestOptions().apply {
    val transformations = image.getGlideTransformsArray(resources)
    if (transformations.isNotEmpty()) {
        transforms(*transformations)
    }
}

Glide.with(context)
    .load(url)
    .apply(options)
    .into(imageView)

We’re going to reuse transformations in different delegates, that’s why we can put them to the extension method applyImageTransformations.

internal fun RequestOptions.applyImageTransformations(resources: Resources, image: TransformableImage): RequestOptions = 
    apply {
        val transformations = image.getGlideTransformsArray(resources)
        if (transformations.isNotEmpty()) {
            transforms(*transformations)
        }
    }

fun getGlideRequestOptions(resources: Resources): RequestOptions = 
    RequestOptions().applyImageTransformations(resources, this)

Also, we add a method to the interface TransformableImage — getGlideTransformsArray. The interface and the extension method applyImageTransformations are marked as internal. It helps to avoid the leak of abstraction — Glide is not a part of the public interface. It’s important if we want to change Glide to any other library.

The code looks like this:

Glide.with(context)
    .load(image.url)
    .apply(image.getGlideRequestOptions(resources))
    .into(imageView)

Creating a delegate to display transaction

We already know how the adapter works. Let’s create a delegate to display the transaction. The basic version looks like this:

class ImageDelegate : BaseRecyclerViewDelegate<ImageDelegate.Model, ImageDelegate.Holder>(
    viewType = R.layout.delegate_image,
    rule = DelegateRule { _, data -> data is Model }
) {

    override fun onCreateViewHolder(parent: ViewGroup) = Holder(parent.inflate(viewType))

    override fun onBindViewHolder(holder: Holder, data: Model, pos: Int, payloads: List<Any>?) = Unit

    data class Model(
        override val listId: String
    ) : ListItem

    class Holder(itemView: View) : RecyclerView.ViewHolder(itemView) {
        val imageView: ImageView = itemView.image
    }
}

To simplify the code we skip displaying the text. We can make this delegate display transactions with pictures from web or resources, with contact userpic generated from the initial letters.

We start by modifying the model.

data class Model(
    override val listId: String,
    val resourceId: Int,
    val url: String? = null,
    val doubleLettersImage: String? = null
) : ListItem

In each case, we use specific parameters gathered in one place. The image will be displayed like this:

override fun onBindViewHolder(holder: Holder, data: Model, pos: Int, payloads: List<Any>?) {
    if (data.url != null) {
        //downloading and displayint by url
    } else if (data.doubleLettersImage != null) {
        //bitmap creation from the string and displaying
    } else {
        holder.imageView.setImageResource(data.resourceId)
    }
}

This solution has some disadvantages:

hard to extend;
the order is important, and it may not be obvious which order to choose;
the logic is inside the adapter (in the delegate).

Let’s try to use image delegates. In the model, we leave only the image to display instead of all other parameters.

class ImageDelegate(
    //
    private val imageDisplayer: ImageDisplayer
    //
) : BaseRecyclerViewDelegate<ImageDelegate.Model, ImageDelegate.Holder>(
    viewType = R.layout.delegate_image,
    rule = DelegateRule { _, data -> data is Model }
) {

    override fun onCreateViewHolder(parent: ViewGroup) = Holder(parent.inflate(viewType))

    override fun onBindViewHolder(holder: Holder, data: Model, pos: Int, payloads: List<Any>?) {
        //
        imageDisplayer.displayTo(data.image, holder.imageView)
        //
    }

    data class Model(
        override val listId: String,
        //
        val image: Image
        //
    ) : ListItem

    class Holder(itemView: View) : RecyclerView.ViewHolder(itemView) {
        val imageView: ImageView = itemView.image
    }
}

The transaction list will look like this:

listOf(
    ImageDelegate.Model(image = ResourceImage(R.drawable.ic_no_avatar)),
    ImageDelegate.Model(image = UrlImage("url to merchant")),
    ImageDelegate.Model(image = DoubleLettersImage("EZ")),
    ImageDelegate.Model(image = UrlImage("url to user avatar")),
)

Its behavior becomes more obvious, and also we take the logic out of the adapter.

Creating a delegate for generated images

Let’s take a particular case of creating a delegate that generates an image of two symbols. First of all, we define requirements for this delegate: it must be able to display the letters and adjust the image.

Hence, the model looks like this:

@Parcelize
data class DoubleLettersImage(
    val letters: String,
    @ColorRes val textColor: Int = Color.GRAY,
    @ColorRes val backgroundColor: Int = Color.TRANSPARENT,
    val sizeInDp: Int = 40,
    val textSizeInDp: Int = 40,
    override val transformations: ImageTransformations? = null
) : Image, TransformableImage

To adjust the background we use ImageTransformations.

Now let’s proceed to bitmap generation. For example, we can use TextDrawable, where the image is built with Canvas. Then we handle the bitmap and set it in ImageView.

private fun generateBitmap(image: DoubleLettersImage, resources: Resources): Bitmap {
    return TextDrawable.builder()
        .beginConfig()
        .textColor(image.textColor)
        .height(dpToPx(resources, image.sizeInDp))
        .width(dpToPx(resources, image.sizeInDp))
        .fontSize(spToPx(resources, image.textSizeInSp))
        .useFont(defaultFont)
        .endConfig()
        .buildBitmap(image.letters, image.backgroundColor);
}

As we use the extension, the delegate takes only a couple of lines. Here is how it works.

The first version with basic settings is:

At the second stage, we crop the image into a circle:

At the third stage, we rotate the image. So we can display the userpic icon as we need to follow the design guidelines.

Creating customized transformation

Let’s say, we need to flip the image horizontally. In order to do so, we build a transformation class framework.

class FlipTransformation private constructor(
    private val horizontal: Boolean
) : BitmapTransformation() {
    override fun transform(pool: BitmapPool, toTransform: Bitmap, outWidth: Int, outHeight: Int): Bitmap = TODO()

    override fun updateDiskCacheKey(messageDigest: MessageDigest) = Unit
}

If we use Glide, the basic class is BitmapTransformation: Glide makes our life easier because it contains TransformationUtils with methods we need. All we have to do is to add the transformation to others.

override fun transform(pool: BitmapPool, toTransform: Bitmap, outWidth: Int, outHeight: Int): Bitmap {
    val exifOrientation = if (horizontal) {
        ExifInterface.ORIENTATION_FLIP_HORIZONTAL
    } else {
        ExifInterface.ORIENTATION_FLIP_VERTICAL
    }
    return TransformationUtils.rotateImageExif(pool, toTransform, exifOrientation)
}

if (transformations?.centerCrop == true) {
    add(CenterCrop())
}
if (transformations?.flipHorizontal != null) {
    add(FlipTransformation(transformations?.flipHorizontal))
}
transformations?.radiusDp?.let { radius ->
    add(RoundedCorners(UiUtils.dpToPx(resources, radius.toFloat()).toInt()))
}

Testing

One of the main reasons why we use this solution is testability.

Let’s see how the clean architecture may look like, and see how data goes to the UI layer. We use the transaction list as data.

It looks pretty regular. The database returns the models list, and on the repository level, we map them into models of the domain level. Then it sends them to UI level. Each mapping stage is covered with tests.

This is how the domain transaction’s model looks like:

data class Transaction(
    val id: String,
    val amount: Money,
    val date: DateTime,
    val type: TransactionType
)

It contains the transaction’s id, amount and date. How does it understand if it’s a money transfer or a purchase? Where does it take the title or URL? The answer is the sealed class.

sealed class TransactionType {
    data class Transfer(
        val contactName: String,
        val contactAvatarUrl: String? = null
    ) :  TransactionType()

    data class CardPayment(
        val merchantName: String,
        val merchantRating: Double = 0.0,
        val merchantLogoUrl: String? = null
    ) :  TransactionType()
}

We see two transaction types — money transfer and purchase. Each of them has a unique set of parameters.

What is the model for the UI layer? Let’s go back to the delegate for the adapter RecyclerView.

class ImageDelegate(
    private val imageDisplayer: ImageDisplayer
) : BaseRecyclerViewDelegate<ImageDelegate.Model, ImageDelegate.Holder>(
    viewType = R.layout.delegate_image,
    rule = DelegateRule { _, data -> data is Model }
) {

    override fun onCreateViewHolder(parent: ViewGroup) = Holder(parent.inflate(viewType))

    override fun onBindViewHolder(holder: Holder, data: Model, pos: Int, payloads: List<Any>?) {
        imageDisplayer.displayTo(data.image, holder.imageView)
    }

    //
    data class Model(
        override val listId: String,
        val image: Image
    ) : ListItem
    //

    class Holder(itemView: View) : RecyclerView.ViewHolder(itemView) {
        val imageView: ImageView = itemView.image
    }
}

Delegate model can be perfectly used as a UI model.

Here are some cases we can test only with the help of delegates.

Case 1 — Money transfer to a contact without a userpic.

Transaction(
    id = "some_id",
    amount = Money(100, Currency.GBP),
    date = DateTime.parse("some_date"),
    type = TransactionType.Transfer(
        contactName = "Some Name"
    )
)

//should be mapped to:

ImageDelegate.Model(
    listId = "some_id",
    image = DoubleLettersImage(
        letters = "SN",
        transformations = ImageTransformations(
            circle = true
        )
    )
)

We expect that if there is no URL for userpic, the model to display the initial letters is created.

Case 2 — Money transfer to a contact with the userpic.

Transaction(
    id = "some_id",
    amount = Money(100, Currency.GBP),
    date = DateTime.parse("some_date"),
    type = TransactionType.Transfer(
        contactName = "Some Name",
        contactAvatarUrl = "some_url"
    )
)

//should be mapped to:

ImageDelegate.Model(
    listId = "some_id",
    image = UrlImage(
        url = "some_url",
        transformations = ImageTransformations(
            circle = true
        )
    )
)

We expect that UrlImage with a transformation will be created.

Case 3 — Purchase in a shop with the userpic.

Transaction(
    id = "some_id",
    amount = Money(100, Currency.GBP),
    date = DateTime.parse("some_date"),
    type = TransactionType.CardPayment(
        merchantName = "Netflix",
        merchantLogoUrl = "some_url"
    )
)

//should be mapped to:

ImageDelegate.Model(
    listId = "some_id",
    image = UrlImage(
        url = "some_url",
        transformations = ImageTransformations(
            circle = true
        )
    )
)

Same as the second: we expect that UrlImage with a transformation will be created.

Case 4 — Purchase in a shop without a userpic.

Transaction(
    id = "some_id",
    amount = Money(100, Currency.GBP),
    date = DateTime.parse("some_date"),
    type = TransactionType.CardPayment(
        merchantName = "Netflix"
    )
)

//should be mapped to:

ImageDelegate.Model(
    listId = "some_id",
    image = ResourceImage(
        drawableRes = R.drawable.ic_no_avatar
    )
)

Here we can make an additional test: every purchase can belong to a separate category, so the icons will differ. We can also check if we map categories in the relevant icons.

Conclusion

We benefit from using delegates.

First, we remove the logic that shouldn’t be in the adapter: it shouldn’t be responsible for the image source choice, depending on its parameters.

Secondly, we don’t depend on image loading and adjusting the method anymore. We can replace Glide with any other library at any moment.

Thirdly, we can check that image type we need is displayed, in other words, we can test the data displaying.

Displaying images in Android app: maintainable, testable, painless. Part I

Eugene Zubkov — Tue, 13 Jun 2023 13:42:29 +0000

If your app shows dozens of thousands of images, these images would most likely come from various sources: downloaded from the web, loaded locally, generated, etc.

Writing additional code for displaying every type is time-consuming, inefficient, not scalable and potentially causing a lot of pain and bugs.

Every time you add a new screen you will get swamped copypasting your essential code and swamped again fixing the bugs you created while copypasting.

What you really need instead of suffering this agony is a slick and elegant system to centralize the whole displaying process and fit the maintainable, testable and painless criteria.

Here is how we did it in Revolut's Android app.

The article is divided into two parts:

Part I - improving the legacy approach and building delegates,
Part II - making transformations, testing and summing-up the results.

Revolut app

There are several types of image use in Revolut app:

Transaction lists with various icons,
Cards lists,
Lottie animations,
GIFs.

Let's take a look at the transactions list. It may contain dozens of cell types, however, we'll pick five of them as an example.

Each image has its own source or can be generated.

The legacy approach

Following the legacy approach to displaying the list you would start with creating the adapter:

class TransactionsAdapter : RecyclerView.Adapter<TransactionsAdapter.ViewHolder>() {
    private var items = mutableListOf<Transaction>()

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): ViewHolder {
        val view = LayoutInflater.from(parent.context)
            .inflate(R.layout.view_transaction, parent, false)
        return ViewHolder(view)
    }

    override fun onBindViewHolder(holder: ViewHandler, position: Int) = Unit

    override fun getItemCount() = items.size

    class ViewHolder(itemView: View) : RecyclerView.ViewHolder(itemView) {
        private val imageView: ImageView = itemView.findViewById(R.id.image)
    }
}

That’s how a standard adapter for RecyclerView looks like. Binding would be the next step here:

override fun onBindViewHolder(holder: ViewHandler, position: Int) {
    val transaction = items[position]
    when {
        transaction.isContactWithAvatar() -> {
            //avatar loading and displaying
        }
        !transaction.isContactWithAvatar() -> {
            //avatar displaying
        }
        transaction.isMerchantWithAvatar() -> {
            //avatar loading and displaying
        }
        !transaction.isMerchantWithAvatar() -> {
            //loading an image from resources 
        }
    }
}

We get a long list of conditions because every type of transaction has its own display logic in the adapter. It can be even more complicated if we use a separate ViewType for each type (it is also led by the adapter contract):

override fun getItemViewType(position: Int): Int {
    val transaction = items[position]
    return when {
        transaction.isContactWithAvatar() -> VIEW_TYPE_CONTACT_WITH_AVATAR
        !transaction.isContactWithAvatar() -> VIEW_TYPE_CONTACT_WITHOUT_AVATAR
        transaction.isMerchantWithAvatar() -> VIEW_TYPE_MERCHANT_WITH_AVATAR
        !transaction.isMerchantWithAvatar() -> VIEW_TYPE_MERCHANT_WITHOUT_AVATAR
        else -> VIEW_TYPE_UNKNOWN
    }
}

As we know, there might be dozens of transaction types, and we can’t use this approach to build the adapter.

Improving the adapter

There are two basic approaches to the adapter’s extension — ViewType and delegates.

The ViewType approach can be used when the app is simple and contains only one list or a couple of screens. This is not our case because such an adapter can’t be reused. If we continue to extend the adapter and to add new ViewTypes, the adapter will constantly grow. Moreover, we’ll have to build new adapters for each screen in the app.

The delegates approach seems to be easier: we don’t need separate adapters for every screen. Four years ago Hannes Dorfmann described the approach, and today you may easily find a library for its implementation. We’ll use Dorfmann’s library.

Take a look at the simple delegate that displays ProgressBar:

class LoadingDelegate :
    AbsListItemAdapterDelegate<LoadingDelegate.Model, ListItem, LoadingDelegate.ViewHandler>() {
    override fun onCreateViewHolder(parent: ViewGroup): ViewHandler =
        ViewHandler(LayoutInflater.from(parent.context).inflate(R.layout.view_loading, parent, false))

    override fun isForViewType(item: ListItem, items: MutableList<ListItem>, position: Int): Boolean = item is Model

    override fun onBindViewHolder(item: Model, holder: ViewHandler, payloads: MutableList<Any>) = Unit

    data class Model(override val listId: String) : ListItem

    class ViewHandler(itemView: View) : RecyclerView.ViewHolder(itemView)
}

interface ListItem {
    val listId: String

    fun calculatePayload(oldItem: ListItem): Any? = null
}

We create a ViewHolder in the delegate as if we did it in standard adapters. After that, we go for binding. The main difference is that each delegate has its own model which will be used to display the cell type needed. Also, each model implements interface ListItem with the listId field and calculatePayloads method.

Let’s create an adapter that can display delegates:

class DiffAdapter(
    delegates: List<AdapterDelegate<List<ListItem>>>
) : AsyncListDifferDelegationAdapter<ListItem>(ListDiffCallback()) {
    init {
        delegates.forEach { delegate -> delegatesManager.addDelegate(delegate) }
    }

    private class ListDiffCallback<T : ListItem> : DiffUtil.ItemCallback<T>() {
        override fun areItemsTheSame(oldItem: T, newItem: T): Boolean = 
            oldItem.listId == newItem.listId

        override fun areContentsTheSame(oldItem: T, newItem: T): Boolean = 
            oldItem.equals(newItem)

        override fun getChangePayload(oldItem: T, newItem: T): Any? = 
            newItem.calculatePayload(oldItem)
    }
}

As you may have noticed, we can easily use the ListItem interface within the ListDiffCallback class, so that DiffUtil doesn’t refresh unchanged cells and doesn’t launch extra animations. Besides, as we use data class for models, equals are available out of the box. All we need to do with DiffUtil is to create the right model of the delegate.

The adapter for every screen is being created by declaring a list of delegates that the screen must support:

private val adapter by lazy {
    DiffAdapter(
        listOf(
            EmptyDelegate(),
            ErrorDelegate(),
            LoadingDelegate(),
            LoadMoreDelegate(),
            CardDelegate()
        )
    )
}

Displaying images

We remove the logic of loading and displaying images from the adapter, and we ease onBindViewHolder. Basically, we need to create two things — an image model and the delegate which will be able to load and display the image. Here is the example of a model where we load the image from sources:

interface Image : Parcelable

@Parcelize
data class ResourceImage(
    @DrawableRes val drawableRes: Int,
    @ColorRes val colorRes: Int? = null
) : Image

First, we build the interface Image. Then we describe a set of parameters for ResourceImage, that can be used to set the image. Particularly — image resource id and colors, if we want to paint it over.

After that, we move to delegate and create its interface. You can see why we need the interface Image.

interface ImageDisplayDelegate {

    fun suitsFor(image: Image): Boolean

    fun displayTo(image: Image, to: ImageView)

}

Each delegate must be able to:

understand if it can display the image or not,
display the image in ImageView.

Loading images from resources will look like this:

class ResourceImagesDisplayDelegate : ImageDisplayDelegate {

    override fun suitsFor(image: Image) = image is ResourceImage

    override fun displayTo(image: Image, to: ImageView) {
        Glide.with(to.context).clear(to)
        with(image as ResourceImage) {
            val drawable = ContextCompat.getDrawable(to.context, drawableRes)
            colorRes?.let { drawable?.setTint(ContextCompat.getColor(to.context, it)) }
            to.setImageDrawable(drawable)
        }
    }

}

You can see that:

Method suitsFor verifies that image is ResourceImage,
We set image in ImageView within the displayTo method, and if colorRes is not null, we set tint.

It’s the simplest of all possible delegates.

Combining delegates

It’s about time to combine all supported delegates in one place and to cut down the interface to the method displayTo.

class ImagesDisplayeDelegates : ImageDisplayer {
    protected val delegates = listOf(
        ResourceImagesDisplayDelegate(),
        UriImageDisplayDelegate(),
        LottieImageDelegate(),
        CountryImageLoader(),
        CurrencyImageDisplayDelegate(),
        BitmapImageDelegate(),
        GifResourseImageDisplayDelegate(),
        CardImagesDisplayDelegate(),
        GrayedOutImageDecoratorDisplayDelegate()
    )

    override fun displayTo(image: Image?, to: ImageView) {
        if (image != null) {
            //begin
            delegates.first { delegate -> delegate.suitsFor(image) }
                .displayTo(image, to)
            //end
        } else {
            to.setImageDrawable(null)
        }
    }
}

Check the highlighter line. Using the first method we find the first suitable delegate to display the image. If it’s not found, there will be a crash. And it’s not an error in the architecture: we intentionally use the fail-fast approach to get rid of unobvious behavior. Otherwise, if the image is not displayed, it’s hard to tell what’s causing the issue.

Stay tuned for the second part of the article to be released next week.