💻 Топ вакансий для мобильных разработчиков за неделю

Android Developer — от 200 000 ₽, гибрид (Санкт-Петербург)

Senior iOS Developer (Swift, SwiftUI, UIKit, CloudKit, APN, Network Extension) — от 500 000 ₽ , удалёнка

Kotlin/Java Developer (JetBrains Platform) — от 300 000 до 370 000 ₽, удалёнка

Senior Flutter-разработчик — от 4 000 до 7 000 $, удалёнка

iOS разработчик — удалёнка

➡️ Еще больше топовых вакансий —‍ в нашем канале Mobile jobs

🐸 Библиотека мобильного разработчика

#свежак

🔍 Архитектура Clean Swift

В Clean Swift приложение состоит из сцен, т.е. каждый экран приложения — это одна сцена. Основное взаимодействие в сцене идет через последовательный цикл между компонентами ViewController -> Interactor -> Presenter. Это называется VIP цикл.

Мостом между компонентами выступает файл Models, который хранит в себе передаваемые данные. Так же есть Router, отвечающий за переход и передачу данных между сценами, и Worker, который берет часть логики Interactor’a на себя.

🔹 View

Storyboard’ы, XIB’ы или UI элементы, написанные через код.

🔹 ViewController

Отвечает только за конфигурацию и взаимодействие с View. В контроллере не должно находиться никакой бизнес логики, взаимодействия с сетью, вычислений и так далее.
Его задача обрабатывать события с View, отображать или отправлять данные (без обработки и проверок) в Interactor.

🔹 Interactor

Содержит в себе бизнес логику сцены.

Он работает с сетью, базой данных и модулями устройства.

Interactor получает запрос из ViewController’a (с данными или пустой), обрабатывает его и, если это требуется, передает новые данные в Presenter.

🔹 Presenter

Занимается подготовкой данных для отображения.

Как пример, добавить маску на номер телефона или сделать первую букву в названии заглавной.
Обрабатывает данные, получение из Interactor’a, после чего отправляет их обратно во ViewController.

🔹 Models

Набор структур для передачи данных между компонентами VIP цикла. Каждый круг цикла имеет в себе 3 вида структур:

🔘 Request — Структура с данными (текст из TextField и т.д.) для передачи из ViewController'a в Interactor
🔘 Response — Структура с данными (загруженными из сети и т.д.) для передачи из Interactor в Presenter
🔘 ViewModel — Структура с обработанными данными (форматирование текста и т.д.) в Presenter’e для передачи обратно во ViewController

🔹 Worker

Разгружает Interactor, забирая на себя часть бизнес логики приложения, если Interactor стремительно разрастается.

Так же можно создавать общие для всех сцен Worker’ы, если их функционал используется в нескольких сценах.

Как пример, в Worker можно выносить логику работы с сетью или базой данных.

🔹 Router

В Router выносится вся логика, отвечающая за переходы и передачу данных между сценами.

____________________

Для прояснения картины работы VIP цикла приведу стандартный пример — авторизация.

1. Пользователь ввел свой логин и пароль, нажал на кнопку авторизации

2. У ViewController срабатывает IBAction, после чего создается структура с введенными, в TextField’ы, данными пользователя (Models -> Request)

3. Созданная структура передается в метод fetchUser в Interactor’e

4. Interactor отправляет запрос в сеть и получает ответ об успешности авторизации

5. На основе полученных данных, создает структуру с результатом (Models -> Response) и передается в метод presentUser в Presenter’e

6. Presenter форматирует данные по необходимости и возвращает их (Models -> ViewModel) в метод displayUser в ViewController’e

7. ViewController отображает полученные данные пользователю. В случае с авторизацией, может выводиться ошибка или срабатывать переход на другую сцену с помощью Router

Таким образом, мы получаем единую и последовательную структуру, с распределением обязанностей на компоненты.

🐸 Библиотека мобильного разработчика

#АрхитектурныйКод #SeniorView #Swift

🎮 KMP Starter — шаблон кроссплатформенного приложения на KMP

KMP Starter — современный, готовый к использованию шаблон приложения на Kotlin Multiplatform с дизайном Material 3, утилитами и чистой архитектурой.

Технический стек: Kotlin Multiplatform для кроссплатформенной разработки, Compose Multiplatform для UI, Material 3 как дизайн-система, Koin для инъекции зависимостей, Room в качестве локальной базы данных, DataStore для хранения настроек, корутины и Flow для асинхронного программирования, RevenueCat для покупок, MixPanel для аналитики, Kotlinx Serialization для сериализации JSON.

💻 KMP Starter на GitHub

🐸 Библиотека мобильного разработчика

#буст #Android

📞 VK Звонки в лесу: звоним в плохих сетях

VK Звонки способны работать даже в условиях высокой потери пакетов и низкой пропускной способности сети. Хотя интернет в крупных городах стал быстрым и стабильным, поездки в метро, использование лифта или подключение к Wi-Fi в кафе по-прежнему создают проблемы с качеством связи.

Спикеры рассказали, как решили эту задачу на Android-клиенте и какие техники для аудио и соединения можно применить в вашем проекте для звонков.

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

👀 Смотреть доклад

🐸 Библиотека мобильного разработчика

#свежак

✏️ adb shell dumpsys meminfo – детальный анализ использования памяти приложением

Мощный инструмент для мониторинга использования памяти вашим приложением в реальном времени. Помогает находить утечки памяти и оптимизировать потребление RAM.

📌 Ключевые метрики:

1. PSS (Proportional Set Size):

• Реальная память, занимаемая приложением
• Включает разделяемую память (пропорционально)

2. Private Dirty:

• Память, принадлежащая только вашему приложению
• Не может быть выгружена в swap

3. Java Heap:

• Память, управляемая Dalvik/ART
• Ключевой показатель для поиска утечек

⚡️ Практические сценарии:

Мониторинг в реальном времени:

# Каждые 2 секунды обновлять информацию
watch -n 2 "adb shell dumpsys meminfo com.yourapp.package"

Сравнение состояний:

# До и после выполнения операции
adb shell dumpsys meminfo com.yourapp.package > before.txt
# Выполняем действия в приложении
adb shell dumpsys meminfo com.yourapp.package > after.txt
diff before.txt after.txt

Поиск утечек в Activity:

# Проверить, не остались ли Activity в памяти
adb shell dumpsys meminfo | grep -E "Activity|View|Context"

⚙️ Анализ конкретных компонентов:

Только Java Heap:

adb shell dumpsys meminfo com.yourapp.package | grep -A 10 "Java Heap"

Нативные allocations:

adb shell dumpsys meminfo com.yourapp.package | grep -A 5 "Native Heap"

📊 Пример вывода для анализа:

Applications Memory Usage (in KB)
Uptime: 1234567 Realtime: 1234567

** MEMINFO in pid 1234 [com.yourapp] **
                   Pss  Private  Private  SwapPss     Heap     Heap     Heap
                 Total    Dirty    Clean    Dirty     Size    Alloc     Free
                ------   ------   ------   ------   ------   ------   ------
  Native Heap    12345    12000      345      100    15000    14000     1000
  Dalvik Heap     5678     5600       78       50     6000     5800      200

🔧 Продвинутое использование:

Профилирование конкретной операции:

#!/bin/bash
echo "Память до:" > mem_log.txt
adb shell dumpsys meminfo com.yourapp.package >> mem_log.txt

# Запускаем тестовый сценарий
adb shell am start -n com.yourapp/.TestActivity

echo "Память после:" >> mem_log.txt  
adb shell dumpsys meminfo com.yourapp.package >> mem_log.txt
Pro-совет: Используйте с procstats для долгосрочного мониторинга:

bash
adb shell dumpsys procstats --hours 1 com.yourapp.package

Как вы отслеживаете использование памяти в своих приложениях? 💬

🐸 Библиотека мобильного разработчика

#буст #MiddlePath #Android

🐸 Библиотека мобильного разработчика

#КодКрашТест #JuniorKit #Swift

⚙️ Превращение меню SwiftUI в мини-панель настроек

Меню в SwiftUI часто используются для быстрых одноразовых команд: выберите пункт, выполните действие — и всё готово. Но что, если вы хотите, чтобы меню функционировало не как простой селектор, а как мини-панель настроек, где пользователи могут последовательно переключать несколько пунктов, прежде чем сделать окончательный выбор? По умолчанию меню закрывается, как только пользователь нажимает на пункт, но с помощью подходящего API это поведение можно изменить.

➖ Переосмысление меню

Обычно при добавлении Menu к метке — например, к значку с тремя точками или кнопке — каждое касание внутри меню выполняет действие и немедленно закрывает меню. Это ожидаемый рабочий процесс «выбрать и закрыть».

Но есть сценарии, в которых может быть предпочтительнее другая модель взаимодействия:

🔘 Меню, допускающее несколько переключателей.
🔘 Меню, сохраняющее постоянное состояние, пока пользователь перемещается по набору пунктов.
🔘 Меню, которое остаётся открытым, пока пользователь пробует различные настройки, возможно, просматривая эффект в режиме реального времени, и закрывается только после того, как пользователь будет удовлетворен результатом.

В таких случаях поведение закрытия по умолчанию не является идеальным.

➖ Настройка поведения закрытия

SwiftUI расширяет меню с помощью модификатора menuActionDismissBehavior(_:). Это даёт вам возможность точно контролировать, должно ли касание внутри меню приводить к его закрытию или оставаться открытым.

Модификатор принимает один параметр типа MenuActionDismissBehavior, который представляет собой перечисление, определяемое примерно следующим образом:

public enum MenuActionDismissBehavior {
    case automatic   // system-default behaviour
    case enabled     // explicitly force dismissal on each tap
    case disabled    // keep the menu open after taps
}

Применение модификатора выглядит так:

Menu("Options") {
    Button("Toggle A") { /* … */ }
    Button("Toggle B") { /* … */ }
    Divider()
    Button("Done") { /* … */ }
}
.menuActionDismissBehavior(.disabled)

При использовании .disabled меню остаётся открытым после каждого действия, позволяя пользователю выполнить несколько действий, прежде чем решить закрыть его.

➖ Наглядный пример: пакетное переключение

Представьте, что у вас есть набор функций, которые пользователь может включить или отключить, и вы хотите, чтобы пользователь мог сделать несколько выборов в меню, прежде чем закрыть его.

struct FeatureToggleMenu: View {
    @State private var featureA = false
    @State private var featureB = false
    @State private var featureC = false
​
    var body: some View {
        Menu {
            Section {
                Toggle("Feature A", isOn: $featureA)
                Toggle("Feature B", isOn: $featureB)
                Toggle("Feature C", isOn: $featureC)
            }
            .menuActionDismissBehavior(.disabled)
            
            Button("Apply Changes") {
                // commit logic here
            }
        } label: {
            Label("Settings", systemImage: "gearshape")
        }
    }
}

В этом макете:

🔘 Пользователь открывает «Настройки» и переключает различные функции, не закрывая меню при каждом нажатии переключателя.
🔘 После выбора он нажимает «Применить изменения», а затем может закрыть меню (в зависимости от реализации).
🔘 Вы даже можете вручную принудительно закрыть меню, используя специальную кнопку «Готово».

➖ Заключение

Модификатор menuActionDismissBehavior(_:) — это удобный API для преобразования типичных меню SwiftUI в более надежные мини-интерфейсы для настроек, переключателей и многошаговых рабочих процессов. Продуманное использование этого может привести к более понятному и интуитивно понятному пользовательскому интерфейсу, когда вам нужно больше, чем простое взаимодействие «выбрать и применить».

🐸 Библиотека мобильного разработчика

#буст #MiddlePath #Swift

🐸 Библиотека мобильного разработчика

#междусобойчик #MiddlePath #Swift