Разработка
- How Cloudflare enforces engineering standards using AI
- After 3 Years and 200M Rows, I Finally Stopped Using UUIDs as Primary Keys
- A Deep (and Fuzzy) Dive Into Search
Маркетинг
- Wrinkles раскрывает скрытые истории окружающих мест
- Как мы потеряли $5674 на рекламе приложения и неожиданно начали расти только после ее отключения
Кроссплатформа
- Offline‑first PWA на примере фитнес‑трекера
- Adding a Koog AI assistant (with structured output) to the FantasyPremierLeague CMP sample
- Practical Kotlin Multiplatform: Implementing the Firebase Sign-up Operation with Ktor
- How I Added Beautiful Blur Effects to My Flutter App
iOS
Если бы неделю назад мне сказали, что .fixedSize спасёт мне вторую половину рабочего дня, я бы рассмеялся. Уже одно название словно предупреждает: этот модификатор загонит вас в угол. Кому вообще нужны представления, зафиксированные в статическом размере? Поэтому, как и многие разработчики на SwiftUI, я мысленно отправил его в категорию «модификаторы, которыми я никогда не воспользуюсь». А затем мне досталась задача по компоновке, которую — вот неожиданность — можно было аккуратно решить только с помощью .fixedSize. И она преподала мне урок, который стоило усвоить много лет назад: плохих API не существует — бывают лишь интерфейсы, для которых вы ещё не нашли подходящий сценарий. Каждый модификатор SwiftUI появился по определённой причине. Принципиально избегая какого-то из них, вы без всякой пользы сокращаете собственный набор инструментов.
- Наконец-то я нашел применение для .fixedSize
- Picture-in-Picture в iOS: от запуска до переключения контента
- Preview Multiple SwiftUI View States with #Preview(arguments:)
- Alignment guides in SwiftUI
Android
Представьте, перед вами задача — после авторизации пользователя навигировать его на главный экран, или показать snackbar, например, об ошибке. В Android для таких событий есть специальное название — One‑Time Events, или же просто Effects — события, которые мы отправляем UI из ViewModel и хотим, чтобы они обработались ровно один раз. И они отличаются от состояния экрана! Состояние существует всегда, а effect отправляется и обрабатывается единожды; в состоянии существуют данные, с которыми user взаимодействует, или которые повторно могут отображаться на экране, когда как effect — совершенно противоположное. Моделировать такой паттерн можно несколькими способами: через состояние, SharedFlow или Channel. В этой статье мы разберем на простом примере каждый подход и обсудим минусы и плюсы, а также обсудим лучшее обходное решение.