🤩 Готовишься к OOD-собеседованию? Новая книга в помощь

10 июня в издательстве «Питер» выходит «Object Oriented Design. Подготовка к сложному интервью» Алекса Сюя — автора бестселлера про System Design и бывшего инженера Twitter, Apple, Zynga и Oracle.

🤐 Внутри:
🔗 Чёткая 4-шаговая схема решения любой OOD-задачи
🔗 Глубокий разбор ООП и принципов SOLID
🔗 14 готовых систем: парковка, кинотеатр, банкомат, лифты, ресторан и др.
🔗 11 реальных задач с интервью с подробным разбором решений
🔗 133 диаграммы архитектур и процессов
🔗 Паттерны проектирования + советы по коммуникации с интервьюером

🎁 Промокод broadcast — скидка 5% на книги издательства "Питер"!

#реклама

🤖 Google прилагает много усилий, чтобы сделать разработку адаптивных интерфейсов проще: библиотеки, поддержка в IDE, инструменты и пр. Понятно, ведь растет популярность складных устройств. Компания старается расширить Android за пределы смартфона, а складные смартфоны набирают обороты популярности (хоть и медленно).

‼️ Android 17 вскроет все недостатки ваших приложений на планшетах и складных смартфонах, потому что там теперь будут игнорироваться ограничения окон приложений.

В ближайших постах я пройдусь по основам адаптивности интерфейса, а пока вы можете изучить:
👉 Обзор экосистемы адаптивности от Google для Android
📹 Adaptive development for the expanding Android ecosystem
📹 Make your UI adaptive with Android Studio's AI agent
👉 Build adaptive apps
👉 Критерии качества адаптивных приложений (3 уровня)

#Android #AndroidDev #UI #Foldable #Планшет

🚀 Yandex Mobile Ads SDK 8 — минимум времени на запуск монетизации, максимум дохода

Что внутри:
🧩 −30% к размеру SDK. Приложение скачивается быстрее и весит меньше
⚡️ Поддержка современных стандартов асинхронной разработки — повышение эффективности рабочих процессов.
🤖Скилл для ИИ-агентов — миграция с 7 версии на 8 теперь автоматизирована.
ИИ-агент берёт рутину на себя.
✔️Обновлённый дизайн форматов и гибкие API — рекламные форматы выглядят свежее, а интерфейсы стало проще адаптировать под свой продукт.

Кстати, если разрабатываете приложения для Android и iOS на Compose Multiplatform — то для вас еще одна хорошая новость. Создавайте интерфейс рекламных блоков без дублирования вёрстки. Единая кодовая база — минимум рутины и быстрый запуск.

➡️ Подробности и документация

#реклама

🤖 ⚙️ Адаптивность под разные экраны — одна из тех вещей, которые откладывают до последнего. А когда приходит требование поддержать планшет, начинается боль. Хотя в Compose это решается в несколько строк.

GridCells.Adaptive сам рассчитывает колонки под доступное пространство — ничего не нужно задавать вручную:

LazyVerticalGrid(
    columns = GridCells.Adaptive(minSize = 160.dp),
    modifier = Modifier.fillMaxSize()
) {
    items(list) { ItemCard(it) }
}

Но почти всегда забывают про пагинацию. pageSize хардкодят, и это ломает всю адаптивность. На планшете с 4 колонками те же 20 элементов — это 5 строк. Пользователь упирается в конец страницы раньше чем успел проскроллить.

Правильно — считать pageSize от реального числа колонок:

BoxWithConstraints {
    val columns = (maxWidth / 160.dp)
        .toInt().coerceAtLeast(1)
    val rows = (maxHeight / 120.dp)
        .toInt().coerceAtLeast(1)
    val pageSize = columns * rows

    val items = remember(pageSize) {
        Pager(PagingConfig(pageSize = pageSize)) { MyPagingSource() }
    }.flow.collectAsLazyPagingItems()

    LazyVerticalGrid(
        columns = GridCells.Adaptive(minSize = 160.dp)
    ) {
        items(items.itemCount) { ItemCard(items[it]) }
    }
}

На смартфоне выйдет ~10 элементов, на планшете ~30. Никаких магических чисел — только математика от реального пространства.

Самый хороший пример тут - галерея. Они показывают адаптивную сетку контента и имеет возможность настройки другого расположения элементов

🔗 Lazy lists and grids — Android Developers

#Compose #Android #AndroidDev #Ui #Adaptive #Адаптивность

🤯 Android 17 умеет убивать ваше приложение молча. Без стектрейса. Разбираемся. И ЭТО БЕЗ КЛИКБЕЙТА

Начиная с Android 17, появился системный MemoryLimiter — лимит памяти на процесс, привязанный к общему объёму RAM устройства. Превысил лимит — процесс убит. Без exception, без стектрейса.

Как это выглядит:
👉 причина завершения в ApplicationExitInfo = REASON_OTHER
👉 в описании строка "MemoryLimiter:AnonSwap"
👉 в Crashlytics этого НЕ будет: это не краш, а системное убийство процесса

И сразу разрушим главное заблуждение: это НЕ про heap size.

getMemoryClass() и largeHeap ограничивают только Java-кучу — объекты под управлением ART. Превысил и получишь OutOfMemoryError со стектрейсом, который ловится. А новый MemoryLimiter считает другое - анонимную память ВСЕГО процесса:
👉 битмапы (с Android 8 их пиксели в нативной памяти, в Java-куче их нет)
👉 нативные библиотеки, медиакодеки, Skia
👉 веса on-device ML/LLM моделей

Всё это в getMemoryClass() не видно. Можно сидеть втрое ниже heap-лимита, никогда не словить OOM — и всё равно быть убитым, потому что суммарная нативная память процесса вылезла за порог. getMemoryClass и OOM — про Java-кучу. MemoryLimiter — про весь процесс. Это два разных предохранителя, и старый про новый вам ничего не скажет.

Важные оговорки, чтобы не было паники на пустом месте:
👉 в Android 17 лимиты заданы консервативно: цель — экстремальные утечки и выбросы, а не нормальные приложения
👉 включены только на части устройств
👉 конкретных чисел Google не публиковал. Реальный лимит своего девайса можно снять командой: adb shell am memory-limiter status

В зоне риска тяжёлые сценарии на устройствах среднего и бюджетного сегмента.
Уже есть задокументированный случай на бете — крупная on-device модель Gemma падала на Pixel 6a с 6 ГБ RAM именно из-за MemoryLimiter. 6 ГБ — это уже не бюджетник. Java-куча там небольшая, а нативка с весами модели — гигабайты в RAM.

Два мифа, которые гуляют по сети и которые повторять не надо:
👉 НЕТ подтверждения, что система шлёт «вежливое предупреждение» перед убийством
👉 НЕТ официального «дедлайна для разработчиков 30 июня». Google его не объявлял

Это первый раз, когда дисциплина по памяти не совет, а правило от ОС. Сейчас лимиты мягкие, но направление одностороннее — закручивать будут, а не отпускать. И самое неприятное тут не сам лимит, а его невидимость: пользователи будут терять сессии, а вы не узнаете, пока специально не начнёте смотреть.

💬 Как вы думаете, связаны ли меры с тем, что оперативка стала дорожать и вставить по 12–16 ГБ стало дорого?

#Android #Android17 #Производительность

🤖 Google как раз выкатила напоминание как оптимизировать расход памяти в Android приложениях. По сути ничего нового для тех кто уже занимался подобным, а остальным на заметку

#Android #AndroidDev #Производительность #Оптимизация

🔴 Созвон Закрытого Сообщества. Жаркая дискуссия: какой агент лучше. Best practices, ошибки и как работать с ИИ.

Гость — Никита @Nek.12. Один из немногих в русскоязычном сообществе, у кого я реально нашел много интересного для работы с ИИ. Никита не использует Claude Code, Codex или Cursor. Он написал своего агента с нуля. Builder — это CLI-хarness с супервайзером, скиллами, Docker-сэндбоксингом, клиент-серверной архитектурой и возможностью гонять агента автономно сутками. Всё сам. В одиночку.

У нас принципиально разные подходы. Я работаю с Claude Code, активно использую MCP-серверы и верю в это. Никита написал статью "MCP is Deprecated" и считает, что сложные агентные оркестраторы — это микроменеджмент, который мешает модели работать.

Будем разбираться, кто прав. Или оба правы по-своему. Или оба не правы.

Формат — живой разговор, вы можете задавать вопросы в чате прямо во время эфира.

🪙 Стрим пройдет для платных подписчиков на Boosty

#AndroidBroadcast #LIVE