❓ Что такое абстрактные классы

Абстрактный класс — это класс, представляющий из себя "заготовку" для целого семейства классов, который описывает для них общий шаблон поведения. Экземпляр такого класса не может быть создан. Абстрактному классу не нужен модификатор open, потому что он "открыт" для наследования по умолчанию.

В теле класса можно объявлять абстрактные свойства и функции. Это полезно, когда часть поведения класса не имеет смысла без реализации в более конкретном подклассе.

abstract class Tree {
  abstract val name: String
  abstract val description: String
  abstract fun info()
}

Каждый наследник обязан переопределять их все.

class Pine : Tree() {
  override val name = "Сосна"
  override val description = "Хвойное дерево с длинными иглами и округлыми шишками"
  override fun info() = "$name - ${description.toLowerCase()}."  
}

Свойства и функции необязательно должны быть абстрактными. У них может быть обобщенная реализация, которая будет с пользой наследоваться всеми подклассами. В этом случае для них в абстрактном классе объявляется конкретная реализация, к которой имеют доступ все наследники.

abstract class Tree {
  abstract val name: String
  abstract val description: String
  fun info(): String = "$name - ${description.toLowerCase()}."
}

...

class Pine : Tree() {
  override val name = "Сосна"
  override val description = "Хвойное дерево с длинными иглами и округлыми шишками"
}

...

val pine = Pine()
println(pine.info())

Так как этот компонент класса уже не будет абстрактным, наследники не смогут его переопределить.

class Pine : Tree() {
  override val name = "Сосна"
  override val description = "Хвойное дерево с длинными иглами и округлыми шишками"

  // ошибка: функция "info" является "final" и не может быть переопределена
  override fun info() = description  
}

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

abstract class Tree {
  abstract val name: String
  abstract val description: String

  open fun info(): String = "$name - ${description.toLowerCase()}."
}

У абстрактного класса может быть конструктор.

abstract class Tree(val name: String, val description: String) {
  open fun info(): String = "$name - ${description.toLowerCase()}."
}

Тогда каждый наследник должен предоставить для него значения.

class Pine(name: String, description: String) : Tree(name, description)

...

val pine = Pine("Сосна", "Хвойное дерево с длинными иглами и округлыми шишками")
println(pine.info())

🔹 Курс «Основы IT для непрограммистов»
🔹 Получить консультацию менеджера
🔹 Сайт Академии 🔹 Сайт Proglib

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

#буст #JuniorKit #Kotlin

✨ Gauge, ProgressView и Slider в SwiftUI

При создании интерфейсов на основе данных в SwiftUI вам часто будет требоваться визуализировать числовое значение или управлять им. Для этой цели можно использовать три встроенных представления — Gauge, ProgressView, и Slider.

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

🔹 Индикатор — отображение значения в диапазоне

Представленный в iOS 16 вид Gauge предназначен для отображения значения, а не для того, чтобы пользователи могли его изменять.

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

Gauge(value: currentTemp, in: 0...100) {
Text("Temperature")
} currentValueLabel: {
Text("\(Int(currentTemp))°C")
}
.tint(.orange)
Gauge(value: currentTemp, in: 0...100) {
    Text("Temperature")
} currentValueLabel: {
    Text("\(Int(currentTemp))°C")
}
.tint(.orange)

Индикатор может быть выполнен в нескольких стилях (.linearCapacity, .accessoryCircular и других) и естественным образом адаптируется к различным макетам — от круглых индикаторов в стиле приборной панели до компактных виджетов.

Используйте Gauge , когда:

🔘 Вам нужно визуализировать измеренное значение.
🔘 Взаимодействие с пользователем не предполагается.
🔘 Вам нужен единый стиль оформления системных виджетов и усложнений.

🔹 ProgressView — индикатор выполнения задачи

ProgressView предназначен для отслеживания прогресса, а не для отображения числовых значений. Он показывает, какая часть задачи выполнена, либо детерминированно (известная доля), либо неопределённо (индикатор вращения).

ProgressView(value: progress, total: 1.0)
.tint(.green)
ProgressView(value: progress, total: 1.0)
    .tint(.green)

Он хорошо подходит для экранов загрузки/выгрузки, процессов адаптации или длительных операций.
Ключевое отличие от Gauge заключается в контексте: значение представляет не реальное измерение, а состояние процесса.

Используйте ProgressView , когда:

🔘 Вы визуализируете процент выполнения задачи.
🔘 Значение всегда стремится к 100 %.
🔘 Вам нужна стандартная системная анимация и обратная связь по доступности.

🔹 Ползунок — обеспечивает прямое управление пользователем

В отличие от Gauge и ProgressView, Slider позволяет вводить данные. Это правильный выбор, если вы хотите, чтобы пользователь мог установить или изменить числовое значение, например яркость, громкость или интенсивность фильтра.

Slider(value: $volume, in: 0...100) {
Text("Volume")
}
.tint(.blue)
Slider(value: $volume, in: 0...100) {
    Text("Volume")
}
.tint(.blue)

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

Используйте Slider , когда:

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

🔹 Выбор правильного представления

При выборе из трёх вариантов:

🔘 Спросите, является ли значение измеренным, вычисленным или контролируемым пользователем.
🔘 Если значение измерено, используйте Gauge.
🔘 Если это означает завершение, используйте ProgressView.
🔘 Если пользователь манипулирует им, используйте Slider.

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

🔸 Курс «Основы IT для непрограммистов»
🔸 Получить консультацию менеджера
🔸 Сайт Академии 🔸 Сайт Proglib

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

#PixelPerfect #MiddlePath #Swift

🔥 Специализация или универсальность в мобильной разработке

Многие мобайл-разработчики приходят в индустрию через одну платформу — iOS или Android — и годами качают глубину в одной экосистеме.

Другие же выбирают путь «универсального бойца»: могут собрать фичу на обе платформы, пишут на Flutter/KMM, знают и Xcode, и Android Studio, и умеют ковыряться в любом стеке.

Но что сегодня выгоднее?
С одной стороны — узкие спецы ценятся выше за глубину.
С другой — универсалы легче адаптируются, быстрее растут и реже «сидят без задач».

А вы сами куда относитесь? Расскажите в комментариях — интересно понять, куда движется рынок👇

🔸 Курс «Специалист по ИИ»
🔸 Получить консультацию менеджера
🔸 Сайт Академии 🔸 Сайт Proglib

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

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

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

Team Lead мобильной разработки — удалёнка

IOS-разработчик (Middle+ / Senior) — от 275 000 до 325 000 ₽, удалёнка

Android Developer (Senior) — от 200 000 до 350 000 ₽, удалёнка

IOS Developer (Middle) / Разработчик iOS — от 200 000 до 300 000 ₽, удалёнка

Ведущий IOS разработчик (Swift) — от 250 000 до 350 000 ₽, удалёнка

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

🔸 Курс «Специалист по ИИ»
🔸 Получить консультацию менеджера
🔸 Сайт Академии 🔸 Сайт Proglib

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

#свежак

🎮 Как выполнить упрощённую миграцию в Core Data

Миграция базы данных требуется всякий раз, когда нам нужно внести изменения в модель Core Data. Для определённого набора изменений Core Data может выполнить почти автоматическую миграцию, которая называется облегчённой миграцией.

Это позволяет нам развивать нашу схему без потери существующих данных или необходимости вручную определять правила сопоставления.

Примеры поддерживаемых изменений: добавление, переименование или удаление сущностей, атрибутов или связей, а также изменение типов связей.

Когда изменения в нашей модели выходят за рамки того, что может определить Core Data, нам необходимо выполнить сложную (ручную) миграцию.

Давайте рассмотрим, как выполнить упрощённую миграцию в Core Data.

🔹 Как выполнить упрощённую миграцию в Core Data

Чтобы выполнить упрощённую миграцию в Core Data, необходимо выполнить следующие действия:

1. Включение облегченной миграции
2. Создание новой версии модели
3. Изменение новой модели

Давайте рассмотрим эти этапы более подробно.

1️⃣ Включение облегчённой миграции

Когда мы используем класс NSPersistentContainer для создания стека Core Data и управления им, нам не нужно выполнять никаких дополнительных действий по настройке, облегчённая миграция активируется автоматически.

Если мы создадим собственный стек Core Data вручную, то сможем явно включить эти параметры при добавлении хранилища:

let coordinator = NSPersistentStoreCoordinator(managedObjectModel: managedObjectModel)
let options = [
    NSMigratePersistentStoresAutomaticallyOption: true,
    NSInferMappingModelAutomaticallyOption: true
]
do {
    try coordinator.addPersistentStore(
 ofType: NSSQLiteStoreType,
 configurationName: nil,
 at: url,
 options: options
    )
} catch {
    // handle migration failure
}

Эти два параметра позволяют Core Data автоматически определять модель сопоставления и переносить данные при обнаружении совместимого изменения схемы.

2️⃣ Создание новой версии модели

Для автоматической миграции Core Data нужны исходная и конечная версии нашей модели данных.

Если мы изменим существующий .xcdatamodeld сразу после выпуска нашего приложения, Core Data не будет знать, как выполнить миграцию, и выдаст ошибку о несовместимости моделей.

Чтобы избежать этого, мы создаем новую версию модели, выбрав Редактор > Добавить версию модели в меню Xcode. Это добавит новый файл .xcdatamodel в наш проект.

После добавления новой версии мы можем установить текущую версию в инспекторе файлов Xcode. Теперь мы можем спокойно вносить изменения, не нарушая работу существующих хранилищ.

3️⃣ Изменение новой версии модели данных

Теперь мы можем вносить изменения в нашу модель. Чтобы Core Data могла создать предполагаемую модель сопоставления, изменения должны соответствовать определённому шаблону, например:

🔘 Добавление или удаление сущностей, атрибутов или связей.
🔘 Переименование сущностей, атрибутов или связей путем установки идентификатора переименования в качестве имени соответствующего свойства или сущности в предыдущей модели в инспекторе моделей данных Xcode.
🔘 Изменение обязательных атрибутов на необязательные или наоборот с указанием значения по умолчанию.
🔘 Изменение отношения «один ко многим» или неупорядоченного отношения на упорядоченное.
🔘 Чтобы проверить, может ли Core Data определить соответствие между двумя версиями модели, мы можем использовать:

let inferred = try? NSMappingModel.inferredMappingModel(
 forSourceModel: oldModel,
 destinationModel: newModel
)

if inferred != nil {
    // Lightweight migration is possible
}

Если этот вызов вернёт nil, Core Data не сможет определить сопоставление, а это значит, что нам потребуется более сложная миграция вручную.

🔸 Курс «Архитектуры и шаблоны проектирования»
🔸 Получить консультацию менеджера
🔸 Сайт Академии 🔸 Сайт Proglib

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

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