Анимация переходов android что это

Анимация в Android: переходы, ч. 1

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

Автор статьи: Андрей Ващенко, разработчик BytePace.

Анимация с помощью Transition представляет собой изменение свойств объекта (View), исходя из местоположения объекта на экране и примененного эффекта. С момента появления Transition в Android (с выхода версии 4.4 KitKat), появилось понятие сцены (Scene), и переход между двумя сценами это и есть Transition. Грубо говоря, чтобы сделать анимацию, нужна начальная сцена и конечная сцена. Например, чтобы сделать анимированное увеличение какого-либо объекта, можно сделать 1 лэйаут, затем скопировать его, и у копии сделать размер элемента больше. В итоге можем получить что-то подобное:

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

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

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

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

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

Сравнение старого и нового чекаута

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

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

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

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

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

Что имеем «из коробки»

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

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

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

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

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

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

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

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

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

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

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

animateLayoutChanges

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

animateLayoutChanges

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

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

setCustomAnimations

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

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

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()

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

setCustomAnimation

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

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

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

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

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

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

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

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

Важно: это будет работать, поскольку мы используем 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.

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

AutoTransition

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

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

Пишем свой Transition

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

• Scene — это расположение элементов на экране в определённый момент времени (layout) и ViewGroup, в которой происходит анимация (sceneRoot).
• Начальная сцена (Start Scene) — это Scene в начальный момент времени.
• Конечная сцена (End Scene) — это Scene в конечный момент времени.
• 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 за девять шагов

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

@TargetApi(VERSION_CODES.LOLLIPOP) class BottomSheetSharedTransition : Transition

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

companion object < private const val PROP_HEIGHT = "heightTransition:height" private val TransitionProperties = arrayOf(PROP_HEIGHT) >override fun getTransitionProperties(): Array = TransitionProperties

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

override fun captureStartValues(transitionValues: TransitionValues)

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

override fun captureStartValues(transitionValues: TransitionValues) < // Запоминаем начальную высоту View. transitionValues.values[PROP_HEIGHT] = transitionValues.view.height // . и затем закрепляем высоту контейнера фрагмента transitionValues.view.parent .let < it as? View >?.also < view ->view.updateLayoutParams  < height = view.height >> >

Аналогично предыдущему методу, нужно запомнить высоту 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 < (view.context.getSystemService( Context.WINDOW_SERVICE ) as WindowManager).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

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

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

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

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  < 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  < height = animation.animatedValue as Int >> // окончании анимации устанавливаем высоту контейнера WRAP_CONTENT doOnEnd < container.updateLayoutParams < height = ViewGroup.LayoutParams.WRAP_CONTENT >> >

override fun createAnimator( sceneRoot: ViewGroup?, startValues: TransitionValues?, endValues: TransitionValues? ): Animator? < if (startValues == null || endValues == null) < return null >val animators = listOf( 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) >>

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

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

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 = 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  < 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" >

newFragment.sharedElementEnterTransition = BottomSheetSharedTransition()

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

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

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

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

Готовый transition

Под спойлером готовый класс BottomSheetSharedTransition

package com.maleev.bottomsheetanimation import android.animation.Animator import android.animation.AnimatorSet import android.animation.ObjectAnimator import android.animation.ValueAnimator import android.annotation.TargetApi import android.content.Context import android.graphics.Point import android.os.Build import android.transition.Transition import android.transition.TransitionValues import android.util.AttributeSet import android.view.View import android.view.ViewGroup import android.view.WindowManager import android.view.animation.AccelerateInterpolator import androidx.core.animation.doOnEnd import androidx.core.view.updateLayoutParams @TargetApi(Build.VERSION_CODES.LOLLIPOP) class BottomSheetSharedTransition : Transition < @Suppress("unused") constructor() : super() @Suppress("unused") constructor( context: Context?, attrs: AttributeSet? ) : super(context, attrs) companion object < private const val PROP_HEIGHT = "heightTransition:height" // the property PROP_VIEW_TYPE is workaround that allows to run transition always // even if height was not changed. It's required as we should set container height // to WRAP_CONTENT after animation complete private const val PROP_VIEW_TYPE = "heightTransition:viewType" private const val ANIMATION_DURATION = 400L private val TransitionProperties = arrayOf(PROP_HEIGHT, PROP_VIEW_TYPE) >override fun getTransitionProperties(): Array = 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  < 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" >override fun createAnimator( sceneRoot: ViewGroup?, startValues: TransitionValues?, endValues: TransitionValues? ): Animator? < if (startValues == null || endValues == null) < return null >val animators = listOf( prepareHeightAnimator( startValues.values[PROP_HEIGHT] as Int, endValues.values[PROP_HEIGHT] as Int, endValues.view ), prepareFadeInAnimator(endValues.view) ) return AnimatorSet() .apply < duration = ANIMATION_DURATION playTogether(animators) >> private fun prepareFadeInAnimator(view: View): Animator = ObjectAnimator .ofFloat(view, "alpha", 0f, 1f) .apply < interpolator = AccelerateInterpolator() >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  < height = animation.animatedValue as Int >> // окончании анимации устанавливаем высоту контейнера WRAP_CONTENT doOnEnd < container.updateLayoutParams < height = ViewGroup.LayoutParams.WRAP_CONTENT >> > private fun getViewHeight(view: View): Int < // Получаем ширину экрана val deviceWidth = getScreenWidth(view) // Попросим View измерить себя при указанной ширине экрана val widthMeasureSpec = View.MeasureSpec.makeMeasureSpec(deviceWidth, View.MeasureSpec.EXACTLY) val heightMeasureSpec = View.MeasureSpec.makeMeasureSpec(0, View.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 < point ->view.context.getSystemService(Context.WINDOW_SERVICE) .let < it as WindowManager >.defaultDisplay .getSize(point) > 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 > 

Когда у нас есть готовый класс 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:

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

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

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

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

Демо проект можно найти вот тут на GitHub. А вакансию Android-разработчика (Нижний Новгород) вот здесь на Хабр Карьера.

• dodo is
• android
• dodo pizza engineering
• mobile development
• animation
• bottom sheet behavior
• анимация в приложениях
• анимация фрагментов

• Блог компании Dodo Engineering
• Разработка мобильных приложений
• Разработка под Android
• Kotlin
• Дизайн мобильных приложений

Анимация переходов android что это

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

Прочитайте внимательно условия! В начале каждой статьи указывается, к какому курсу относится данная статья. Например, если статья из 4 курса, значит нужно заплатить за все курсы по четвёртый включительно.

Стоимость регистрации — символические 355 рублей. После регистрации у вас будет доступ ко второму курсу.

Для регистрации сначала необходимо пополнить ЮMoney 410011383280263 на указанную сумму или QIWI (перевод по никнейму), а затем прислать письмо на адрес [email protected] с указанием, на какой кошелёк вы делали оплату и реквизиты, по которым можно вас определить (не прикрепляйте к письму картинки или файлы, пишите в письме). Учитывайте комиссию при переводах.

По поводу перевода на ЮMoney. Если делать перевод по указанной ссылке, то к сумме нужно прибавить 3% самостоятельно. Если вы знаете, как переводить по номеру кошелька 410011383280263 без указанной ссылки, то по идее ваш банк сам рассчитает комиссию. Эти новые правила стали применяться в октябре 2022, возможно вам придётся доплачивать, когда я увижу точную сумму прихода.

Не присылайте в письме мои номера кошельков — поверьте, я их знаю и без вас.

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

Доступ к третьему курсу обучения доступен только после оплаты второго курса и составляет 355 руб.

Доступ к четвёртому курсу обучения доступен после оплаты третьего курса и составляет 355 руб. и т.д.

При оплате сразу всех курсов одновременно (2-10) цена составит 3195 руб.

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

Также возможен приём на PayPal (только для зарубежных пользователей). Обратите внимание, что в этом случае стоимость одного курса составляет 7$.

На данный момент PayPal не доступен в России.

Webmoney тоже не особо доступен в России, но по запросу можно отправить на Z-кошелёк (7S), если вдруг кому-то удобно из других стран.

Анимация переходов между двумя фрагментами

Одним из краеугольных камней в Material design являются осмысленные движения между экранами. Lollipop предоставляет поддержку этих анимаций в форме фреймворка переходов между Activity и Fragment. Поскольку статей по данной теме не так много, я решил написать свою собственную!

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

Если вы желаете увидеть, что получилось — готовое приложение находится на GitHub.

Поддержка предыдущих версий Android?

У меня есть для вас две новости: хорошая и плохая. Плохая новость заключается в том, что до Lollipop данный фреймворк не работает. Не смотря на это, проблема решается методами библиотеки поддержки с помощью которой вы можете реализовать анимированые переходы доступные в API 21+.

В статье будут использоваться функции из библиотеки поддержки для обеспечения перемещения контента.

Имена переходов

Для ассоциации View на первом экране и его двойника на втором нужна связь. Lollipop предлагает использовать свойство “transition name” для связи View между собой.

Существует два способа добавления имени перехода (transition name) для ваших View:

• В коде можно использовать ViewCompat.setTransitionName() . Конечно, вы так же можете просто вызвать setTransitionName() , если поддержка начинается с Lollipop.
• Для добавления в XML, используйте атрибут android:transitionName .

Настройка FragmentTransaction

Настройка FragmentTransactions должна быть вам очень знакомой:

getSupportFragmentManager() .beginTransaction() .addSharedElement(sharedElement, transitionName) .replace(R.id.container, newFragment) .addToBackStack(null) .commit(); 

Чтобы указать какую View будем передавать между фрагментами — используем метод addSharedElement() .

Переданная View в addSharedElement() это View из первого фрагмента, которую вы хотите разделить (share) со вторым фрагментом. Имя перехода тут является именем перехода в разделенной (shared) View во втором фрагменте.

Настройка анимации перехода

Наконец-то пришел момент, когда мы зададим анимацию перехода между фрагментами.

Для shared элементов:

• Для перехода с первого фрагмента во второй используем метод setSharedElementEnterTransition() .
• Для возврата назад используем метод setSharedElementReturnTransition() . Анимация произойдет при нажатии кнопки назад.

Вы так же можете анимировать переходы для всех non-shared View. Для этих View, используйте setEnterTransition() , setExitTransition() , setReturnTransition() , и setReenterTransition() в соответствующих фрагментах.

Каждый из этих методов принимает один параметр Transition предназначенный для выполнения анимации.

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

Классы анимации перехода

Android предоставляет некоторые готовые анимации переходов, что подходят для большинства случаев. Fade выполняет анимацию исчезновения. Slide анимирует переход появления/исчезновения скольжением из угла экрана. Explode анимация подобная взрыву, изображение движется от краев экрана. И наконец, AutoTransition заставит изображение исчезать, двигаться и изменять размер. Это лишь некоторые примеры из пакета перемещений, их на самом деле намного больше!

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

public class DetailsTransition extends TransitionSet < public DetailsTransition() < setOrdering(ORDERING_TOGETHER); addTransition(new ChangeBounds()). addTransition(new ChangeTransform()). addTransition(new ChangeImageTransform())); >> 

Наш кастомный переход есть ни что иное как набор из трех готовых переходов собранных вместе:

• ChangeBounds
  анимирует границы (положение и размер) нашей view.
• ChangeTransform
  анимирует масштаб view, включая родителя.
• ChangeImageTransform
  позволяет нам изменять размер (и/или тип масштаба) нашего изображения

Вы так же можете создать более сложные анимации используя XML. Если вы предпочитаете XML, то вам будет интересно посмотреть документацию на сайте андроида Transition
.

Все вместе

Код который в итоге у нас получился оказался достаточно простым:

DetailsFragment details = DetailsFragment.newInstance(); // Note that we need the API version check here because the actual transition classes (e.g. Fade) // are not in the support library and are only available in API 21+. The methods we are calling on the Fragment // ARE available in the support library (though they don't do anything on API < 21) if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) < details.setSharedElementEnterTransition(new DetailsTransition()); details.setEnterTransition(new Fade()); setExitTransition(new Fade()); details.setSharedElementReturnTransition(new DetailsTransition()); >getActivity().getSupportFragmentManager() .beginTransaction() .addSharedElement(holder.image, "sharedImage") .replace(R.id.container, details) .addToBackStack(null) .commit(); 

Вот и все! Простой способ реализации анимации переходов между двумя фрагментами готов!

• Android
• Fragment transitions

• Разработка мобильных приложений
• Разработка под Android