Разработка мобильных приложений: все материалы — 05.08

Разработка

• 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. В этой статье мы разберем на простом примере каждый подход и обсудим минусы и плюсы, а также обсудим лучшее обходное решение.

• Tidy — управление задачами
• Погружение в One‑Time Events в Android
• Android AppFunctions: Teaching AI Agents How to Use Your App
• Your Android App Is One Null Away From Crashing — Here’s Why

← Предыдущий выпуск