10 самых распространенных ошибок с Jetpack Compose

Jetpack Compose произвел революцию в создании пользовательского интерфейса для приложений Android, внедрив декларативный подход. Он упрощает многие аспекты разработки пользовательского интерфейса, но также вводит новые концепции, которые могут поставить в тупик даже опытных разработчиков. Вот 10 основных ошибок, которые многие из нас совершали при работе с Jetpack Compose, а также пояснения и фрагменты кода, которые помогут вам их избежать.

1. Не помнить о правильном использовании remember

В Jetpack Compose управление состоянием имеет решающее значение, и функция remember является ключевой частью этого процесса. Распространенная ошибка — забывать использовать remember, когда вам нужно сохранить значение во время перекомпоновки. Без remember при каждой рекомпозиции переменная будет инициализироваться заново, что приведет к проблемам с производительностью и ошибкам.

Пример с ошибкой:

var count by mutableStateOf(0)
Button(onClick = { count++ }) {
    Text("Count: $count")
}

var count by mutableStateOf(0)

Button(onClick = { count++ }) {

    Text("Count: $count")

}

Правильная версия:

var count by remember { mutableStateOf(0) }
Button(onClick = { count++ }) {
    Text("Count: $count")
}

xxxxxxxxxx

var count by remember { mutableStateOf(0) }

Button(onClick = { count++ }) {

    Text("Count: $count")

}

В исправленной версии remember гарантирует, что переменная count сохраняет свое значение при всех перекомпоновках.

2. Чрезмерное использование Modifier.fillMaxSize()

Modifier.fillMaxSize() часто используется для того, чтобы заставить композит заполнить все доступное пространство, но чрезмерное его использование может привести к загромождению и плохой структурированности пользовательского интерфейса. Лучше использовать этот модификатор только в случае необходимости и рассматривать альтернативные варианты, такие как Modifier.fillMaxWidth() или Modifier.fillMaxHeight(), в зависимости от потребностей макета.

Пример с ошибкой:

Column(
    modifier = Modifier.fillMaxSize()
) {
    Text("Title")
    Button(onClick = {}) {
        Text("Click me")
    }
}

xxxxxxxxxx

Column(

    modifier = Modifier.fillMaxSize()

) {

    Text("Title")

    Button(onClick = {}) {

        Text("Click me")

    }

}

Правильная версия:

Column(
    modifier = Modifier.fillMaxWidth().padding(16.dp)
) {
    Text("Title")
    Spacer(modifier = Modifier.height(8.dp))
    Button(
        onClick = {},
        modifier = Modifier.align(Alignment.CenterHorizontally)
    ) {
        Text("Click me")
    }
}

xxxxxxxxxx

Column(

    modifier = Modifier.fillMaxWidth().padding(16.dp)

) {

    Text("Title")

    Spacer(modifier = Modifier.height(8.dp))

    Button(

        onClick = {},

        modifier = Modifier.align(Alignment.CenterHorizontally)

    ) {

        Text("Click me")

    }

}

В данном случае использование функции fillMaxWidth() и правильные отступы приводят к лучшей структуризации макета.

3. Игнорирование оптимизаций производительности

Jetpack Compose поощряет декларативный стиль, но разработчики могут легко забыть о производительности, что приводит к неэффективному обновлению пользовательского интерфейса. Оптимизация перекомпоновки путем поднятия состояния, использования remember и избегания ненужной перекомпоновки — важнейшие методы.

Я рассказывал об этом в своей другой статье (или вот другая статья про уменьшение рекомпозиций).

Пример с ошибкой:

@Composable
fun MyComposable() {
    val name = getNameFromDatabase() // Expensive operation
    Text("Hello, $name")
}

xxxxxxxxxx

@Composable

fun MyComposable() {

    val name = getNameFromDatabase() // Expensive operation

    Text("Hello, $name")

}

Правильная версия:

@Composable
fun MyComposable() {
    val name by remember { mutableStateOf(getNameFromDatabase()) }
    Text("Hello, $name")
}

xxxxxxxxxx

@Composable

fun MyComposable() {

    val name by remember { mutableStateOf(getNameFromDatabase()) }

    Text("Hello, $name")

}

В правильной версии дорогостоящая операция getNameFromDatabase() выполняется только один раз, что повышает производительность.

4. Путаница со State и MutableState

State и MutableState часто путают, особенно новички. State доступно только для чтения, а MutableState позволяет вносить изменения, которые вызывают перекомпоновку. Важно правильно их использовать, чтобы эффективно управлять состоянием.

Пример с ошибкой:

val name: State<String> = remember by { mutableStateOf("John") }
name.value = "Doe" // Error: State is read-only

xxxxxxxxxx

val name: State<String> = remember by { mutableStateOf("John") }

name.value = "Doe" // Error: State is read-only

Правильная версия:

var name by remember { mutableStateOf("John") }
name = "Doe" // Accessing and updating directly

xxxxxxxxxx

var name by remember { mutableStateOf("John") }

name = "Doe" // Accessing and updating directly

Правильное использование MutableState обеспечивает обновление пользовательского интерфейса при изменении состояния.

5. Неправильное использование LaunchedEffect

LaunchedEffect — это мощный инструмент в Jetpack Compose, который позволяет выполнять функции приостановки и другие побочные эффекты в ответ на изменения жизненного цикла или состояния композабл. Однако его правильное использование требует хорошего понимания того, как он работает и когда его следует применять. Неправильное использование LaunchedEffect может привести к тому, что побочные эффекты будут запускаться в неожиданное время, выполняться чаще, чем нужно, или даже не выполняться, когда это ожидалось.

Давайте поговорим об этом немного подробнее.

Что такое LaunchedEffect?

LaunchedEffect — это композитная функция, которая запускает корутину при изменении определенного ключа. Эта корутина выполняется до тех пор, пока ключ остается неизменным, и автоматически отменяется, когда композабл покидает композицию или ключ меняется. Это делает LaunchedEffect идеальным для обработки побочных эффектов, таких как сетевые запросы, анимация или любые другие операции, которые должны запускаться при изменении состояния или свойства.

Распространенные ошибки и как их избежать

1. Неправильное указание ключа

Одна из самых распространенных ошибок — это неправильное указание ключа для LaunchedEffect. Ключ определяет, когда эффект должен быть повторно запущен. Если вы опустите ключ или используете постоянный ключ, например Unit, эффект запустится только один раз, когда композит войдет в композицию. В некоторых случаях это может быть то, что вам нужно, но часто вам нужно, чтобы эффект повторно запускался при изменении определенных зависимостей.

Пример с ошибкой:

@Composable
fun MyComposable(userId: String) {
    LaunchedEffect(Unit) {
        // Fetch user data when the composable is first composed
        val userData = fetchUserData(userId)
        // Update UI with the fetched data
    }
}

xxxxxxxxxx

@Composable

fun MyComposable(userId: String) {

    LaunchedEffect(Unit) {

        // Fetch user data when the composable is first composed

        val userData = fetchUserData(userId)

        // Update UI with the fetched data

    }

}

Проблема: Эффект LaunchedEffect запускается только один раз , когда композабл компонуется на экране. Если userId изменится, эффект не будет запущен снова, и в пользовательском интерфейсе будут отображаться устаревшие данные.

Правильная версия:

@Composable
fun MyComposable(userId: String) {
    LaunchedEffect(userId) {
        // Fetch user data whenever userId changes
        val userData = fetchUserData(userId)
        // Update UI with the fetched data
    }
}

xxxxxxxxxx

@Composable

fun MyComposable(userId: String) {

    LaunchedEffect(userId) {

        // Fetch user data whenever userId changes

        val userData = fetchUserData(userId)

        // Update UI with the fetched data

    }

}

Пояснение: Используя userId в качестве ключа, LaunchedEffect будет запускаться заново при каждом изменении userId, гарантируя, что пользовательский интерфейс всегда отражает текущие данные пользователя.

2. Провокация ненужных повторных вычислений

Если вы предоставите ключ, который меняется слишком часто, LaunchedEffect может запускаться чаще, чем необходимо, что приведет к проблемам с производительностью. Например, использование в качестве ключа неважной части состояния может привести к повторному запуску эффекта, когда в этом нет необходимости.

Пример с ошибкой:

@Composable
fun MyComposable(userId: String, userName: String) {
    LaunchedEffect(userName) {
        // Fetch user data when userName changes
        val userData = fetchUserData(userId)
        // Update UI with the fetched data
    }
}

xxxxxxxxxx

@Composable

fun MyComposable(userId: String, userName: String) {

    LaunchedEffect(userName) {

        // Fetch user data when userName changes

        val userData = fetchUserData(userId)

        // Update UI with the fetched data

    }

}

Проблема: Если имя пользователя часто меняется, но не влияет на логику получения данных, это может вызвать ненужные сетевые вызовы или операции, что приведет к неэффективности.

Правильная версия:

@Composable
fun MyComposable(userId: String) {
    LaunchedEffect(userId) {
        // Fetch user data only when userId changes
        val userData = fetchUserData(userId)
        // Update UI with the fetched data
    }
}

xxxxxxxxxx

@Composable

fun MyComposable(userId: String) {

    LaunchedEffect(userId) {

        // Fetch user data only when userId changes

        val userData = fetchUserData(userId)

        // Update UI with the fetched data

    }

}

Пояснение: Здесь в качестве ключа используется только userId, что гарантирует, что эффект будет выполняться только тогда, когда это необходимо.

3. Неправильное понимание жизненного цикла LaunchedEffect

LaunchedEffect запускается в контексте жизненного цикла элемента. Когда композабл выходит из композиции (например, удаляется из пользовательского интерфейса), корутин, запущенный LaunchedEffect, автоматически отменяется. Распространенной ошибкой является предположение, что LaunchedEffect будет продолжать работать даже после удаления композабл.

Пример с ошибкой:

@Composable
fun MyComposable(isVisible: Boolean, userId: String) {
    if (isVisible) {
        LaunchedEffect(userId) {
            // Fetch user data when the composable is visible
            val userData = fetchUserData(userId)
            // Update UI with the fetched data
        }
    }
}

xxxxxxxxxx

@Composable

fun MyComposable(isVisible: Boolean, userId: String) {

    if (isVisible) {

        LaunchedEffect(userId) {

            // Fetch user data when the composable is visible

            val userData = fetchUserData(userId)

            // Update UI with the fetched data

        }

    }

}

Проблема: Если значение isVisible становится ложным, эффект LaunchedEffect отменяется. Если isVisible снова становится истиной, эффект запускается повторно, что может привести к ненужной выборке данных или операциям.

Правильная версия:

@Composable
fun MyComposable(isVisible: Boolean, userId: String) {
    if (isVisible) {
        LaunchedEffect(userId) {
            // Fetch user data when the composable is visible
            val userData = fetchUserData(userId)
            // Update UI with the fetched data
        }
    } else {
        // Optionally handle the case when the composable is not visible
    }
}

xxxxxxxxxx

@Composable

fun MyComposable(isVisible: Boolean, userId: String) {

    if (isVisible) {

        LaunchedEffect(userId) {

            // Fetch user data when the composable is visible

            val userData = fetchUserData(userId)

            // Update UI with the fetched data

        }

    } else {

        // Optionally handle the case when the composable is not visible

    }

}

Пояснения: Понимание того, когда LaunchedEffect активен, поможет вам эффективнее управлять побочными эффектами. Если вам нужно выполнить очистку или другие операции, когда композит покидает макет, подумайте об использовании DisposableEffect вместо этого.

Лучшие практики использования LaunchedEffect

• Используйте значимые ключи: Убедитесь, что ключ, предоставляемый LaunchedEffect, представляет состояние, которое должно вызывать эффект. Это гарантирует, что эффект будет повторно запущен только тогда, когда он действительно необходим.
• Избегайте дорогостоящих операций при каждой перекомпозиции: Если ключ меняется слишком часто или если операция внутри LaunchedEffect является дорогостоящей, подумайте, можно ли перестроить код, чтобы избежать ненужных рекомпозиций.
• Поймите жизненный цикл: Осознайте, что LaunchedEffect привязан к жизненному циклу композабл. Он автоматически отменяется, когда композит покидает композицию, что полезно, но требует тщательного рассмотрения, чтобы избежать непредвиденного поведения.
• Рассмотрите возможность использования DisposableEffect для очистки: Если вам нужно выполнить очистку, когда элемент удаляется из композиции, DisposableEffect будет лучшим выбором, чем LaunchedEffect.

Понимая и правильно используя LaunchedEffect, вы сможете эффективно управлять побочными эффектами в своих приложениях Jetpack Compose, обеспечивая отзывчивость и эффективность пользовательского интерфейса.

6. Неправильное управление рекомпозицией

Рекомпозиция — это основная концепция Compose, но неправильное управление ею может привести к неэффективному обновлению пользовательского интерфейса и проблемам с производительностью. Стремитесь к тому, чтобы ваши композиты были как можно более статичными, и используйте remember для кэширования значений, которые не должны меняться при рекомпозиции.

Пример с ошибкой:

@Composable
fun MyComposable() {
    val list = (1..100).toList()
    list.forEach {
        Text("Item: $it")
    }
}

xxxxxxxxxx

@Composable

fun MyComposable() {

    val list = (1..100).toList()

    list.forEach {

        Text("Item: $it")

    }

}

Правильная версия:

@Composable
fun MyComposable() {
    val list = (1..100).toList()
    LazyColumn {
        items(list) { item ->
            Text("Item: $item")
        }
    }
}

xxxxxxxxxx

@Composable

fun MyComposable() {

    val list = (1..100).toList()

    LazyColumn {

        items(list) { item ->

            Text("Item: $item")

        }

    }

}

Правильная версия позволяет избежать регенерации списка при каждой перекомпоновке.

7. Переусложнение пользовательского интерфейса с помощью вложенных композабл

Jetpack Compose позволяет создавать глубоко вложенные элементы, но это может привести к сложностям в обслуживании и отладке кода. Чтобы избежать чрезмерного усложнения пользовательского интерфейса, сохраняйте модульность и возможность многократного использования композабл элементов.

Пример с ошибкой:

@Composable
fun ComplexUI() {
    Column {
        Row {
            Text("Name:")
            Text("John Doe")
        }
        Row {
            Text("Age:")
            Text("30")
        }
        // More nested rows...
    }
}

xxxxxxxxxx

@Composable

fun ComplexUI() {

    Column {

        Row {

            Text("Name:")

            Text("John Doe")

        }

        Row {

            Text("Age:")

            Text("30")

        }

        // More nested rows...

    }

}

Правильная версия:

@Composable
fun UserInfo(label: String, info: String) {
    Row {
        Text("$label: ")
        Text(info)
    }
}

@Composable
fun ComplexUI() {
    Column {
        UserInfo(label = "Name", info = "John Doe")
        UserInfo(label = "Age", info = "30")
        // Reuse UserInfo composable for other rows...
    }
}

xxxxxxxxxx

@Composable

fun UserInfo(label: String, info: String) {

    Row {

        Text("$label: ")

        Text(info)

    }

}

​

@Composable

fun ComplexUI() {

    Column {

        UserInfo(label = "Name", info = "John Doe")

        UserInfo(label = "Age", info = "30")

        // Reuse UserInfo composable for other rows...

    }

}

Такой модульный подход делает код более читаемым и удобным для сопровождения.

8. Неэффективное использование тем и стилей

Compose предоставляет мощную систему тем, но ее игнорирование может привести к несогласованности пользовательского интерфейса. Правильная настройка и использование темы обеспечивают целостный внешний вид и единое ощущение во всем приложении.

Пример с ошибкой:

@Composable
fun MyComposable() {
    Text("Hello, World!", color = Color.Blue, fontSize = 18.sp)
}

xxxxxxxxxx

@Composable

fun MyComposable() {

    Text("Hello, World!", color = Color.Blue, fontSize = 18.sp)

}

Правильная версия:

@Composable
fun MyComposable() {
    Text(
        "Hello, World!",
        style = MaterialTheme.typography.h6,
        color = MaterialTheme.colors.primary
    )
}

xxxxxxxxxx

@Composable

fun MyComposable() {

    Text(

        "Hello, World!",

        style = MaterialTheme.typography.h6,

        color = MaterialTheme.colors.primary

    )

}

Использование MaterialTheme для типографики и цветов обеспечивает единообразие во всем приложении.

9. Неадекватное тестирование

Compose упрощает написание UI-тестов, однако этим часто пренебрегают. Написание тестов гарантирует, что ваш пользовательский интерфейс будет вести себя правильно в различных состояниях и сценариях, что очень важно для надежности приложения.

Пример с ошибкой:

// No tests written for composables

xxxxxxxxxx

// No tests written for composables

Правильная версия:

@get:Rule
val composeTestRule = createComposeRule()

@Test
fun testMyComposable() {
    composeTestRule.setContent {
        MyComposable()
    }
    composeTestRule.onNodeWithText("Hello, World!").assertExists()
}

xxxxxxxxxx

@get:Rule

val composeTestRule = createComposeRule()

​

@Test

fun testMyComposable() {

    composeTestRule.setContent {

        MyComposable()

    }

    composeTestRule.onNodeWithText("Hello, World!").assertExists()

}

Написание тестов гарантирует, что ваши композабл будут вести себя так, как ожидается.

10. Пренебрежение доступностью

Доступность имеет решающее значение для создания инклюзивных приложений. Jetpack Compose предлагает такие инструменты, как semantics и contentDescription, но ими часто пренебрегают. Включение этих функций в процесс разработки гарантирует, что все смогут пользоваться вашим приложением.

Пример с ошибкой:

@Composable
fun ImageWithoutDescription() {
    Image(painter = painterResource(id = R.drawable.my_image), contentDescription = null)
}

xxxxxxxxxx

@Composable

fun ImageWithoutDescription() {

    Image(painter = painterResource(id = R.drawable.my_image), contentDescription = null)

}

Правильная версия:

@Composable
fun AccessibleImage() {
    Image(
        painter = painterResource(id = R.drawable.my_image),
        contentDescription = "Description of the image"
    )
}

xxxxxxxxxx

@Composable

fun AccessibleImage() {

    Image(

        painter = painterResource(id = R.drawable.my_image),

        contentDescription = "Description of the image"

    )

}

Добавление contentDescription делает пользовательский интерфейс доступным для пользователей, использующих программы чтения с экрана.

Заключение

Jetpack Compose — это мощный инструмент, упрощающий разработку пользовательского интерфейса для Android, но и он имеет свои сложности. Если вы будете знать об этих распространенных ошибках и о том, как их избежать, вы сможете создавать более эффективные, удобные и доступные приложения. Помните, что цель — не просто заставить ваш код работать, а сделать его надежным и простым в обслуживании. Счастливого кодинга!

Источник