itmo_conspects

Backend-driven UI на Android

Лекция 1

Интерфейс, управляемый бэкендом (Backend-driven UI или Server-driven UI) - это архитектурный подход, при котором бэкенд определяет не только данные, но и саму структуру, логику и внешний вид интерфейса клиентского приложения

Клиент в таком подходе выступает как рендерер - он получает описание интерфейса (обычно в формате JSON) и отображает его. Это позволяет:

Недостатки такого подхода:

Язык Kotlin

До недавнего времени Android-приложения разрабатывались на языке Java, но в 2010-ых начал свое развитие язык программирования Kotlin, и индустрия начала переход на него

Kotlin - статически типизируемый, объектно-ориентированный язык, использующий виртуальную машину Java для исполнения. При создании целью было сделать язык лаконичным, удобным и безопасным по сравнению с Java

Типы, как и в Java, делятся на примитивные и ссылочные. Переменные примитивных типов хранят значение непосредственно (то есть оно копируется при передаче), а ссылочных - ссылку на объект в памяти

Переменные объявляются двумя способами:

var a = 10
var b: Long = 10
val c = 20

Компилятор может угадать тип по типу литерала значения. Тип можно указать явно в объявлении переменной. В Kotlin существуют такие же примитивные типы, как и в Java:

Примитивы на уровне языка Kotlin являются объектами, то есть имеют соответствующие методы, однако на уровне байткода они оптимизируются до примитивов виртуальной машины

Для сравнения переменных есть операторы:

Оператор is используется для соответствия переменной типу:

if (obj is String) {
    println("This is String!")
}

Обнуляемые типы

Язык Kotlin расширяет систему типов, добавляя типы с допустимым отсутствием значения null. Такие типы называются обнуляемыми (nullable) и обозначаются как X?, например, String?. Соответственно типы, которые не допускают null, называются необнуляемыми (non-nullable)

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

Другой оператор as используется для приведения объекта к типу:

val x: String = y as String
val x: String? = y as String?

В случае если объект нельзя привести к другому, то as вызывает исключение ClassCastException. Чтобы избежать этого, есть оператор as?, который в случае неприведения типа возвращает null:

val x: String? = y as? String

В этом случае x равен null, если y нельзя привести к String

Управление потоком

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

Для управления циклами есть ключевые слова:

Для циклов, функций и скоупов применимы метки - идентификаторы, указывающиеся с помощью @:

loop@ for (i in 1..10) {
    for (j in 1..10) {
        if (i > 4)
            break@loop
    }
}

Метки помогают управлять потоком, но ухудшают читаемость кода. Так, в примере выше внешний цикл прерывается

С помощью меток можно прерывать исполнение не только в циклах, но и в анонимных функциях:

run loop@{
    listOf(1, 2, 3, 4, 5).forEach {
        if (it == 3)
            return@loop
        print(it)
    }
}

Помимо такого бесконтекстного блока run есть еще способы выполнить блок кода в контексте объекта:

Главные различия - это то, как передается, и то, что возвращается:

Ключевое слово Как передается объект Что возвращает
let it результат лямбды
run this результат лямбды
apply this сам объект
also it сам объект

Исключения обрабатываются с помощью try-catch:

try {
    // опасный код
} catch (e: SomeException) {
    // обрабатываем исключение
} finally {
    // выполняется в любом случае
}

В Kotlin нет проверяемых исключений - компилятор не требует их обязательной обработки

ООП в Kotlin

В Kotlin ООП схоже с тем, что в языке Java

В Kotlin есть основной конструктор и вторичные конструкторы

  1. Основной конструктор (Primary Constructor) объявляется в заголовке класса:

     class User(val name: String, var age: Int)

    Здесь name и age - параметры конструктора, а val/var означают, что параметры сразу становятся свойствами класса

    Если убрать val/var, это будут просто параметры class User(name: String, age: Int), тогда внутри класса их нужно присвоить вручную

    Далее код инициализации выполняется в блоке init:

     class User(val name: String, var age: Int) {

     init {
         require(age >= 0) { "Age must be positive" }
         println("User created")
     }
 }

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

    Ключевое слово constructor обычно опускается:

     class User constructor(val name: String)

    Оно пишется явно только если нужен модификатор доступа:

     class User private constructor(val name: String)

  2. Вторичный конструктор (Secondary Constructor) объявляется внутри класса с ключевым словом constructor:

     class User {

     var name: String
     var age: Int

     constructor(name: String, age: Int) {
         this.name = name
         this.age = age
     }
 }

    Если в классе есть основной конструктор, то каждый вторичный конструктор обязан вызвать его через this(...):

     class User(val name: String, var age: Int) {

     constructor(name: String) : this(name, 0)
 }

    В этом случае 1) вызывается основной конструктор; 2) выполняются init блоки; 3) выполняется тело вторичного конструктора

Если основной конструктор отсутствует, то класс может иметь только вторичный:

class User {

    var name: String
    var age: Int

    constructor(name: String) {
        this.name = name
        this.age = 0
    }
}

В Kotlin чаще используют значения по умолчанию, companion object (аналог статичных полей) с фабричными методами и слово apply, поэтому вторичные конструкторы используются реже, чем в Java

В Kotlin все объекты неявно наследуются от Any. По умолчанию класс нельзя наследовать. Чтобы один класс смог наследоваться от другого, класс-родитель должен иметь модификатор open:

open class Base(p: Int)
class Derived(p: Int) : Base(p)

Аналогично с методами: чтобы их можно было переопределить, они должны иметь модификатор open

Абстрактные классы объявляются с помощью abstract:

abstract class Shape {
    abstract fun draw()
}

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

Свойства определяются через var и val:

class Address {
    var a: String = "A"
    val b: String = "B"
    val c: String
        get() = this.toString() + "."

    var counter = 0
        set(value) {
            if (value >= 0)
                field = value 
                // field - специальное слово, 
                //которое ссылается на значение свойства
        }
}

Интерфейсы схожи с теми, что присутствуют в других языках:

interface MyInterface {
    fun bar()
    fun foo() {
        // метод с реализацией по умолчанию
    }
}

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

Также Kotlin имеет модификаторы доступа для свойств и методов:

Помимо обычных классов, в Kotlin есть классы данных. Класс данных (Data Class) - синтаксический сахар для упрощенного создания DTO (Data Transfer Object). Класс данных:

Пример:

data class User(val name: String = "", val age: Int = 0)

Для этого основной конструктор должен иметь как минимум один параметр, все параметры основного конструктора должны быть отмечены как свойства (через var или val), и классы данных не могут быть абстрактными или иметь модификаторы open, sealed и inner

Как в C#, Kotlin позволяет расширить функциональность класса добавлением методов расширения (Extension Method):

data class Book(
    val id: Long,
    val author: String,
    val title: String,
    val price: BigDecimal
)

class SomeService {
    fun analyzeBook(book: Book) {
        val formattedInfo = book.getFormattedInfo() // вызов метода
        
    }

    // его объявление
    private fun Book.getFormattedInfo(): String = "Book $author - $title has price - $price"
}

При компиляции метод Book.getFormattedInfo() превращается в подобное:

public String getFormattedInfo() {
    return "Book " + author + " - " + title + " has price - " + price;
}

Kotlin позволяется генерировать код во время исполнения, что позволяет генерировать класс-родитель на этапе исполнения и сделать так, чтобы целевой класс наследовался от него

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

Вложенные классы - классы, вложенные в другие классы:

class Outer {
    private val bar: Int = 1
    class Nested {
        fun foo() = 2
    }
}

val value = Outer.Nested().foo() // == 2

Вложенные классы не имеют доступа к приватным полям внешнего класса, поэтому существуют внутренние классы, которые имеют ссылку на объект внешнего класса:

class Outer {
    private val bar: Int = 1
    inner class Inner {
        fun foo() = bar
    }
}

val demo = Outer().Inner().foo() // == 1

В Kotlin есть возможность создать класс-перечисление:

enum class Direction {
    NORTH, SOUTH, WEST, EAST
}

enum class Color(val rgb: Int) {
    RED(0xFF0000),
    GREEN(0x00FF00),
    BLUE(0x0000FF)
}

Каждый элемент перечисления является объектов этого класса

В Kotlin есть возможность создания анонимных объектов:

val obj = object {
    val x = 10
}

Их в том числе можно наследовать от других классов:

val listener = object : View.OnClickListener {
    override fun onClick(v: View?) { }
}

Функции

Функции объявляются с помощью ключевого слова fun:

fun sum(a: Int, b: Int = 1): Int {
    return a + b
}

Аргументы функции могут иметь значения по умолчанию, а для отсутствия возвращаемого значения используют Unit (аналог void)

Вызов функции осуществляется так:

sum(3, 5)
// или
sum(3)
// или
sum(a = 3)
// или
sum(a = 3, b = 5)

Функция высшего порядка - функция, принимающая другую функцию:

fun operate(x: Int, op: (Int) -> Int): Int {
    return op(x)
}

Kotlin поддерживает создание функций, вложенных в другую функцию:

fun dfs(graph: Graph) {
    val visited = HashSet<Vertex>()

    fun dfs(current: Vertex) {
        if (!visited.add(current)) return
        for (v in current.neighbors)
            dfs(v)
    }

    dfs(graph.vertices[0])
}

Функции могут иметь обобщенные параметры (Generic):

fun <T> singletonList(item: T): List<T> { 
    /*...*/
}

В Kotlin функции являются функциями первого класса, то есть могут храниться в контейнерах. Для этого функции представляются объектами функционального типа, который описывается так: (A, B) -> C

Здесь функция такого типа принимает параметры типов A и B и возвращает значение типа C

На уровне JVM функциональные типы компилируются в объекты, реализующие интерфейсы

Если параметров нет, то кортеж пуст: () -> A

Если возвращаемого типа нет, то пишут Unit в объявлении: () -> Unit

Также существуют функциональные типы с получателем, которые записываются так: A.(B) -> C

Это означает, что есть объект-получатель типа A, есть параметр типа B и возвращается C

Например, можно создать метод расширения:

val repeatFun: String.(Int) -> String = { times ->
    this.repeat(times)
}

val result = "Hi".repeatFun(3)

Внутри лямбды словом this описан объект-получатель

Для таких типов (как и для других) можно задать псевдоним:

typealias ClickHandler = (Button, ClickEvent) -> Unit

Kotlin позволяет создавать встроенные функции. Код таких функций на этапе компиляции встраивается внутри другого кода

Иногда это приводит к улучшению производительности, но наибольший смысл встроенные функции имеют, если их аргумент - это лямбда-функция. Тогда код лямбда функции вставиться в тело функции:

inline fun test(block: () -> Unit) {
    println("Before")
    block()
    println("After")
}

test {
    println("Hello")
}

Поэтому такой код превращается в:

println("Before")
println("Hello")
println("After")

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

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

inline fun process(
    inlineBlock: () -> Unit,
    noinline normalBlock: () -> Unit
) {
    inlineBlock()

    val stored = normalBlock   // можно сохранить
    stored()
}

Встроенные лямбда-функции поддерживают нелокальные возвраты, то есть использование return внутри лямбда-функции вынудит выйти из внешней функции:

inline fun test(block: () -> Unit) {
    block()
    println("After block")
}

fun example() {
    test {
        return   // выйдет из example()
    }
    println("This won't print")
}

Это работает, потому что лямбда встроена. Чтобы устранить это, есть слово crossinline, которое запрещает слово return внутри лямбды:

inline fun test(crossinline block: () -> Unit) {
    block()
    println("After block")
}

fun example() {
    test {
        // return
        // ошибка компиляции
    }
    println("This will print")
}

Наконец, слово reified позволяет использовать тип во время выполнения

Обычно обобщенные типы стираются на этапе компиляции (так как на нем вместо T подставляется Object), то есть нельзя написать:

fun <T> check(value: Any): Boolean {
    return value is T  // ошибка, так как T - это Object
}

потому что тип T неизвестен во время выполнения в виртуальной машине. Для решения этого можно применить встроенную функцию и слово reified:

inline fun <reified T> check(value: Any): Boolean {
    return value is T
}

val result = check<String>("Hello")

Теперь компилятор подставляет реальный тип вместо T

Архитектура Android-приложений

Устройства на Android представляют внушительную долю рынка мобильных устройства и являются смартфонами, планшетами, телевизорами, часами и другими подобными

Операционная система Android начала свое развитие в 2000-ых, а версия 1.0 появилась в 2008. Сейчас на начало 2026 года актуальной является Android 16, а по статистике от Google примерно 99% устройств имеют Android версии 7.0 и новее

Android имеет такой программный стек из 5 уровней:

  1. Приложения

    Это сами Android-приложения, в том числе системные (Телефон, Камера, Контакты и другие) и сторонние приложения из Google Play

    Каждое приложение: работает в своём процессе, имеет свой UID и изолировано в “песочнице” (sandbox)

  2. Application Framework

    Это набор Java/Kotlin API, с которыми работают разработчики

  3. Android Runtime (ART)

    Android Runtime - виртуальная машина для исполнения, которая пришла на замену другой машины Dalvik

    ART отвечает за выполнение байткода, сборку мусора, управление памятью, AOT- и JIT-компиляцию

    Каждое приложение запускается в своём экземпляре ART

  4. Нативные библиотеки и машиннозависимые модули (HAL)

    Это включает:

    • libc, SSL, SQLite, OpenGL и другие библиотеки, которые используются через Java Native Interface
    • драйвера для камеры, аудио, сенсоров и других модулей, которые используются в устройстве

  5. Ядро Linux

    Android использует модифицированное ядро Linux как фундамент. Оно отвечает за управление памятью, процессы и потоки, безопасность, драйвера и энергопотребление

Простенькое Android-приложение состоит из:

Для сборки используется система Gradle. Результатом сборки является:

App Bundle содержит все ресурсы, а магазин (например, Google Play) генерирует оптимизированный APK для устройства пользователя

Так как Android основан на Linux, запущенное приложение представляет собой созданный процесс

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

В основе главного потока лежит android.os.Looper, который содержит очередь сообщений MessageQueue и обрабатывает сообщения последовательно

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

Как правило, нет каких-либо гарантий, что новое сообщение обработается точно через данное число секунд

Далее Looper работает с этим компонентами:

Сущность android.app.Activity - это активность, один экран с элементами Android-приложения

Для создания активности необходимо создать класс-наследник и указать его в манифесте. Жизненный цикл для активности внутри приложения выглядит так:

Жизненный цикл активности

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

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

Активности представляют из себя стек, что позволяет по кнопке “Назад” возвращаться к предыдущей активности

Контекст android.content.Context предоставляет информацию о текущем окружении приложения, в том числе предоставляющий доступ:

У сущностей Application, Activity, Service, ContentProvider и BroadcastProvider есть свои контексты

Лекция 2. Намерение, стек активностей, фрагмент

Намерение

Активности не вызывают друг друга непосредственно. Вместо этого одна активность выражает намерение создать (или сделать что-то другое) активность

Намерение выражается в объекте Intent - объекте для запроса действия от другого компонента Android, например, для создания службы Service

Есть три основных способа использования намерений:

К намерениям можно добавлять дополнительные данные с помощью метода putExtra

Также есть два типа намерений: явные и неявные

Само намерение состоит из:

Для того, чтобы иметь возможность принимать неявные намерения от операционной системы, нужно указать их типы в манифесте AndroidManifest.xml. Например, можно ограничиться намерениями, действия которых заключаются в просмотре веб-контента по https://my_host

<intent-filter>
   <action android:name="android.intent.action.VIEW" />
   <category android:name="android.intent.category.DEFAULT" />
   <category android:name="android.intent.category.BROWSABLE" />
   <data android:scheme="https" android:host="my_host" />
</intent-filter>

Такой блок называется фильтром намерений

Стек активностей

Одной из архитектурных целей, которые разработчики Android преследовали во время разработки, - это предсказуемость навигации. Для этого на нижней навигационной панели каждого приложения есть три универсальные кнопки: кнопка “Назад”, кнопка “Домой” и кнопка “Недавние” (в более поздних версиях есть возможность заменить эти кнопки на управление свайпами)

Кнопка “Назад” необходима для того, чтобы возвращаться на предыдущий экран с интерфейсом, а, чтобы иметь такую возможность, нужно хранить их

Для этого в каждом приложении есть стек активностей - Back Stack

Когда нажимается иконка приложения в телефоне, вызывается стартовая активность, которая кладется на вершину стека. Если из нее перейти в другую, то она положиться на вершину, тем самым по кнопке “Назад” можно возвращаться к предыдущим активностям

При повторном открытии приложения стек восстанавливается, при этом одна активность может существовать в стеке несколько раз

Правила дополнения стека и снятия со стека для конкретной активности можно переопределить с помощью свойства launchMode в манифесте AndroidManifest.xml:

Источник: https://developer.android.com/guide/components/activities/tasks-and-back-stack

Вместе с режимом запуска можно использовать флаги, который используется при создании намерения и имеют больший приоритет, чем launchMode

Фрагмент

Фрагмент (Fragment, androidx.fragment.app.Fragment) - модульная часть интерфейса внутри активности. Фрагмент имеет свой жизненный цикл и может быть переиспользован в разных активностей. Также несколько фрагментов могут находиться в одной активности одновременно

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

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

У фрагмента такой жизненный цикл:

Жизненный цикл фрагмента

Фрагмент создается как класс, наследующийся от Fragment:

class MyFragment : Fragment(R.layout.fragment_main)

Или вручную с созданием представления:

override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View {
    _binding = FragmentMyBinding.inflate(inflater, container, false)
    return binding.root
}

В само приложение фрагмент добавляется:

Здесь создается транзакция, которая позволяет условно атомарно изменить фрагмент. Для навигации между фрагментами у FragmentTransaction есть три основных метода:

Другой метод, addToBackStack(), добавляет транзакцию в стек. При нажатии на кнопку “Назад” транзакция откатится и вернётся предыдущий фрагмент. Без этого нажатие кнопки “Назад” закроет активность

supportFragmentManager.beginTransaction()
    .replace(R.id.container, DetailFragment())
    .addToBackStack(null)
    .commit()

Для передачи данных между фрагментами можно использовать объект Bundle:

companion object {
    fun newInstance(name: String) = MyFragment().apply {
        arguments = Bundle().apply { putString("key", name) }
    }
}

Получить данные можно с помощью свойства arguments

val name = arguments?.getString("key")

Лекция 3. Работа с сетью и UI

Сетевое взаимодействие

Сейчас самым распространенным сетевым стеком является TCP/IP. Он состоит из:

Подробнее о нем описано в курсе “Телекоммуникационные системы и технологии”

Чтобы Android-приложение могло работать с сетью, необходимо в AndroidManifest.xml прописать нужные разрешения:

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

Для доступа к сетевому API все чаще используется HTTP (HyperText Transfer Protocol). Обычно HTTP работает так:

Подробнее про HTTP описано в курсе “Web-разработка: Backend”

HTTP поддерживает типы запросов, которые семантически обозначают, что надо сделать с ресурсом, самые используемые это:

По умолчанию, протокол HTTP не поддерживает шифрование запросов, и любой участник передачи сообщения может его прочитать. Для борьбы с этим был создан протокол HTTPS (HTTP Secure)

Чаще всего ответом сервера на запрос будут данные в формате JSON (JavaScript Object Notation). Чтобы перевести JSON-текст в объектную модель, в Android-экосистеме используют:

Рассмотрим библиотеку GSON. Ее возможности включают автоматически маппинг JSON-объекта в сущность домена в виде POJO (Plain Old Java Object):

data class Person(
    @SerializedName("full_name")
    val name: String,
    val age: Int,

    @SerializedName(value = "email_address", alternate = ["email", "e"])
    val email: String? = null
)

val gson = Gson()

// Сериализация
val p = Person("Alice", 30)
val json: String = gson.toJson(p)
println(json) // {"name":"Alice","age":30}

// Десериализация
val jsonString = """{"name":"Bob","age":25,"email":"bob@example.com"}"""
val person: Person = gson.fromJson(jsonString, Person::class.java)
println(person) // Person(name="Bob", age=25, email="bob@example.com")

GSON позволяет задать имя ключа при сериализации и дополнительные имени для десериализации (в примере выше электронную почту можно указать как e и email). Также GSON производит автоматические преобразование к нужному типу, например, 0 и false, выданные сервером, преобразуются к булевому типу

Помимо обычного конвертера Gson(), можно указать дополнительные параметры в GsonBuilder(), например:

val gson = GsonBuilder()
   .setDateFormat("секунды ss, минуты mm, день dd, месяц MM, год yyyy")
   .setFieldNamingPolicy(FieldNamingPolicy.UPPER_CAMEL_CASE)
   .create()

Здесь указаны формат даты и политика полей имен (в данном случае свойство firstName сконвертируется в FirstName в JSON)

Одной из популярных библиотек для HTTP-обмена в Android является Retrofit. Это библиотека позволяется превратить API веб-приложений в интерфейс языка Java

Работает она так: сначала описываем сущности домены, которые приходят из API

data class Post(
    val userId: Int,
    val id: Int,
    val title: String,
    val body: String
)

Далее создаем интерфейс, аналогичный API:

interface JsonPlaceholderApi {
    // на GET запрос по http://host.com/posts
    // вернуть список постов
    @GET("posts")
    suspend fun getPosts(): List<Post>
}

Далее создает сервис и оборачивающая его функция:

val service = retrofit.create(JsonPlaceholderApi::class.java)

suspend fun fetchData() {
    try {
        val posts = service.getPosts()
        posts.forEach { println(it.title) }
    } catch (e: Exception) {
        println("Ошибка: ${e.message}")
    }
}

Также этот сервис можно настраивать под свои нужды, например, можно заказать конвертер из библиотеки GSON:

val service = retrofit.Builder()
    .baseUrl("http://example.com")
    .addConverterFactory(GsonConverterFactory.create())
    .build()
    .create(PokeApiService::class.java)

Далее этот сервис работает так:

Здесь в интерфейсе и функции fetchData есть ключевое слово suspend. Оно говорит о том, что метод и функции являются корутинами, то есть объектами асинхронного исполнения

Корутины - это механизм асинхронного программирования в Kotlin, позволяющий писать конкурентный код в последовательном стиле без блокировки потоков. В отличие от классических потоков, корутины легковесны: на одном потоке могут выполняться тысячи корутин. Корутины исполняются в области жизни CoroutineScope, которая привязана к компоненту пользовательского интерфейса

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

До этого вместо корутин использовали интерфейс Call<T>:

interface MyApiService {
    @GET("users")
    fun getUsers(): Call<List<User>> 
}

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

val call: Call<List<User>> = service.getUsers() // запрос создан, но не отправлен

call.enqueue(object : Callback<List<User>> {
    override fun onResponse(call: Call<List<User>>, response: Response<List<User>>) {
        if (response.isSuccessful) {
            val users = response.body()
            println("Получено пользователей: ${users?.size}")
        } else {
            println("Ошибка сервера: ${response.code()}")
        }
    }

    override fun onFailure(call: Call<List<User>>, t: Throwable) {
        println("Ошибка сети: ${t.message}")
    }
})

Также библиотека OkHttp позволяет работать с протоколом WebSocket:

val ws = OkHttpClient().newWebSocket(
    Request.Builder().url("ws:sample").build(), 
    object: WebSocketListener() {
        override fun onMessage(webSocket: WebSocket, text: String) {
            super.onMessage(webSocket, text)
        }

        override fun onOpen(webSocket: WebSocket, response: Response) {
            super.onOpen(webSocket, response)
        }

        override fun onClosed(webSocket: WebSocket, code: Int, reason: String) {
            super.onClosed(webSocket, code, reason)
        }

        override fun onClosing(webSocket: WebSocket, code: Int, reason: String) {
            super.onClosing(webSocket, code, reason)
        }
    }
)
ws.send("Hello")

Здесь в методе создания веб-сокета передается объект класса, реализующий 4 метода

Помимо HTTP-запросов можно отправлять сырые запросы по TCP или UDP

Так работает передача по TCP:

// Создаем TCP-сокет
val echoSocket = Socket(hostName, portNumber)

// Достаем из него поток для отправки текста
val out = PrintWriter(echoSocket.getOutputStream(), true)

// Перенаправляем стандартный поток ввода в наш сокет
System.setIn(echoSocket.getInputStream())

Так создаются UDP-сокеты:

// Создание сокета
val socket = DatagramSocket(1024, InetAddress.getByName("0.0.0.0"))
socket.reuseAddress = true
socket.broadcast = true

// Ждем датаграмму
val recvBuf = ByteArray(10)
val packet = DatagramPacket(recvBuf, recvBuf.size)
socket.receive(packet)

UI

Android позволяет создавать интерфейсы несколькими способами:

Объявление в XML-файле и программные можно комбинировать

Рассмотрим объявления в формате XML. Все XML-файлы хранятся в папке /res/, в частности:

В /res/layout как раз-таки описано то, как выглядит интерфейс приложения, а именно его элементы на соответствующих экранах, как они расположены, каких цветов и так далее

Обычно один такой файл выглядит так:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/root"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    android:gravity="center"
    android:padding="24dp">

    <TextView
        android:id="@+id/textCount"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Count: 0"
        android:textSize="32sp"
        android:layout_marginBottom="16dp" />

    <Button
        android:id="@+id/buttonIncrement"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Increment" />

    <Space
        android:layout_width="wrap_content"
        android:layout_height="12dp" />

    <Button
        android:id="@+id/buttonReset"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Reset" />

</LinearLayout>

Здесь интерфейс описан как линейный макет с объектами представления

Иерархия в интерфейсе

Объект представления View

Класс View - это базовый класс, который представляет элемент интерфейса

View является классом-родителем для множества других элементов:

В XML-файле объект представления задается тегом его класса, например:

    <TextView
        android:id="@+id/textCount"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Count: 0"
        android:textSize="32sp"
        android:layout_marginBottom="16dp" />

Далее идут атрибуты объекта представления, такие как:

Жизненный цикл View состоит из следующих этапов:

Если View некорректна или неактуальна, можно воспользоваться следующими методами:

Жизненный цикл представления

Также можно создать свой наследник View. Для этого создаем класс:

class CircleView @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null
) : View(context, attrs) {

    private val paint = Paint(Paint.ANTI_ALIAS_FLAG).apply {
        color = Color.RED
    }

    fun setColor(color: Int) {
        paint.color = color
        invalidate()  // перерисовать
    }

    override fun onDraw(canvas: Canvas) {
        super.onDraw(canvas)
        // Рисуем круг по центру View
        val cx = width / 2f
        val cy = height / 2f
        val radius = min(width, height) / 2f
        canvas.drawCircle(cx, cy, radius, paint)
    }
}

Далее использовать программно или в XML:

<com.example.exampleapp.CircleView
    android:layout_width="100dp"
    android:layout_height="100dp" />

Для таких View можно объявлять свои атрибуты в файле /res/values/attrs.xml, например:

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <declare-styleable name="CircleView">
        <attr name="circleColor" format="color" />
    </declare-styleable>
</resources>

Далее в классе читать атрибуты:

class CircleView @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
    defStyleAttr: Int = 0
) : View(context, attrs, defStyleAttr) {

    init {
        // Читаем атрибуты
        val typedArray = context.obtainStyledAttributes(attrs, R.styleable.CircleView)
        val defaultColor = Color.RED
        val color = typedArray.getColor(R.styleable.CircleView_circleColor, defaultColor)
        typedArray.recycle()

        paint.color = color
    }

    // ...
}

Здесь defStyleAttr указывает на атрибут в теме, содержащий стиль по уполчанию для CircleView

Далее цвет можно указать так:

    <com.example.exampleapp.CircleView
        android:layout_width="100dp"
        android:layout_height="100dp"
        app:circleColor="@color/blue" />

Объект макета Layout

Так в Android-приложении весь интерфейс одного экрана живет в одной активности. Для компоновки элементов интерфейса используют объект макета Layout. Сам макет с его элементами описывается в XML-файле в папке /res/layout (или программно)

Рассмотрим основные классы, которые наследуются от Layout:

Самый быстрый - это FrameLayout. Далее идут LinearLayout, GridLayout и другие

Разметка элементов регулируется атрибутами в объектах макетов и дочерних элементах

Макеты

Главное правило - избегать излишней вложенности. RelativeLayout и LinearLayout могут два раза пробегаться по элементам при отрисовке. Если интерфейс сложный, то лучше использовать ConstraintLayout

Также для удобства макеты можно вкладывать друг в друга, указывая имя XML-файла с помощью тега <include>. Например, если есть res/layout/header.xml:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:background="#2196F3"
    android:padding="16dp">

    <TextView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Заголовок приложения"
        android:textColor="#FFFFFF" />
</LinearLayout>

То можно его включить в другом макете так:

<include
    android:id="@+id/main_header"
    layout="@layout/header" />

А если нужно не весь Layout, а только его содержимое, то можно применить тег <merge>:

<?xml version="1.0" encoding="utf-8"?>
<merge xmlns:android="http://schemas.android.com/apk/res/android">

    <TextView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Заголовок приложения"
        android:textColor="#FFFFFF" />
</merge>

<include layout="@layout/header" />

Это позволяет улучшить производительность и уменьшить вложенность иерархии

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

public class MainActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        // Создаем LinearLayout
        LinearLayout layout = new LinearLayout(this);
        layout.setOrientation(LinearLayout.VERTICAL);
        layout.setLayoutParams(new LayoutParams(LayoutParams.MATCH_PARENT, LayoutParams.MATCH_PARENT));

        // Создаем кнопку
        Button button = new Button(this);
        button.setText("Нажми меня");
        button.setLayoutParams(new LayoutParams(LayoutParams.WRAP_CONTENT, LayoutParams.WRAP_CONTENT));

        // Добавляем кнопку в LinearLayout
        layout.addView(button);

        // Устанавливаем LinearLayout как корневой элемент Activity
        setContentView(layout);
    }
}

Процесс надувания

Далее, когда запускается приложение и создается активность, происходит процесс надувания (inflate) - специальный сервис LayoutInflater превращает XML-теги в объекты языка, с которыми можно работать внутри кода

// Получаем экземпляр LayoutInflater
val inflater = LayoutInflater.from(context) 
// или getLayoutInflater()

// Надувание
val rootView: View = inflater.inflate(R.layout.item_view, null)

// Теперь находим дочерние представления по их идентификатору,
// используя findViewById<T>
val title = rootView.findViewById<TextView>(R.id.titleTextView)
val button = rootView.findViewById<Button>(R.id.actionButton)

// Устанавливаем текст и обработчик
title.text = "Заголовок"
button.setOnClickListener {
    // действие
}

// Добавляем rootView на какой-нибудь макет
someLinearLayout.addView(rootView)

Здесь R в R.layout.item_view, R.id.titleTextView, R.id.actionButton - это автоматически сгенерированный класс, создающийся на этапе компиляции и состоящий из указателей на ресурсы приложений (в данном случае мы заказали кнопку из файла или /res/layout/item_button.xml)

Метод inflate имеет такую сигнатуру:

inflate(@LayoutRes resource: Int, root: ViewGroup?, attachToRoot: Boolean): View

Здесь resource - указатель из R, root - родительский элемент, который будет использоваться для вычисления размеров и отступов, attachToRoot - надо ли сразу добавить надутый элемент в родителю

Внутри LayoutInflater:

Объекты связки

Android SDK позволяет использовать объекты связки (binding)

Сначала появился объект Synthetic Binding - плагин kotlin-android-extensions позволял обращаться к View по идентификатору напрямую, без findViewById, как к свойствам

Плагин подключался в build.gradle:

plugins {
    id 'kotlin-android-extensions'
}

В коде импортировался kotlinx.android.synthetic.main.<layout>.* и класс использовался:

import kotlinx.android.synthetic.main.activity_main.*
textView.text = "Hello, world"

Плагин автоматически генерировал кэш в хешмапе, избегая повторного вызова методов findViewById, но мог вернуть null, если объект представления не существует

Также были проблемы с конфликтами имен, с null-безопасностью и производительностью кэша, поэтому от такого решения отказались

Далее появился объект связки представления - View Binding

Для его использования нужно добавить флаг в build.gradle.kts:

android {
    buildFeatures {
        viewBinding = true
    }
}

Далее объект связки представляет свойство в объекте активности или фрагмента, которое можно надуть:

class MainActivity : AppCompatActivity() {
    private lateinit var binding: ActivityMainBinding

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityMainBinding.inflate(layoutInflater)
        setContentView(binding.root)

        // непосредственное изменение
        binding.button.text = "Нажми"
    }
}

ViewBinding позволяет обращаться к внутренним элементами интерфейса, описанных в XML, не через метод findViewById, а через свойства объекта автоматически сгенерированного класса ___Binding

При этом поля имеют названия указанных идентификаторов, но в camelCase (то есть @+id/button_ok преобразовывается в buttonOk), работает быстрее, чем findViewById, и более типобезопасно

Для реактивного интерфейса придумали объект связки данных Data Binding

Реактивный интерфейс - подход к разработке интерфейсов, который использует реактивное программирование для управления потоками данных и событий, позволяя автоматически обновлять интерфейс при изменении данных

Data Binding позволяет связывать компоненты интерфейса напрямую с источниками данных прямо в XML. Включается Data Binding в build.gradle.kts:

android {
    buildFeatures {
        dataBinding = true
    }
}

Далее в XML-файле добавляется тег <data>, например:

<layout xmlns:android="http://schemas.android.com/apk/res/android">
    <data>
        <variable name="viewModel" type="com.example.MyViewModel" />
    </data>
    <LinearLayout>
        <TextView android:text="@{viewModel.userName}" />
        <Button android:onClick="@{() -> viewModel.onButtonClick()}" />
        <EditText android:text="@={viewModel.userInput}" />
    </LinearLayout>
</layout>

В теге <data> объявляется переменная, значения свойств которой можно записать в объектах представления

Программно viewModel привязывается к объектам интерфейса так:

val binding: ActivityMainBinding = DataBindingUtil.setContentView(this, R.layout.activity_main)
binding.viewModel = myViewModel
binding.lifecycleOwner = this   // для наблюдения

Для реактивного подхода используется классы, подобные LiveData, за которыми можно закрепить функцию, исполняющуюся при изменении данных (паттерн “Наблюдатель”)

Data Binding позволяет уменьшить количество кода в активности, поддерживает двухстороннее изменение (если есть поле для ввода, то значение поменяется и в коде), но приложение медленнее компилируется, и его сложнее отлаживать

Фреймворк Jetpack Compose

Jetpack Compose - новый фреймворк, который позволяет декларативно задать интерфейс на языке программирования

Пример его использования:

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            CounterAppTheme {
                Surface(modifier = Modifier.fillMaxSize(), color = MaterialTheme.colorScheme.background) {
                    CounterScreen()
                }
            }
        }
    }
}

@Composable
fun CounterScreen() {
    var count by remember { mutableStateOf(0) }

    Column(
        modifier = Modifier
            .fillMaxSize()
            .padding(24.dp),
        verticalArrangement = Arrangement.Center,
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        Text(text = "Count: $count", fontSize = 32.sp, modifier = Modifier.padding(bottom = 16.dp))
        Button(onClick = { count++ }) {
            Text("Increment")
        }
        Spacer(Modifier.height(12.dp))
        OutlinedButton(onClick = { count = 0 }) {
            Text("Reset")
        }
    }
}

Здесь задается столбец из элементов: текста с счетчиком, кнопки инкремента и кнопки сброса

Адаптивный дизайн

Далее будут приведены хорошие практики для создания дизайна, который будет хорошо работать на разных устройствах:

Лекция 4. Архитектура Android-приложения

Программная архитектура приложения - это то, как приложение устроено на высоком уровне: из каких частей оно состоит, как эти части взаимодействуют и по каким правилам эта система должна развиваться

Цель архитектуры - это уменьшение трудозатрат на создание, содержание и развитие системы

За время развития индустрии в компаниях пришли к многочисленным решениям организации кода, таких как MVC (Model-View-Controller), трехслойная или гексагональная архитектура

Позднее Роберт Мартин сформировал принцип “чистой архитектуры” (Clean Architecture):

Из этого следует, что бизнес-логика не должна зависеть от пользовательского интерфейса, от базы данных или другого внешнего сервиса

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

Обычно выделяют 4 слоя (от внутреннего к внешнему):

Чистая архитектура

Зависимости в таком положении указываются только из внешнего слоя вовнутрь, то есть сущности и их варианты использования не должны зависеть от пользовательского интерфейса

Чтобы элементы какого-либо внешнего слоя общались между собой, они должны взаимодействовать через элемент внутреннего слоя, который имеет два интерфейса: один для запроса и другой для ответа

Взаимодействие элементов

Применительно к Android-приложениям архитектуру делят на три слоя:

Слой пользовательского интерфейса включает элементы интерфейса, которые отображаются на экране, и носителей состояния (State holder). Носители состояния хранят данные, которые получили из другого слоя, и предоставляют их пользовательскому интерфейсу

Слой доменной модели опционален и отвечает за инкапсуляцию сложной бизнес-логики

Слой данных определяет, как приложение получает, хранит и синхронизирует данные

Архитектура Android-приложения

Пример файловой организации проекта может быть таким:

📁 src
    📁 data
        📁 remote
            📁 api
            📁 dto
        📁 local
            📁 db
            📁 dao
            📁 entities
        📁 mapper
        📁 repository
    📁 domain
        📁 model
        📁 repository
        📁 usecase
    📁 presentation
        📁 screen
            📁 main
                📄 MainActivity
                📄 MainViewModel
                📄 MainUiState
        📁 mapper

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

MVC

Архитектура MVC (Model-View-Controller) состоит из трех компонентов: модели, представления и контроллера.

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

Преимущества MVC:

Недостатки MVC:

MVC

MVP

Архитектура MVP (Model-View-Presenter) разделяет ответственность между моделью, представлением и презентатором

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

Преимущества MVP:

Недостатки MVP:

MVP

MVVM

Архитектура MVVM (Model-View-ViewModel) особенно популярна в Android-разработке. В ней:

В модель представления обычно помещают логику экрана, которая не должна зависеть от жизненного цикла конкретных активности или фрагмента. В Android-разработке этот паттерн часто используют вместе с типами LiveData, StateFlow или во фреймворке Jetpack Compose

Преимущества MVVM:

Недостатки MVVM:

MVVM

MVI

Архитектура MVI (Model-View-Intent) строится вокруг однонаправленного потока данных (Unidirectional Data Flow)

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

Преимущества MVI:

Недостатки MVI:

MVI

MVVM и MVI чаще всего применяются в современных Android-приложениях, потому что они хорошо сочетаются с реактивным подходом и удобны для сопровождения

Лекция 5. Дизайн-система и интерфейс, управляемый бэкендом

Дизайн-система

Дизайн-система - это система, которая помогает создать единый и последовательный дизайн для всех устройств

Дизайн-система представляет из себя набор правил и компонентов, таких как цветовая схема, типография, готовые макеты из элементов и их компоновка

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

Разберем, для чего нужны эти компоненты:

Дизайн-система должна быть:

Дизайн-система позволяет:

В Android-разработке дизайн-система часто выражается в виде темы приложения, набора стилей, токенов и библиотеки компонентов

Для создания дизайн-системы можно воспользоваться такими инструментами: Sketch, Figma, Adobe XD, Lunacy и так далее

Сейчас Google рекомендует использовать для Android-приложений дизайн-систему Material Design - https://m3.material.io/

Интерфейс, управляемый бэкендом

Сейчас мобильные приложения можно разделить на два типа:

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

Поэтому появляется архитектура интерфейса, управляемого бэкендом (Backend Driven UI или Server Driven UI), - при таком подходе интерфейс приложения строится на основе данных, полученных с сервера

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

Обычно это выглядит так:

  1. Клиент отправляет запрос на сервер
  2. Сервер возвращает схему экрана, например, в формате JSON
  3. Клиент разбирает ответ и сопоставляет каждый тип блока с локальным компонентом интерфейса
  4. На экране строится итоговый интерфейс

Например, сервер может прислать описание такого вида:

{
  "screen": "profile",
  "components": [
    { "type": "text", "value": "Профиль" },
    { "type": "image", "url": "https://example.com/avatar.png" },
    { "type": "button", "title": "Редактировать" }
  ]
}

Тогда клиент должен уметь понять, что text нужно отрисовать как текстовый элемент, image как изображение, а button как кнопку. То есть на клиенте остается универсальный движок отрисовки и набор поддерживаемых компонентов

Преимущества интерфейса, управляемого бэкендом:

Однако существуют недостатки:

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

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

This site is open source. Improve this page.