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

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

📎 Блок инициализации (init блок)

Основной конструктор не может в себе содержать какую-либо логику по инициализации свойств (исполняемый код). Он предназначен исключительно для объявления свойств и присвоения им полученных значений. Поэтому вся логика может быть помещена в блок инициализации — блок кода, обязательно выполняемый при создании объекта независимо от того, с помощью какого конструктора этот объект создаётся. Помечается он словом init.

class Person(val name: String, var age: Int) {
    var id: Int = 0

    // require выдает ошибку с указанным текстом, если условие в левой части false
    init {
        require(name.isNotBlank(), { "У человека должно быть имя!" })
        require(age > -1, { "Возраст не может быть отрицательным." })
    }

    constructor(name: String, age: Int, id: Int) : this(name, age) {
        if (id > 0) this.id = id * 2
    }
}

По сути блок инициализации — это способ настроить переменные или значения, а также проверить, что были переданы допустимые параметры. Код в блоке инициализации выполняется сразу после создания экземпляра класса, т.е. сразу после вызова основного конструктора. В классе может быть один или несколько блоков инициализации и выполняться они будут последовательно.

class Person(val name: String, var age: Int) {
    // сначала вызывается основной конструктор и создаются свойства класса
    // далее вызывается первый блок инициализации
    init {
        ...
    }

    // после первого вызывается второй блок инициализации
    init {
        ...
    }

    // и т.д.
}

Блок инициализации может быть добавлен, даже если у класса нет основного конструктора. В этом случае его код будет выполнен раньше кода вторичных конструкторов.

➡️ Подробнее в статье

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

#буст #MiddlePath #Kotlin

⚡️ Команда дня: flutter pub outdated

Хочешь понять, какие зависимости твоего проекта устарели — и стоит ли их обновлять? Вот команда, которая быстро всё покажет:

flutter pub outdated

📌 Что делает:

— Проверяет все пакеты в pubspec.yaml
— Показывает текущие, доступные и последние версии библиотек
— Помогает понять, где можно безопасно обновиться

Пример вывода:

Package         Current  Upgradable  Resolvable  Latest
http            1.2.0    1.3.0       1.3.0       1.3.0
provider        6.0.0    6.1.0       6.1.0       7.0.0

👀 Полезно, когда:

— Готовишь проект к релизу и хочешь убедиться, что всё актуально
— Нужно проверить, не тянет ли зависимость старые версии других пакетов
— Хочешь поддерживать проект «в форме» 💪

💡 Совет:

Чтобы обновить всё возможное, просто выполни:

flutter pub upgrade --major-versions

А вы как часто обновляете зависимости в своих проектах? 💬

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

#буст #MiddlePath

⚙️ Внедрение доступности (Accessibility) в мобильное приложение

Хотите сделать ваше приложение доступным для всех пользователей? Этот промпт поможет реализовать полноценную поддержку accessibility.

📝 Промпт:

Implement comprehensive accessibility features for a mobile app that includes:

— Add proper content descriptions for all UI elements
— Implement logical focus order and navigation
— Support screen readers (TalkBack/VoiceOver)
— Ensure sufficient color contrast and text sizing
— Add accessibility labels and hints
— Support voice control and switch access
— Test with accessibility services enabled

💡 Расширения:

— Добавьте Implement custom accessibility actions для сложных UI компонентов
— Добавьте Add haptic feedback for key interactions для невизуального взаимодействия
— Добавьте Support dynamic font sizing without breaking layouts для адаптивности текста

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

#буст #MiddlePath

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

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

✏️ 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

⚙️ Превращение меню 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

✨ Организация представлений SwiftUI с помощью ToolbarContent и @ToolbarContentBuilder

По мере роста проектов SwiftUI одна из частых проблем — управление сложными иерархиями представлений. Даже простой экран может быстро превратиться в десятки вложенных модификаторов. После снятия лимита в 10 вложенных представлений стало проще писать глубоко вложенные body, но код стал труднее читать и сопровождать.

🔹 Разбираем крупные реализации body

Когда body растягивается на десятки строк, страдает читаемость. Лучше разбивать большие представления SwiftUI на мелкие подпредставления или выделять повторно используемые части в вычисляемые свойства или функции. Это сохраняет лаконичность и упрощает понимание, тестирование и повторное использование.

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

🔹 Проблема с панелями инструментов

Модификатор .toolbar позволяет создавать кнопки, меню и элементы управления, адаптируемые под разные платформы. Но если элементов становится много, код внутри .toolbar { ... } быстро теряет читаемость.
Перенести логику в вычисляемое свойство нельзя — .toolbar ожидает содержимое, соответствующее ToolbarContent.

🔹 ToolbarContent и @ToolbarContentBuilder

SwiftUI решает это с помощью:

• ToolbarContent — протокола для элементов панели инструментов;
• @ToolbarContentBuilder — билдера, создающего набор элементов панели.

Объединив их, можно вынести содержимое панели инструментов в отдельный блок, сделав body чище и понятнее.

Пример

struct DemoView: View {
    @State private var message = "Hello, world!"

    var body: some View {
        NavigationStack {
            Text(message)
                .font(.title2)
                .padding()
                .navigationTitle("Home")
                .toolbar { toolbarContent }
        }
    }

    @ToolbarContentBuilder
    private var toolbarContent: some ToolbarContent {
        ToolbarItem(placement: .navigationBarLeading) {
            Button { message = "Left tapped" } label: {
                Label("Left", systemImage: "line.3.horizontal")
            }
        }
        ToolbarItem(placement: .navigationBarTrailing) {
            Button { message = "Right tapped" } label: {
                Label("Right", systemImage: "star")
            }
        }
    }
}

🔹 Заключение

Использование @ToolbarContentBuilder для отделения содержимого панели инструментов от основного окна имеет ряд преимуществ:

• Улучшена читаемость: Ваш body текст по-прежнему сосредоточен на вёрстке, а логика панели инструментов реализована в другом месте.
• Лучшая организация: Группировка элементов панели инструментов в отдельном блоке позволяет с первого взгляда оценить их структуру и расположение.
• Масштабируемость: Когда на панели инструментов появляется несколько кнопок, меню или условная логика, поддерживать её в рабочем состоянии становится намного проще.

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

#PixelPerfect #MiddlePath #Swift

🌛 Реализация офлайн-режима

Хотите, чтобы ваше приложение работало даже без интернета? Этот промпт поможет реализовать надежный офлайн-режим и синхронизацию данных.

📝 Промпт:

Implement offline-first approach for a mobile app that includes:

— Set up local database (Room/SQLite/CoreData)
— Implement data synchronization strategy
— Handle conflict resolution for concurrent modifications
— Manage offline queue for pending operations
— Add network connectivity detection
— Implement cache management and expiration policies
— Provide user feedback for sync status

💡 Расширения:

— Добавьте Implement reactive UI updates using observables для автоматического обновления интерфейса
— Добавьте Add retry mechanisms with exponential backoff для надежной синхронизации
— Добавьте Support large file caching with storage management для работы с медиа в офлайне

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

#буст #MiddlePath