От переводчика: данная статья является переработкой английской статьи по паттернам разработки. В процессе адаптации на русский немало пришлось изменить. Оригинал

От редактора: ссылка на источник – в конце статьи

Выбор между различными паттернами разработки всегда сопровождается рядом споров и дискуссий, а разные взгляды разработчиков на это еще больше усложняют задачу. Существует ли решение этой идеологической проблемы? Давайте поговорим о MVC, MVP, MVVM и MVI прагматично. Давайте ответим на вопросы: “Почему?”, “Как найти консенсус?”

Вступление

Вопрос выбора между MVC, MVP, MVVM и MVI коснулся меня, когда я делал приложение для Warta Mobile вместе с моей командой. Нам было необходимо продвинуться от минимально жизнеспособного продукта к проверенному и полностью укомплектованному приложению, и мы знали, что необходимо будет ввести какую-либо архитектуру.

У многих есть непоколебимое мнение насчет различных паттернов разработки. Но когда вы рассматриваете архитектуру, такую как MVC, то, казалось бы, полностью стандартные и определенные элементы: модель (Model), представление (View) и контроллер (Controller), разные люди описывают по-разному.

Трюгве Реенскауг (Trygve Reenskaug) — изобрел и определил MVC. Через 24 года после этого он описал это не как архитектуру, а как набор реальных моделей, которые были основаны на идее MVC.

Я пришел к выводу, что поскольку каждый проект — уникален, то нет идеальной архитектуры.

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

Чего мы хотим добиться?

Масштабируемость, сопровождаемость, надежность

Очевидно, что масштабируемость (scalability) — возможность расширять проект, реализовывать новые функции.

Сопровождаемость (maintainability) — можно определить как необходимость небольших, атомарных изменений после того, как все функции реализованы. Например, это может быть изменение цвета в пользовательском интерфейсе. Чем лучше сопровождаемость проекта, тем легче новым разработчикам поддерживать проект.

Надежность (reliability) — понятно, что никто не станет тратить нервы на нестабильные приложения!

Разделение ответственности, повторное использование кода, тестируемость

Важнейшим элементом здесь является разделение ответственности (Separation of Concerns): различные идеи должны быть разделены. Если мы хотим изменить что-то, мы не должны ходить по разным участкам кода.

Без разделения ответственности ни повторное использование кода (Code Reusability), ни тестируемость (Testability) практически невозможно реализовать.

Ключ в независимости, как заметил Uncle Bob в Clean Architecture. К примеру, если вы используете библиотеку для загрузки изображений, вы не захотите использовать другую библиотеку для решения проблем, созданных первой! Независимость в архитектуре приложения частично реализует масштабируемость и сопровождаемость.

Model View Controller

У архитектуры MVC есть два варианта: контроллер-супервизор (supervising controller) и пассивное представление (passive view).

MVC с контроллером-супервизором

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

Архитектуру MVC можно охарактеризовать двумя пунктами:

• Представление — это визуальная проекция модели
• Контроллер — это соединение между пользователем и системой

Диаграмма иллюстрирует идеологию паттерна. Здесь представление определяет как слушателей, так и обратные вызовы; представление передает вход в контроллер.

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

Пассивное представление MVC

Главная идея пассивного представления MVC — это то, что представление полностью управляется контроллером. Помимо этого, код четко разделен на два уровня: бизнес логику и логику отображения:

• Бизнес логика — то, как работает приложение
• Логика отображения — то, как выглядит приложение

Massive View Controller

Нельзя трактовать Activity как представление (view). Необходимо рассматривать его как слой отображения, а сам контроллер выносить в отдельный класс.

А чтобы уменьшить код контроллеров представлений, можно разделить представления или определить субпредставления (subviews) с их собственными контроллерами. Реализация MVC паттерна таким образом позволяет легко разбивать код на модули.

Однако, при таком подходе появляются некоторые проблемы:

• Объединение логики отображения и бизнес логики
• Трудности при тестировании

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

Все это — и есть главная идея MVP.

Model View Presenter

Данная архитектура облегчает unit-тестирование, презентер (presenter) прост для написание тестов, а также может многократно использоваться, потому что представление может реализовать несколько интерфейсов.

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

Use cases

Создание use cases — это процесс выноса бизнес логики в отдельные классы, делая их частью модели. Они независимы от контроллера, и каждый содержит в себе одно бизнес-правило. Это повышает возможность многократного использования и упрощает написание тестов.

В примере на GitHub, в login controller вынесен use case валидации и use case логина. Логин производит соединение с сетью. Если есть общие бизнес правила в других контроллерах или презентерах, можно будет переиспользовать эти use case’ы.

Привязывание представления (View Bindings)

В реализации MVP есть четыре линейные функции, которые ничего не делают, кроме небольших изменений в пользовательском интерфейсе. Можно избежать этого лишнего кода, использовав view binding.

Все способы биндинга можно найти здесь.

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

Стоит отметить, что с точки зрения презентера ничего не изменилось.

Model View View-Model

Существует другой способ биндинга: вместо привязывания представления к интерфейсу мы привязываем элементы представления к параметрам view-модели — такая архитектура называется MVVM. В нашем примере поля email, password и разметка определены с помощью связываний. Когда мы меняем параметры в нашей модели, в разметку тоже вносятся изменения.

ViewModel’и просты для написания тестов, потому что они не требуют написания mock-объектов — потому что вы меняете свой собственный элемент, а потом проверяете, как он изменился.

Model View Intent

Еще один элемент, который можно ввести в архитектуре, обычно называется MVI.

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

В библиотеке RxJava то, что создает события, называется observable, то есть кнопка будет являться observable в парадигме реактивного программирования.

А вот TextView только отображает какой-либо текст и никаких данных не создает. В RxJava такие элементы, которые только принимают данные, называются consumer.

Также существуют элементы, которые делают и то, и то, т. е. и принимают, и отправляют информацию, например TextEdit. Такой элемент одновременно является и создателем (producer), и приемником (receiver), а в RxJava он называется subject.

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

Заключение

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

Другие паттерны, такие как MVVM, удаление шаблонного кода, MVI могут еще сильнее улучшить масштабируемость, но сделают проект зависимым от RxJava.

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

Все исходники можно найти здесь.

Источник: Паттерны разработки: MVC vs MVP vs MVVM vs MVI

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

Перед дальнейшим прочтением настоятельно рекомендую ознакомиться с первой частью.

Вступление

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

В этой части мы добавим автодополнение кода и подсветку ошибок.

Автодополнение кода

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

1. Пользователь пишет слово.
2. После ввода N первых символов появляется окошко с подсказками.
3. При нажатии на подсказку слово автоматически «допечатывается».
4. Окошко с подсказками закрывается, и курсор переносится в конец слова.
5. Если пользователь сам ввел слово, отображаемое в подсказке, то окошко с подсказками должно автоматически закрыться.

Ничего не напоминает? В андроиде уже есть компонент с точно такой же логикой — MultiAutoCompleteTextView, поэтому писать костыли с PopupWindow нам не придется (их уже написали за нас).

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

class TextProcessor @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
    defStyleAttr: Int = R.attr.autoCompleteTextViewStyle
) : MultiAutoCompleteTextView(context, attrs, defStyleAttr)

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

Чтобы ArrayAdapter мог понимать, какие подсказки нужно отобразить, нам нужно переопределить метод getFilter:

override fun getFilter(): Filter {
    return object : Filter() {

        private val suggestions = mutableListOf<String>()

        override fun performFiltering(constraint: CharSequence?): FilterResults {
            //...
        }

        override fun publishResults(constraint: CharSequence?, results: FilterResults) {
            clear() // необходимо очистить старый список
            addAll(suggestions)
            notifyDataSetChanged()
        }
    }
}

И в методе performFiltering наполнить список suggestions из слов, основываясь на слове, которое начал вводить пользователь (содержится в переменной constraint).

Откуда взять данные перед фильтрацией?

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

private val staticSuggestions = mutableListOf(
    "function",
    "return",
    "var",
    "const",
    "let",
    "null"
    ...
)

...

override fun performFiltering(constraint: CharSequence?): FilterResults {
    val filterResults = FilterResults()
    val input = constraint.toString()
    suggestions.clear() // очищаем старый список
    for (suggestion in staticSuggestions) {
        if (suggestion.startsWith(input, ignoreCase = true) && 
            !suggestion.equals(input, ignoreCase = true)) {
            suggestions.add(suggestion)
        }
    }
    filterResults.values = suggestions
    filterResults.count = suggestions.size
    return filterResults
}

Логика фильтрации тут довольно примитивная — проходимся по всему списку и, игнорируя регистр, сравниваем начало строки.

Установили адаптер, пишем текст — не работает. Что не так? По первой ссылке в гугле натыкаемся на ответ, в котором говорится, что мы забыли установить Tokenizer.

Для чего нужен Tokenizer?

Говоря простым языком, Tokenizer помогает MultiAutoCompleteTextView понять, после какого введенного символа можно считать ввод слова завершенным. Также у него есть готовая реализация в виде CommaTokenizer с разделением слов на запятые, что в данном случае нам не подходит.

Что ж, раз CommaTokenizer нас не устраивает, тогда напишем свой:

class SymbolsTokenizer : MultiAutoCompleteTextView.Tokenizer {

    companion object {
        private const val TOKEN = "!@#$%^&*()_+-={}|[]:;'<>/<.? \r\n\t"
    }

    override fun findTokenStart(text: CharSequence, cursor: Int): Int {
        var i = cursor
        while (i > 0 && !TOKEN.contains(text[i - 1])) {
            i--
        }
        while (i < cursor && text[i] == ' ') {
            i++
        }
        return i
    }

    override fun findTokenEnd(text: CharSequence, cursor: Int): Int {
        var i = cursor
        while (i < text.length) {
            if (TOKEN.contains(text[i - 1])) {
                return i
            } else {
                i++
            }
        }
        return text.length
    }

    override fun terminateToken(text: CharSequence): CharSequence = text
}

Разбираемся:
TOKEN — строка с символами, которые отделяют одно слово от другого. В методах findTokenStart и findTokenEnd мы проходимся по тексту в поисках этих самых отделяющих символов. Метод terminateToken позволяет вернуть измененный результат, но нам он не нужен, поэтому просто возвращаем текст без изменений.

Ещё я предпочитаю добавлять задержку на ввод в 2 символа перед отображением списка:

textProcessor.threshold = 2

Устанавливаем, запускаем, пишем текст — работает! Вот только почему-то окошко с подсказками странно себя ведет — отображается во всю ширину, высота у него маленькая, да и по идее оно ведь должно появляться под курсором. Как будем фиксить?

Исправляем визуальные недостатки

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

Для начала определимся с размерами. На мой взгляд, наиболее удобным вариантом будет окошко размером с половину от высоты и ширины экрана, но т. к. размер нашей View изменяется в зависимости от состояния клавиатуры, подбирать размеры будем в методе onSizeChanged:

override fun onSizeChanged(w: Int, h: Int, oldw: Int, oldh: Int) {
    super.onSizeChanged(w, h, oldw, oldh)
    updateSyntaxHighlighting()
    dropDownWidth = w * 1 / 2
    dropDownHeight = h * 1 / 2
}

Выглядеть стало лучше, но не сильно. Мы хотим добиться, чтобы окошко появлялось под курсором и перемещалось вместе с ним во время редактирования.

Если с перемещением по X всё довольно просто — берем координату начала буквы и устанавливаем это значение в dropDownHorizontalOffset, то с подбором высоты будет сложнее.

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

Судя по картинке, Baseline — это то, что нам нужно. Именно на этом уровне и должно появляться окошко с вариантами автодополнения.

Теперь напишем метод, который будем вызывать при изменении текста в onTextChanged:

private fun onPopupChangePosition() {
    val line = layout.getLineForOffset(selectionStart) // строка с курсором
    val x = layout.getPrimaryHorizontal(selectionStart) // координата курсора
    val y = layout.getLineBaseline(line) // тот самый baseline

    val offsetHorizontal = x + gutterWidth // нумерация строк - тоже часть отступа
    dropDownHorizontalOffset = offsetHorizontal.toInt()

    val offsetVertical = y - scrollY // -scrollY чтобы не "заезжать" за экран
    dropDownVerticalOffset = offsetVertical
}

Вроде ничего не забыли — смещение по X работает, но смещение по Y рассчитывается неправильно. Это потому что мы не указали dropDownAnchor в разметке:

android:dropDownAnchor="@id/toolbar"

Указав Toolbar в качестве dropDownAnchor, мы даём виджету понять, что выпадающий список будет отображаться под ним.

Теперь если мы начнем редактировать текст, то всё будет работать, но со временем мы заметим — если окошко не помещается под курсором, оно переносится вверх с огромным отступом, что выглядит некрасиво. Самое время написать костыль:

val offset = offsetVertical + dropDownHeight
if (offset < getVisibleHeight()) {
    dropDownVerticalOffset = offsetVertical
} else {
    dropDownVerticalOffset = offsetVertical - dropDownHeight
}

...

private fun getVisibleHeight(): Int {
    val rect = Rect()
    getWindowVisibleDisplayFrame(rect)
    return rect.bottom - rect.top
}

Нам не нужно изменять отступ, если сумма offsetVertical + dropDownHeight меньше видимой высоты экрана, ведь в таком случае окошко помещается под курсором. Но если всё-таки больше, то вычитаем из отступа dropDownHeight — так оно поместится над курсором без огромного отступа, который добавляет сам виджет.

P.S. На гифке можно заметить промаргивания клавиатуры, и, честно говоря, я не знаю, как это исправить, поэтому если у вас есть решение — пишите.

Подсветка ошибок

С подсветкой ошибок всё гораздо проще, чем кажется. Т.к. сами мы напрямую не можем определять синтаксические ошибки в коде — будем использовать стороннюю библиотеку-парсер. Т.к. я пишу редактор для JavaScript, мой выбор пал на Rhino — популярный JavaScript-движок, который проверен временем и всё ещё поддерживается.

Как парсить будем?

Запуск Rhino — довольно тяжелая операция, поэтому запускать парсер после каждого введенного символа (как мы делали с подсветкой) — вообще не вариант. Для решения этой проблемы я буду использовать библиотеку RxBinding, а для тех, кто не хочет тащить в проект RxJava, можно попробовать подобные варианты.

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

textProcessor.textChangeEvents()
    .skipInitialValue()
    .debounce(1500, TimeUnit.MILLISECONDS)
    .filter { it.text.isNotEmpty() }
    .distinctUntilChanged()
    .observeOn(AndroidSchedulers.mainThread())
    .subscribeBy {
        // Запуск парсера будет тут
    }
    .disposeOnFragmentDestroyView()

Теперь напишем модель, которую нам будет возвращать парсер:

data class ParseResult(val exception: RhinoException?)

Предлагаю использовать такую логику: если ошибок не найдено, то exception будет null. В противном случае мы получим объект RhinoException, который содержит в себе всю необходимую информацию — номер строки, сообщение об ошибке, StackTrace и т. д.

Ну и собственно, сам парсинг:

// Это должно выполняться в фоне!
val context = Context.enter() // org.mozilla.javascript.Context
context.optimizationLevel = -1
context.maximumInterpreterStackDepth = 1
try {
    val scope = context.initStandardObjects()

    context.evaluateString(scope, sourceCode, fileName, 1, null)
    return ParseResult(null)
} catch (e: RhinoException) {
    return ParseResult(e)
} finally {
    Context.exit()
}

Разбираемся:
Самое главное тут — это метод evaluateString. Он позволяет запустить код, который мы передали в качестве строки sourceCode. В fileName указывается имя файла — оно будет отображаться в ошибках, единица — номер строки для начала отсчета, последний аргумент — это security domain, но он нам не нужен, поэтому ставим null.

optimizationLevel и maximumInterpreterStackDepth

Параметр optimizationLevel со значением от 1 до 9 позволяет включить определенные «оптимизации» кода (data flow analysis, type flow analysis и т. д.), что превратит простую проверку синтаксических ошибок в очень длительную операцию, а нам это ни к чему.

Если же использовать его со значением 0, то все эти «оптимизации» применяться не будут. Однако, если я правильно понял, Rhino по-прежнему будет использовать часть ресурсов, ненужных для простой проверки ошибок, а значит, нам это не подходит.

Остаётся только отрицательное значение — указав -1, мы активируем режим «интерпретатора», а это именно то, что нам нужно. В документации сказано, что это самый быстрый и экономичный вариант работы Rhino.

Параметр maximumInterpreterStackDepth позволяет ограничить количество рекурсивных вызовов.

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

1. Пользователь напишет следующий код:

function recurse() { recurse(); } recurse();

2. Rhino запустит код, и через секунду наше приложение вылетит с OutOfMemoryError. Конец.

Отображение ошибок

Как я говорил ранее, как только мы получим ParseResult, содержащий RhinoException, у нас появится весь необходимый набор данных для отображения, в том числе и номер строки — нужно лишь вызвать метод lineNumber().

Теперь напишем спан с красной волнистой линией, который я скопировал на StackOverflow. Кода много, но логика простая — рисуем две короткие красные линии под разным углом.

class ErrorSpan(
    private val lineWidth: Float = 1 * Resources.getSystem().displayMetrics.density + 0.5f,
    private val waveSize: Float = 3 * Resources.getSystem().displayMetrics.density + 0.5f,
    private val color: Int = Color.RED
) : LineBackgroundSpan {

    override fun drawBackground(
        canvas: Canvas,
        paint: Paint,
        left: Int,
        right: Int,
        top: Int,
        baseline: Int,
        bottom: Int,
        text: CharSequence,
        start: Int,
        end: Int,
        lineNumber: Int
    ) {
        val width = paint.measureText(text, start, end)
        val linePaint = Paint(paint)
        linePaint.color = color
        linePaint.strokeWidth = lineWidth

        val doubleWaveSize = waveSize * 2
        var i = left.toFloat()
        while (i < left + width) {
            canvas.drawLine(i, bottom.toFloat(), i + waveSize, bottom - waveSize, linePaint)
            canvas.drawLine(i + waveSize, bottom - waveSize, i + doubleWaveSize, bottom.toFloat(), linePaint)
            i += doubleWaveSize
        }
    }
}

Теперь можно написать метод установки спана на проблемную строку:

fun setErrorLine(lineNumber: Int) {
    if (lineNumber in 0 until lineCount) {
        val lineStart = layout.getLineStart(lineNumber)
        val lineEnd = layout.getLineEnd(lineNumber)
        text.setSpan(ErrorSpan(), lineStart, lineEnd, Spannable.SPAN_EXCLUSIVE_EXCLUSIVE)
    }
}

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

Поэтому, чтобы не получить IndexOutOfBoundsException, мы добавляем проверку в самом начале. Ну а дальше по знакомой схеме вычисляем первый и последний символ строки, после чего устанавливаем спан.

Главное — не забыть очистить текст от уже установленных спанов в afterTextChanged:

fun clearErrorSpans() {
    val spans = text.getSpans<ErrorSpan>(0, text.length)
    for (span in spans) {
        text.removeSpan(span)
    }
}

Почему редакторы кода лагают?

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

Если открыть тот же TextView.java на 9к+ строк кода, то любой текстовый редактор, написанный по такому же принципу, как наш, будет лагать.

Q: А почему QuickEdit тогда не лагает?
A: Потому что под капотом он не использует ни EditText, ни TextView.

В последнее время набирают популярность редакторы кода на CustomView (вот и вот, ну или вот и вот, их очень много). Исторически так сложилось, что TextView имеет слишком много лишней логики, которая не нужна редакторам кода. Первое, что приходит на ум, — Autofill, Emoji, Compound Drawables, кликабельные ссылки и т. д.

Если я правильно понял, авторы библиотек просто избавились от всего этого, в следствие чего получили текстовый редактор, способный работать с файлами в миллион строк без особой нагрузки на UI Thread. (Хотя частично могу ошибаться, в исходниках не сильно разобрался)

Есть ещё один вариант, но на мой взгляд менее привлекательный — редакторы кода на WebView (вот и вот, их тоже очень много). Мне они не нравятся, потому что UI на WebView выглядит хуже, чем нативный, да и редакторам на CustomView они также проигрывают по производительности.

Заключение

Если ваша задача — написать редактор кода и выйти в топ Google Play, то не тратьте время и возьмите готовую библиотеку на CustomView. Если же вы хотите получить уникальный опыт — пишите всё сами, используя нативные виджеты.

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

Спасибо!

Источник: Редактор кода на Android: часть 2

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

Вступление

Привет всем! Судя из названия, вполне понятно, о чем будет идти речь, но всё же я должен вставить свои пару слов перед тем, как перейти к коду.

Я решил разделить статью на 2 части, в первой мы поэтапно напишем оптимизированную подсветку синтаксиса и нумерацию строк, а во второй добавим автодополнение кода и подсветку ошибок.

Для начала составим список того, что наш редактор должен уметь:

• Подсвечивать синтаксис
• Отображать нумерацию строк
• Показывать варианты автодополнения (расскажу во второй части)
• Подсвечивать синтаксические ошибки (расскажу во второй части)

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

MVP — простой текстовый редактор

На данном этапе проблем возникнуть не должно — растягиваем EditText на весь экран, указываем gravity, прозрачный background, чтобы убрать полосу снизу, размер шрифта, цвет текста и т.д. Я люблю начинать с визуальной части, так мне становится проще понять, чего не хватает в приложении и над какими деталями ещё стоит поработать.

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

Подсветка синтаксиса

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

Очевидно, чтобы контролировать весь процесс — реагировать на ввод, отрисовывать номера строк, нам придется писать CustomView, наследуясь от EditText. Накидываем TextWatcher, чтобы слушать изменения в тексте и переопределяем метод afterTextChanged, в котором и будем вызывать метод, отвечающий за подсветку:

class TextProcessor @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
    defStyleAttr: Int = R.attr.editTextStyle
) : EditText(context, attrs, defStyleAttr) {

    private val textWatcher = object : TextWatcher {
        override fun beforeTextChanged(s: CharSequence?, start: Int, count: Int, after: Int) {}
        override fun onTextChanged(s: CharSequence?, start: Int, before: Int, count: Int) {}
        override fun afterTextChanged(s: Editable?) {
            syntaxHighlight()
        }
    }

    private fun syntaxHighlight() {
        // Тут будем подсвечивать текст
    }
}

Q: Почему мы используем TextWatcher как переменную, ведь можно реализовать интерфейс прямо в классе?
A: Так уж получилось, что у TextWatcher есть метод, который конфликтует c уже существующим методом у TextView:

// Метод TextWatcher
fun onTextChanged(s: CharSequence?, start: Int, before: Int, count: Int)

// Метод TextView
fun onTextChanged(text: CharSequence?, start: Int, lengthBefore: Int, lengthAfter: Int)

Оба этих метода имеют одинаковое название и одинаковые аргументы, да и смысл вроде у них тот же, но проблема в том, что метод onTextChanged у TextView вызовется вместе с onTextChanged у TextWatcher. Если проставим логи в теле метода, то увидим, что onTextChanged вызовется дважды:

Это очень критично, если мы планируем добавлять функционал Undo/Redo. Также нам может понадобится момент, в котором не будут работать слушатели, в котором мы сможем очищать стэк с изменениями текста. Мы ведь не хотим, чтобы после открытия нового файла можно было нажать Undo и получить совершенно другой текст. Хоть об Undo/Redo в этой статье говориться не будет, важно учитывать этот момент.

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

fun processText(newText: String) {
    removeTextChangedListener(textWatcher)
    // undoStack.clear()
    // redoStack.clear()
    setText(newText)
    addTextChangedListener(textWatcher)
}

Но вернёмся к подсветке.

Во многих языках программирования есть такая замечательная штука как RegEx – это инструмент, позволяющий искать совпадения текста в строке. Рекомендую как минимум ознакомится с его базовыми возможностями, потому что рано или поздно любому программисту может понадобиться «вытащить» какой-либо кусочек информации из текста.

Сейчас нам важно знать только две вещи:

1. Pattern определяет, что конкретно нам нужно найти в тексте.
2. Matcher будет пробегать по всему тексту в попытках найти то, что мы указали в Pattern.

Может не совсем корректно описал, но принцип работы такой.

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

private val KEYWORDS = Pattern.compile(
    "\\b(function|var|this|if|else|break|case|try|catch|while|return|switch)\\b"
)

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

Далее с помощью Matcher мы пройдёмся по всему тексту и установим спаны:

private fun syntaxHighlight() {
    val matcher = KEYWORDS.matcher(text)
    matcher.region(0, text.length)
    while (matcher.find()) {
        text.setSpan(
            ForegroundColorSpan(Color.parseColor("#7F0055")),
            matcher.start(),
            matcher.end(),
            Spannable.SPAN_EXCLUSIVE_EXCLUSIVE
        )
    }
}

Поясню: мы получаем объект Matcher у Pattern и указываем ему область для поиска в символах (соответственно, с 0 по text.length – это весь текст). Далее вызов matcher.find() вернёт true, если в тексте было найдено совпадение, а с помощью вызовов matcher.start() и matcher.end() мы получим позиции начала и конца совпадения в тексте. Зная эти данные, мы можем использовать метод setSpan для раскраски определённых участков текста.

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

Итак, запускаем!

Результат соответствует ожиданиям ровно до того момента, пока мы не начнём редактировать большой файл (на скриншоте файл в ~1000 строк).

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

Поиск решения

Первое, что приходит в голову, – вынести тяжелую операцию в фоновый поток. Но тяжелая операция тут – это setSpan по всему тексту, а не регулярки. (Думаю, можно не объяснять, почему нельзя вызывать setSpan из фонового потока).

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

Точно! Так и сделаем! Вот только… как?

Оптимизация

Хоть я и упомянул, что нас заботит только производительность метода setSpan, всё же рекомендую выносить работу RegEx в фоновой поток, чтобы добиться максимальной плавности.

Нам нужен класс, который будет в фоне обрабатывать весь текст и возвращать список спанов.
Конкретной реализации приводить не буду, но если кому интересно, то я использую AsyncTask, работающий на ThreadPoolExecutor. (Да-да, AsyncTask в 2020!)

Нам главное, чтобы выполнялась такая логика:

1. В beforeTextChanged останавливаем Task, который парсит текст.
2. В afterTextChanged запускаем Task, который парсит текст.
3. По окончании своей работы Task должен вернуть список спанов в TextProcessor, который в свою очередь подсветит только видимую часть.

И да, спаны тоже будем писать свои собственные:

data class SyntaxHighlightSpan(
    private val color: Int,
    val start: Int,
    val end: Int
) : CharacterStyle() {

    // можно заморочиться и добавить italic, например, только для комментариев
    override fun updateDrawState(textPaint: TextPaint?) {
        textPaint?.color = color
    }
}

Таким образом, код редактора превращается в нечто подобное:

class TextProcessor @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
    defStyleAttr: Int = R.attr.editTextStyle
) : EditText(context, attrs, defStyleAttr) {

    private val textWatcher = object : TextWatcher {
        override fun beforeTextChanged(s: CharSequence?, start: Int, count: Int, after: Int) {
            cancelSyntaxHighlighting()
        }
        override fun onTextChanged(s: CharSequence?, start: Int, before: Int, count: Int) {}
        override fun afterTextChanged(s: Editable?) {
            syntaxHighlight()
        }
    }

    private var syntaxHighlightSpans: List<SyntaxHighlightSpan> = emptyList()

    private var javaScriptStyler: JavaScriptStyler? = null

    fun processText(newText: String) {
        removeTextChangedListener(textWatcher)
        // undoStack.clear()
        // redoStack.clear()
        setText(newText)
        addTextChangedListener(textWatcher)
        // syntaxHighlight()
    }

    private fun syntaxHighlight() {
        javaScriptStyler = JavaScriptStyler()
        javaScriptStyler?.setSpansCallback { spans ->
            syntaxHighlightSpans = spans
            updateSyntaxHighlighting()
        }
        javaScriptStyler?.runTask(text.toString())
    }

    private fun cancelSyntaxHighlighting() {
        javaScriptStyler?.cancelTask()
    }

    private fun updateSyntaxHighlighting() {
        // подсветка видимой части будет тут
    }
}

Т.к. конкретной реализации обработки в фоне я не показал, представим, что мы написали некий JavaScriptStyler, который в фоне будет делать всё то же самое, что мы делали до этого в UI Thread — пробегать по всему тексту в поисках совпадений и заполнять список спанов, а в конце своей работы возвращать результат в setSpansCallback. В этот момент запустится метод updateSyntaxHighlighting, который пройдётся по списку спанов и отобразит только те, что видны в данный момент на экране.

Как понять, какой текст попадает в видимую область?

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

val topVisibleLine = scrollY / lineHeight
val bottomVisibleLine = topVisibleLine + height / lineHeight + 1 // height - высота View
val lineStart = layout.getLineStart(topVisibleLine)
val lineEnd = layout.getLineEnd(bottomVisibleLine)

И он работает! Теперь вынесем topVisibleLine и bottomVisibleLine в отдельные методы и добавим пару дополнительных проверок, на случай если что-то пойдёт не так:

private fun getTopVisibleLine(): Int {
    if (lineHeight == 0) {
        return 0
    }
    val line = scrollY / lineHeight
    if (line < 0) {
        return 0
    }
    return if (line >= lineCount) {
        lineCount - 1
    } else line
}

private fun getBottomVisibleLine(): Int {
    if (lineHeight == 0) {
        return 0
    }
    val line = getTopVisibleLine() + height / lineHeight + 1
    if (line < 0) {
        return 0
    }
    return if (line >= lineCount) {
        lineCount - 1
    } else line
}

Последнее, что остаётся сделать, — пройтись по полученному списку спанов и раскрасить текст:

for (span in syntaxHighlightSpans) {
    val isInText = span.start >= 0 && span.end <= text.length
    val isValid = span.start <= span.end
    val isVisible = span.start in lineStart..lineEnd
            || span.start <= lineEnd && span.end >= lineStart
    if (isInText && isValid && isVisible)) {
        text.setSpan(
            span,
            if (span.start < lineStart) lineStart else span.start,
            if (span.end > lineEnd) lineEnd else span.end,
            Spannable.SPAN_EXCLUSIVE_EXCLUSIVE
        )
    }
}

Не пугайтесь страшного if'а, он всего лишь проверяет, попадает ли спан из списка в видимую область.

Ну что, работает?

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

// Примечание: метод getSpans из библиотеки core-ktx
val textSpans = text.getSpans<SyntaxHighlightSpan>(0, text.length)
for (span in textSpans) {
    text.removeSpan(span)
}

Ещё один косяк — после закрытия клавиатуры кусок текста остаётся неподсвеченным. Исправляем:

override fun onSizeChanged(w: Int, h: Int, oldw: Int, oldh: Int) {
    super.onSizeChanged(w, h, oldw, oldh)
    updateSyntaxHighlighting()
}

Главное – не забыть указать adjustResize в манифесте.

Скроллинг

Говоря про скроллинг, снова буду ссылаться на эту статью. Автор предлагает ждать 500 мс после окончания скроллинга, что противоречит моему чувству прекрасного. Я не хочу дожидаться, пока прогрузится подсветка, я хочу видеть результат моментально.

Также автор приводит аргумент, что запускать парсер после каждого «проскролленного» пикселя затратно, и я полностью с этим согласен (вообще рекомендую полностью ознакомится с его статьей, она небольшая, но там много интересного). Но дело в том, что у нас уже есть готовый список спанов и нам не нужно запускать парсер.

Достаточно вызывать метод, отвечающий за обновление подсветки:

override fun onScrollChanged(horiz: Int, vert: Int, oldHoriz: Int, oldVert: Int) {
    super.onScrollChanged(horiz, vert, oldHoriz, oldVert)
    updateSyntaxHighlighting()
}

Нумерация строк

Если мы добавим в разметку ещё один TextView, то будет проблематично их между собой связать (например, синхронно обновлять размер текста), да и если у нас большой файл, то придется полностью обновлять текст с номерами после каждой введенной буквы, что не очень круто. Поэтому будем использовать стандартные средства любой CustomView — рисование на Canvas в onDraw, это и быстро, и несложно.

Для начала определим, что будем рисовать:

• Номера строк
• Вертикальную линию, отделяющую поле ввода от номеров строк

Предварительно необходимо вычислить и установить padding слева от редактора, чтобы не было конфликтов с напечатанным текстом.

Для этого напишем функцию, которая будет обновлять отступ перед отрисовкой:

private var gutterWidth = 0
private var gutterDigitCount = 0
private var gutterMargin = 4.dpToPx() // отступ от разделителя в пикселях

...

private fun updateGutter() {
    var count = 3
    var widestNumber = 0
    var widestWidth = 0f

    gutterDigitCount = lineCount.toString().length
    for (i in 0..9) {
        val width = paint.measureText(i.toString())
        if (width > widestWidth) {
            widestNumber = i
            widestWidth = width
        }
    }
    if (gutterDigitCount >= count) {
        count = gutterDigitCount
    }
    val builder = StringBuilder()
    for (i in 0 until count) {
        builder.append(widestNumber.toString())
    }
    gutterWidth = paint.measureText(builder.toString()).toInt()
    gutterWidth += gutterMargin
    if (paddingLeft != gutterWidth + gutterMargin) {
        setPadding(gutterWidth + gutterMargin, gutterMargin, paddingRight, 0)
    }
}

Пояснение:

Для начала мы узнаем кол-во строк в EditText (не путать с кол-вом "\n" в тексте) и берем кол-во символов от этого числа. Например, если у нас 100 строк, то переменная gutterDigitCount будет равна 3, потому что в числе 100 ровно 3 символа. Но допустим, у нас всего 1 строка – а значит отступ в 1 символ будет визуально казаться маленьким, и для этого мы используем переменную count, чтобы задать минимально отображаемый отступ в 3 символа, даже если у нас меньше 100 строк кода.

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

Далее устанавливаем отступ, предварительно вычислив widestNumber и widestWidth.

Приступим к рисованию

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

setHorizontallyScrolling(true)

Ну а теперь можно приступать к рисованию. Объявим переменные с типом Paint:

private val gutterTextPaint = Paint() // Нумерация строк
private val gutterDividerPaint = Paint() // Отделяющая линия

Где-нибудь в init блоке установим цвет текста и цвет разделителя. Важно помнить, что если вы поменяете шрифт текста, то шрифт Paint'а придется применять вручную. Для этого советую переопределить метод setTypeface. Аналогично и с размером текста.

После чего переопределяем метод onDraw:

override fun onDraw(canvas: Canvas?) {
    updateGutter()
    super.onDraw(canvas)
    var topVisibleLine = getTopVisibleLine()
    val bottomVisibleLine = getBottomVisibleLine()
    val textRight = (gutterWidth - gutterMargin / 2) + scrollX
    while (topVisibleLine <= bottomVisibleLine) {
        canvas?.drawText(
            (topVisibleLine + 1).toString(),
            textRight.toFloat(),
            (layout.getLineBaseline(topVisibleLine) + paddingTop).toFloat(),
            gutterTextPaint
        )
        topVisibleLine++
    }
    canvas?.drawLine(
        (gutterWidth + scrollX).toFloat(),
        scrollY.toFloat(),
        (gutterWidth + scrollX).toFloat(),
        (scrollY + height).toFloat(),
        gutterDividerPaint
    )
}

Смотрим на результат

Выглядит круто.

Что же мы сделали в onDraw? Перед вызовом super-метода мы обновили отступ, после чего отрисовали номера только в видимой области. Ну и под конец провели вертикальную линию, визуально отделяющую нумерацию строк от редактора кода.

Для красоты можно ещё перекрасить отступ в другой цвет, визуально выделить строку, на которой находится курсор, но это я уже оставлю на ваше усмотрение.

Заключение

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

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

Задавайте вопросы и предлагайте темы для обсуждения (см. источник), ведь я вполне мог что-то упустить.

Спасибо!

Источник: Редактор кода на Android: часть 1

Ваши пользователи жалуются на то, что приложение очень быстро сажает заряд телефона? Запущенный фоновый сервис внезапно останавливается? Сообщения от FCM не доходят до пользователя? Что связывает эти три серьезных вопроса? Ответ прост — неверно выстроенная работа с энергопотреблением приложения.

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

В интернете огромное количество разрозненной информации, собрать которую в единое общее руководство было одной из основных целей этой статьи (см. источник).

Общая информация

В Android есть следующие платформенные фичи для оптимизации энергопотребления:

• Doze and App Standby
• App Standby Buckets
• Background restrictions
• Power management restrictions
• Testing and troubleshooting

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

• Doze Mode.
• App Standby.

Doze Mode

Когда устройство находится в режиме Doze, доступ приложений к определенным ресурсам откладывается до появления окна обслуживания (maintenance window). Список конкретных ограничений.

Если пользователь оставляет на какое-то время устройство отключенным от зарядки и с выключенным экраном, то оно переходит в режим Doze. В этом режиме система пытается сохранить заряд батареи, ограничивая доступ приложений к сетевым и ресурсоемким службам, откладывает Jobs, синхронизацию и Alarms.

Периодически система выходит из режима Doze, чтобы приложения могли выполнить отложенные действия. Во время этого окна обслуживания (maintenance window) система запускает все отложенные синхронизации, Jobs, Alarms и позволяет приложениям получить доступ к сети.

Со временем система все реже и реже планирует maintenance windows, что помогает снизить расход энергии, когда устройство не на зарядке.

В режиме Doze к приложениям применяются следующие ограничения:

• Доступ в сеть приостановлен.
• Стандартные AlarmManager откладываются до следующего окна обслуживания.
• Система не сканирует Wi-Fi.
• Система не позволяет запускаться sync adapters.
• Система не позволяет запускаться JobScheduler.

Чеклист для приложения в режиме Doze:

• Использовать FCM для обмена сообщениями.
• Если пользователь должен сразу увидеть уведомление, то нужно использовать FCM с высоким приоритетом.
• Предоставлять достаточное количество информации в сообщении, чтобы избежать последующих запросов в сеть.
• Установить критически оповещения с setAndAllowWhileIdle() and setExactAndAllowWhileIdle().
• Протестировать приложение в режиме Doze.

App StandBy, App StandBy Buckets

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

• Пользователь явно запускает приложение.
• Приложение находится на переднем плане (явно или в качестве Foreground service, либо используется другой Activity).
• Приложение генерирует уведомления, которые пользователь видит на экране блокировки или в области уведомлений.
• Приложение является активным приложением администратора устройств.

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

Определение частоты использования отличается у разных производителей, особенно «жестит» Samsung.

В Android 9 появились новые фичи для управления питанием устройства. Они делятся на две категории:

• App standby buckets. Система ограничивает доступ приложения к ресурсам устройства в зависимости от модели поведения пользователя.
• Battery Saver Improvements. Когда включена функция экономии заряда батареи, система накладывает ограничения на все приложения.

Эти ограничения применяются ко всем приложениям независимо от их targetSdk.

App StandBy Buckets помогает системе приоритизировать запросы приложений к ресурсам на основании того, как давно и как часто использовалось приложение. На основе шаблонов использования приложение помещается в один из пяти сегментов. Система ограничивает ресурсы устройства, доступные для каждого приложения, в зависимости от того, в каком сегменте находится приложение.

Пять сегментов, назначаемые приложениям в зависимости от приоритета:

• Active. Приложение находится в активном сегменте, если пользователь в настоящий момент использует приложение. Т.е. если видна Activity, или запущен Foreground service, или есть synchronized adapter, связанный с приложением на переднем плане, или пользователь кликнул на уведомление. Если приложение в активном сегменте, то никакие ограничения на использование ресурсов устройства не накладываются.
• Working set. Приложение находится в этом сегменте, если часто запускается, но в данный момент не активно. Система накладывает умеренные ограничения на действия этого приложения.
• Frequent. Приложение находится в этом сегменте, если используется часто, но не каждый день. Система накладывает больше ограничений, также накладываются ограничения на количество сообщений FCM с высоким приоритетом.
• Rare. Приложение находится в этом сегменте, если оно редко используется. В этом случае система накладывает строгие ограничения и на получение сообщений FCM с высоким приоритетом. Система также ограничивает возможность приложения подключаться к интернету.
• Never. Это сегмент для приложений, которые были установлены, но никогда не запускались. Система накладывает жесткие ограничения.

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

Для определения сегмента, в который система поместит приложение, используется машинное обучение. С его помощью прогнозируется поведение пользователя. Например, если приложение из сегмента Rare было только что использовано и перешло в Active, то это не означает, что после использования приложение поднимется в более приоритетный сегмент. Сегменты определяются на основе прогнозов будущих действий пользователя, а не на основе недавнего использования.

Полезная информация по работе с App StandBy Buckets:

• НЕ пытаться манипулировать тем, к какому сегменту система отнесет приложение.
• Создать Launcher Activity, если ее нет.
• Создавать обработчик нажатий на уведомления. Если с ними нельзя взаимодействовать, то приложение не сможет перейти в активный сегмент.
• Если приложение не показывает пользователю уведомление при получении high-priority FCM-уведомления, то пользователь не сможет взаимодействовать с приложением и оно не перейдет в активный сегмент. Если многие сообщения будут помечены как high-priority, то приложение исчерпает свою квоту на такие сообщения, и все последующие будут иметь normal-priority.

Firebase Cloud Messaging с App StandBy и режимом Doze

Необходимо использовать FCM для взаимодействия с приложением во время простоя устройства. FCM оптимизирован для работы в режимах ожидания Doze и App StandBy с помощью высокоприоритетных FCM-сообщений. Высокоприоритетные сообщения позволяют разбудить приложение для доступа к сети, даже если устройство находится в режиме Doze или приложение в режиме App StandBy. В обоих режимах система доставляет сообщение и дает приложению временный доступ к сетевым сервисам, а затем возвращает устройство или приложение в режим ожидания.

Как протестировать приложение с различными ограничениями системы

Тестирование Doze Mode

• Получить доступ к ADB (android device bridge) в текущей сессии:

export PATH=«~/Library/Android/sdk/platform-tools»:$PATH

• Перевести систему в режим ожидания:

adb shell dumpsys deviceidle force-idle

• Выйти из режима ожидания:

adb shell dumpsys deviceidle unforce

• Активировать устройство:

adb shell dumpsys battery reset

• Проверить поведение приложения.

Тестирование приложения с App StandBy для Android < 9

• Перевести приложение в App StandBy:

$ adb shell dumpsys battery unplug
$ adb shell am set-inactive <package_name> true

• Пробудить приложение:

$ adb shell am set-inactive <package_name> false
$ adb shell am get-inactive <package_name>

• Проверить работу приложения. Убедиться, что восстанавливается корректно. Проверить, продолжают ли работать уведомления и фоновые процессы.

Тестирование App Standby Buckets

Можно вручную переместить приложение в определенный App StandBy bucket с помощью команды:

adb shell am set-standby-bucket <package_name> active|working_set|frequent|rare

Команда проверки, в каком сегменте сейчас приложение:

adb shell am get-standby-bucket <package_name>

Тестирование ограничений на фоновые процессы

• Вручную применить ограничения на выполнение фоновых задач:

adb shell cmd appops set <package_name> RUN_ANY_IN_BACKGROUND ignore

• Убрать ограничения на выполнение фоновых процессов:

adb shell cmd appops set <package_name> RUN_ANY_IN_BACKGROUND allow

Тестирование режима Battery safety

• Отключить устройство от ПК:
• Проверить поведение устройства в условиях экономии энергии:

adb shell settings put global low_power 1

• Отменить ручную настройку:

adb shell dumpsys battery reset

Фоновые оптимизации

Ограничения, начиная с Android 7:

• Не отправляются широковещательные сообщения `CONNECTIVITY_ACTION`, если receiver объявлен в манифесте. Если receiver зарегистрирован динамически, то сообщение будет получено.
• Приложения не могут получать или отправлять `ACTION_NEW_PICTURE` или `ACTION_NEW_VIDEO`.

Ограничения, начиная с Android 9:

Если система замечает, что приложение потребляет чрезмерное количество ресурсов, она уведомляет пользователя и дает ему возможность ограничить действия приложения. Это поведение включает в себя:

• Чрезмерные wake locks.
• Избыточное количество фоновых сервисов.

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

Battery Historian

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

Анализ приложения с помощью Battery Historian

Предварительно необходимо установить Docker.

• Получить доступ к ADB (android device bridge) в текущей сессии:

export PATH=«~/Library/Android/sdk/platform-tools»:$PATH

• Подключить устройство к ПК.
• Убить текущий ADB-сервер.

adb kill-server

• Проверить доступные устройства:

adb devices

• Сбросить данные о батарее:

adb shell dumpsys batterystats --reset

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

adb devices

• Сделать дамп данных батареи:

adb shell dumpsys batterystats > [path/b]batterystats.txt

• Создать отчет для данных:

adb bugreport [path/]bugreport.zip

• Запустить (порт можно указать любой):

docker run -p 5554:5554 gcr.io/android-battery-historian/stable:3.0 --port 5554

• В браузере перейти по ссылке http://localhost:5554 и открыть ZIP файл.
• Вот так примерно будет выглядеть график BatteryHistorian:

На этом графике вы можете узнать, в какой момент запустился ваш сервис, установились wake locks, был запущен JobScheduler и другую информацию. Возможно, вы даже узнаете о своем приложении то, чего еще не знали и о чем не подозревали. Уделите этому инструменту пару-тройку свободных часов и, гарантирую, вы не пожалеете.

Energy Profiler

Energy Profiler — встроенный в Android Studio анализатор энергопотребления. Думаю, тут не стоит задерживаться. Этот инструмент довольно хорошо описан, и каждый может оценить его в действии.

BatteryStats + UI-тесты

В этой главе мы разберем, как можно использовать связку из BatteryStats и UI-тестирования.

• Перед запуском теста я написал bash-скрипт:

echo Write test class path e.g. <путь_к_классу_с_тестом>
read testName
export PATH=«~/Library/Android/sdk/platform-tools»:$PATH
adb shell dumpsys battery unplug
adb shell dumpsys batterystats --reset
adb shell am instrument -w  \ -e class $testName \ com.myapp.test/androidx.test.runner.AndroidJUnitRunner
adb shell dumpsys batterystats | awk -f BatteryStatsParseScript.awk > BatteryTestsResult.txt
adb shell dumpsys batterystats > BatteryTestsResultFull.txt
adb shell dumpsys batterystats reset
echo You can find the output file in the parent directory named BatteryTestsResult.txt

• Для начала нужно ввести расположение класса с тестом. Например, класс `com.myApp.MyTestEspressoTest`.
• Далее подключается ADB.
• Устройство отключается от ПК.
• Сбрасывается статистика BatteryStats.
• Запускается тест, подставляет класс, введенный нами ранее, и используемый фреймворк для тестирования.
• Выгружается информация об энергопотреблении и парсится в более читаемый формат с помощью .awk-файла. Далее этот файл сохраняется под именем BatteryTestsResultFull.txt в главной папке приложения (или в любой другой, которую вы выберете).
• Выводится сообщение с расположением файла с результатом.
• Сбрасывается статистика BatteryStats.
• Вы восхитительны!

Для парсинга файла, получившегося после теста, применяется .awk-файл. Сам файл я решил не прикладывать, т.к. он получился огромным и не все будут использовать те же поля, что использовал я. В результате получаем текстовый BatteryTestsResult.txt такого содержания:

Estimated battery capacity: 3700 mAh

Time on battery: 32s 609ms (100.0%) realtime, 32s 610ms (100.0%) uptime

App Uid u0a358
Cpu Usage: 1.56 mAh
Radio Usage:  mAh
WiFi Usage: 0.0476 mAh
Wake Usage:  mAh
Sensor Usage:  mAh
GPS Usage: 0.0417 mAh
Total App Usage: 1.65mAh

Total time in seconds: 32 seconds
Usage per second: 0.0515625 mAh/seconds

User activity: 14 touch

Wi-Fi network: 335.22KB received, 342.84KB sent (packets 745 received, 758 sent)

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

P.S. Проблемы с Samsung

При написании статьи я наткнулся на полезный сайт https://dontkillmyapp.com, на котором можно узнать, какие ограничения накладывают различные производители на энергопотребление устройств. Самой частой проблемой, с которой я сталкивался, была жалоба пользователей Samsung на высокое энергопотребление различными приложениями. И на этом ресурсе я нашел ответ на свой вопрос.

Вместе с релизом Samsung S8 была представлена утилита для увеличения времени работы батареи под названием App Power Monitor. И чтобы приложения работали корректно, их нужно вносить в whitelist. Также Samsung — рекордсмен по убийству приложений благодаря его «Адаптивной батарее».

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

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

Источник: Энергопотребление Android-приложений

Написано огромное количество документации и статей о важной визуальной составляющей приложений — анимации. Несмотря на это мы (Dodo Pizza – см. источник) смогли вляпаться в проблемы столкнулись с загвоздками при её реализации.

Данная статья о проблеме и анализе вариантов её решения. Я не дам вам серебряную пулю против всех монстров, но покажу, как можно изучить конкретного, чтобы создать пулю специально для него. Разберу это на примере того, как мы подружили анимацию смены фрагментов с Bottom Sheet.

Бриллиантовый чекаут: предыстория

Бриллиантовый чекаут — кодовое название нашего проекта. Смысл его очень прост — сократить время, затрачиваемое клиентом на последнем этапе оформления заказа. Если в старой версии для оформления заказа требовалось минимум четыре клика на двух экранах (а каждый новый экран — это потенциальная потеря контекста пользователем), «бриллиантовый чекаут» в идеальном случае требует всего один клик на одном экране.

Между собой мы называем новый экран «шторка». На рисунке вы видите, в каком виде мы получили задание от дизайнеров. Данное дизайнерское решение является стандартным, известно оно под именем Bottom Sheet, описано в Material Design (в том числе для Android) и в разных вариациях используется во многих приложениях. Google предлагает нам два готовых варианта реализации: модальный (Modal) и постоянный (Persistent). Разница между этими подходами описана во многих и многих статьях.

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

Смотри, какая классная анимация на iOS. Давай так же сделаем?

Такой вызов не принять мы не могли! Ладно, шучу по поводу «дизайнеры неожиданно пришли с предложением сделать анимацию», но часть про iOS — чистая правда.

Стандартные переходы между экранами (то есть отсутствие переходов) выглядели хоть и не слишком коряво, но до соответствия званию «бриллиантовый чекаут» не дотягивали. Хотя, кого я обманываю, это действительно было ужасно:

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

1. Клиент нажимал на поле адреса пиццерии – в ответ открывался фрагмент «Самовывоз». Открывался он на весь экран (так было задумано) с резким скачком, при этом список пиццерий появлялся с небольшой задержкой.
2. Когда клиент нажимал «Назад» – возврат на предыдущий экран происходил с резким скачком.
3. При нажатии на поле способа оплаты – снизу с резким скачком открывался фрагмент «Способ оплаты». Список способов оплаты появлялся с задержкой, при их появлении экран увеличивался со скачком.
4. При нажатии «Назад» – возврат обратно с резким скачком.

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

В чём, собственно, проблема: где клиенту хорошо, там у нас ограничения

Пользователям не нравится, когда на экране происходит слишком много резких движений. Это отвлекает и смущает. Кроме того, всегда хочется видеть плавный отклик на своё действие, а не судороги.

Это привело нас к техническому ограничению: мы решили, что нам нельзя на каждую смену экрана закрывать текущий bottom sheet и показывать новый, а также будет плохо показывать несколько bottom sheet один над другим. Так, в рамках нашей реализации (каждый экран — новый фрагмент), можно сделать только один bottom sheet, который должен двигаться максимально плавно в ответ на действия пользователей.

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

Предварительная разметка

Корневой элемент «шторки» очень простой — это всего лишь прямоугольный фон с закруглёнными сверху углами и контейнер, в который помещаются фрагменты.

<?xml version="1.0" encoding="utf-8"?>
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:background="@drawable/dialog_gray200_background">
 
    <androidx.fragment.app.FragmentContainerView
        android:id="@+id/container"
        android:layout_width="match_parent"
       android:layout_height="match_parent" />
 
</FrameLayout>

И файл dialog_gray200_background.xml выглядит так:

<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android">
  <item>
    <shape android:shape="rectangle">
      <solid android:color="@color/gray200" />
      <corners
          android:bottomLeftRadius="0dp"
          android:bottomRightRadius="0dp"
          android:topLeftRadius="10dp"
          android:topRightRadius="10dp" />
    </shape>
  </item>
</selector>

Каждый новый экран представляет собой отдельный фрагмент, фрагменты сменяются с помощью метода replace, тут всё стандартно.

Первые попытки реализовать анимацию

animateLayoutChanges

Вспоминаем о древней эльфийской магии animateLayoutChanges, которая на самом деле представляет собой дефолтный LayoutTransition. Хотя animateLayoutChanges совершенно не рассчитан на смену фрагментов, есть надежда, что это поможет с анимацией высоты. Также FragmentContainerView не поддерживает animateLayoutChanges, поэтому меняем его на старый добрый FrameLayout.

<?xml version="1.0" encoding="utf-8"?>
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:background="@drawable/dialog_gray200_background">
 
  <FrameLayout
      android:id="@+id/container"
      android:layout_width="match_parent"
      android:layout_height="match_parent"
      android:animateLayoutChanges="true" />
 
</FrameLayout>

Запускаем:

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

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

setCustomAnimations

FragmentTransaction позволяет задать анимацию, описанную в xml-формате с помощью метода setCustomAnimation. Для этого в ресурсах создаём папку с названием «anim» и складываем туда четыре файла анимации:

to_right_out.xml

<?xml version="1.0" encoding="utf-8"?>
<set xmlns:android="http://schemas.android.com/apk/res/android"
    android:duration="500"
    android:interpolator="@android:anim/accelerate_interpolator">
  <translate android:toXDelta="100%" />
</set>

to_right_in.xml

<?xml version="1.0" encoding="utf-8"?>
<set xmlns:android="http://schemas.android.com/apk/res/android"
    android:duration="500"
    android:interpolator="@android:anim/accelerate_interpolator">
  <translate android:fromXDelta="-100%" />
</set>

to_left_out.xml

<?xml version="1.0" encoding="utf-8"?>
<set xmlns:android="http://schemas.android.com/apk/res/android"
    android:duration="500"
    android:interpolator="@android:anim/accelerate_interpolator">
  <translate android:toXDelta="-100%" />
</set>

to_left_in.xml

<?xml version="1.0" encoding="utf-8"?>
<set xmlns:android="http://schemas.android.com/apk/res/android"
    android:duration="500"
    android:interpolator="@android:anim/accelerate_interpolator">
  <translate android:fromXDelta="100%" />
</set>

И затем устанавливаем эти анимации в транзакции:

fragmentManager
    .beginTransaction()
    .setCustomAnimations(R.anim.to_left_in, R.anim.to_left_out, R.anim.to_right_in, R.anim.to_right_out)
    .replace(containerId, newFragment)
    .addToBackStack(newFragment.tag)
    .commit()

Получаем вот такой результат:

Что мы имеем при такой реализации:

• Уже стало лучше — видно, как экраны сменяют друг друга в ответ на действие пользователя.
• Но всё равно есть скачок из-за разной высоты фрагментов. Так происходит из-за того, что при переходе фрагментов в иерархии есть только один фрагмент. Именно он подстраивает высоту контейнера под себя, а второй отображается «как получилось».
• Всё ещё есть проблема с асинхронной загрузкой данных о способах оплаты — экран появляется сначала пустым, а потом со скачком наполняется контентом.

Это никуда не годится. Вывод: нужно что-то другое.

А может попробуем что-то внезапное: Shared Element Transition

Большинство Android-разработчиков знает про Shared Element Transition. Однако, хотя этот инструмент очень гибкий, многие сталкиваются с проблемами при его использовании и поэтому не очень любят применять его.

Суть его довольно проста — мы можем анимировать переход элементов одного фрагмента в другой. Например, можем элемент на первом фрагменте (назовём его «начальным элементом») с анимацией переместить на место элемента на втором фрагменте (этот элемент назовём «конечным элементом»), при этом с фэйдом скрыть остальные элементы первого фрагмента и с фэйдом показать второй фрагмент. Элемент, который должен анимироваться с одного фрагмента на другой, называется Shared Element.

Чтобы задать Shared Element, нам нужно:

• пометить начальный элемент и конечный элемент атрибутом transitionName с одинаковым значением;
• указать sharedElementEnterTransition для второго фрагмента.

А что если использовать корневую View фрагмента в качестве Shared Element? Возможно, Shared Element Transition придумывали не для этого. Хотя, если подумать, сложно найти аргумент, почему это решение не подойдёт. Мы хотим анимировать начальный элемент в конечный элемент между двумя фрагментами. Не вижу идеологического противоречия. Давайте попробуем сделать так!

Для каждого фрагмента, который находится внутри «шторки», для корневой View указываем атрибут transitionName с одинаковым значением:

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout 
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:transitionName="checkoutTransition">

Важно: это будет работать, поскольку мы используем REPLACE в транзакции фрагментов. Если вы используете ADD (или используете ADD и скрываете предыдущий фрагмент с помощью previousFragment.hide() [не надо так делать]), то transitionName придётся задавать динамически и очищать после завершения анимации. Так приходится делать, потому что в один момент времени в текущей иерархии View не может быть две View с одинаковым transitionName. Осуществить это можно, но будет лучше, если вы сможете обойтись без такого хака. Если вам всё-таки очень нужно использовать ADD, вдохновение для реализации можно найти в этой статье.

Далее нужно указать класс Transition'а, который будет отвечать за то, как будет протекать наш переход. Для начала проверим, что есть «из коробки» — используем AutoTransition.

newFragment.sharedElementEnterTransition = AutoTransition()

И мы должны задать Shared Element, который хотим анимировать, в транзакции фрагментов. В нашем случае это будет корневая View фрагмента:

fragmentManager
    .beginTransaction()
    .apply {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
            addSharedElement(
                currentFragment.requireView(),
                currentFragment.requireView().transitionName
            )
            setReorderingAllowed(true)
        }
    }
    .replace(containerId, newFragment)
    .addToBackStack(newFragment.tag)
    .commit()

Важно: обратите внимание, что transitionName (как и весь Transition API) доступен, начиная с версии Android Lollipop.

Посмотрим, что получилось:

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

Раз стандартная реализация нам не подошла, что нужно сделать? Конечно же, нужно переписать всё на Flutter написать свой Transition!

Пишем свой Transition

Transition — это класс из Transition API, который отвечает за создание анимации между двумя сценами (Scene). Основные элементы этого API:

• Scene — это расположение элементов на экране в определённый момент времени (layout) и ViewGroup, в которой происходит анимация (sceneRoot).
• Начальная сцена (Start Scene) — это Scene в начальный момент времени.
• Конечная сцена (End Scene) — это Scene в конечный момент времени.
• Transition — класс, который собирает свойства начальной и конечной сцены и создаёт аниматор для анимации между ними.

В классе Transition мы будем использовать четыре метода:

• fun getTransitionProperties(): Array. Данный метод должен вернуть набор свойств, которые будут анимироваться. Из этого метода нужно вернуть массив строк (ключей) в свободном виде, главное, чтобы методы captureStartValues и captureEndValues (описанные далее) записали свойства с этими ключами. Пример будет далее.
• fun captureStartValues(transitionValues: TransitionValues). В данном методе мы получаем нужные свойства layout'а начальной сцены. Например, мы можем получить начальное расположение элементов, высоту, прозрачность и так далее.
• fun captureEndValues(transitionValues: TransitionValues). Такой же метод, только для получения свойств layout'а конечной сцены.
• fun createAnimator(sceneRoot: ViewGroup?, startValues: TransitionValues?, endValues: TransitionValues?): Animator?. Этот метод должен использовать свойства начальной и конечной сцены, собранные ранее, чтобы создать анимацию между этими свойствами. Обратите внимание, что если свойства между начальной и конечной сценой не поменялись, то данный метод не вызовется вовсе.

Реализуем свой Transition за девять шагов

1. Создаём класс, который представляет Transition.

@TargetApi(VERSION_CODES.LOLLIPOP)
class BottomSheetSharedTransition : Transition {
    @Suppress("unused")
    constructor() : super()

    @Suppress("unused")
    constructor(
        context: Context?,
        attrs: AttributeSet?
    ) : super(context, attrs)
}

Напоминаю, что Transition API доступен с версии Android Lollipop.

2. Реализуем getTransitionProperties.

Поскольку мы хотим анимировать высоту View, заведём константу PROP_HEIGHT, соответствующую этому свойству (значение может быть любым) и вернём массив с этой константой:

companion object {
    private const val PROP_HEIGHT = "heightTransition:height"
    
    private val TransitionProperties = arrayOf(PROP_HEIGHT)
}

override fun getTransitionProperties(): Array<String> = TransitionProperties

3. Реализуем captureStartValues.

Нам нужно запомнить высоту той View, которая хранится в параметре transitionValues. Значение высоты нам нужно записать в поле transitionValues.values (он имеет тип Map) c ключом PROP_HEIGHT:

override fun captureStartValues(transitionValues: TransitionValues) {
    transitionValues.values[PROP_HEIGHT] = transitionValues.view.height
}

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

override fun captureStartValues(transitionValues: TransitionValues) {
    // Запоминаем начальную высоту View...
    transitionValues.values[PROP_HEIGHT] = transitionValues.view.height

    //...и затем закрепляем высоту контейнера фрагмента
    transitionValues.view.parent
        .let { it as? View }
        ?.also { view ->
            view.updateLayoutParams<ViewGroup.LayoutParams> {
                height = view.height
            }
        }
}

4. Реализуем captureEndValues.

Аналогично предыдущему методу, нужно запомнить высоту View. Но не всё так просто. На предыдущем шаге мы зафиксировали высоту контейнера. Новый фрагмент по высоте может быть меньше, равным или больше предыдущего фрагмента. В первых двух случаях мы можем просто взять высоту нового фрагмента. Однако, в случае когда новый фрагмент должен занять больше места, чем старый, значение высоты будет ограничено высотой контейнера. Поэтому придётся пойти на небольшую хитрость — мы просто измерим view, чтобы определить, сколько места на самом деле ей требуется. Реализация будет выглядеть так:

override fun captureEndValues(transitionValues: TransitionValues) {
    // Измеряем и запоминаем высоту View
    transitionValues.values[PROP_HEIGHT] =
        getViewHeight(transitionValues.view.parent as View)
}

И метод getViewHeight:

private fun getViewHeight(view: View): Int {
    // Получаем ширину экрана
    val deviceWidth = getScreenWidth(view)

    // Попросим View измерить себя при указанной ширине экрана
    val widthMeasureSpec = MeasureSpec.makeMeasureSpec(deviceWidth, MeasureSpec.EXACTLY)
    val heightMeasureSpec = MeasureSpec.makeMeasureSpec(0, MeasureSpec.UNSPECIFIED)

    return view
        // измеряем
        .apply { measure(widthMeasureSpec, heightMeasureSpec) }
        // получаем измеренную высоту
        .measuredHeight
        // если View хочет занять высоту больше доступной высоты экрана,
        // мы должны вернуть высоту экрана
        .coerceAtMost(getScreenHeight(view))
}

private fun getScreenHeight(view: View) =
    getDisplaySize(view).y - getStatusBarHeight(view.context)
    
private fun getScreenWidth(view: View) =
    getDisplaySize(view).x private

fun getDisplaySize(view: View) = Point().also {
    val wm = view.context.getSystemService(Context.WINDOW_SERVICE) as WindowManager)
    vm.defaultDisplay.getSize(it)
}

private fun getStatusBarHeight(context: Context): Int = 
    context.resources
        .getIdentifier("status_bar_height", "dimen", "android")
        .takeIf { resourceId -> resourceId > 0 }
        ?.let { resourceId -> context.resources.getDimensionPixelSize(resourceId) }
        ?: 0

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

5. Реализация анимации. Fade in.

Начальный фрагмент нам анимировать не нужно, так как при старте транзакции он удалится из иерархии. Будем показывать конечный фрагмент с фэйдом. Добавляем метод в класс «BottomSheetSharedTransition», ничего хитрого:

private fun prepareFadeInAnimator(view: View): Animator =
    ObjectAnimator.ofFloat(view, View.ALPHA, 0f, 1f) 

6. Реализация анимации. Анимация высоты.

Ранее мы запомнили начальную и конечную высоту, теперь мы можем анимировать высоту контейнера фрагментов:

private fun prepareHeightAnimator(
    startHeight: Int,
    endHeight: Int,
    view: View
) = ValueAnimator.ofInt(startHeight, endHeight)
    .apply {
        val container = view.parent.let { it as View }

        // изменяем высоту контейнера фрагментов
        addUpdateListener { animation ->
            container.updateLayoutParams<ViewGroup.LayoutParams> {
                height = animation.animatedValue as Int
            }
        }
    }

Создаём ValueAnimator и обновляем высоту конечного фрагмента. Снова ничего сложного, но есть нюанс. Поскольку мы меняем высоту контейнера, после анимации его высота будет фиксированной. Это означает, что если фрагмент в ходе своей работы будет менять высоту, то контейнер не будет подстраиваться под это изменение. Чтобы этого избежать, по окончании анимации нужно установить высоту контейнера в значение WRAP_CONTENT. Таким образом, метод для анимации высоты контейнера будет выглядеть так:

private fun prepareHeightAnimator(
    startHeight: Int,
    endHeight: Int,
    view: View
) = ValueAnimator.ofInt(startHeight, endHeight)
    .apply {
        val container = view.parent.let { it as View }

        // изменяем высоту контейнера фрагментов
        addUpdateListener { animation ->
            container.updateLayoutParams<ViewGroup.LayoutParams> {
                height = animation.animatedValue as Int
            }
        }

        // окончании анимации устанавливаем высоту контейнера WRAP_CONTENT
        doOnEnd {
            container.updateLayoutParams<ViewGroup.LayoutParams> {
                height = ViewGroup.LayoutParams.WRAP_CONTENT
            }
        }
    }

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

7. Реализация анимации. createAnimator.

override fun createAnimator(
    sceneRoot: ViewGroup?,
    startValues: TransitionValues?,
    endValues: TransitionValues?
): Animator? {
    if (startValues == null || endValues == null) {
        return null
    }

    val animators = listOf<Animator>(
        prepareHeightAnimator(
            startValues.values[PROP_HEIGHT] as Int,
            endValues.values[PROP_HEIGHT] as Int,
            endValues.view
        ),
        prepareFadeInAnimator(endValues.view)
    )

    return AnimatorSet().apply {
        interpolator = FastOutSlowInInterpolator()
        duration = ANIMATION_DURATION
        playTogether(animators)
    }
}

8. Всегда анимируем переход.

Последний нюанс касательно реализации данного Transititon'а. Звёзды могут сойтись таким образом, что высота начального фрагмента будет точно равна высоте конечного фрагмента. Такое вполне может быть, если оба фрагмента занимают всю высоту экрана. В таком случае метод «createAnimator» не будет вызван совсем. Что же произойдёт?

• Не будет Fade'а нового фрагмента, он просто резко появится на экране.
• Поскольку в методе «captureStartValues» мы зафиксировали высоту контейнера, а анимации не произойдёт, высота контейнера никогда не станет равной WRAP_CONTENT.

Неприятно, но не смертельно. Можно обойти это поведение простым трюком: нужно добавить любое значение, которое будет отличаться для начальной сцены и конечной сцены, в список свойств Transition'а. Можно просто добавить строки с разными значениями:

companion object {
    private const val PROP_HEIGHT = "heightTransition:height"
    private const val PROP_VIEW_TYPE = "heightTransition:viewType"

    private val TransitionProperties = arrayOf(PROP_HEIGHT, PROP_VIEW_TYPE)
}

override fun getTransitionProperties(): Array<String> = TransitionProperties

override fun captureStartValues(transitionValues: TransitionValues) {
    // Запоминаем начальную высоту View...
    transitionValues.values[PROP_HEIGHT] = transitionValues.view.height
    transitionValues.values[PROP_VIEW_TYPE] = "start"

    //...и затем закрепляем высоту контейнера фрагмента
    transitionValues.view.parent
        .let { it as? View }
        ?.also { view ->
            view.updateLayoutParams<ViewGroup.LayoutParams> {
            height = view.height
        }
    }
}

override fun captureEndValues(transitionValues: TransitionValues) {
    // Измеряем и запоминаем высоту View
    transitionValues.values[PROP_HEIGHT] =
        getViewHeight(transitionValues.view.parent as View)
    transitionValues.values[PROP_VIEW_TYPE] = "end"
} 

Обратите внимание, добавилось свойство «PROPVIEWTYPE», и в методах «captureStartValues» и «captureEndValues» записываем разные значения этого свойства. Всё, транзишн готов!

9. Применяем Transition.

newFragment.sharedElementEnterTransition = BottomSheetSharedTransition()

Асинхронная загрузка данных

Чтобы анимация началась вовремя и выглядела хорошо, нужно просто отложить переход между фрагментами (и, соответственно, анимацию) до момента, пока данные не будут загружены. Для этого внутри фрагмента нужно вызвать метод postponeEnterTransition. По окончании долгих задач по загрузке данных не забудьте вызвать startPostponedEnterTransition. Я уверен, вы знали об этом приёме, но напомнить лишний раз не помешает.

Всё вместе: что в итоге получилось

С новым BottomSheetSharedTransition и использованием postponeEnterTransition при асинхронной загрузке данных у нас получилась такая анимация:

В источнике в этом месте приводится готовый класс BottomSheetSharedTransition

Когда у нас есть готовый класс Transition'а, его применение сводится к простым шагам:

Шаг 1. При транзакции фрагмента добавляем Shared Element и устанавливаем Transition:

private fun transitToFragment(newFragment: Fragment) {
    val currentFragmentRoot = childFragmentManager.fragments[0].requireView()
 
    childFragmentManager
        .beginTransaction()
        .apply {
            if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
                addSharedElement(currentFragmentRoot, currentFragmentRoot.transitionName)
                setReorderingAllowed(true)
 
                newFragment.sharedElementEnterTransition = BottomSheetSharedTransition()
            }
        }
        .replace(R.id.container, newFragment)
        .addToBackStack(newFragment.javaClass.name)
        .commit()
}

Шаг 2. В разметке фрагментов (текущего фрагмента и следующего), которые должны анимироваться внутри BottomSheetDialogFragment, устанавливаем transitionName:

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout 
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:transitionName="checkoutTransition">

На этом всё, конец.

А можно было сделать всё иначе?

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

• Отказаться от фрагментов, использовать один фрагмент с множеством View и анимировать конкретные View. Так вы получите больший контроль над анимацией, но потеряете преимущества фрагментов: нативную поддержку навигации и готовую обработку жизненного цикла (придётся реализовывать это самостоятельно).
• Использовать MotionLayout. Технология MotionLayout на данный момент всё ещё находится на стадии бета, но выглядит очень многообещающе, и уже есть официальные примеры, демонстрирующие красивые переходы между фрагментами.
• Не использовать анимацию. Да, наш дизайн является частным случаем, и вы вполне можете счесть анимацию в данном случае избыточной. Вместо этого можно показывать один Bottom Sheet поверх другого или скрывать один Bottom Sheet и следом показывать другой.
• Отказаться от Bottom Sheet совсем. Нет изменения высоты контейнера фрагментов — нет проблем.

Демо проект можно найти вот тут на GitHub.

Источник: Анимация в Android: плавные переходы фрагментов внутри Bottom Sheet

Всем привет!

Меня зовут Антон Князев, senior Android-разработчик компании Omega-R (см. источник). В течение последних семи лет я профессионально занимаюсь разработкой мобильных приложений и решаю сложные проблемы нативной разработки.

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

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

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

Первая библиотека, которую мы выложили на GitHub, является простым расширением RecyclerView.

Начнем с проблем, которые она решала:

1. Нет дефолтного layoutManager – это неудобно, так как часто приходится выбирать один и тот же LinearLayoutManager.
2. Нет возможности добавлять divider и item space через xml – тоже неудобно, так как необходимо добавлять либо в item layout, либо через ItemDecorator.
3. Нельзя просто добавить header и footer через xml – это возможно только через отдельный ViewHolder.

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

1. Проблема: нет дефолтного layoutManager

Разработчики RecyclerView не предусмотрели возможности выбора LayoutManager по умолчанию. Задать layoutManager можно следующими способами:

1. Через XML в атрибуте app:layoutManager=”LinearLayoutManager”:

<?xml version="1.0" encoding="utf-8"?>
<androidx.recyclerview.widget.RecyclerView
    ...
     app:layoutManager="LinearLayoutManager"/>

2. Через код:

recyclerView.layoutManager = LinearLayoutManager(this)

По нашему опыту, в большинстве случаев нужен именно LinearLayoutManager.

Вот несколько примеров таких списков из наших приложений ITProTV, Простой Мир и Dexen:

Решение: добавим дефолтный layoutManager

В OmegaRecyclerView добавляется лишь 3 строчки:

if (layoutManager == null)  {
    layoutManager = LinearLayoutManager(context, attrs, defStyleAttr, 0)
}

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

<?xml version="1.0" encoding="utf-8"?>
<com.omega_r.libs.omegarecyclerview.OmegaRecyclerView
    android:id="@+id/recyclerview"
    android:layout_width="match_parent"
    android:layout_height="match_parent" />

2. Проблема: нет возможности добавлять divider и item space через xml

Добавлять divider приходится довольно часто при использовании RecyclerView. Например, в проекте “Простой Мир” один из экранов был с таким нестандартным divider (горизонтальная линия):

Из этого макета видно, что:

• используется divider между элементами и в самом конце;
• используется item space.

Каким образом это можно реализовать в Android стандартным путем?

Способ 1

Самый очевидный способ – включить divider как элемент ImageView:

 <RelativeLayout
   ...
   android:paddingStart="20dp"
   android:paddingTop="12dp"
   android:paddingEnd="20dp"
   android:paddingBottom="12dp">

   ...

   <ImageView
       ...
       android:layout_alignParentBottom="true"
       android:src="@drawable/divider"/>

</RelativeLayout>

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

Способ 2

Другим способом является использование DividerItemDecoration, который может нарисовать этот divider. Для него необходимо дополнительно создать drawable:

<?xml version="1.0" encoding="utf-8"?>
<layer-list xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:left="32dp">
        <shape android:shape="rectangle">
            <size
                android:width="1dp"
                android:height="1dp" />
            <solid android:color="@color/gray_dark" />
        </shape>
    </item>
</layer-list>

Для добавления отступа требуется написать свой ItemDecoration:

class VerticalSpaceItemDecoration(
    private val verticalSpaceHeight: Int
): RecyclerView.ItemDecoration {

    override fun getItemOffsets(
        outRect: Rect,
        view: View,
        parent: RecyclerView,
        state: RecyclerView.State
    ) {
        outRect.bottom = verticalSpaceHeight
    }
}

DividerItemDecoration прост: он рисует divider всегда под каждым элементом списка.
Но в случае изменения требований придется искать другое решение.

Решение: дополним возможностью добавлять divider и item space через xml

Итак, наш OmegaRecyclerView должен уметь добавлять divider с помощью следующих атрибутов:

1. divider – определяет drawable, может быть назначен и цвет напрямую;
2. dividerShow (beginning, middle, end) – флаги, которые определяют, где рисовать;
3. dividerHeight – задает высоту divider, в случае с цветом становится особенно нужным;
4. dividerPadding, dividerPaddingStart, dividerPaddingEnd – отступы: общий, с начала, с конца;
5. dividerAlpha – определяет прозрачность;
6. itemSpace – отступы между элементами списка.

Все эти атрибуты применяются непосредственно к нашему OmegaRecyclerView с помощью двух специальных ItemDecoration.

Один из ItemDecoration добавляет отступы между элементами, второй – рисует сам divider. Необходимо учитывать, что при наличии отступа между элементами второй ItemDecoration рисует divider посередине отступа. Возможности поддерживать все возможные варианты LayoutManager нет, поэтому поддерживаем только LinearLayoutManager и GridLayoutManager. Также следует учитывать ориентацию списка для LinearLayoutManager.

Для того чтобы упростить код, выделим специальный DividerDecorationHelper, который будет читать и записывать относительные данные в Rect, зависящие от ориентации и порядка следования (обратный или прямой). В нем будут методы setStart, setEnd, getStart, getEnd.

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

1. проверка, что layoutManager является наследником LinearLayoutManager;
2. вычисление текущей ориентации и порядка следования;
3. определение подходящего DividerDecorationHelper.

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

override fun getItemOffset(
    outRect: Rect,
    parent: RecyclerView,
    helper: DividerDecorationHelper,
    position: Int,
    itemCount: Int
) {
    if (isShowBeginDivider() || countBeginEndPositions <= position) {
        helper.setStart(outRect, space)
    }
    if (isShowEndDivider() && position == itemCount - countBeginEndPositions) {
        helper.setEnd(outRect, space)
    }
}

Следующий DividerItemDecoration будет непосредственно рисовать divider. Он должен учитывать отступ между элементами и рисовать divider посередине. Для начала переопределим метод getItemOffset для случая, когда отступ не задан, но divider требуется для рисования.

override fun getItemOffset(
    outRect: Rect,
    parent: RecyclerView,
    helper: DividerDecorationHelper,
    position: Int,
    itemCount: Int
) {
    if (position == 0 && isShowBeginDivider()) {
        helper.setStart(outRect, dviderSize)
    }
    if (position != 0 && isShowMiddleDivider()) {
        helper.setStart(outRect, dividerSize)
    }
    if (position == itemCount - 1 && isShowEndDivider()) {
        helper.setEnd(outRect, dividerSize)
    }
}

Также добавим опцию, которая позволит DividerItemDecoration спрашивать adapter, можно ли рисовать выше или ниже выбранного элемента. Для реализации такой возможности создадим свой адаптер, наследуемый от стандартного со следующими методами:

open fun isDividerAllowedAbove(position: Int): Boolean {
    return true
}

open fun isDividerAllowedBelow(position: Int): Boolean {
    return true
}

Далее переопределим метод onDrawOver, чтобы рисовать divider поверх нарисованных элементов. В этом методе надо пройтись по всем элементам, видимым на экране (через getChildAt), и при необходимости нарисовать этот divider. Также надо учесть, что из атрибута dividerDrawable может прийти и цвет, у которого нет высоты. Для такого случая высоту можно взять из атрибута dividerHeight.

3. Проблема: нельзя напрямую добавить header и footer через xml

В RecyclerView невозможно добавлять view через xml, но есть другие способы сделать это.

Способ 1

Один из очевидных способ добавлении view – через adapter. Причем необходимо отличать header и footer в adapter при введении своего идентификатора для viewType.

fun onCreateViewHolder(parent: ViewGroup, viewType: Int): RecyclerView.ViewHolder? {
    val inflater = LayoutInflater.from(parent.context)
    return when (viewType) {
        TYPE_HEADER -> {
            val headerView: View = inflater.inflate(R.layout.item_header, parent, false)
            HeaderViewHolder(itemView)
        }
        TYPE_ITEM -> {
            val itemView: View = inflater.inflate(R.layout.item_view, parent, false)
            ItemViewHolder(itemView)
        }
        else -> null
    }
}

Способ 2

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

val mergeAdapter = MergeAdapter(headerAdapter, itemAdapter,  footerAdapter)
recyclerView.adapter = mergeAdapter

Решение: дополним возможностью простого добавления header и footer через xml

Первое, что нужно сделать, – перехватить добавление view в нашем OmegaRecyclerView, когда идет процесс inflate. Для этого следует переопределить метод addView и добавить себе header и footer view. Этот метод используется самим RecyclerView для дополнения видимыми элементами списка. Но view, добавленные через xml, не будут иметь ViewHolder, что в конечном итоге вызовет NullPointerException.

Итак, нам надо определить, когда view добавляется во время inflate. К счастью, существует protected метод onFinishInflate, который вызывается при завершении процесса inflate. Поэтому при вызове этого метода помечаем, что процесс inflate завершен.

protected override fun onFinishInflate() {
    super.onFinishInflate()
    finishedInflate = true
}

Таким образом, метод addView будет выглядеть следующим образом:

override fun addView(view: View, index: Int, params: ViewGroup.LayoutParams) {
    if (finishedInflate) {
        super.addView(view, index, params)
    } else {
        // save header and footer views
    }
}

Далее необходимо запомнить все эти добавочные view и передать в специальный адаптер по типу MergeAdapter.

Также нам удалось решить еще одну проблему: при вызове метода findViewById наши view возвращаться не будут. Для решения этой проблемы переопределим метод findViewTraversal: в нем необходимо сравнить id найденных нами view и вернуть view при совпадении. Поскольку этот метод скрыт, просто пишем его, не указывая, что он override.

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

1. Мы уже в 2018 году создали свой ViewPager из RecyclerView. Причем в нашем ViewPager есть бесконечный скролл.
2. ExpandableRecyclerView – специальный класс для добавления раскрывающегося списка с возможностью выбора анимации раскрытия.
3. StickyHeader – специфический элемент списка, который можно добавлять через адаптер.

Всё это является результатом наработанного опыта Omega-R. Эволюция мастерства разработчиков проходит через несколько стадий. Сначала появляется желание скопировать код из другого проекта или сделать что-то похожее на него. Потом приходит стадия, когда необходимо зафиксировать накопленный опыт и создать отдельный репозиторий.

На следующей стадии начинаешь целенаправленно создавать фичи, которые не решался делать в проектах. Это может занять значительное время, но позволяет создать задел на будущее и ускорить разработку в новых проектах. Приглашаю каждого, кто сталкивается с трудностями в разработке, познакомиться с нашими решениями в GitHub-репозитории Omega-R.

Источник: Кодовая база. Расширяем RecyclerView

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

Автор: Вячеслав Ворожейкин. Ссылка на источник – в конце статьи.

Предисловие

Впервые наткнувшись на статью о Model-View-Intent (MVI) под Android, я даже не открыл ее. "Серьезно!? Архитектура на Android Intents?"

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

Изучая MVI, я невольно столкнулся с проблемой, что весь подход выглядит как-то запутанно, как какие-то дебри. Да, на выходе получается решение с плюсами по отношению к MVP и MVVM, но, смотря на эту всю комплексность, задаешься вопросом: "А стоило ли?".

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

Так я решил написать свое решение. Основные требования (по значимости):

1. Простое;
2. Покрывает все UI кейсы, которые я только могу придумать;
3. Структурированное.

И что это?

Позвольте представить — Джунгли (Jungle). Под капотом — только RxJava с ее реактивным подходом.

База

• State — "устойчивые" данные о UI, которые должны быть показаны даже после пересоздания View;
• Action — "неустойчивые" данные об UI, которые не должны быть показаны после пересоздания View (например, данные о Snackbar и Toast);
• Event — Intent из Model-View-Intent;
• MviView — интерфейс, через который поставляются новые Actions и обновления State;
• Middleware — посредник между одной функциональностью бизнес логики и UI;
• Store — посредник между Model и View, который решает, как обрабатывать Events, поставлять обновления State и новые Actions.

Все отношения, показанные на картинке, опциональны

Как это работает?

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

1. Показывать ProgressBar во время загрузки.
2. Отображать Button для перезагрузки списка и Toast с сообщением об ошибке в случае ошибки.
3. Если страны были успешно загружены, отображать список стран.
4. Попробовать загрузить страны на открытии окна автоматически, без каких-либо действий пользователя.

Давайте напишем нашу UI часть:

sealed class DemoEvent {
   object Load : DemoEvent()
}

sealed class DemoAction {
   data class ShowError(val error: String) : DemoAction()
}

data class DemoState(
   val loading: Boolean = false,
   val countries: List<Country> = emptyList()
)

class DemoFragment : Fragment, MviView<DemoState, DemoAction> {

   private lateinit var demoStore: DemoStore
   private var adapter: DemoAdapter? = null

   /*Initializations are skipped*/

   override fun onViewCreated(view: View, bundle: Bundle?) {
      super.onViewCreated(view, bundle)
      demoStore.run {
         attach(this@DemoFragment)
         dispatchEventSource(
            RxView.clicks(demo_load)
               .map { DemoEvent.Load }
         )
      }
   }

   override fun onDestroyView() {
      super.onDestroyView()
      demoStore.detach()
   }

   override fun render(state: DemoState) {
      val showReload = state.run {
         !loading && countries.isEmpty()
      }
      demo_load.visibility = if (showReload)
         View.GONE else
         View.VISIBLE
      demo_progress.visibility = if (state.loading)
         View.VISIBLE else
         View.GONE
      demo_recycler.visibility = if (state.countries.isEmpty())
         View.GONE else
         View.VISIBLE
      adapter?.apply {
         setItems(state.countries)
         notifyDataSetChanged()
      }
   }

   override fun processAction(action: DemoAction) {
      when (action) {
         is DemoAction.ShowError ->
            Toast.makeText(
               requireContext(),
               action.error,
               Toast.LENGTH_SHORT
            ).show()
      }
   }
}

Что из этого (пока) можно понять? Мы можем послать DemoEvent.Load нашему DemoStore (по клику на кнопку Reload), получить DemoAction.ShowError (с данными об ошибке) и отобразить Toast, получить обновление по DemoState (с данными о странах и состоянии загрузки) и отобразить UI компоненты в соответствии с требованиями. Вроде бы не так уж и сложно.

Теперь приступим к нашему DemoStore. В первую очередь, унаследуем его от Store, разрешим получать DemoEvent, производить DemoAction и изменять DemoState:

class DemoStore(
   foregroundScheduler: Scheduler,
   backgroundScheduler: Scheduler
) : Store<DemoEvent, DemoState, DemoAction>(
   foregroundScheduler = foregroundScheduler,
   backgroundScheduler = backgroundScheduler
)

Затем создадим CountryMiddleware, который будет ответственным за предоставление данных о загрузке стран:

class CountryMiddleware(
   private val getCountriesInteractor: GetCountriesInteractor
) : Middleware<CountryMiddleware.Input>() {

   override val inputType = Input::class.java

   override fun transform(upstream: Observable<Input>) =
      upstream.switchMap<CommandResult> {
         getCountriesInteractor.execute()
            .map<Output> { Output.Loaded(it) }
            .onErrorReturn {
               Output.Failed(it.message ?: "Can't load countries")
            }
            .startWith(Output.Loading)
      }

   object Input : Command

   sealed class Output : CommandResult {
      object Loading : Output()
      data class Loaded(val countries: List<Country>) : Output()
      data class Failed(val error: String) : Output()
   }
}

Что такое Command? Это специфичный сигнал, который побуждает "что-то" сделать. А CommandResult? Это результат выполнения этого "чего-то".

В нашем случае CountryMiddleware.Input сигнализирует, что логика CountryMiddleware должна быть выполнена. Каждое выполнение логики Middleware возвращает CommandResult; для лучшей структуры приложения можно хранить этот результат внутри sealed класса (CountryMiddleware.Output).

В нашем случае мы попросту возвращаем Observable, который испустит Output.Loading во время загрузки, Output.Loaded с данными на успешную загрузку, Output.Failed с информацией об ошибке на ошибку.

Давайте вернемся к DemoStore и заставим обработать CountryMiddleware при нажатии кнопки Reload:

class DemoStore(..., countryMiddleware: CountryMiddleware)... {

   override val middlewares = listOf(countryMiddleware)

   override fun convertEvent(event: DemoEvent) = when (event) {
      is DemoEvent.Load -> CountryMiddleware.Input
   }
}

Переопределяя поле middlewares, мы указываем, какие Middlewares наш DemoStore может обработать. Под капотом Store использует Commands. Поэтому нам следует сконвертировать наш DemoEvent.Load в CountryMiddleware.Input (для того чтобы принудить перезагрузку).

Итак, теперь мы можем получать результат от CountryMiddleware. Давайте позволим последнему изменять наш DemoState:

class DemoStore ... {
   ...

   override val initialState = DemoState()

   override fun reduceCommandResult(
      state: DemoState,
      result: CommandResult
   ) = when (result) {
      is CountryMiddleware.Output.Loading ->
         state.copy(loading = true)
      is CountryMiddleware.Output.Loaded ->
         state.copy(loading = false, countries = result.countries)
      is CountryMiddleware.Output.Failed ->
         state.copy(loading = false)
      else -> state
   }
}

Прежде чем изменять State, необходимо указать его начальное состояние в initialState. После этого в методе reduceCommandResult описывается логика того, как каждый CommandResult изменяет State.

Для отображения ошибки загрузки используется DemoAction.ShowError. Чтобы сгенерировать последний, необходимо предоставить новую Command (из CommandResult) и связать ее с нашим Action:

class DemoStore ... {
   ...

   override fun produceCommand(commandResult: CommandResult) =
      when (commandResult) {
         is CountryMiddleware.Output.Failed ->
            ProduceActionCommand.Error(commandResult.error)
         else -> null
      }

   override fun produceAction(command: Command) =
      when (command) {
         is ProduceActionCommand.Error ->
            DemoAction.ShowError(command.error)
         else -> null
      }

   sealed class ProduceActionCommand : Command {
      data class Error(val error: String) : ProduceActionCommand()
   }
}

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

class DemoStore ... {
   ...

   override val bootstrapCommands = listOf(CountryMiddleware.Input)
}

Сделано!

Просто?

Можно использовать конкретно только то, что вам нужно, без какой-либо лишней логики. Несколько классов и щепотка магии под капотом. Один Store, опционально несколько Middlewares, опционально имплементация MviView.

Ваша View должна только отображать обновления какой-то функциональности бизнес логики? Вам даже не нужны Events, только Store, Middleware и переопределение метода render функции в MviView.

Только кнопка, по клику которой происходит какая-то навигация? Окей, стоит только поиграться с Event внутри Store и ничего больше.

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

Структурировано?

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

• Хранить Commands в sealed классах внутри Store, группируя их по назначения: генерирующие Actions или напрямую изменяющие State.
• Хранить Commands, относящихся к Middlewares, внутри последних.

Также стоит помнить, что Middleware — про одну функциональность, что делает его похожим на UseCase (Interactor). На мой взгляд, присутствие последнего (и, как следствие, какого-то domain layer) говорит о хорошо структурированном проекте. По этой же аналогии, я считаю, что использование Middleware способствует улучшению структуры проекта.

Заключение

С использованием Джунгей у меня есть четкое представление того, как организуется навигация внутри подхода. Я также уверен, что проблема SingleLiveEvent может быть легко разрешена с использованием Actions.

Более подробные разборы работы можно найти в wiki. Отвечу на любые вопросы. Буду рад, если вам данное решение покажется полезным!

Источник: Приручая MVI

В этой статье автор продолжает рассказывать про инструменты, которые почему-то обделили вниманием. В своей предыдущей статье он написал про возможности ActivityLifecycleCallbacks и как их можно применять не только для логирования жизненного цикла. Но кроме Activity есть еще и Fragment, и ему хотелось получить для них подобное поведение. Далее рассказ ведется от лица автора.

Не долго думая, я открыл поиск по классам в AndroidStudio (Cmd/Ctrl + O) и ввел туда FragmentLifecycleCallbacks. И каково же было мое удивление, когда поиск показал мне FragmentManager.FragmentLifecycleCallbacks. Самые нетерпеливые читатели писали про это в комментариях, поэтому вот продолжение всей этой истории. Скорее под кат!

Что это такое

Интерфейс наподобие ActivityLifecycleCallbacks, только для Fragment.

FragmentLifecycleCallbacks

В отличие от ActivityLifecycleCallbacks он управляется не самим Fragment, а FragmentManager, что дает ряд преимуществ. Например, у этого интерфейса методы с приставкой Pre-, которые вызываются до соответствующих методов Fragment. А методы без приставки вызываются после того, как сработают эти же методы Fragment.

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

Но перейдем к интересному — как это запустить.

Как зарегистрировать

Чтобы заставить FragmentLifecycleCallbacks работать, его нужно зарегистрировать на FragmentManager. Для этого надо вызвать FragmentManager.registerFragmentLifecycleCallback(), передав в него два параметра: сам callback и флаг — recursive. Флаг показывает, нужно ли применить этот callback только к этому FragmentManager или его надо рекурсивно прокидывать во все childFragmentManager’ы этого FragmentManager'а и дальше по иерархии.

FragmentLifecycleCallback стоит регистрировать до Activity.onCreate(), иначе мы можем получить не все события, например, при восстановлении состояния.

class FlcExampleActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        supportFragmentManager
            .registerFragmentLifecycleCallbacks(
                ExampleFragmentLifecycleCallback(),
                true
            )

        super.onCreate(savedInstanceState)
    }
}

class ExampleFragmentLifecycleCallback : FragmentManager.FragmentLifecycleCallbacks()

Выглядит не очень красиво, и в некоторых ситуациях потребует заводить что-то вроде базовой Activity. Но если ты уже прочитал мою статью про ActivityLifecycleCallbacks, то знаешь, на что базовые Activity отлично заменяются =).

class ActivityFragmentLifecycleCallbacks :
    Application.ActivityLifecycleCallbacks,
    FragmentManager.FragmentLifecycleCallbacks() {

    override fun onActivityCreated(
        activity: Activity,
        savedInstanceState: Bundle?
    ) {
        (activity as? FragmentActivity)
            ?.supportFragmentManager
            ?.registerFragmentLifecycleCallbacks(this, true)
    }
}

И тут мы получаем потрясающую синергию callback’ов. Благодаря этому решению мы теперь можем дотянуться почти до любого объекта Activity и Fragment, создаваемых в системе. И теперь, когда мы видим все как на ладони, можно заставить всю эту систему работать на нас.

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

Сразу про dependency injection: да, теперь можно распространять зависимости по всему приложению, даже если у вас Single Activity Application. Помнишь пример из предыдущей статьи, про RequireCoolTool? То же самое можно сделать для всех Activity и Fragment в приложении. И ты уже догадался как, да? Но я все равно покажу пример.

Dependency injection

interface CoolTool {
    val extraInfo: String
}

class CoolToolImpl : CoolTool {
    override val extraInfo = "i am dependency"
}

interface RequireCoolTool {
    var coolTool: CoolTool
}

class InjectingLifecycleCallbacks :
    Application.ActivityLifecycleCallbacks,
    FragmentManager.FragmentLifecycleCallbacks() {

    private val coolToolImpl = CoolToolImpl()

    override fun onActivityCreated(
        activity: Activity,
        savedInstanceState: Bundle?
    ) {
        (activity as? RequireCoolTool)?.coolTool = coolToolImpl
        (activity as? FragmentActivity)
            ?.supportFragmentManager
            ?.registerFragmentLifecycleCallbacks(this, true)
    }

    override fun onFragmentPreCreated(
        fm: FragmentManager,
        f: Fragment,
        savedInstanceState: Bundle?
    ) {
        (f as? RequireCoolTool)?.coolTool = coolToolImpl
    }
}

class DIActivity : AppCompatActivity(), RequireCoolTool {

    override lateinit var coolTool: CoolTool

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContentView(LinearLayout {
            orientation = LinearLayout.VERTICAL
            FrameLayout {
                layoutParams = LinearLayout.LayoutParams(
                    LinearLayout.LayoutParams.MATCH_PARENT, 0, 1f)
                Text(
                    """
                    DI example activity
                    CoolTool.extraInfo="${coolTool.extraInfo}"
                    """.trimIndent()
                )
            }
            FrameLayout {
                layoutParams = LinearLayout.LayoutParams(
                    LinearLayout.LayoutParams.MATCH_PARENT, 0, 1f)
                id = R.id.container
            }
        })

        supportFragmentManager.findFragmentById(R.id.container) ?: run {
            supportFragmentManager
                .beginTransaction()
                .add(R.id.container, DIFragment())
                .commit()
        }
    }
}

class DIFragment : Fragment(), RequireCoolTool {

    override lateinit var coolTool: CoolTool

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View? =
        inflater.context.FrameLayout {
            setBackgroundColor(Color.LTGRAY)
            Text(
                """
                    DI example fragment
                    CoolTool.extraInfo="${coolTool.extraInfo}"
                    """.trimIndent()
            )
        }

}

И конечно же с Dagger’ом все тоже идеально работает.

Dagger

interface DaggerTool {
    val extraInfo: String
}

class DaggerToolImpl : DaggerTool {
    override val extraInfo = "i am dependency"
}

class DaggerInjectingLifecycleCallbacks(
    val dispatchingAndroidInjector: DispatchingAndroidInjector<Any>
) : Application.ActivityLifecycleCallbacks,
    FragmentManager.FragmentLifecycleCallbacks() {

    override fun onActivityCreated(
        activity: Activity,
        savedInstanceState: Bundle?
    ) {
        dispatchingAndroidInjector.maybeInject(activity)
        (activity as? FragmentActivity)
            ?.supportFragmentManager
            ?.registerFragmentLifecycleCallbacks(this, true)
    }

    override fun onFragmentPreCreated(
        fm: FragmentManager,
        f: Fragment,
        savedInstanceState: Bundle?
    ) {
        dispatchingAndroidInjector.maybeInject(f)
    }
}

class DaggerActivity : AppCompatActivity() {

    @Inject
    lateinit var daggerTool: DaggerTool

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContentView(LinearLayout {
            orientation = LinearLayout.VERTICAL
            FrameLayout {
                layoutParams = LinearLayout.LayoutParams(
                    LinearLayout.LayoutParams.MATCH_PARENT, 0, 1f)
                Text(
                    """
                    Dagger example activity
                    CoolTool.extraInfo="${daggerTool.extraInfo}"
                    """.trimIndent()
                )
            }
            FrameLayout {
                layoutParams = LinearLayout.LayoutParams(
                    LinearLayout.LayoutParams.MATCH_PARENT, 0, 1f)
                id = R.id.container
            }
        })

        supportFragmentManager.findFragmentById(R.id.container) ?: run {
            supportFragmentManager
                .beginTransaction()
                .add(R.id.container, DIFragment())
                .commit()
        }
    }
}

class DaggerFragment : Fragment() {

    @Inject
    lateinit var daggerTool: DaggerTool

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View? =
        inflater.context.FrameLayout {
            Text(
                """
                Dagger example fragment
                DaggerTool.extraInfo="${daggerTool.extraInfo}"
                """.trimIndent()
            )
        }
}

@Module
class DaggerModule {
    @Provides
    fun provideDaggerTool(): DaggerTool {
        return DaggerToolImpl()
    }
}

@Module
abstract class DaggerAndroidModule {
    @ContributesAndroidInjector(modules = [DaggerModule::class])
    abstract fun contributeDaggerActivity(): DaggerActivity

    @ContributesAndroidInjector(modules = [DaggerModule::class])
    abstract fun contributeDaggerFragment(): DaggerFragment
}

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

Конечно, можно делать все то же самое, что и с Activity, например, отправлять аналитику.

Analytics

interface Screen {
    val screenName: String
}

interface ScreenWithParameters : Screen {
    val parameters: Map<String, String>
}

class AnalyticsCallback(
    val sendAnalytics: (String, Map<String, String>?) -> Unit
) : Application.ActivityLifecycleCallbacks, 
    FragmentManager.FragmentLifecycleCallbacks() {

    override fun onActivityCreated(
        activity: Activity,
        savedInstanceState: Bundle?
    ) {
        if (savedInstanceState == null) {
            (activity as? Screen)?.screenName?.let {
                sendAnalytics(
                    it,
                    (activity as? ScreenWithParameters)?.parameters
                )
            }
        }
    }
}

class AnalyticsActivity : AppCompatActivity(), ScreenWithParameters {

    override val screenName: String = "First screen"

    override val parameters: Map<String, String> = mapOf("key" to "value")

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContentView(LinearLayout {
            orientation = android.widget.LinearLayout.VERTICAL
            FrameLayout {
                layoutParams = LayoutParams(LayoutParams.MATCH_PARENT, 0, 1f)
                Text(
                    """
                    Analytics example
                    see output in Logcat by "Analytics" tag
                    """.trimIndent()
                )
            }
            FrameLayout {
                layoutParams = LayoutParams(LayoutParams.MATCH_PARENT, 0, 1f)
                id = R.id.container
            }
        })

        with(supportFragmentManager) {
            findFragmentById(R.id.container) ?: commit {
                add(R.id.container, AnalyticsFragment())
            }
        }
    }
}

class AnalyticsFragment : Fragment(), ScreenWithParameters {

    override val screenName: String = "Fragment screen"

    override val parameters: Map<String, String> = mapOf("key" to "value")

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View? =
        inflater.context.FrameLayout {
            setBackgroundColor(Color.LTGRAY)
            Text(
                """
                Analytics example
                see output in Logcat by "Analytics" tag
                """.trimIndent()
            )
        }
}

А какие варианты использования знаешь ты?

Источник: Раскладываем на части FragmentLifecycleCallbacks

С детства я люблю читать инструкции (автор статьи – Владимир Генович). Я вырос, но меня до сих пор удивляет то, как взрослые люди безалаберно относятся к инструкциям: многие из них считают, что все знают, и при этом пользуются одной-двумя функциями, в то время как их намного больше! Кто из вас пользовался функцией поддержания температуры в микроволновке? А она есть почти в каждой.

Однажды я решил почитать документацию к различным классам Android framework. Пробежался по основным классам: View, Activity, Fragment, Application, — и меня очень заинтересовал метод Application.registerActivityLifecycleCallbacks() и интерфейс ActivityLifecycleCallbacks. Из примеров его использования в интернете не нашлось ничего лучше, чем логирование жизненного цикла Activity. Тогда я начал сам экспериментировать с ним, и теперь мы в Яндекс.Деньгах активно используем его при решении целого спектра задач, связанных с воздействием на объекты Activity снаружи.

Что такое ActivityLifecycleCallbacks?

Посмотрите на этот интерфейс, вот как он выглядел, когда появился в API 14:

public interface ActivityLifecycleCallbacks {
    void onActivityCreated(Activity activity, Bundle savedInstanceState);
    void onActivityStarted(Activity activity);
    void onActivityResumed(Activity activity);
    void onActivityPaused(Activity activity);
    void onActivityStopped(Activity activity);
    void onActivitySaveInstanceState(Activity activity, Bundle outState);
    void onActivityDestroyed(Activity activity);
}

Возможно, этому интерфейсу уделяют так мало внимания, потому что он появился только в Android 4.0 ICS. А зря, ведь он позволяет нативно делать очень интересную вещь: воздействовать на все объекты Activity снаружи. Но об этом позже, а сначала внимательнее посмотрим на методы.

Каждый метод отображает аналогичный метод жизненного цикла Activity и вызывается в тот момент, когда метод срабатывает на какой-либо Activity в приложении. То есть если приложение запускается с MainActivity, то первым мы получим вызов ActivityLifecycleCallback.onActivityCreated(MainActivity, null).

Отлично, но как это работает? Тут никакой магии: Activity сами сообщают о том, в каком они состоянии. Вот кусочек кода из Activity.onCreate():

    mFragments.restoreAllState(p, mLastNonConfigurationInstances != null
            ? mLastNonConfigurationInstances.fragments : null);
}
mFragments.dispatchCreate();
getApplication().dispatchActivityCreated(this, savedInstanceState);
if (mVoiceInteractor != null) {

Это выглядит так, как если бы мы сами сделали BaseActivity. Только коллеги из Android сделали это за нас, еще и обязали всех этим пользоваться. И это очень даже хорошо!

В API 29 эти методы работают почти так же, но их Pre- и Post-копии честно вызываются до и после конкретных методов. Вероятно, теперь этим управляет ActivityManager, но это только мои догадки, потому что я не углублялся в исходники достаточно, чтобы это выяснить.

Как заставить ActivityLifecycleCallbacks работать?

Как и все callbacks, сначала их надо зарегистрировать. Мы регистрируем все ActivityLifecycleCallbacks в Application.onCreate(), таким образом получаем информацию обо всех Activity и возможность ими управлять.

class MyApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        registerActivityLifecycleCallbacks(MyCallbacks())
    }
}

Небольшое отступление: начиная с API 29 ActivityLifecycleCallbacks можно зарегистрировать еще и изнутри Activity. Это будет локальный callback, который работает только для этой Activity.

Вот и все. Но это вы можете найти, просто введя название ActivityLifecycleCallbacks в строку поисковика. Там будет много примеров про логирование жизненного цикла Activity, но разве это интересно? У Activity много публичных методов (около 400), и все это можно использовать для того, чтобы делать много интересных и полезных вещей.

Что с этим можно сделать?

А что вы хотите? Хотите динамически менять тему во всех Activity в приложении? Пожалуйста: метод setTheme() — публичный, а значит, его можно вызывать из ActivityLifecycleCallback:

class ThemeCallback(
    @StyleRes val myTheme: Int
) : ActivityLifecycleCallbacks {
    override fun onActivityCreated(
        activity: Activity, 
        savedInstanceState: Bundle?
    ) {
        activity.setTheme(myTheme)
    }
}

Повторяйте этот трюк ТОЛЬКО дома
Какие-то Activity из подключенных библиотек могут использовать свои кастомные темы. Поэтому проверьте пакет или любой другой признак, по которому можно определить, что тему этой Activity можно безопасно менять. Например, проверяем пакет так (по-котлиновски =)):

class ThemeCallback(
    @StyleRes val myTheme: Int
) : ActivityLifecycleCallbacks {
    override fun onActivityCreated(
        activity: Activity,
        savedInstanceState: Bundle?
    ) {
        val myPackage = "my.cool.application"
        activity
            .takeIf { it.javaClass.name.startsWith(myPackage) }
            ?.setTheme(myTheme)
    }
}

Пример не работает? Возможно, вы забыли зарегистрировать ThemeCallback в Application или Application в AndroidManifest.

Хотите еще интересный пример? Можно показывать диалоги на любой Activity в приложении.

class DialogCallback(
    val dialogFragment: DialogFragment
) : Application.ActivityLifecycleCallbacks {
    override fun onActivityCreated(
        activity: Activity,
        savedInstanceState: Bundle?
    ) {
        if (savedInstanceState == null) {
            val tag = dialogFragment.javaClass.name
            (activity as? AppCompatActivity)
                ?.supportFragmentManager
                ?.also { fragmentManager ->
                    if (fragmentManager.findFragmentByTag(tag) == null) {
                        dialogFragment.show(fragmentManager, tag)
                    }
                }
        }
    }
}

Повторяйте этот трюк ТОЛЬКО дома
Конечно же, не стоит показывать диалог на каждом экране — наши пользователи не будут нас любить за такое. Но иногда может быть полезно показать что-то такое на каких-то конкретных экранах.

А вот еще кейс: что если нам надо запустить Activity? Тут все просто: Activity.startActivity() — и погнали. Но что делать, если нам надо дождаться результата после вызова Activity.startActivityForResult()? У меня есть один рецепт:

class StartingActivityCallback : Application.ActivityLifecycleCallbacks {
    override fun onActivityCreated(
        activity: Activity,
        savedInstanceState: Bundle?
    ) {
        if (savedInstanceState == null) {
            (activity as? AppCompatActivity)
                ?.supportFragmentManager
                ?.also { fragmentManager ->
                    val startingFragment = findOrCreateFragment(fragmentManager)

                    startingFragment.listener = { resultCode, data ->
                        // handle response here
                    }

                    // start Activity inside StartingFragment
                }
        }
    }

    private fun findOrCreateFragment(
        fragmentManager: FragmentManager
    ): StartingFragment {
        val tag = StartingFragment::class.java.name
        return fragmentManager
            .findFragmentByTag(tag) as StartingFragment?
                ?: StartingFragment().apply {
                    fragmentManager
                        .beginTransaction()
                        .add(this, tag)
                        .commit()
                }
    }
}

В примере мы просто закидываем Fragment, который запускает Activity и получает результат, а потом делегирует его обработку нам. Будьте осторожны: тут мы проверяем, что наша Activity является AppCompatActivity, что может привести к бесконечному циклу. Используйте другие условия.

Усложним примеры. До этого момента мы использовали только те методы, которые уже есть в Activity. Как насчет того, чтобы добавить свои? Допустим, мы хотим отправлять аналитику об открытии экрана. При этом у наших экранов свои имена. Как решить эту задачу? Очень просто. Создадим интерфейс Screen, который сможет отдавать имя экрана:

interface Screen {
    val screenName: String
}

Теперь имплементируем его в нужных Activity:

class NamedActivity : Activity(), Screen {
    override val screenName: String  = "First screen"
}

После этого натравим на такие Activity специальные ActivityLifecycleCallback’и:

class AnalyticsActivityCallback(
    val sendAnalytics: (String) -> Unit
) : Application.ActivityLifecycleCallbacks {
    override fun onActivityCreated(
        activity: Activity,
        savedInstanceState: Bundle?
    ) {
        if (savedInstanceState == null) {
            (activity as? Screen)?.screenName?.let(sendAnalytics)
        }
    }
}

Видите? Мы просто проверяем интерфейс и, если он реализован, отправляем аналитику.

Повторим для закрепления. Что делать, если надо прокидывать еще и какие-то параметры? Расширим интерфейс:

interface ScreenWithParameters : Screen {
    val parameters: Map<String, String>
}

Имплементируем:

class NamedActivity : Activity(), ScreenWithParameters {
    override val screenName: String = "First screen"
    override val parameters: Map<String, String> = mapOf("key" to "value")
}

Отправляем:

class AnalyticsActivityCallback(
    val sendAnalytics: (String, Map<String, String>?) -> Unit
) : Application.ActivityLifecycleCallbacks {
    override fun onActivityCreated(
        activity: Activity,
        savedInstanceState: Bundle?
    ) {
        if (savedInstanceState == null) {
            (activity as? Screen)?.screenName?.let { name ->
                sendAnalytics(
                    name,
                    (activity as? ScreenWithParameters)?.parameters
                )
            }
        }
    }
}

Но это все еще легко. Все это было только ради того, чтобы подвести вас к по-настоящему интересной теме: нативное внедрение зависимостей. Да, у нас есть Dagger, Koin, Guice, Kodein и прочее. Но на небольших проектах они избыточны. Но у меня есть решение… Угадайте какое?

Допустим, у нас есть некоторый инструмент, вроде такого:

class CoolToolImpl {
    val extraInfo = "i am dependency"
}

Закроем его интерфейсом, как взрослые программисты:

interface CoolTool {
    val extraInfo: String
}

class CoolToolImpl : CoolTool {
    override val extraInfo = "i am dependency"
}

А теперь немного уличной магии от ActivityLifecycleCallbacks: мы создадим интерфейс для внедрения этой зависимости, реализуем его в нужных Activity, а с помощью ActivityLifecycleCallbacks найдем его и внедрим реализацию CoolToolImpl.

interface RequireCoolTool {
    var coolTool: CoolTool
}

class CoolToolActivity : Activity(), RequireCoolTool {
    override lateinit var coolTool: CoolTool
}

class InjectingLifecycleCallbacks : ActivityLifecycleCallbacks {
    override fun onActivityCreated(
        activity: Activity,
        savedInstanceState: Bundle?
    ) {
        (activity as? RequireCoolTool)?.coolTool = CoolToolImpl()
    }
}

Не забудьте зарегистрировать InjectingLifecycleCallbacks в вашем Application, запускайте — и все работает.

И не забудьте протестировать:

@RunWith(AndroidJUnit4::class)
class DIActivityTest {

    @Test
    fun `should access extraInfo when created`() {
        // prepare
        val mockTool: CoolTool = mock()
        val application = getApplicationContext<android.app.Application>()
        application.registerActivityLifecycleCallbacks(
            object : Application.ActivityLifecycleCallbacks {
                override fun onActivityCreated(
                    activity: Activity,
                    savedInstanceState: Bundle?
                ) {
                    (activity as? RequireCoolTool)?.coolTool = mockTool
                }
            })

        // invoke
        launch<DIActivity>(Intent(application, DIActivity::class.java))

        // assert
        verify(mockTool).extraInfo
    }
}

Но на больших проектах такой подход будет плохо масштабироваться, поэтому я не собираюсь отбирать ни у кого DI-фреймворки. Куда лучше объединить усилия и достигнуть синергии. Покажу на примере Dagger 2. Если у вас в проекте есть какая-то базовая Activity, которая делает что-то вроде AndroidInjection.inject(this), то пора ее выкинуть. Вместо этого сделаем следующее:

1. по инструкции внедряем DispatchingAndroidInjector в Application;
2. создаем ActivityLifecycleCallbacks, который вызывает DispatchingAndroidInjector.maybeInject() на каждой Activity;
3. регистрируем ActivityLifecycleCallbacks в Application.

class MyApplication : Application() {

    @Inject
    lateinit var dispatchingAndroidInjector: DispatchingAndroidInjector<Any>

    override fun onCreate() {
        super.onCreate()
        DaggerYourApplicationComponent.create().inject(this);
        registerActivityLifecycleCallbacks(
            InjectingLifecycleCallbacks(
                dispatchingAndroidInjector
            )
        )
    }
}

class InjectingLifecycleCallbacks(
    val dispatchingAndroidInjector: DispatchingAndroidInjector<Any>
) : ActivityLifecycleCallbacks {

    override fun onActivityCreated(
        activity: Activity,
        savedInstanceState: Bundle?
    ) {
       dispatchingAndroidInjector.maybeInject(activity)
    }
}

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

Подведем итоги

ActivityLifecycleCallbacks — это недооцененный, мощный инструмент. Попробуйте какой-нибудь из этих примеров, и пусть они помогут вам в ваших проектах так же, как помогают Яндекс.Деньгам делать наши приложения лучше.

Источник: ActivityLifecycleCallbacks — слепое пятно в публичном API

Activity — это одна из самых ярких концепций в Android (самой популярной мобильной операционной системе с хорошо продуманной архитектурой управления памятью, которая отлично реализует многозадачность).

Так или иначе, с запуском Activity на экране не все так однозначно. Способ, которым оно было запущено, также важен. Нюансов в этой теме очень много. Одним из действительно важных является launchMode, о котором мы и поговорим в этой статье.

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

Вот почему важно указывать, нужно ли создавать новую Activity или использовать существующую, иначе это может привести к плохому UX или сбоям. Благодаря разработчикам ядра Android, это легко сделать с помощью launchMode, который и был специально для этого создан.

Определение launchMode

По сути, мы можем определить launchMode напрямую в качестве атрибута тега <activity> в AndroidManifest.xml:

<activity
    android:name=".SingleTaskActivity"
    android:label="singleTask launchMode"
    android:launchMode="singleTask">

Доступно 4 типа launchMode. Давайте рассмотрим их по очереди.

standard

Это режим «по умолчанию».

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

Поведение на пре-Lollipop Android

Этот вид Activity будет создан и помещен в верх стека в той же задаче, которая и отправила Intent.

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

А это то, что вы увидите в диспетчере задач (может показаться немного странным):

Если мы переключим приложение на другую задачу, а затем переключимся обратно в Галерею, мы все равно увидим, что Activity со стандартным launchMode помещается поверх задачи Галереи. В результате, если нам нужно что-то сделать в Галерее, мы должны сначала закончить нашу работу в этой дополнительной Activity.

Поведение на Lollipop Android

Если эти Activity относятся к одному и тому же приложению, поведение будет таким же, как и в пре-Lollipop реализации — размещение в стеке поверх задачи.

Но в случае если Intent отправлен из другого приложения, будет создана новая задача и вновь созданное Activity будет размещено в качестве корневого, как показано ниже.

Это то, что вы увидите в диспетчере задач.

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

Примером такого вида Activity является Compose Email Activity (составление письма) или Social Network's Status Posting Activity (обновление статуса в соцсети). Если у вас на уме Activity, которое отдельно обрабатывает каждый Intent, то вы думаете именно о standard Activity.

singleTop

Следующий режим — singleTop. Он ведет себя почти так же, как и standard, – экземпляров singleTop Activity можно создать столько, сколько мы захотим. Единственное отличие состоит в том, что если уже есть экземпляр Activity с таким же типом наверху стека в вызывающей задаче, то никакого нового Activity создано не будет, вместо этого Intent будет отправлен существующему экземпляру Activity через метод onNewIntent().

В режиме singleTop вы должны предусмотреть обработку входящего Intent в onCreate() и onNewIntent(), чтобы он работал во всех случаях.

Пример использования этого режима — функция поиска. Давайте подумаем о создании окна поиска, которое направляет вас к SearchActivity, чтобы увидеть результаты поиска. Для лучшего UX обычно мы всегда помещаем окно поиска на страницу результатов поиска, чтобы позволить пользователю выполнить следующий поиск, не возвращаясь назад.

А теперь представьте, что если мы всегда запускаем новое SearchActivity, чтобы обслуживать новый результат поиска, то мы получим 10 новых Activity для 10 итераций поиска. Было бы очень странно возвращаться назад, так как вам нужно было бы нажимать назад 10 раз, чтобы пройти через все результаты поиска, чтобы вернуться к корневой Activity.

Вместо этого, если SearchActivity уже находится наверху стека, лучше отправить Intent в существующий экземпляр Activity и позволить ему обновить результат поиска. Теперь будет только одна SearchActivity, размещенная наверху стека, и вы можете просто нажать кнопку «Назад» один раз, чтобы вернуться к предыдущей Activity. В этом больше смысла.

В любом случае singleTop работает в той же задаче, что и вызывающая сторона. Если вы ожидаете, что Intent будет отправлен в существующую Activity, помещенную поверх любой другой задачи, я должен вас разочаровать, сказав, что там это так уже не работает. В случае если Intent отправлен из другого приложения в singleTop Activity, новая Activity будет запущена в том же аспекте, что и для standard launchMode (пре-Lollipop: помещено поверх вызывающей задачи, Lollipop: будет создана новая задача).

singleTask

Этот режим сильно отличается от standard и singleTop. Activity с singleTask launchMode разрешено иметь только один экземпляр в системе (а-ля синглтон). Если в системе уже существует экземпляр Activity, вся задача, удерживающая экземпляр, будет перемещена наверх, а Intent будет предоставлен через метод onNewIntent(). В противном случае будет создана новая Activity и помещена в соответствующую задачу.

Работая в одном приложении

Если в системе еще не было экземпляра singleTask Activity, будет создан новый, и он будет просто помещен вверх стека в той же задаче.

Но если он существует, все Activity, расположенные над этим singleTask Activity, автоматически будут жестоко уничтожены надлежащим образом (жизненный цикл закончен), чтобы отобразить на вершине стека нужную нам Activity. В то же время Intent будет отправлен в singleTask Activity через прекрасный метод onNewIntent().

Это не имеет смысла с точки зрения пользовательского опыта, но оно разработано именно таким образом…

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

Система создает новую задачу и создает экземпляр activity в корне новой задачи.

Но на практике похоже, что это работает не так, как описано. SingleTask Activity по-прежнему помещается наверх стека Activity задачи, как видно из результата команды dumpsys activity.

sk id #239
  TaskRecord{428efe30 #239 A=com.thecheesefactory.lab.launchmode U=0 sz=2}
  Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10000000 cmp=com.thecheesefactory.lab.launchmode/.StandardActivity }
    Hist #1: ActivityRecord{429a88d0 u0 com.thecheesefactory.lab.launchmode/.SingleTaskActivity t239}
      Intent { cmp=com.thecheesefactory.lab.launchmode/.SingleTaskActivity }
      ProcessRecord{42243130 18965:com.thecheesefactory.lab.launchmode/u0a123}
    Hist #0: ActivityRecord{425fec98 u0 com.thecheesefactory.lab.launchmode/.StandardActivity t239}
      Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10000000 cmp=com.thecheesefactory.lab.launchmode/.StandardActivity }
      ProcessRecord{42243130 18965:com.thecheesefactory.lab.launchmode/u0a123}

Если вы хотите, чтобы singleTask Activity вело себя так, как описано в документации: создайте новую задачу и поместите Activity в качестве корневого Activity. Вам нужно определить атрибут taskAffinity для singleTask Activity следующим образом.

<activity
    android:name=".SingleTaskActivity"
    android:label="singleTask launchMode"
    android:launchMode="singleTask"
    android:taskAffinity="">

Таким будет результат, когда мы попытаемся запустить SingleTaskActivity.

Ваша задача – решить, использовать taskAffinity или нет в зависимости от желаемого поведения Activity.

Взаимодействуя с другим приложением

Если Intent отправлен из другого приложения и в системе еще не создано ни одного экземпляра Activity, будет создана новая задача с новой Activity, размещенной в качестве корневой Activity.

Если не существует задачи, которая бы являлась владельцем вызывающей singleTask Activity, вместо нее будет выведена наверх новая Activity.

В случае если в какой-либо задаче существует экземпляр Activity, вся задача будет перемещена вверх и для каждого отдельного Activity, расположенного над singleTask Activity, будет завершен жизненный цикл. Если нажата кнопка «Назад», пользователь должен пройти через Activity в стеке, прежде чем вернуться к вызывающей задаче.

Примером использования этого режима является любое Entry Point Activity, например, страница «Входящие» почтового клиента или таймлайн соцсети. Эти Activity не предполагают более чем одного экземпляра, поэтому singleTask отлично справится со своей задачей. В любом случае, вы должны использовать этот режим с умом, так как в этом режиме Activity могут быть уничтожены без подтверждения пользователя, как описано выше.

singleInstance

Этот режим очень похож на singleTask, где в системе мог существовать только один экземпляр Activity. Разница в том, что задача, которая располагает этой Activity, может иметь только одну Activity — ту, у которой атрибут singleInstance. Если из этого вида Activity вызывается другая Activity, автоматически создается новое задание для размещения этой новой Activity. Аналогичным образом, если вызывается singleInstance Activity, будет создана новая задача для размещения этой Activity.

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

Вот что происходит, когда вызывается singleInstance Activity, в то время как в стеке уже существует какая-либо Activity.

А вот что мы видим в диспетчере задач.

Поскольку эта задача может иметь только одну Activity, мы больше не можем переключаться обратно на задачу № 1. Единственный способ сделать это — перезапустить приложение из лаунчера, но, как в итоге получится, singleInstance задача будет скрыта в фоновом режиме.

Во всяком случае, есть некоторые обходные пути для этой проблемы. Как и в случае с singleTask Activity, просто назначьте атрибут taskAffinity для singleInstance Activity, разрешающим существование нескольких задач в диспетчере задач.

<activity
    android:name=".SingleInstanceActivity"
    android:label="singleInstance launchMode"
    android:launchMode="singleInstance"
    android:taskAffinity="">

Теперь картина имеет больше смысла.

Этот режим используется редко. Некоторые из вариантов использования на практике — это лаунчер-Activity или приложение, для которого вы на 100% уверены, что там должна быть только одна Activity. В любом случае, я предлагаю вам не использовать этот режим, если на то нет крайней необходимости.

Intent-флаги

Помимо назначения режима запуска непосредственно в AndroidManifest.xml, мы также можем регулировать поведение с помощью инструмента, называемого Intent-флагами, например:

Intent intent = new Intent(StandardActivity.this, StandardActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP);
startActivity(intent);

запустит StandardActivity с условием singleTop launchMode.

Есть довольно много флагов, с которыми вы можете работать. Вы можете найти больше информации об этом здесь.

Надеюсь, вы нашли эту статью полезной =)

Источник: Разбираемся с launchMode Android Activity: standard, singleTop, singleTask и singleInstance