Современные блокировки в Swift: мьютекс и фреймворк Synchronization
Фреймворк Synchronization вводит мьютексы — современные блокировки Swift для создания исключительного доступа к данным. Он отлично работает с Swift Concurrency и предоставляет решение для не-sendable типов, без введения накладных расходов на акторы.
Swift предлагает несколько решений для блокировки доступа к изменяемому контенту и предотвращения так называемого состояния гонки. Блокировки, такие как NSLock, DispatchSemaphore или последовательная DispatchQueue, являются популярным выбором для многих. В некоторых статьях сравнивается их производительность и указывается, какая из них работает лучше всего, но я хотел бы представить вам современный вариант блокировки Swift, представленный в SE-433 Synchronous Mutual Exclusion Lock.
В этой статье я не буду рассказывать, какой блокировщик работает лучше всего, и не буду сравнивать их с этим новым вариантом. Каждый блокировщик может иметь свой профиль производительности и свои особенности. В этой статье мы рассмотрим стандартизированную версию так называемого мьютекс блокировщика.
https://www.avanderlee.com/concurrency/modern-swift-lock-mutex-the-synchronization-framework/
#ios
👉 @developer_mobila
Фреймворк Synchronization вводит мьютексы — современные блокировки Swift для создания исключительного доступа к данным. Он отлично работает с Swift Concurrency и предоставляет решение для не-sendable типов, без введения накладных расходов на акторы.
Swift предлагает несколько решений для блокировки доступа к изменяемому контенту и предотвращения так называемого состояния гонки. Блокировки, такие как NSLock, DispatchSemaphore или последовательная DispatchQueue, являются популярным выбором для многих. В некоторых статьях сравнивается их производительность и указывается, какая из них работает лучше всего, но я хотел бы представить вам современный вариант блокировки Swift, представленный в SE-433 Synchronous Mutual Exclusion Lock.
В этой статье я не буду рассказывать, какой блокировщик работает лучше всего, и не буду сравнивать их с этим новым вариантом. Каждый блокировщик может иметь свой профиль производительности и свои особенности. В этой статье мы рассмотрим стандартизированную версию так называемого мьютекс блокировщика.
https://www.avanderlee.com/concurrency/modern-swift-lock-mutex-the-synchronization-framework/
#ios
👉 @developer_mobila
👍1
🏆 Пройди тест из 10 вопросов, проверь свой уровень знаний и приходи учиться на онлайн-курс «Kotlin Backend Developer. Professional» от OTUS!
На курсе:
🎫 Курс можно приобрести в рассрочку
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Android Dev Hub
Основы AGSL для android разработчика
В последние годы интерфейсы приложений становятся все более интерактивными. Простого эффекта нажатия на кнопку уже недостаточно - пользователи ждут живых анимаций и визуальной глубины. Но создание таких эффектов традиционно требовало от разработчиков значительных усилий.
Представь: тебе нужно «поколдовать» над пикселями прямо в UI - добавить живой градиент, искажение картинки под пальцем, стеклянный блеск карточке и тому подобные эффекты. Раньше для этого приходилось прибегать к «тяжеловесам» таким как OpenGL/Vulkan, либо мучить CPU постобработкой битмапов. AGSL (Android Graphics Shading Language) решает это элегантнее: это язык фрагментных шейдеров, встроенный в сам графический стек Android, так что эффекты применяются прямо на уровне отрисовки интерфейса.
https://habr.com/ru/articles/971992/
👉@androidspb
В последние годы интерфейсы приложений становятся все более интерактивными. Простого эффекта нажатия на кнопку уже недостаточно - пользователи ждут живых анимаций и визуальной глубины. Но создание таких эффектов традиционно требовало от разработчиков значительных усилий.
Представь: тебе нужно «поколдовать» над пикселями прямо в UI - добавить живой градиент, искажение картинки под пальцем, стеклянный блеск карточке и тому подобные эффекты. Раньше для этого приходилось прибегать к «тяжеловесам» таким как OpenGL/Vulkan, либо мучить CPU постобработкой битмапов. AGSL (Android Graphics Shading Language) решает это элегантнее: это язык фрагментных шейдеров, встроенный в сам графический стек Android, так что эффекты применяются прямо на уровне отрисовки интерфейса.
https://habr.com/ru/articles/971992/
👉@androidspb
👍2❤1
Утечка памяти: детективная история с Xcode
Я не мог предположить, что при повторном входе пользователя в систему возникнет такая серьезная проблема, как «половина функций нашего приложения дублируется в памяти». И что у нее есть такое простое решение, как перемещение захвата [weak self] на одну строку вверх.
Недавно я столкнулся с забавной ошибкой, связанной с глубокими ссылками.
Иногда при нажатии на push-уведомление некоторые пользователи сообщали, что целевой экран появляется дважды — приложение открывалось, переходило на нужный экран, но переход между экранами происходил дважды.
Я начал расследование, не подозревая, насколько глубокой окажется эта кроличья нора.
https://www.emergetools.com/blog/posts/the-memory-leak-an-xcode-detective-story
#ios
👉 @developer_mobila
Я не мог предположить, что при повторном входе пользователя в систему возникнет такая серьезная проблема, как «половина функций нашего приложения дублируется в памяти». И что у нее есть такое простое решение, как перемещение захвата [weak self] на одну строку вверх.
Недавно я столкнулся с забавной ошибкой, связанной с глубокими ссылками.
Иногда при нажатии на push-уведомление некоторые пользователи сообщали, что целевой экран появляется дважды — приложение открывалось, переходило на нужный экран, но переход между экранами происходил дважды.
Я начал расследование, не подозревая, насколько глубокой окажется эта кроличья нора.
https://www.emergetools.com/blog/posts/the-memory-leak-an-xcode-detective-story
#ios
👉 @developer_mobila
👍1
This media is not supported in your browser
VIEW IN TELEGRAM
🤖 Как сделать свой оператор Flow и не сломать логику приложения
Когда стандартных операторов Flow становится мало — значит, вы вышли на следующий уровень. На открытом уроке вы узнаете, как писать свои операторы для сложных сценариев, управлять потоками данных и правильно обрабатывать события в Kotlin. Мы покажем, как реализовать собственный оператор, работать с несколькими потоками в рамках одного и не потерять производительность.
❗️ Разберём подходы, которые помогают писать читаемый и поддерживаемый асинхронный код. Урок будет полезен Android-разработчикам уровня junior+, которые уже знакомы с Flow и хотят разобраться, как расширять его под реальные задачи.
🗓 8 декабря, 20:00 МСК. Открытый урок проходит в преддверии старта курса «Android Developer. Professional». Регистрация открыта: https://vk.cc/cRY1g7
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Когда стандартных операторов Flow становится мало — значит, вы вышли на следующий уровень. На открытом уроке вы узнаете, как писать свои операторы для сложных сценариев, управлять потоками данных и правильно обрабатывать события в Kotlin. Мы покажем, как реализовать собственный оператор, работать с несколькими потоками в рамках одного и не потерять производительность.
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Please open Telegram to view this post
VIEW IN TELEGRAM
Compose animations - Android Developers Backstage
Chapters:
Intro (00:00)
Animation capabilities of Compose (1:06)
Different types of animation specs (3:43)
Layers of functionality, transitions (7:49)
TargetBasedAnimation (9:48)
Vectors & velocity of color change (12:43)
Second layer parallel to animation spec (16:39)
Animation interruptions (18:48)
Motion layout problem-solving (20:19)
Both scale and move in question (25:45)
Different mental models for layout animation in Compose vs. View (26:20)
Shared element (31:05)
Are there things you wish more people were aware of? (34:19)
What's the tooling story for this? (41:57)
What is Look Ahead? (43:16)
All software is regret (48:49)
New API: Modifier.animateBounds (51:52)
How to reach Doris – leave a comment (55:57)
Motion Frame of Reference Placement (57:29)
Wrap up (59:10)
https://www.youtube.com/watch?v=kFtFP5dBJDo
#Android
👉 @developer_mobila
Chapters:
Intro (00:00)
Animation capabilities of Compose (1:06)
Different types of animation specs (3:43)
Layers of functionality, transitions (7:49)
TargetBasedAnimation (9:48)
Vectors & velocity of color change (12:43)
Second layer parallel to animation spec (16:39)
Animation interruptions (18:48)
Motion layout problem-solving (20:19)
Both scale and move in question (25:45)
Different mental models for layout animation in Compose vs. View (26:20)
Shared element (31:05)
Are there things you wish more people were aware of? (34:19)
What's the tooling story for this? (41:57)
What is Look Ahead? (43:16)
All software is regret (48:49)
New API: Modifier.animateBounds (51:52)
How to reach Doris – leave a comment (55:57)
Motion Frame of Reference Placement (57:29)
Wrap up (59:10)
https://www.youtube.com/watch?v=kFtFP5dBJDo
#Android
👉 @developer_mobila
YouTube
Compose animations - Android Developers Backstage
In this episode, Chet, Romain, and Tor chat with Doris Liu from the Compose team about animations in Compose -- covering everything from the basic primitives up to the recently added Shared Element Transitions.
Chapters:
Intro (00:00)
Animation capabilities…
Chapters:
Intro (00:00)
Animation capabilities…
👍1
This media is not supported in your browser
VIEW IN TELEGRAM
🛫 Flutter + Telegram: создаём полноценное веб-приложение с ботом и интерфейсом
Мир mini-apps в Telegram растёт, и теперь вы можете стать частью этого тренда. На открытом уроке вы узнаете, как соединить Flutter Web и Telegram Bot API, создать интерактивный интерфейс и развернуть приложение на Firebase Hosting. Мы разберёмся, как использовать dart:js_interop, связать Flutter Web-приложение с Telegram-ботом и настроить всё так, чтобы ваше приложение заработало прямо в мессенджере.
❗️ Занятие будет полезно Flutter- и Fullstack-разработчикам, которые хотят выйти за рамки мобильной разработки и использовать Flutter для современных Telegram-мини-приложений.
🗓 11 декабря в 20:00 МСК. Открытый урок проходит в преддверии старта курса «Flutter Mobile Developer». Регистрация открыта: https://vk.cc/cS9Ygm
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
Мир mini-apps в Telegram растёт, и теперь вы можете стать частью этого тренда. На открытом уроке вы узнаете, как соединить Flutter Web и Telegram Bot API, создать интерактивный интерфейс и развернуть приложение на Firebase Hosting. Мы разберёмся, как использовать dart:js_interop, связать Flutter Web-приложение с Telegram-ботом и настроить всё так, чтобы ваше приложение заработало прямо в мессенджере.
❗️ Занятие будет полезно Flutter- и Fullstack-разработчикам, которые хотят выйти за рамки мобильной разработки и использовать Flutter для современных Telegram-мини-приложений.
🗓 11 декабря в 20:00 МСК. Открытый урок проходит в преддверии старта курса «Flutter Mobile Developer». Регистрация открыта: https://vk.cc/cS9Ygm
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
Media is too big
VIEW IN TELEGRAM
Custom Keyboards SwiftUI - iOS 16+
В этом видео я собираюсь показать, как создавать пользовательские клавиатуры для текстовых полей с использованием SwiftUI
источник
#ios
👉 @developer_mobila
В этом видео я собираюсь показать, как создавать пользовательские клавиатуры для текстовых полей с использованием SwiftUI
источник
#ios
👉 @developer_mobila
👍3
Ускоряем Android-приложения с помощью Baseline Profiles
Привет, меня зовут Даниль Гатиатуллин, я инженер юнита Performance в Авито. Наша команда отвечает за производительность приложения Авито: мы следим за скоростью старта приложения и отрисовки экранов, качеством скролла, отслеживаем сетевые ошибки и занимаемся оптимизациями.
В этой статье я расскажу, что такое Baseline Profiles, как он ускоряет запуск программы и каким приложениям он принесет больше пользы. В качестве примера возьму наш эксперимент, который ускорил время запуска приложения на 15%. Также расскажу, как мы автоматизировали добавление профилей в каждый релиз.
https://habr.com/ru/companies/avito/articles/842218/
#Android
👉 @developer_mobila
Привет, меня зовут Даниль Гатиатуллин, я инженер юнита Performance в Авито. Наша команда отвечает за производительность приложения Авито: мы следим за скоростью старта приложения и отрисовки экранов, качеством скролла, отслеживаем сетевые ошибки и занимаемся оптимизациями.
В этой статье я расскажу, что такое Baseline Profiles, как он ускоряет запуск программы и каким приложениям он принесет больше пользы. В качестве примера возьму наш эксперимент, который ускорил время запуска приложения на 15%. Также расскажу, как мы автоматизировали добавление профилей в каждый релиз.
https://habr.com/ru/companies/avito/articles/842218/
#Android
👉 @developer_mobila
👍1
Heat — это нативный клиент с открытым исходным кодом для iOS и macOS, позволяющий взаимодействовать с самыми популярными LLM-сервисами.
Фичи:
Поддержка популярных LLM-провайдеров (OpenAI, Mistral, Anthropic, Gemini)
Поддержка локальных LLM с открытым исходным кодом с помощью Ollama
Поддержка генерирования изображений (Stable Diffusion и Dall-e)
Поиск и просмотр веб-страниц для повышения точности ответов
Чтение и понимание календаря
Поиск в файловой системе (только для десктопа)
Базовое сохранение данных в памяти
Никаких зависимостей от сервера, кроме доступа к моделям
https://github.com/nathanborror/Heat
#ios
👉 @developer_mobila
Фичи:
Поддержка популярных LLM-провайдеров (OpenAI, Mistral, Anthropic, Gemini)
Поддержка локальных LLM с открытым исходным кодом с помощью Ollama
Поддержка генерирования изображений (Stable Diffusion и Dall-e)
Поиск и просмотр веб-страниц для повышения точности ответов
Чтение и понимание календаря
Поиск в файловой системе (только для десктопа)
Базовое сохранение данных в памяти
Никаких зависимостей от сервера, кроме доступа к моделям
https://github.com/nathanborror/Heat
#ios
👉 @developer_mobila
👍2
Offline-First - это не просто кэширование GET-запросов
Многие путают Offline-Capable (показали кэш, если нет сети) и Offline-First (приложение полностью функционально без сети, сеть - лишь способ синхронизации).
На собеседованиях часто слышу: "Ну, сохраним в Room/Realm, а когда появится сеть - отправим на бэкенд". Звучит просто, пока не натыкаешься на Concurrancy & Conflict Resolution.
Допустим, у нас таск-трекер. Юзер А (в метро) меняет статус задачи на "Done". Юзер Б (в лифте) меняет описание этой же задачи. Оба выходят в онлайн. Что попадет в базу?
Если вы используете стратегию Last Write Wins (LWW), кто-то потеряет данные.
О чем стоит думать при проектировании синхронизации:
1. Optimistic UI: Мы обязаны показать изменение мгновенно. Но как откатить стейт, если сервер вернул 409 Conflict или бизнес-валидацию? Нужен надежный механизм транзакций на клиенте.
2. Queue Management: Очередь запросов должна быть персистентной. Но что, если первый запрос упал? Блокировать всю очередь? Или пропустить и нарушить причинно-следственную связь (causality)?
3. CRDTs (Conflict-free Replicated Data Types): Это "Святой Грааль" распределенных систем.
- Вместо хранения значения, мы храним операции.
- Математика CRDT гарантирует, что независимо от порядка применения операций, итоговое состояние у всех клиентов будет одинаковым (Eventual Consistency).
Практические выводы:
- Не пишите свои велосипеды для синка, если проект сложнее "To-Do листа". Это распределенная система в миниатюре.
- Смотрите в сторону решений, поддерживающих CRDT или дифференциальную синхронизацию "из коробки" (например, PowerSync, Replicache, или старый добрый Couchbase, если позволяет легаси).
- Если пишете сами - всегда версионируйте сущности (Vector Clocks) и проектируйте API так, чтобы сервер мог принимать патчи, а не целиковые объекты.
Offline-First - это не про базу данных на клиенте. Это про умение разруливать энтропию, когда Source of Truth временно недоступен.
#mobile #architecture #systemdesign #offlinefirst
👉 @developer_mobila
Многие путают Offline-Capable (показали кэш, если нет сети) и Offline-First (приложение полностью функционально без сети, сеть - лишь способ синхронизации).
На собеседованиях часто слышу: "Ну, сохраним в Room/Realm, а когда появится сеть - отправим на бэкенд". Звучит просто, пока не натыкаешься на Concurrancy & Conflict Resolution.
Допустим, у нас таск-трекер. Юзер А (в метро) меняет статус задачи на "Done". Юзер Б (в лифте) меняет описание этой же задачи. Оба выходят в онлайн. Что попадет в базу?
Если вы используете стратегию Last Write Wins (LWW), кто-то потеряет данные.
О чем стоит думать при проектировании синхронизации:
1. Optimistic UI: Мы обязаны показать изменение мгновенно. Но как откатить стейт, если сервер вернул 409 Conflict или бизнес-валидацию? Нужен надежный механизм транзакций на клиенте.
2. Queue Management: Очередь запросов должна быть персистентной. Но что, если первый запрос упал? Блокировать всю очередь? Или пропустить и нарушить причинно-следственную связь (causality)?
3. CRDTs (Conflict-free Replicated Data Types): Это "Святой Грааль" распределенных систем.
- Вместо хранения значения, мы храним операции.
- Математика CRDT гарантирует, что независимо от порядка применения операций, итоговое состояние у всех клиентов будет одинаковым (Eventual Consistency).
Практические выводы:
- Не пишите свои велосипеды для синка, если проект сложнее "To-Do листа". Это распределенная система в миниатюре.
- Смотрите в сторону решений, поддерживающих CRDT или дифференциальную синхронизацию "из коробки" (например, PowerSync, Replicache, или старый добрый Couchbase, если позволяет легаси).
- Если пишете сами - всегда версионируйте сущности (Vector Clocks) и проектируйте API так, чтобы сервер мог принимать патчи, а не целиковые объекты.
Offline-First - это не про базу данных на клиенте. Это про умение разруливать энтропию, когда Source of Truth временно недоступен.
#mobile #architecture #systemdesign #offlinefirst
👉 @developer_mobila
👍2❤1
Forwarded from Mobile VK Hub
This media is not supported in your browser
VIEW IN TELEGRAM
Конец года, и снова заканчиваются все подписки 😱
Узнали? Согласны? Не беда — мы как раз разыгрываем промокоды на год от Облака Mail и VK Музыки!
Условия участия простые:
🔹 подпишитесь на наш канал @mobilehubvk
🔹нажмите кнопку «Участвовать»
🔹 дождитесь 30 декабря — в этом посте мы выберем случайным образом 6 победителей
Информацию об организаторе, правилах и призах ищите по ссылке.
Удачи!
Узнали? Согласны? Не беда — мы как раз разыгрываем промокоды на год от Облака Mail и VK Музыки!
Условия участия простые:
🔹 подпишитесь на наш канал @mobilehubvk
🔹нажмите кнопку «Участвовать»
🔹 дождитесь 30 декабря — в этом посте мы выберем случайным образом 6 победителей
Информацию об организаторе, правилах и призах ищите по ссылке.
Удачи!
👍2❤1
👨💻 Как писать чистый код на SwiftUI: вспоминаем паттерны
Легко написать работающий экран на SwiftUI. Сложно написать поддерживаемое приложение. Часто проблема кроется в непонимании того, какие паттерны уже "зашиты" в фреймворк.
В этой статье автор разбирает 5 основных паттернов, которые вы, скорее всего, уже используете, но не называете их своими именами:
🔹 Observer - основа реактивности SwiftUI.
🔹 Builder - магия, которая позволяет писать декларативный UI.
🔹 Adapter - мост в мир UIKit.
🔹 Decorator - суть всех модификаторов.
🔹 Strategy - способ гибкой настройки логики.
Понимание этих концепций поможет не изобретать велосипед, а писать идиоматичный код.
https://medium.com/ios-nest/design-patterns-in-swiftui-9091a4fa722e
#iOS #Engineering #SwiftUI
👉 @developer_mobila
Легко написать работающий экран на SwiftUI. Сложно написать поддерживаемое приложение. Часто проблема кроется в непонимании того, какие паттерны уже "зашиты" в фреймворк.
В этой статье автор разбирает 5 основных паттернов, которые вы, скорее всего, уже используете, но не называете их своими именами:
🔹 Observer - основа реактивности SwiftUI.
🔹 Builder - магия, которая позволяет писать декларативный UI.
🔹 Adapter - мост в мир UIKit.
🔹 Decorator - суть всех модификаторов.
🔹 Strategy - способ гибкой настройки логики.
Понимание этих концепций поможет не изобретать велосипед, а писать идиоматичный код.
https://medium.com/ios-nest/design-patterns-in-swiftui-9091a4fa722e
#iOS #Engineering #SwiftUI
👉 @developer_mobila
👍1
🚀 Что учить мобильному разработчику в 2026 году?
Индустрия не стоит на месте. То, что было «модно» пару лет назад, сегодня - стандарт индустрии, а знание легаси-технологий потихоньку отходит на второй план (но все еще нужно для поддержки).
Мы собрали ключевые фокусы для Junior и Middle разработчиков на этот год. Сверяйте свои планы! 👇
🤖 Android (Kotlin)
🔵 Jetpack Compose: Это уже база. XML верстка уходит в легаси. Если вы еще не перешли на Compose - 2026 год самое время.
🔵 KMP (Kotlin Multiplatform): Главный тренд. Бизнес хочет экономить, и шарить логику между iOS и Android стало стандартом. Учитесь выносить Data и Domain слои в общий модуль.
🔵 Gradle Version Catalogs: Стандарт управления зависимостями.
🍎 iOS (Swift)
🔵 SwiftUI: Как и с Android - это база для новых проектов. UIKit знать нужно (его еще много), но пилить новые экраны лучше декларативно.
🔵 Swift 6 & Concurrency: Разберитесь наконец с
🔵 Смотрим в сторону KMP: Да, iOS-разработчикам тоже полезно понимать, как подключать общие модули на Kotlin. Это повышает вашу ценность на рынке.
🛠 Общее (Must Have)
🔵 AI-ассистенты: Copilot, Cursor или встроенные AI в IDE. Это не «чит», это инструмент ускорения. Учитесь писать правильные промпты для рефакторинга и тестов.
🔵 CI/CD: Понимание, как ваше приложение собирается и летит в стор (GitHub Actions, Fastlane). Не ждите, пока это сделает DevOps, разберитесь сами.
🎓 Совет новичкам: Не пытайтесь выучить всё сразу. Выберите одну киллер-фичу (например, Compose или Concurrency) и углубитесь в нее в этом месяце.
💬 Вопрос: Какую технологию вы поставили себе в план изучить первой в этом году? Пишите в комментарии, обсудим! 👇
#roadmap #карьера #android #ios #тренды2026
👉 @developer_mobila
Индустрия не стоит на месте. То, что было «модно» пару лет назад, сегодня - стандарт индустрии, а знание легаси-технологий потихоньку отходит на второй план (но все еще нужно для поддержки).
Мы собрали ключевые фокусы для Junior и Middle разработчиков на этот год. Сверяйте свои планы! 👇
🤖 Android (Kotlin)
buildSrc и простое перечисление в build.gradle уступают место TOML-файлам.🍎 iOS (Swift)
async/await и Actors. Понимание потокобезопасности отличает Мидла от Джуна.🛠 Общее (Must Have)
🎓 Совет новичкам: Не пытайтесь выучить всё сразу. Выберите одну киллер-фичу (например, Compose или Concurrency) и углубитесь в нее в этом месяце.
💬 Вопрос: Какую технологию вы поставили себе в план изучить первой в этом году? Пишите в комментарии, обсудим! 👇
#roadmap #карьера #android #ios #тренды2026
👉 @developer_mobila
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
💼 Вопрос с собеседования: «Как вы боретесь с утечками памяти?»
Этот вопрос гарантированно зададут на собеседовании и Android, и iOS разработчику. Лид хочет услышать не сухую теорию, а ваши инструменты.
Вот как отличается уровень ответов:
❌ Ответ Джуна:
«Утечка - это когда память не освобождается, забивается, и приложение падает с ошибкой Out Of Memory. Я стараюсь писать чистый код и надеюсь на Garbage Collector (или ARC в iOS)».
👉 Вердикт: Слишком абстрактно. Не понятно, умеет ли кандидат реально находить и чинить проблемы в коде.
✅ Ответ Мидла:
«Утечки чаще всего возникают, когда объекты удерживаются дольше, чем нужно.
Классика жанра:
🤖 Android: Ссылка на
🍎 iOS: Retain Cycle (циклические ссылки), когда два объекта сильно ссылаются друг на друга (часто бывает в кложурах).
Как я их ищу:
1. Инструменты: Не гадаю на кофейной гуще, а запускаю Android Profiler (или библиотеку LeakCanary) / Xcode Instruments (Leaks & Memory Graph).
2. Лечение: Использую
👉 Вердикт: Четкое понимание причины + знание профайлеров + конкретное решение.
💡 Совет: Перед следующим собеседованием запустите свой пет-проект с профайлером. Даже если там нет утечек, вы сможете сказать: «Я проверял свой проект через Instruments/Profiler, потребление памяти стабильное». Это огромный плюс в карму.
Сталкивались с OOM (Out Of Memory) в реальных проектах или пока проносило? 👇
#собеседование #карьера #ios #android #tips
👉 @developer_mobila
Этот вопрос гарантированно зададут на собеседовании и Android, и iOS разработчику. Лид хочет услышать не сухую теорию, а ваши инструменты.
Вот как отличается уровень ответов:
❌ Ответ Джуна:
«Утечка - это когда память не освобождается, забивается, и приложение падает с ошибкой Out Of Memory. Я стараюсь писать чистый код и надеюсь на Garbage Collector (или ARC в iOS)».
👉 Вердикт: Слишком абстрактно. Не понятно, умеет ли кандидат реально находить и чинить проблемы в коде.
✅ Ответ Мидла:
«Утечки чаще всего возникают, когда объекты удерживаются дольше, чем нужно.
Классика жанра:
🤖 Android: Ссылка на
Activity или Context внутри статического поля или долгоживущего фонового потока.🍎 iOS: Retain Cycle (циклические ссылки), когда два объекта сильно ссылаются друг на друга (часто бывает в кложурах).
Как я их ищу:
1. Инструменты: Не гадаю на кофейной гуще, а запускаю Android Profiler (или библиотеку LeakCanary) / Xcode Instruments (Leaks & Memory Graph).
2. Лечение: Использую
WeakReference или [weak self], чтобы разорвать сильную связь».👉 Вердикт: Четкое понимание причины + знание профайлеров + конкретное решение.
💡 Совет: Перед следующим собеседованием запустите свой пет-проект с профайлером. Даже если там нет утечек, вы сможете сказать: «Я проверял свой проект через Instruments/Profiler, потребление памяти стабильное». Это огромный плюс в карму.
Сталкивались с OOM (Out Of Memory) в реальных проектах или пока проносило? 👇
#собеседование #карьера #ios #android #tips
👉 @developer_mobila
👍4❤2
🛠 Хватит писать To-Do листы! Топ бесплатных API для твоего портфолио
Рекрутеры видят сотни «списков задач» и «калькуляторов». Чтобы выделиться, нужно показать работу с сетью, сложным UI, кэшированием и картинками.
Лучший способ это сделать - написать клиент для реального API. Вот подборка бесплатных, стабильных и открытых API, на которых можно построить крутой проект:
🎬 1. The Movie DB (TMDB)
🔵 Что там: Огромная база фильмов, актеров, рейтингов и постеров.
🔵 Чему научишься: Работать со сложными списками (RecyclerView/LazyColumn), пагинацией, поиском и загрузкой изображений (Glide/Coil/Kingfisher).
🔵 Идея: Клон Netflix или «Кинопоиска».
🚀 2. NASA Open APIs
🔵 Что там: Фото дня (APOD), данные о Марсе, астероидах.
🔵 Чему научишься: Работать с красивым медиа-контентом и датами.
🔵 Идея: Приложение «Космос сегодня» с ежедневными уведомлениями.
3. PokéAPI
🔵 Что там: Всё о покемонах. Полностью открытое, не требует ключа (Auth Key).
🔵 Чему научишься: Архитектуре. Данные хорошо структурированы, идеально для тренировки Clean Architecture и маппинга JSON в модели.
🔵 Идея: «Покедекс» с детальной информацией и статами.
📈 4. CoinGecko API
🔵 Что там: Курсы криптовалют в реальном времени.
🔵 Чему научишься: Работать с Websockets (если найдешь) или частым обновлением данных, рисовать графики.
🔵 Идея: Трекер портфеля крипты.
💡 Совет ментора: Не пытайтесь сделать всё сразу. Возьмите один экран (например, список популярных фильмов) и сделайте его идеально: с обработкой ошибок («нет интернета»), скелетоном при загрузке и красивой анимацией. Это ценнее, чем кривое, но большое приложение.
Сохраняй подборку, чтобы не потерять! А какое API вы использовали в своем последнем проекте? 👇
#ресурсы #api #петпроект #ideas #android #ios
👉 @developer_mobila
Рекрутеры видят сотни «списков задач» и «калькуляторов». Чтобы выделиться, нужно показать работу с сетью, сложным UI, кэшированием и картинками.
Лучший способ это сделать - написать клиент для реального API. Вот подборка бесплатных, стабильных и открытых API, на которых можно построить крутой проект:
🎬 1. The Movie DB (TMDB)
🚀 2. NASA Open APIs
3. PokéAPI
📈 4. CoinGecko API
💡 Совет ментора: Не пытайтесь сделать всё сразу. Возьмите один экран (например, список популярных фильмов) и сделайте его идеально: с обработкой ошибок («нет интернета»), скелетоном при загрузке и красивой анимацией. Это ценнее, чем кривое, но большое приложение.
Сохраняй подборку, чтобы не потерять! А какое API вы использовали в своем последнем проекте? 👇
#ресурсы #api #петпроект #ideas #android #ios
👉 @developer_mobila
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
☠️ Баг, который вы не видите, а пользователи ненавидят
Представьте: пользователь заполнил длинную форму регистрации, свернул приложение, чтобы скопировать код из SMS, возвращается... а экран пустой. Данные исчезли. 🤬
Это System-initiated process death. Самая частая причина удаления приложения у пользователей и головная боль разработчиков.
Почему это происходит?
ОС (Android или iOS) всегда не хватает оперативной памяти. Когда ваше приложение уходит в фон, система может «тихо» убить его процесс, чтобы освободить ресурсы для активного окна (например, Камеры).
❌ Ошибка новичка:
«Я храню данные в
Реальность:
✅ Как делать правильно (Level Up):
🤖 Android:
Перестаньте полагаться только на поля класса. Используйте SavedStateHandle.
Это специальный механизм внутри ViewModel, который сохраняет небольшие кусочки данных (ID, поисковый запрос, ввод пользователя) в системный бандл. Система бережно восстановит его даже после смерти процесса.
Гуглить:
🍏 iOS (SwiftUI/UIKit):
В SwiftUI для простых данных (например, выбранная вкладка или текст) используйте обертку
Для сложных данных — сохраняйте их в локальную БД (CoreData/Realm/SwiftData) при каждом изменении, а не при закрытии экрана.
🛠 Как проверить себя (Челлендж на 5 минут):
Не верьте эмулятору. Проверьте свой текущий проект прямо сейчас:
1. Запустите приложение и введите данные в любое поле.
2. Сверните приложение (Home).
3. Android: В настройках разработчика включите опцию «Don't keep activities» (Не сохранять действия).
4. iOS: В Xcode нажмите Debug -> Simulate Memory Warning или остановите дебаг и запустите другое тяжелое приложение.
5. Вернитесь в свое приложение.
Если данные исчезли или случился краш, поздравляю, вы нашли критический баг. Время фиксить!
Знали про SavedStateHandle или по старинке сохраняли всё в базу данных? 👇
#android #ios #bugs #middle #architecture #обучение
👉 @developer_mobila
Представьте: пользователь заполнил длинную форму регистрации, свернул приложение, чтобы скопировать код из SMS, возвращается... а экран пустой. Данные исчезли. 🤬
Это System-initiated process death. Самая частая причина удаления приложения у пользователей и головная боль разработчиков.
Почему это происходит?
ОС (Android или iOS) всегда не хватает оперативной памяти. Когда ваше приложение уходит в фон, система может «тихо» убить его процесс, чтобы освободить ресурсы для активного окна (например, Камеры).
❌ Ошибка новичка:
«Я храню данные в
ViewModel (Android) или в переменной контроллера (iOS), они же живут долго!»Реальность:
ViewModel переживает поворот экрана, но умирает вместе с процессом. Синглтоны тоже сбрасываются.✅ Как делать правильно (Level Up):
🤖 Android:
Перестаньте полагаться только на поля класса. Используйте SavedStateHandle.
Это специальный механизм внутри ViewModel, который сохраняет небольшие кусочки данных (ID, поисковый запрос, ввод пользователя) в системный бандл. Система бережно восстановит его даже после смерти процесса.
Гуглить:
SavedStateHandle, Parcelable.🍏 iOS (SwiftUI/UIKit):
В SwiftUI для простых данных (например, выбранная вкладка или текст) используйте обертку
@SceneStorage. Она автоматически сохраняет и восстанавливает состояние.Для сложных данных — сохраняйте их в локальную БД (CoreData/Realm/SwiftData) при каждом изменении, а не при закрытии экрана.
🛠 Как проверить себя (Челлендж на 5 минут):
Не верьте эмулятору. Проверьте свой текущий проект прямо сейчас:
1. Запустите приложение и введите данные в любое поле.
2. Сверните приложение (Home).
3. Android: В настройках разработчика включите опцию «Don't keep activities» (Не сохранять действия).
4. iOS: В Xcode нажмите Debug -> Simulate Memory Warning или остановите дебаг и запустите другое тяжелое приложение.
5. Вернитесь в свое приложение.
Если данные исчезли или случился краш, поздравляю, вы нашли критический баг. Время фиксить!
Знали про SavedStateHandle или по старинке сохраняли всё в базу данных? 👇
#android #ios #bugs #middle #architecture #обучение
👉 @developer_mobila
👍7🔥2
🛑 Хватит спамить принтами! Дебажим как профи
Признавайтесь, делали так?
У вас есть цикл на 100 элементов, и ошибка вылетает только на 87-м. Вы ставите обычный брейкпоинт и 86 раз яростно жмете «Resume Program» (▶️), проклиная всё на свете, пока не дойдете до нужного состояния.
Или еще хуже:
Есть способ элегантнее, который отличает опытного разработчика от новичка - Conditional Breakpoints (Условные точки останова).
Они останавливают выполнение программы только тогда, когда выполняется определенное условие.
Как это сделать за 5 секунд:
🤖 Android Studio (IntelliJ IDEA):
1. Поставьте обычный красный брейкпоинт.
2. Нажмите на него правой кнопкой мыши.
3. В поле "Condition" напишите условие на языке Kotlin/Java.
Пример:
4. Готово! Студия проигнорирует первые 86 итераций и остановится точно там, где нужно.
🍎 Xcode:
1. Поставьте синий брейкпоинт.
2. Нажмите на него правой кнопкой (или двойной клик) -> "Edit Breakpoint".
3. В поле "Condition" пишите условие на Swift.
Пример:
💡 Бонус-фича для тех, кто не любит останавливаться:
В настройках брейкпоинта уберите галочку Suspend (Остановить) и поставьте галочку Log Message (Evaluate and log).
Теперь IDE будет сама писать в консоль значения переменных при прохождении этой точки, не останавливая приложение. Это те же принты, только вам не нужно пачкать ими код и пересобирать проект!
Какая ваша любимая фишка дебаггера, о которой мало кто знает? Делитесь в комментариях 👇
#productivity #androidstudio #xcode #debug #tips #middle
👉 @developer_mobila
Признавайтесь, делали так?
У вас есть цикл на 100 элементов, и ошибка вылетает только на 87-м. Вы ставите обычный брейкпоинт и 86 раз яростно жмете «Resume Program» (▶️), проклиная всё на свете, пока не дойдете до нужного состояния.
Или еще хуже:
Log.d("TAG", "Я тут")Log.d("TAG", "А теперь тут, значение i = $i")Есть способ элегантнее, который отличает опытного разработчика от новичка - Conditional Breakpoints (Условные точки останова).
Они останавливают выполнение программы только тогда, когда выполняется определенное условие.
Как это сделать за 5 секунд:
🤖 Android Studio (IntelliJ IDEA):
1. Поставьте обычный красный брейкпоинт.
2. Нажмите на него правой кнопкой мыши.
3. В поле "Condition" напишите условие на языке Kotlin/Java.
Пример:
item.id == 87 или user.name.contains("Test") && i > 504. Готово! Студия проигнорирует первые 86 итераций и остановится точно там, где нужно.
🍎 Xcode:
1. Поставьте синий брейкпоинт.
2. Нажмите на него правой кнопкой (или двойной клик) -> "Edit Breakpoint".
3. В поле "Condition" пишите условие на Swift.
Пример:
indexPath.row == 87💡 Бонус-фича для тех, кто не любит останавливаться:
В настройках брейкпоинта уберите галочку Suspend (Остановить) и поставьте галочку Log Message (Evaluate and log).
Теперь IDE будет сама писать в консоль значения переменных при прохождении этой точки, не останавливая приложение. Это те же принты, только вам не нужно пачкать ими код и пересобирать проект!
Какая ваша любимая фишка дебаггера, о которой мало кто знает? Делитесь в комментариях 👇
#productivity #androidstudio #xcode #debug #tips #middle
👉 @developer_mobila
❤3👍2
👆 Почему пользователи ненавидят ваши кнопки (даже если они красивые)
Знакомая ситуация: вы сверстали экран идеально по макету. Иконка «Закрыть» (крестик) - ровно 24x24, как нарисовал дизайнер.
Но пользователи бесятся, тыкая в нее по 5 раз, и не могут попасть.
Это классическая ошибка новичка: путать видимый размер и кликабельную область.
В гайдлайнах (HIG и Material Design) написано кровью:
🔴 Минимальная область нажатия:
🔵 🍎 iOS: 44x44 pt
🔵 🤖 Android: 48x48 dp
Если ваша иконка меньше (например, 24x24), вы обязаны искусственно увеличить область нажатия, не меняя визуал.
Как это сделать грамотно:
🤖 Android (Compose & XML):
🔵 Compose: Используйте модификатор
🔵 XML: Добавьте
🍏 iOS (SwiftUI & UIKit):
🔵 SwiftUI: Распространенная ошибка — вешать
🔵 Плохо:
🔵 Хорошо:
🔵 UIKit: Переопределите метод
💡 Лайфхак:
Включите в настройках разработчика на телефоне «Показывать границы элементов» (Show layout bounds). Если вы видите маленькие прямоугольники вокруг кнопок, это повод для рефакторинга.
Заботьтесь о пальцах своих пользователей! А вы спорите с дизайнерами, когда они рисуют слишком мелкие элементы? 👇
#ux #ui #android #ios #tips #mobile #design
👉 @developer_mobila
Знакомая ситуация: вы сверстали экран идеально по макету. Иконка «Закрыть» (крестик) - ровно 24x24, как нарисовал дизайнер.
Но пользователи бесятся, тыкая в нее по 5 раз, и не могут попасть.
Это классическая ошибка новичка: путать видимый размер и кликабельную область.
В гайдлайнах (HIG и Material Design) написано кровью:
🔴 Минимальная область нажатия:
Если ваша иконка меньше (например, 24x24), вы обязаны искусственно увеличить область нажатия, не меняя визуал.
Как это сделать грамотно:
🤖 Android (Compose & XML):
.minimumInteractiveComponentSize(). Он сам добавит невидимые отступы, чтобы дотянуть размер до 48dp.padding="12dp" к самому ImageView или оберните его в прозрачный контейнер, на который повесьте клик. Не используйте TouchDelegate без крайней нужды, это больно.🍏 iOS (SwiftUI & UIKit):
.onTapGesture на маленькую иконку.Image("close").onTapGesture { ... }Image("close").frame(width: 44, height: 44).contentShape(Rectangle()).onTapGesture { ... } (мы делаем прозрачную рамку вокруг).point(inside:with:) в кнопке, чтобы она ловила касания за своими пределами.💡 Лайфхак:
Включите в настройках разработчика на телефоне «Показывать границы элементов» (Show layout bounds). Если вы видите маленькие прямоугольники вокруг кнопок, это повод для рефакторинга.
Заботьтесь о пальцах своих пользователей! А вы спорите с дизайнерами, когда они рисуют слишком мелкие элементы? 👇
#ux #ui #android #ios #tips #mobile #design
👉 @developer_mobila
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5👏1
🍝 Ваш код похож на спагетти? Синдром «Божественного объекта»
Знакомая картина: открываешь проект, заходишь в
Там и работа с сетью, и валидация полей, и анимации, и сохранение в базу, и даже форматирование даты. В мире разработки это называется God Object (или Massive View Controller).
Почему это плохо?
1. Невозможно тестировать. Как написать юнит-тест на класс, который делает всё?
2. Сложно менять. Поправил верстку — сломалась база данных.
3. Конфликты при слиянии. В команде двое разработчиков полезли в этот файл — здравствуй, merge conflict на полдня.
🚀 Как лечить (Гайд для перехода в Middle):
Если видишь класс больше 300-400 строк, начинай «резню»:
1. ✂️ Всю логику сети - в Repository.
Во View/Activity не должно быть
2. ✂️ Всю бизнес-логику - в UseCases (Интеракторы).
Валидация пароля, подсчет корзины, фильтрация списков - это чистая логика. Выносите её в отдельные классы (
3. ✂️ Сложный UI - в Custom Views / Child ViewControllers.
Если у вас в адаптере списка 500 строк кода настройки ячеек - вынесите ячейку в отдельный класс с методом
💡 Правило одной ответственности (SRP):
Класс должен иметь только одну причину для изменения.
🔵 Если дизайнер поменял цвет кнопок - меняем только View.
🔵 Если бэкенд поменял формат JSON, меняем только DTO/Repository.
🔵 Если эти изменения заставляют вас править один и тот же файл, у вас архитектурная проблема.
🏁 Задание на неделю:
Найдите самый «жирный» класс в своем проекте и попытайтесь вынести из него хотя бы одну функцию в отдельный вспомогательный класс. Ваш код скажет вам спасибо.
Сколько строк в самом большом файле вашего текущего проекта? Пишите честно 👇
#architecture #cleanCode #refactoring #middle #android #ios
👉 @developer_mobila
Знакомая картина: открываешь проект, заходишь в
MainActivity или ProfileViewController, а там... 1500 строк кода. 😱Там и работа с сетью, и валидация полей, и анимации, и сохранение в базу, и даже форматирование даты. В мире разработки это называется God Object (или Massive View Controller).
Почему это плохо?
1. Невозможно тестировать. Как написать юнит-тест на класс, который делает всё?
2. Сложно менять. Поправил верстку — сломалась база данных.
3. Конфликты при слиянии. В команде двое разработчиков полезли в этот файл — здравствуй, merge conflict на полдня.
🚀 Как лечить (Гайд для перехода в Middle):
Если видишь класс больше 300-400 строк, начинай «резню»:
1. ✂️ Всю логику сети - в Repository.
Во View/Activity не должно быть
http-клиентов и JSON-парсинга. Она должна просто сказать: repository.getUsers() и показать спиннер.2. ✂️ Всю бизнес-логику - в UseCases (Интеракторы).
Валидация пароля, подсчет корзины, фильтрация списков - это чистая логика. Выносите её в отдельные классы (
PasswordValidator, CartCalculator).3. ✂️ Сложный UI - в Custom Views / Child ViewControllers.
Если у вас в адаптере списка 500 строк кода настройки ячеек - вынесите ячейку в отдельный класс с методом
bind(data).💡 Правило одной ответственности (SRP):
Класс должен иметь только одну причину для изменения.
🏁 Задание на неделю:
Найдите самый «жирный» класс в своем проекте и попытайтесь вынести из него хотя бы одну функцию в отдельный вспомогательный класс. Ваш код скажет вам спасибо.
Сколько строк в самом большом файле вашего текущего проекта? Пишите честно 👇
#architecture #cleanCode #refactoring #middle #android #ios
👉 @developer_mobila
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍1🤡1🥱1
🧹 Убираем за собой: Как не опозориться при Code Review
Знакомая ситуация? Вы работали над фичей, сделали 10 коммитов с названиями:
🔵
🔵
🔵
🔵
🔵
А потом отправляете это в Pull Request. Тимлид открывает историю и… плачет кровавыми слезами. 🩸
Отличное правило хорошего тона: «Ветка может быть грязной, пока она локальна. Но в
Вам нужен Git Interactive Rebase. Это магия, которая позволяет переписать историю.
🛠 Как это сделать (Консоль / IDE):
Допустим, вы хотите объединить последние 5 мелких коммитов в один красивый.
1. Пишем в терминале:
2. Откроется редактор со списком ваших коммитов. Перед каждым стоит слово
3. Меняем команды:
🔵 Оставляем
🔵 У остальных меняем
🔵 Если хотите переименовать - используйте
4. Сохраняем и закрываем. Git предложит написать одно общее сообщение для нового «супер-коммита».
5. Отправляем на сервер:
💡 Результат:
Вместо 5 мусорных записей у вас одна красивая:
Коллеги на ревью скажут спасибо:
✅ Проще читать изменения.
✅ Если баг - проще откатить один коммит, чем искать в куче мелких.
А вы используете Rebase или предпочитаете честную историю со всеми «фиксами»? 👇
#git #teamwork #middle #tips #tools #bestpractices
👉 @developer_mobila
Знакомая ситуация? Вы работали над фичей, сделали 10 коммитов с названиями:
initwipfix crashfix typoaaaaa rabotay plsА потом отправляете это в Pull Request. Тимлид открывает историю и… плачет кровавыми слезами. 🩸
Отличное правило хорошего тона: «Ветка может быть грязной, пока она локальна. Но в
main должен уйти чистый и атомарный код».Вам нужен Git Interactive Rebase. Это магия, которая позволяет переписать историю.
🛠 Как это сделать (Консоль / IDE):
Допустим, вы хотите объединить последние 5 мелких коммитов в один красивый.
1. Пишем в терминале:
git rebase -i HEAD~52. Откроется редактор со списком ваших коммитов. Перед каждым стоит слово
pick.3. Меняем команды:
pick у самого первого (верхнего) коммита.pick на squash (или s) - это значит «сплющить» этот коммит с предыдущим.reword.4. Сохраняем и закрываем. Git предложит написать одно общее сообщение для нового «супер-коммита».
5. Отправляем на сервер:
git push --force (Осторожно! Делайте это только в своей ветке, пока никто другой в ней не работает).💡 Результат:
Вместо 5 мусорных записей у вас одна красивая:
Feature: Added dark mode implementation.Коллеги на ревью скажут спасибо:
✅ Проще читать изменения.
✅ Если баг - проще откатить один коммит, чем искать в куче мелких.
А вы используете Rebase или предпочитаете честную историю со всеми «фиксами»? 👇
#git #teamwork #middle #tips #tools #bestpractices
👉 @developer_mobila
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤1