Мобильная разработка #1

🔐 Вы только что подарили хакерам доступ. Где НЕЛЬЗЯ хранить ключи Классическая история: вы пишете пет-проект, используете API (например, ChatGPT или Firebase), и пишете прямо в коде: val apiKey = "sk-proj-12345..." Потом git push, и вы идете спать. А утром ваш ключ заблокирован, или с карты списали деньги за чужой трафик. 🤖 Реальность: Боты сканируют публичные репозитории GitHub на наличие строк, похожих на ключи, за секунды после публикации. Удалить коммит не поможет, он уже в кеше у злоумышленников. Как делать правильно (Middle Way): Секреты никогда не должны попадать в систему контроля версий (Git). Они должны жить только локально на вашем компьютере. 🤖 Android: Используйте файл local.properties. Он по умолчанию добавлен в .gitignore. 1. Откройте local.properties и добавьте: MY_API_KEY="ваш_ключ". 2. В build.gradle (app) считайте его и прокиньте в код:

    
        
defaultConfig {
    buildConfigField("String", "API_KEY", gradleLocalProperties(rootDir).getProperty("MY_API_KEY"))
}

{}
    

3. В коде используйте: BuildConfig.API_KEY. 🍏 iOS: Вариантов много, но самый простой для старта: 1. Создайте файл Secrets.xcconfig (или .plist). 2. Сразу же добавьте его в .gitignore. 3. Запишите ключ туда. 4. В настройках проекта (Build Settings) подключите этот конфиг или считывайте файл программно. 🛡 Золотое правило: Если вы клонируете свой проект на чистый ноутбук, он не должен собраться сразу. Он должен попросить вас создать локальный файл с ключами. Это не баг, это безопасность. Признавайтесь, случалось случайно комитить пароли или токены? 👇 #security #android #ios #git #tips #middle #safety 👉 @developer_mobila

🧹 Убираем за собой: Как не опозориться при Code Review Знакомая ситуация? Вы работали над фичей, сделали 10 коммитов с названиями: 🔵init 🔵wip 🔵fix crash 🔵fix typo 🔵aaaaa rabotay pls А потом отправляете это в Pull Request. Тимлид открывает историю и… плачет кровавыми слезами. 🩸 Отличное правило хорошего тона: «Ветка может быть грязной, пока она локальна. Но в main должен уйти чистый и атомарный код». Вам нужен Git Interactive Rebase. Это магия, которая позволяет переписать историю. 🛠 Как это сделать (Консоль / IDE): Допустим, вы хотите объединить последние 5 мелких коммитов в один красивый. 1. Пишем в терминале: git rebase -i HEAD~5 2. Откроется редактор со списком ваших коммитов. Перед каждым стоит слово 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

🍝 Ваш код похож на спагетти? Синдром «Божественного объекта» Знакомая картина: открываешь проект, заходишь в 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): Класс должен иметь только одну причину для изменения. 🔵Если дизайнер поменял цвет кнопок - меняем только View. 🔵Если бэкенд поменял формат JSON, меняем только DTO/Repository. 🔵Если эти изменения заставляют вас править один и тот же файл, у вас архитектурная проблема. 🏁 Задание на неделю: Найдите самый «жирный» класс в своем проекте и попытайтесь вынести из него хотя бы одну функцию в отдельный вспомогательный класс. Ваш код скажет вам спасибо. Сколько строк в самом большом файле вашего текущего проекта? Пишите честно 👇 #architecture #cleanCode #refactoring #middle #android #ios 👉 @developer_mobila

👆 Почему пользователи ненавидят ваши кнопки (даже если они красивые) Знакомая ситуация: вы сверстали экран идеально по макету. Иконка «Закрыть» (крестик) - ровно 24x24, как нарисовал дизайнер. Но пользователи бесятся, тыкая в нее по 5 раз, и не могут попасть. Это классическая ошибка новичка: путать видимый размер и кликабельную область. В гайдлайнах (HIG и Material Design) написано кровью: 🔴 Минимальная область нажатия: 🔵🍎 iOS: 44x44 pt 🔵🤖 Android: 48x48 dp Если ваша иконка меньше (например, 24x24), вы обязаны искусственно увеличить область нажатия, не меняя визуал. Как это сделать грамотно: 🤖 Android (Compose & XML): 🔵Compose: Используйте модификатор .minimumInteractiveComponentSize(). Он сам добавит невидимые отступы, чтобы дотянуть размер до 48dp. 🔵XML: Добавьте padding="12dp" к самому ImageView или оберните его в прозрачный контейнер, на который повесьте клик. Не используйте TouchDelegate без крайней нужды, это больно. 🍏 iOS (SwiftUI & UIKit): 🔵SwiftUI: Распространенная ошибка — вешать .onTapGesture на маленькую иконку. 🔵Плохо: Image("close").onTapGesture { ... } 🔵Хорошо: Image("close").frame(width: 44, height: 44).contentShape(Rectangle()).onTapGesture { ... } (мы делаем прозрачную рамку вокруг). 🔵UIKit: Переопределите метод point(inside:with:) в кнопке, чтобы она ловила касания за своими пределами. 💡 Лайфхак: Включите в настройках разработчика на телефоне «Показывать границы элементов» (Show layout bounds). Если вы видите маленькие прямоугольники вокруг кнопок, это повод для рефакторинга. Заботьтесь о пальцах своих пользователей! А вы спорите с дизайнерами, когда они рисуют слишком мелкие элементы? 👇 #ux #ui #android #ios #tips #mobile #design 👉 @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 > 50 4. Готово! Студия проигнорирует первые 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

☠️ Баг, который вы не видите, а пользователи ненавидят Представьте: пользователь заполнил длинную форму регистрации, свернул приложение, чтобы скопировать код из 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

🚀 Что учить мобильному разработчику в 2026 году? Индустрия не стоит на месте. То, что было «модно» пару лет назад, сегодня - стандарт индустрии, а знание легаси-технологий потихоньку отходит на второй план (но все еще нужно для поддержки). Мы собрали ключевые фокусы для Junior и Middle разработчиков на этот год. Сверяйте свои планы! 👇 🤖 Android (Kotlin) 🔵Jetpack Compose: Это уже база. XML верстка уходит в легаси. Если вы еще не перешли на Compose - 2026 год самое время. 🔵KMP (Kotlin Multiplatform): Главный тренд. Бизнес хочет экономить, и шарить логику между iOS и Android стало стандартом. Учитесь выносить Data и Domain слои в общий модуль. 🔵Gradle Version Catalogs: Стандарт управления зависимостями. buildSrc и простое перечисление в build.gradle уступают место TOML-файлам. 🍎 iOS (Swift) 🔵SwiftUI: Как и с Android - это база для новых проектов. UIKit знать нужно (его еще много), но пилить новые экраны лучше декларативно. 🔵Swift 6 & Concurrency: Разберитесь наконец с async/await и Actors. Понимание потокобезопасности отличает Мидла от Джуна. 🔵Смотрим в сторону KMP: Да, iOS-разработчикам тоже полезно понимать, как подключать общие модули на Kotlin. Это повышает вашу ценность на рынке. 🛠 Общее (Must Have) 🔵AI-ассистенты: Copilot, Cursor или встроенные AI в IDE. Это не «чит», это инструмент ускорения. Учитесь писать правильные промпты для рефакторинга и тестов. 🔵CI/CD: Понимание, как ваше приложение собирается и летит в стор (GitHub Actions, Fastlane). Не ждите, пока это сделает DevOps, разберитесь сами. 🎓 Совет новичкам: Не пытайтесь выучить всё сразу. Выберите одну киллер-фичу (например, Compose или Concurrency) и углубитесь в нее в этом месяце. 💬 Вопрос: Какую технологию вы поставили себе в план изучить первой в этом году? Пишите в комментарии, обсудим! 👇 #roadmap #карьера #android #ios #тренды2026 👉 @developer_mobila

👨‍💻 Как писать чистый код на 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

Конец года, и снова заканчиваются все подписки 😱 Узнали? Согласны? Не беда — мы как раз разыгрываем промокоды на год от Облака Mail и VK Музыки! Условия участия простые: 🔹 подпишитесь на наш канал @mobilehubvk 🔹нажмите кнопку «Участвовать» 🔹 дождитесь 30 декабря — в этом посте мы выберем случайным образом 6 победителей Информацию об организаторе, правилах и призах ищите по ссылке. Удачи!

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