What’s new in Android Studio Iguana
Обзор фичей новой Android Studio Iguana.
Debugging
• Version control in App Quality Insights
• View Crashlytics in App Quality Insights
Design
• Jetpack Compose UI Check
• Progressive rendering for Compose Preview
Develop
• Intellij platform update
Testing
• Baseline Profiles wizard
• Espresso Device API
• The latest Android Virtual Devices
Build
• Support for Gradle Version Catalogs
• Policy issue warnings in Google Play SDK Index
• CompileSDK version support
Читать (En) | Смотреть (En)
Обзор фичей новой Android Studio Iguana.
Debugging
• Version control in App Quality Insights
• View Crashlytics in App Quality Insights
Design
• Jetpack Compose UI Check
• Progressive rendering for Compose Preview
Develop
• Intellij platform update
Testing
• Baseline Profiles wizard
• Espresso Device API
• The latest Android Virtual Devices
Build
• Support for Gradle Version Catalogs
• Policy issue warnings in Google Play SDK Index
• CompileSDK version support
Читать (En) | Смотреть (En)
Hilt, ViewModels & Assisted Injection
Если пропустили, там это, в Hilt подвезли поддержку Assisted Injection. Если используете Hilt, в статье смотрите как использовать.
Читать (En)
Если пропустили, там это, в Hilt подвезли поддержку Assisted Injection. Если используете Hilt, в статье смотрите как использовать.
Читать (En)
Container transform animation with Jetpack Compose
На данный момент в Jetpack Compose нет поддержки shared element transitions, но если вам хочется сделать нечто подобное, читайте статью.
Там рассказывается, как сделать похожее с помощью AnimatedContent.
Читать (En)
На данный момент в Jetpack Compose нет поддержки shared element transitions, но если вам хочется сделать нечто подобное, читайте статью.
Там рассказывается, как сделать похожее с помощью AnimatedContent.
Читать (En)
How to Drag and Drop using Modifier.dragAndDropSource/Target — Jetpack Compose
Подробный гайд по реализации Drag and Drop в Jepack Compose с помощью модификаторов dragAndDropSource и dragAndDropTarget.
Читать (En)
Подробный гайд по реализации Drag and Drop в Jepack Compose с помощью модификаторов dragAndDropSource и dragAndDropTarget.
Читать (En)
Ликбез по вложенной прокрутке в Jetpack Compose
Перевод статьи про вложенный скроллинг в Jetpack Compose.
Читать (Ru)
Перевод статьи про вложенный скроллинг в Jetpack Compose.
Читать (Ru)
Как и где практиковаться начинающему мобильному разработчику
В статье рассказывается, как начинающим разработчикам можно прокачивать свои знания и применять их на практике.
👉 Пет-проекты
👉 Известные приложения
👉 Вклад в Open Source
👉 Хакатоны
👉 Тестовые задания
👉 Стажировки
👉 Решение алгоритмических задач
👉 Портфолио на Github
Читать (Ru)
В статье рассказывается, как начинающим разработчикам можно прокачивать свои знания и применять их на практике.
👉 Пет-проекты
👉 Известные приложения
👉 Вклад в Open Source
👉 Хакатоны
👉 Тестовые задания
👉 Стажировки
👉 Решение алгоритмических задач
👉 Портфолио на Github
Читать (Ru)
Seven recipes to understand flows and asynchrony in Kotlin
Статья с наглядными примерами, про асинхронность в Kotlin и flows в частности: зачем нужны flows, отличия горячих от холодных, как преобразовать коллбеки в suspend функции и flows и т.д.
👉 Java callbacks, the bad old days
👉 Doing callbacks the Kotlin way: suspendCoroutine
👉 Suspend functions can only return once
👉 Using callbackFlow to return multiple things from an async callback
👉 Collecting a flow
👉 Cold flows and awaitClose
👉 SharedFlow and multiple collectors
👉 Sharing a cold flow, making it hot
Читать (En)
Статья с наглядными примерами, про асинхронность в Kotlin и flows в частности: зачем нужны flows, отличия горячих от холодных, как преобразовать коллбеки в suspend функции и flows и т.д.
👉 Java callbacks, the bad old days
👉 Doing callbacks the Kotlin way: suspendCoroutine
👉 Suspend functions can only return once
👉 Using callbackFlow to return multiple things from an async callback
👉 Collecting a flow
👉 Cold flows and awaitClose
👉 SharedFlow and multiple collectors
👉 Sharing a cold flow, making it hot
Читать (En)
Optimize App Performance By Mastering Stability in Jetpack Compose
Ещё одна статья про управление стабильностью в Jetpack Compose и понимание внутренней работы Compose для повышения производительности вашего приложения.
👉 Jetpack Compose Phases
👉 Understanding Stability
👉 Inferring Composable Functions
👉 Stability Annotations
👉 Stabilize Composable Functions
👉 Stability In Multi-Module Architecture
👉 Strong Skipping Mode
Читать (En)
Ещё одна статья про управление стабильностью в Jetpack Compose и понимание внутренней работы Compose для повышения производительности вашего приложения.
👉 Jetpack Compose Phases
👉 Understanding Stability
👉 Inferring Composable Functions
👉 Stability Annotations
👉 Stabilize Composable Functions
👉 Stability In Multi-Module Architecture
👉 Strong Skipping Mode
Читать (En)
Вы за это заплатите! Цена Чистой Архитектуры
Статья о способах обеспечения масштабируемости проекта и как этому может навредить неправильное восприятие Чистой Архитектуры.
👉 Цена и ценность. Немного теории
👉 Для чего нужен SOLID?
👉 На чём основана Чистая Архитектура
👉 Непонимание терминологии
👉 Противопоставление Чистой Архитектуры другим архитектурам
👉 Что делает Чистую Архитектуру дорогой?
👉 Примеры
Читать (Ru)
Статья о способах обеспечения масштабируемости проекта и как этому может навредить неправильное восприятие Чистой Архитектуры.
👉 Цена и ценность. Немного теории
👉 Для чего нужен SOLID?
👉 На чём основана Чистая Архитектура
👉 Непонимание терминологии
👉 Противопоставление Чистой Архитектуры другим архитектурам
👉 Что делает Чистую Архитектуру дорогой?
👉 Примеры
Читать (Ru)
Avoid "Useless" Cases in Layered Architecture
Автор рассказывает про бесполезность UseCase`ов, которые не содержать логики и предлагает избавляться от таких сущностей, дабы не засорять кодовую базу.
Существуют разные мнения на этот счёт: кто-то предпочитает использовать по необходимости, кто-то вообще не использует UseCase`ы и т.д. Я считаю, нужно либо использовать везде, либо не использовать вообще. Но лучше использовать 😉 и вот почему:
Во-первых – Единообразие. Если в проекте используются UseCase`ы, то будет лучше использовать такие сущности везде, даже если они не содержат никакой логики и просто проксируют вызов репозитория, дабы поддерживать проект в едином стиле. Кодовая база, написанная в едином стиле, будет проще для понимания и восприятия.
Во-вторых – Переиспользование. Если мы переиспользуем UseCase`ы, при любых изменениях в будущем, нам не нужно будет вносить правки во все места, где используется текущая функциональность. При использовании репозитория напрямую, нужно будет вносить везде.
В-третьих – Стандарт. Если уж используется слоёная архитектура, то зачем игнорировать один из слоёв?!🤔
Да, со вторым пунктом конечно можно поспорить, мол возможно и не будет правок в будущем, но всё же.
Читать (En)
Автор рассказывает про бесполезность UseCase`ов, которые не содержать логики и предлагает избавляться от таких сущностей, дабы не засорять кодовую базу.
Существуют разные мнения на этот счёт: кто-то предпочитает использовать по необходимости, кто-то вообще не использует UseCase`ы и т.д. Я считаю, нужно либо использовать везде, либо не использовать вообще. Но лучше использовать 😉 и вот почему:
Во-первых – Единообразие. Если в проекте используются UseCase`ы, то будет лучше использовать такие сущности везде, даже если они не содержат никакой логики и просто проксируют вызов репозитория, дабы поддерживать проект в едином стиле. Кодовая база, написанная в едином стиле, будет проще для понимания и восприятия.
Во-вторых – Переиспользование. Если мы переиспользуем UseCase`ы, при любых изменениях в будущем, нам не нужно будет вносить правки во все места, где используется текущая функциональность. При использовании репозитория напрямую, нужно будет вносить везде.
В-третьих – Стандарт. Если уж используется слоёная архитектура, то зачем игнорировать один из слоёв?!
Да, со вторым пунктом конечно можно поспорить, мол возможно и не будет правок в будущем, но всё же.
Читать (En)
Please open Telegram to view this post
VIEW IN TELEGRAM
ViewModel + Kotlin Multiplatform. Пробуем нативное решение
Тут Гугловцы подвезли поддержку ViewModel для Kotlin Multiplatform.
Анна Жаркова подготовила статью с обзором изменений и примером использования.
Читать (Ru)
Тут Гугловцы подвезли поддержку ViewModel для Kotlin Multiplatform.
Анна Жаркова подготовила статью с обзором изменений и примером использования.
Читать (Ru)
Про пагинацию
Я тут досматриваю очередной публичный собес и решил поделиться своими мыслями, касаемо пагинации.
Когда ребята проектировали реализацию списка объявлений, естественно затронули тему пагинации. Георгий предложил использовать пагинацию через Cursor и кажется он забыл сказать про одно важное преимущество этого способа – Гибкость. В чём же собственно гибкость? Попробую объяснить.
Давайте на примере пагинации через Page, посмотрим как мы взаимодействуем с бэком. Обычно в запросе мы передаём параметры вида
А теперь давайте посмотрим как мы взаимодействуем с бэком через Cursor. При использовании способа через Cursor, мы в запросе передаём полученный с бэка Cursor – обычно это строка, в которой закодированны какие-то данные(уникальный id, token, либо что-то подобное). При запросе первой пачки мы ничего не знаем о Cursor, передаём дефолтное значение(null или пустую строку), в ответ бэк нам присылает актуальный Cursor, который мы передаём в следующем запросе и так до тех пор, пока не закончатся данные.
При таком взаимодействии, бэкенд сам формирует Cursor, запихивает туда данные, нужные ему для дальнейшей работы и при необходимости может менять свою внутреннюю логику без правок на клиенте, что собственно довольно гибко.
То есть, теоретически можно сделать так: в курсор запихать
Я тут досматриваю очередной публичный собес и решил поделиться своими мыслями, касаемо пагинации.
Когда ребята проектировали реализацию списка объявлений, естественно затронули тему пагинации. Георгий предложил использовать пагинацию через Cursor и кажется он забыл сказать про одно важное преимущество этого способа – Гибкость. В чём же собственно гибкость? Попробую объяснить.
Давайте на примере пагинации через Page, посмотрим как мы взаимодействуем с бэком. Обычно в запросе мы передаём параметры вида
page=1
, size=20
. При такой реализации бэкенд жестко привязан именно к этим параметрам и такому формату. Если допустим на бэке нужно будет поменять какую-то внутреннюю логику, то с большей вероятностью, это либо не получится сделать, либо нужно будет вносить правки на клиенте.А теперь давайте посмотрим как мы взаимодействуем с бэком через Cursor. При использовании способа через Cursor, мы в запросе передаём полученный с бэка Cursor – обычно это строка, в которой закодированны какие-то данные(уникальный id, token, либо что-то подобное). При запросе первой пачки мы ничего не знаем о Cursor, передаём дефолтное значение(null или пустую строку), в ответ бэк нам присылает актуальный Cursor, который мы передаём в следующем запросе и так до тех пор, пока не закончатся данные.
При таком взаимодействии, бэкенд сам формирует Cursor, запихивает туда данные, нужные ему для дальнейшей работы и при необходимости может менять свою внутреннюю логику без правок на клиенте, что собственно довольно гибко.
То есть, теоретически можно сделать так: в курсор запихать
Cursor="page=1"
, закодировать, вернуть в ответе клиенту, клиент в свою очередь отправит этот Cursor на бэк, бэк декодирует Cursor, вернёт следующую пачку данных и Cursor="page=2"
. Таким образом клиент будет взаимодействовать с бэком через курсорную пагинацию, но внутри бэк будет использовать постраничную. Это чисто пример для наглядности, так делать не надо 😁Вы за это заплатите! Цена Чистой Архитектуры. Часть 2
Продолжение про организацию масштабируемости проекта и цену чистой архитектуры.
👉 На чем мы остановились?
👉 Разрывы связей
👉 Опциональные компоненты(шаблоны проектирования и конвертация)
👉 Экстремальная экономия(проксирующие DataSource-ы и UseCase-ы)
👉 Куда нас это привело?Снова к Чистой Архитектуре!
👉 Единый продукт
В заключение несколько важных для понимания моментов
🟢 Слои не так важны, как компоненты, из которых они сложены
🟢 Зависимости зависят от устойчивости
🟢 Устойчивость не равна редкой изменяемости
🟢 Интерфейсы ситуативны
🟢 Чистота — это свойство
🟢 Чистая Архитектура дешевле, чем её представляют
Читать (Ru)
Продолжение про организацию масштабируемости проекта и цену чистой архитектуры.
👉 На чем мы остановились?
👉 Разрывы связей
👉 Опциональные компоненты(шаблоны проектирования и конвертация)
👉 Экстремальная экономия(проксирующие DataSource-ы и UseCase-ы)
👉 Куда нас это привело?
👉 Единый продукт
В заключение несколько важных для понимания моментов
Читать (Ru)
Please open Telegram to view this post
VIEW IN TELEGRAM
Mastering Android ViewModels: Essential Dos and Don’ts Part 1
Тут стартанули цикл статей про то, что можно делать во ViewModel, а чего лучше не делать.
В первой части разбираются возможные недостатки при инициализации состояния в блоке
👉 Тесная связь с созданием ViewModel
👉 Проблемы тестирования
👉 Ограниченная гибкость
👉 Обработка изменений конфигурации
👉 Управление ресурсами
👉 Отзывчивый UI
Читать (En)
Тут стартанули цикл статей про то, что можно делать во ViewModel, а чего лучше не делать.
В первой части разбираются возможные недостатки при инициализации состояния в блоке
init { }
👉 Тесная связь с созданием ViewModel
👉 Проблемы тестирования
👉 Ограниченная гибкость
👉 Обработка изменений конфигурации
👉 Управление ресурсами
👉 Отзывчивый UI
Читать (En)
Google открыли доступ для всех к Gemini 1.5 Pro
Говорят это одна из мощнейших нейронок с бесплатным доступом в 1М токенов.
Прежде чем тестить, почитайте доступные регионы и включите нужный VPN 😉
У меня не удалось потестить, на всех версиях модели Gemini получаю ошибку – An internal error has occurred, так что имейте в виду, может работать не стабильно.
Попробовать
Говорят это одна из мощнейших нейронок с бесплатным доступом в 1М токенов.
Прежде чем тестить, почитайте доступные регионы и включите нужный VPN 😉
У меня не удалось потестить, на всех версиях модели Gemini получаю ошибку – An internal error has occurred, так что имейте в виду, может работать не стабильно.
Попробовать
Android ProGuard: Mastering Security and Efficiency with ProGuard
Базовая статья по основам ProGuard.
👉 What is ProGuard?
👉 Setting Up ProGuard in an Android Project
👉 ProGuard Rules
👉 Practical Example
👉 Running ProGuard
👉 Common Issues and How to mitigate
👉 Best Practices
Читать (En)
Базовая статья по основам ProGuard.
👉 What is ProGuard?
👉 Setting Up ProGuard in an Android Project
👉 ProGuard Rules
👉 Practical Example
👉 Running ProGuard
👉 Common Issues and How to mitigate
👉 Best Practices
Читать (En)
Context receivers — новые extension functions
Ещё одна интересная статья про Context receivers от разработчика Ozon, в которой рассматриваются возможные варианты использования фичи.
Читать (Ru)
Ещё одна интересная статья про Context receivers от разработчика Ozon, в которой рассматриваются возможные варианты использования фичи.
Читать (Ru)
Stop Passing Event/UI-Action Callbacks in Jetpack Compose
Полезная статья, в которой автор предлагает отказаться от передачи множества коллбеков в composable функции и вместо этого использовать один, общий коллбек с sealed классом
Читать (En)
Полезная статья, в которой автор предлагает отказаться от передачи множества коллбеков в composable функции и вместо этого использовать один, общий коллбек с sealed классом
UiAction
и обрабатывать соответственно эти экшены во ViewModel по типу MVI паттерна.Читать (En)
Line height в Android TextView: где не сходится с Figma, как мешает pixel-perfect, и как это решить
Интересная статья от команды Avito Android Design System про проблему неконсистентности параметра
Если ещё верстаете XML и не перешли на Compose – обязательно почитайте.
P.S. Интересно, а как дела с этим в Compose, кто-нибудь знает? 🤔
Читать (Ru)
Интересная статья от команды Avito Android Design System про проблему неконсистентности параметра
Line height
между Figma и Android.Если ещё верстаете XML и не перешли на Compose – обязательно почитайте.
P.S. Интересно, а как дела с этим в Compose, кто-нибудь знает? 🤔
Читать (Ru)