Donovan LaDuke - Developer

Reusable Styles in Compose

2024-10-17T00:00:00Z

Sharing code helps reduce the complexity of making changes in a codebase by ensuring that the code that changes together, stays together. This can be accomplished through classes, functions, or even constants depending on the situation. In Jetpack Compose this is often accomplished by creating reusable composables. Another way to share UI logic is by leveraging shared modifier chains.

Modifier chains #

Due to the way that modifiers are applied we can treat Modifiers as reusable building blocks. A new modifier function can be created by making an extension function off Modifier that returns a Modifier. The basic syntax looks like this.

fun Modifier.paddedBorder(): Modifier {
  return this
    .border(1.dp, Color.Black)
    .padding(8.dp)
}

This example creates a reusable Modifier that applies a padding around the element and a border around that padding. While this example is simple, it illustrates the flexibility of this idea.

Use Cases #

This structure can be used to create shared styles that can be reused, remixed, and expanded upon. Additionally, it can create shared styling that can be applied to all kinds of layout components. For example this approach can be used to create a cardStyle() modifier which would allow adding card styling to any layout composable (e.g. Row, Column, etc).

fun Modifier.cardStyle(): Modifier {
  val shape = RoundedCornerShape(4.dp)

  return this
    .shadow(4.dp, shape)
    .background(Color.White)
}

Word of Warning #

Using modifiers this way can result in tying the codebase in knots if not used carefully, as is often the case with poorly executed styling in CSS. Here is a good list to consider when using this approach.

Avoid creating a deep nested "inheritance" of modifiers that makes them difficult to change/fix
Use this approach only for truly global "styles" or styles internal to a file/module
Don't use this approach for every modifier, the "atomic" nature of modifiers is beneficial for reuse and maintenance

Conclusion #

As always, view new approaches as a tool in the toolbox. Leverage this particular tool when a set of modifiers need grouped for a particular reason to improve reusability. Until next time, thanks!

Hidden Gems of the Kotlin Standard Library - List

2024-10-03T00:00:00Z

One of the greatest things about working in Kotlin is access to the Kotlin Standard Library. This extensive catalogue of types and helper functions assist in writing streamlined and efficient code. All this while not relying on excessive external dependencies or requiring each codebase to reimplement the same functionality over and over again. This is an overview of five hidden gems in the Standard Library.

orEmpty #

Dealing with nullable list can be a pain as calling functions on it requires a null traversal call for each function.

fun printDoubleStrings(
  strings: List<String>?
) {
  strings
    ?.map { "$it $it" }
    ?.forEach { println(it) }
}

By using the orEmpty function to covert a nullable list to an empty list, that can all be avoided.

fun printDoubleStrings(
  strings: List<String>?
) {
  strings
    .orEmpty()
    .map { "$it $it" }
    .forEach { println(it) }
}

Check out the docs here

filterIsInstance #

When leveraging a list of items that is of a interface or sealed class type, filtering by the type can be an effective way to work with the list.

sealed class Result {
  data class Success(
    val content: Float
  ): Result()
  data class Failure(
    val message: String
  ): Result()
}

fun logErrors(results: List<Result>) {
  val failures = results.filter {
    it is Result.Failure
  }

  println("Failure Messages")
  failures.forEach {
    println(
        (it as Result.Failure).message
    )
  }
}

This code can be streamlined by using filterIsInstance to only get objects of a specific type from the list. This also changes the type of the list downstream to the filtered type, removing unnecessary casting and type checking.

sealed class Result {
  data class Success(
    val content: Float
  ): Result()
  data class Failure(
    val message: String
  ): Result()
}

fun logErrors(results: List<Result>) {
  val failures = results
    .filterIsInstance<Result.Failure>()

  println("Failure Messages")
  failures.forEach {
    println(it.message)
  }
}

Check out the docs here

distictBy #

If a list should only have unique elements inside, using distinct will remove duplicates. But if the logic is not that simple, then the distinctBy function can be used.

data class Message(
  val id: Int,
  val content: String,
)

fun distinctMessages(
  messages: List<Message>
): List<Message> {
  return messages
    .distinctBy { it.id }
}

Check out the docs here

chunked #

If a list needs broken up into smaller lists of a given size, the chunked function can be used. This is helpful for creating a paged list if, for example, no more than a certain number of elements should be shown at a given time. As an additional note, if the list is not evenly divisible, the final list will contain the remaining elements.

fun pagedNumbers(
  range: IntRange
): List<List<Int>> {
  return range
    .toList()
    .chunked(5)
}

Check out the docs here

random #

This is just a fun helper that selects a random element from the list.

fun greetUser() {
  val greetings = listOf(
    "Hello!",
    "Hey!",
    "Hola!",
    "Salut!",
  )
  
  println(greetings.random())
}

Check out the docs here

Conclusion #

The Kotlin Standard Library is full of gems like this. Hopefully this has brought inspiration to look for more interesting functionality available through the Standard Library. Until next time, thanks!

Spacing Concepts in Jetpack Compose - An Overview

2024-09-19T00:00:00Z

When learning to create a UI in Jetpack Compose, it can become overwhelming to decide how best to create visual spacing in a UI. Spacing can be applied using a Spacer composable or the padding modifier or even using Arrangement. These can all create the same end effect, so how can one choose the "correct" solution? This article will lay out a mental model for choosing the right approach for fixed spacing situations that make the intent clear while improving long term maintainability.

Creating a Mental Model of Space in a UI #

When thinking of spacing it is important to consider the relationship between the components. The first relationship components can be in a "Parent-Child" relationship, i.e. one component is nested inside of the other. The other relationship is a "Sibling" relationship, i.e. the components are nested in the same wrapping (Parent) component. Now it is possible to outline approaches for each scenario.

Parent-Child Spacing #

In a Parent-Child relationship the most important consideration is who "owns" the spacing. It is best practice to have the parent own the spacing and not the child. This means that if there should be space between the parent and the child, then the modifier should be applied to the parent. In general most spacing between a parent and child are done with the padding modifier applied to the parent.

Sibling Spacing #

In a Sibling relationship, there are more valid options for creating spacing as there is not a clear-cut "owner" of the spacing. If the siblings are in a directional layout (i.e. a Column or Row) it is appropriate to use Arrangement.spaceBy and/or Spacer components. Use Arrangement.spaceBy on the parent layout if the siblings have equal space between each other. Use a Spacer composable if the spacing is irregular. Spacer can also be used in conjunction with Arrangement.spacedBy as a one-off inside an otherwise uniformly spaced layout.

When using the Spacer composable, adding the appropriate height or width modifier will create the expected spacing. It can be beneficial to create Spacer overloads that accept a height or width directly to simplify their use. Compare the existing Spacer(modifier = Modifier.height(8.dp) with the streamlined Spacer(height = 8.dp).

Here is this idea in code and can be copied for use in any project.

@Composable
fun Spacer(
  modifier: Modifier = Modifier,
  height: Dp = 0.dp,
  width: Dp = 0.dp,
) {
  androidx.compose.foundation.layout.Spacer(
    modifier = modifier.size(width, height)
  )
}

Touch Targets and Indicators #

One situation to be aware of where fixed spacing can get more complicated is when interactive elements need touch indicators. A common occurrence of this scenario is a list of elements that "appear" to have padding applied from the parent component. However if the padding is applied in that way, when the list items are clicked, the indicator will stop short of the screen edge. In this case, the end result requires moving the padding from the parent to the child. While this could seem in contradiction with the previous statement on ownership, it is important to consider that the touch indicator is owned by the child. This implies that the additional space does in-fact belong to the child and not the parent.

Conclusion #

Creating readable and consistent layouts in Jetpack Compose can be complex and no approach will be comprehensive. However, this framework makes it easier to think through what spacing approaches to apply and where. The result will be layouts that are more consistent and maintainable. Until next time, thank you!

Improve Compose UI with Spacing Constants

2024-09-05T00:00:00Z

A standard approach to laying out UI is to adhere to an 8pt grid system. This system ensures consistency in the look and feel of an application's UI and a smooth layout on a variety of screen sizes. But perhaps even more importantly, it gives a consistent language to be shared between developers and designers. This can result in better collaboration and less discrepancies between design and implementation. Once the team adopts this mindset, the next step is to set up the project to use this approach. Below is outlined an implementation using Jetpack Compose.

Approach #

The simplest way to implement this approach is to use an enum or sealed class in Kotlin and create new overloads for the assorted spacing modifiers and/or composables (e.g. padding and Spacer). Then utilize the new methods instead of the existing methods. Here is a simplified example as an overview of the approach.

Example #

First, set up the sealed class and wrap the underlying dp values so they can be easily accessed.

sealed class Dimen(val dp: Dp)

data object Space0: Dimen(0.dp)
data object Space1: Dimen(8.dp)
data object Space2: Dimen(16.dp)

Then, create new overloads for the relevant spacing modifiers and/or composables.

fun Modifier.padding(all: Dimen): Modifier 
  = this.padding(all = all.dp)

fun PaddingValues(
  all: Dimen = Space0
): PaddingValues {
  return PaddingValues(all = all.dp)
}

@Composable
fun DimenSpacer(
  height: Dimen = Space0,
  width: Dimen = Space0,
  modifier: Modifier = Modifier,
) {
  Spacer(
    modifier = modifier.size(
      height = height.dp,
      width = width.dp,
    )
  )
}

Finally, replace existing uses of hard-coded spacing values with the new components.

@Composable
fun TestComposable(
  modifier: Modifier = Modifier,
) {
  Row(modifier = modifier) {
    Text(text = "Hello") 
    Spacer(height = Space1)
    Text(
      text = "World",
      modifier = Modifier
        .padding(all = Space2),
    )
  }
}

That's all it takes to start adopting a formal set of spacing constants.

The Why #

The immediate question is why bother? It may seem like a lot of overhead and Modifier.padding(all = 8.dp) looks pretty similar to Modifier.padding(all = Spacing1)? The short answer is that the version with a hard-coded constant 8.dp could easily become 7.dp and it wouldn't stand out. By constraining the valid values there is a pit of success that ensures consistency from both developers and designers. For designers, they get immediate feedback from developers if a value doesn't conform to the 8-pt grid and any deviation becomes an intentional choice. On the developers side, it becomes obvious in code review if an invalid size is used, ensuring consistent and correct values.

Conclusion #

Adopting spacing constants can be a benefit to both the project and the team by creating a consistent language of design. Consider trying this in a project to see how it works and as always tweak as necessary. Until next time, thanks!

Replace Useless Cases with Interfaces

2024-08-15T00:00:00Z

A previous blog post discussing the value in removing useless cases, encouraged interacting with the repository layer directly instead of creating use case classes that acted as mere pass throughs for the repository layer. This is a great approach, but might not work in all scenarios. For example a team might want to always have a use case either for consistency sake or for separation of concerns. This post offers a different solution to keep the architectural benefits of use cases without the bloat of pass through classes.

The Approach #

The biggest issue with creating pass through use cases, is the existence of a bunch of useless code that does nothing valuable. However, there might be reasons a given project chooses to adopt an "always have a use case" philosophy. What that approach does not imply is that a class must exist for each use case. By leveraging an interface, the use case can be implemented by the repository class instead of a dedicated class. This keeps the architecture while removing the bloat.

Example #

This example shows a basic implementation of a counter using this pattern.

First, start with a basic repository.

class CounterRepository {
  private val _value = StateFlow(0)
  val value: Flow<Int> = _value

  fun addOne() { _value.update { it + 1 } }
  fun subOne() { _value.update { it - 1 } }
}

Then add a set of use case interfaces like this.

interface AddUseCase { fun addOne() }

interface SubUseCase { fun subOne() }

interface GetValueUseCase { 
    val value: Flow<Int> 
}

Now the repository can implement these interfaces.

class CounterRepository: 
  AddUseCase, 
  SubUseCase, 
  GetValueUseCase {
    override val value: Flow<Int> ...

    override fun addOne() ...
    override fun subOne() ...
}

Finally, the use cases can be used in the code like usual.

class CountingViewModel(
  private val addOne: AddOneUseCase,
  private val subOne: SubUseCase,
  private val getValue: GetValueUseCase,
): ViewModel() {
  ...
}

To complete the work, fulfill the dependencies using the repository for the use cases. This will be dependent on the dependency framework used in the project.

Aside: Leveraging the invoke operator #

A common pattern with use cases is to expose the invoke operator. With this approach that isn't possible in the interface due to the overloading of the invoke operator by the repository from multiple use cases. A work around is to add an invoke operator extension on each use case interfaces which avoids both the conflicting function names and the need for the repository to implement the function with the trade-off that now the use case exposes two functions.

interface AddUseCase { fun addOne() }

operator fun AddUseCase.invoke() { 
    this.addOne() 
}

While this approach adds a small layer of pass through, it is a single function that is easily updated if the time comes to add more functionality to the use case.

Conclusion #

With those small changes, the use cases now serve an architectural purpose without introducing additional unnecessary bloat. To see a more fleshed out example using Hilt, check out this gist. Until next time, thanks!

How to Add an aiexclude File

2024-08-01T00:00:00Z

At Google I/O 2024, Google announced support for a code generation tool powered by their Gemini LLM in Android Studio. While this feature can be a useful tool in some cases, there are likely parts of a code base that shouldn't be shared with a third party such as business critical or proprietary code. This oversharing can be avoided by adding an .aiexclude file to your project.

Formatting an .aiexclude File #

Opting out files from Gemini is as simple as adding an .aiexclude file in the root of the project or in the specific subfolder that should be excluded. To ignore all file, just leave the file blank or add the single * selector. If specific files should be matched, the syntax is similar to a .gitignore file with some notable exceptions. See the documentation page for all the specifics. And just like that, the code that should be private won't be sent to Google.

Conclusion #

One quick note as a wrap up, any files covered by the .aiexclude file will not get Gemini powered autocomplete, so it is a trade-off between privacy and productivity. Now the project team can leverage AI enabled autocomplete if that is desired while protecting the specific code that shouldn't be shared. Until next time, thanks!

Cross-Document View Transitions

2024-07-18T00:00:00Z

Websites with full page reloads can often result in users perceiving a website as slow. This, amongst many other reasons, has driven developers to choose Single Page Application (SPA) frameworks like React, Vue, and Angular. This can be a great choice for many web apps, but other sites would benefit from choosing a traditional multi-page approach. For example this blog is built using 11ty a JS based static site generator which means each page will show a loading transition between loads. Now however with Cross-Document View Transitions, as shown off at Google I/O this year, the perception of quick, integrated, page loading is possible with multi-page sites.

To add support to a website, add the following snippet CSS block to your CSS file to turn navigation transitions on. Just by adding this block, the website will now perform a subtle fade between screens.

@view-transition {
  navigation: auto;
}

Note, a preview version of the API required adding a view-transition meta tag to your head block, this is no longer required and is instead replaced with the above CSS solution.

Adding Multi-Page Application Element Transitions #

If there are shared elements that should animate between pages to show continuity, this can be accomplished with the view-transition-name CSS property. By applying view-transition-name to the elements the browser will identify the element as being shared and generate the transition animation. The view-transition-name needs to be applied to elements on both screens in order for the animation to work, otherwise it will be ignored.

<!-- Page 1 -->
<a href="/page2" style="view-transition-name: page-2-title">Page 2 Title</a>

<!-- Page 2 -->
<h1 style="view-transition-name: page-2-title">Page 2 Title</h1>

Now when a user navigates between "Page 1" and "Page 2" in the above example, the page-2-title element will animate by moving and resizing to show continuity. This animation works both forward and backwards, so there is no additional work required to support the user pressing the back or forward button.

Browser Support #

As of writing this article this feature is only available in Chrome and Microsoft Edge. However, there is no current plans for support in FireFox or Safari so users of those browsers will retain the existing experience. See this MDN article for more details and up to date support.

Quick Notes #

Progressive Enhancement - This feature is a great example of progressive enhancement, giving users of old or non-supporting browsers the existing experience, while giving users of more modern browsers an upgraded experience.
Unique Ids - The view-transition-name variables must be unique per page or the animations will fail to play. This means if there are multiple links in a list/detail view, every element will need a uniquely generated id.
Custom Animations - If the default animation is not what is desired, the animations for entering and exiting can be overridden with the ::view-transition-new and ::view-transition-old pseudo-element selectors.
Accessibility Motion Support - If the animation played results in a lot of motion, strongly consider using the prefers-reduced-motion media query to disable the animations.
Ensuring Elements Exist - If the other page will take a moment to load before rendering, consider adding a blocking render link like this <link rel="expect" blocking="render" href="#my-id"> to ensure the animation plays smoothly.
Cross-Document, Same-Domain - While the elements exist on different pages, they must exist in the same domain. So transitions between www.example.com and www.example.com/page2 will work but not www.example.com and page2.example.com.

Conclusion #

Want to see this in action? If you navigated to this article from somewhere else on this site and are using Chrome, then the animation probably already played. When navigating between pages, the pages softly fade between one another and the post header information animates seamlessly between lists and posts. Feel free to navigate around to experience the animation and consider adding support for this new enhancement to give users an even better experience while traversing the web. Until next time, thanks!

Improving Perceived Performance with Delayed Visibility

2024-07-04T00:00:00Z

While improving performance is an important metric, an equally important metric is perceived performance. Users will often care less about how fast a piece of software is as compared to how fast the software feels. While there are many approaches to accomplishing this, the one this article will show is preventing unnecessary loading spinners.

Delayed Visibility #

When loading data, the UI is unlikely to know if the data will be loaded from a fast source (like an in-memory cache) or a slow source (like a network request). In this case the naive solution is to just always show a loading indicator. This will work just fine in the "slow source" scenario, but for "fast sources" this will lead to a flickering effect where the indicator is shown briefly before disappearing.

To avoid this flicker, a brief rendering delay can be added to the loading indicator. By choosing a short delay before rendering (like 100ms), the loading spinner will show quick enough to let the user know a "slow source" is loading, but will hide quick enough that the indicator won't render for a "fast source".

There are likely several ways of accomplishing this, but here is an example inspired by this Stack Overflow post on a visibility modifier and this summary on delaying a composable's visibility.

@Composable
fun Modifier.delayedVisibility(delay: Duration): Modifier {
  var show by remember { mutableStateOf(false) }

  LaunchedEffect(Unit) {
    launch {
      delay(delay)
      show = true
    }
  }

  return layout { measurable, constraints ->
    val placeable = measurable.measure(constraints)

    layout(placeable.width, placeable.height) {
      if (show) {
        placeable.placeRelative(0, 0)
      }
    }
  }
}

Then in practice, the modifier is used as follows.

@Composable
fun ExampleComposable(isLoading: Boolean) {
  if(isLoading) {
    CircularProgressIndicator(
      modifier = Modifier.delayedVisibility(
        delay = 100.milliseconds,
      )
    )
  } else {
    // TODO Content
  }
}

This usage could be further refined by incorporating an AnimatedVisibility or other animations to improve the transition between states, giving an even more seamless illusion for the end user.

Conclusion #

While the best thing to do for users is actually improve performance, that isn't always feasible and has limits. Improving perceived performance is a great way to smooth over the rough edges that naturally occur when developing apps for mobile devices. Consider using delayed visibility to give users the perception of a faster app experience. Until next time, thanks!

Using Lists in Compose Previews

2024-06-20T00:00:00Z

When making a Compose component there are scenarios where it is helpful to preview several variations of the component. At the start, just creating separate preview functions for each can work just fine, but as the number of previews grows this becomes unmaintainable. A solution for this is presented in the documentation using PreviewParameterProvider which can be found here. This solution works, but using a List is far more common than using a Sequence. Thankfully there is a built-in implementation for this that doesn't require calling asSequence on the List.

Enter CollectionPreviewParameterProvider #

The CollectionPreviewParameterProvider implementation of PreviewParameterProvider is a class that takes a single parameter of Collection<T> which is a supertype of List, this means the list can be passed directly in, no conversion necessary. Then inside the class is converted to a Sequence without the implementer ever having to think about it. Here is the example from the documentation updated to use a CollectionPreviewParameterProvider.

class UserPreviewParameterProvider 
  : CollectionPreviewParameterProvider<User>(
  collection = listOf(
    User("Elise"),
    User("Frank"),
    User("Julia")
  )
)

@Preview
@Composable
fun UserProfilePreview(
  @PreviewParameter(UserPreviewParameterProvider::class) 
  user: User
) {
  UserProfile(user)
}

Conclusion #

With this simple change using an existing list of dummy data becomes trivial and will work the same as PreviewParameterProvider in most cases. To learn more about approaches to previewing composables check out my article here. Until next time, thanks!

Dynamic Layouts with ContextualFlowRow and ContextualFlowColumn

2024-06-06T00:00:00Z

At Google I/O 2024, a new layout component for Compose was announced, the "Contextual Flow Layout", including both a ContextualFlowRow and ContextualFlowColumn. These new components allow for layouts that show a fixed number or rows or columns respectively while filling the allocated space. This has major advantages for creating consistent layouts for dynamic lists without a ton of work, but also makes screens better adapt to large form factor devices like tablets and foldables.

A Note on FlowRow and FlowColumn #

FlowRow and FlowColumn also received updates with similar parameters including maxLines and overflow, however there are some key differences. For one the contextual layouts provide an index and other scoped values for rendering elements for the content parameter that are not available to the base flow layouts. Additionally, there are stricter requirements around when you access counts in the overflow context. More importantly, unlike the contextual flow layouts, they are not lazy layouts. For this article, the focus will remain on the contextual flow layouts and the examples may not be transferable to use with FlowRow or FlowColumn even if the parameters are similar.

ContextualFlowRow & ContextualFlowColumn #

The API for ContextualFlowRow and ContextualFlowColumn are generally the, same so going forward the examples will show ContextualFlowRow unless there is something to highlight specifically with ContextualFlowColumn. To begin, here is a simple usage of a ContextualFlowRow.

// Values Provided as Example
val items = List(100) { Random.nextFloat() }

ContextualFlowRow(
  itemCount = items.size,
  maxLines = 3,
  maxItemsInEachRow = Int.MAX_VALUE,
  horizontalArrangement = Arrangement.Start,
  verticalArrangement = Arrangement.Top,
  overflow = ContextualFlowRowOverflow.Clip,
  modifier = Modifier,
) { index ->
  Text(text = items[index].toString())
}

Parameters #

First is itemCount: Int which is the only required parameter besides content. This parameter tells the layout how many items are in the list which allows the component to know if there are more items to layout and enables lazily laying out the elements.

Next is maxLines: Int which tells the component how many rows to layout before applying the overflow policy (more on that soon). By default the value is Int.MAX_VALUE which would effectively mean never apply the overflow policy. This parameter is the same in ContextualFlowColumn but applies to the number of columns instead of rows. This parameter is unaware of the size of the line and will keep laying out components so long as it has space. If the specific number of elements in a line should be restricted, use the maxItemsInEachRow: Int to do so. This parameter is defaulted to Int.MAX_VALUE, which is effectively no limit.

There are two parameters for arranging components within the Contextual Flow Layout, horizontalArrangement: Arrangement and verticalArrangement: Arrangement. These work similar to Column and Row arrangement parameters. For both ContextualFlowRow and ContextualFlowColumn the default values are Arrangement.Start for horizontalArrangement and Arrangement.Top for verticalArrangement.

The last three parameters are the standard modifier: Modifier parameter, the overflow: ContextualFlowRowOverflow which applies an overflow policy (overflow: ContextualFlowColumnOverflow for ContextualFlowColumn), and the content: @Composable ContextualFlowRowScope.(index: Int) -> Unit block (content: @Composable ContextualFlowColumnScope.(index: Int) -> Unit for ContextualFlowColumn). The Content Block and Overflow Policy are the bread and butter of the contextual flow layouts and will be covered in their own sections below.

Content Block #

Contextual flow layouts are lazy layouts so elements not visible are not in the composition. To assist in this, the content block of the contextual flow layouts provides an index which can be used to look up the current item and then render a composable for the current item. The content is also in a ContextualFlowRowScope which gives access to a few more values that can be helpful in more complex layouts.

maxHeight - The maximum vertical space allowed for the element in the given row (maxWidth in ContextualFlowColumn)
maxWidthInLine - The maximum horizontal space available for the element in the current row (maxHeightInLine in ContextualFlowColumn)
lineIndex - The index of the line the element is being placed in (e.g. 1 for the second row)
indexInLine - The index of the element in the line (e.g. 3 for the fourth element in the row)

Together, these can be used to create complex and dynamic layouts within the content block. Below is a simple example that displays values in a checkerboard style pattern.

ContextualFlowRow(
  itemCount = 64,
  maxItemsInEachRow = 8,
  modifier = Modifier.padding(innerPadding)
) { index ->
  val color = when(lineIndex % 2 == 0) {
    true -> if(indexInLine % 2 == 0) {
      Color.Black 
    } else { 
      Color.Red
    }
    false -> if(indexInLine % 2 == 0) {
      Color.Red 
    } else { 
      Color.Black
    }
  }

  Box(modifier = Modifier.size(48.dp).background(color)) {
    Text(text = index.toString(), color = Color.White)
  }
}

Overflow Policy #

There are four overflow policies provided to use and they are Clip, Visible, expandIndicator, and expandOrCollapseIndicator.

Clip #

This policy hides all elements that don't fit within the maxLines. This is the default setting for ContextualFlowRow and ContextualFlowColumn.

overflow = ContextualFlowRowOverflow.Clip

Visible #

This policy shows all elements, even those that don't fit within the maxLines.

overflow = ContextualFlowRowOverflow.Visible

expandIndicator #

This policy hides all the elements and shows the provided content if there are hidden elements. This content block which is provided to the expandIndicator is in the context of ContextualFlowRowOverflowScope. This scope provides the shownItemCount and totalItemCount. These can be used to provide information to the user about the displayed elements including the number of hidden elements (totalItemCount - shownItemCount). The content block is a generic composable so it is up to the consumer to provide appropriate UI and functionality.

overflow = ContextualFlowRowOverflow.expandIndicator {
  val hiddenCount = totalItemCount - shownItemCount
  Button(onClick = { /* TODO: Show Items */ }) {
    Text(text = "Show $hiddenCount Hidden Item(s)")
  }
}

expandOrCollapseIndicator #

This policy build upon by the expandIndicator policy by adding an additional parameter for a collapse indicator that shows when all elements are visible. Like the expandIndicator policy, both the expandIndicator and collapseIndicator parameters are in the ContextualFlowRowOverflowScope. In addition to the expandIndicator and collapseIndicator parameters, this policy also takes a minRowsToShowCollapse for specifying the minimum visible lines before collapse is shown and minHeightToShowCollapse for specifying a minimum space available before showing the collapseIndicator (minColumnsToShowCollapse and minWidthToShowCollapse respectively for ContextualFlowColumn) The intent of this is to allow expanding to show all, and collapsing back to the previous state. Again like the expandIndicator, the

overflow = ContextualFlowRowOverflow
  .expandOrCollapseIndicator(
    expandIndicator = {
      val hiddenCount = totalItemCount - shownItemCount
      Button(onClick = { /* TODO: Show Items */ }) {
        Text(text = "Show $hiddenCount Hidden Item(s)")
      }
    },
    collapseIndicator = {
      Button(onClick = { /* TODO: Show Less */ }) {
        Text(text = "Show Less")
      }
    },
  )

Conclusion #

A demonstration app using the new components can be found here on GitHub for exploration. Contextual flow layouts open up a whole new set of opportunities for developing dynamic layouts. Until next time, thanks!

Donovan LaDuke - Developer

Reusable Styles in Compose

Modifier chains #

Use Cases #

Word of Warning #

Conclusion #

Hidden Gems of the Kotlin Standard Library - List

orEmpty #

filterIsInstance #

distictBy #

chunked #

random #

Conclusion #

Spacing Concepts in Jetpack Compose - An Overview

Creating a Mental Model of Space in a UI #

Parent-Child Spacing #

Sibling Spacing #

Touch Targets and Indicators #

Conclusion #

Improve Compose UI with Spacing Constants

Approach #

Example #

The Why #

Conclusion #

Replace Useless Cases with Interfaces

The Approach #

Example #

Aside: Leveraging the invoke operator #

Conclusion #

How to Add an aiexclude File

Formatting an .aiexclude File #

Conclusion #

Cross-Document View Transitions

Adding Multi-Page Application Navigation Transitions #

Adding Multi-Page Application Element Transitions #

Browser Support #

Quick Notes #

Conclusion #

Improving Perceived Performance with Delayed Visibility

Delayed Visibility #

Conclusion #

Using Lists in Compose Previews

Enter CollectionPreviewParameterProvider #

Conclusion #

Dynamic Layouts with ContextualFlowRow and ContextualFlowColumn

A Note on FlowRow and FlowColumn #

ContextualFlowRow & ContextualFlowColumn #

Parameters #

Content Block #

Overflow Policy #

Clip #

Visible #

expandIndicator #

expandOrCollapseIndicator #

Conclusion #