Android activity intent animation

Создание анимаций переходов между Activity в Android

Начиная с Android 4.4 в арсенале разработчиков появился дополнительный инструмент для создания анимаций — Transitions Framework. Изначально он предназначался для создания анимаций изменения состояния приложения путём манипулирования несколькими View. С выходом Android 5.0 набор доступных для использования анимаций был расширен, чтобы соответствовать представленной тогда же концепции Material Design.

Transitions Framework позволяет быстро и безболезненно создавать различные анимации. Поэтому в процессе работы над iFunny было невозможно пройти мимо этого инструментария. Вниманию читателей предлагается частный случай использования Transitions API — создание анимации перехода между Activity с эффектом «бесшовности».

С визуальной точки зрения представленные в Transitions Framework анимации переходов между Activity можно условно разделить на два типа: обычные анимации и анимации с общим элементом. Концепт анимации с общим элементом продемонстрирован на честно украденном с сайта developer.android.com рис. 1. На нём в роли общих элементов выступают аватар и имя контакта.

Рис. 1. Анимация перехода между Activity с общими элементами

Но никто не любит длинные вступления, поэтому сразу перейдём к рассказу о том, как создавались анимации данного типа в приложении iFunny. В качестве первого примера рассмотрим анимацию, показанную на рис. 2. Для её использования нам потребуется Android версии 5.0 и выше.

Рис. 2. Анимация перехода между Activity на экране аутентификации пользователя

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

Первым шагом к созданию подобного перехода является, как ни странно, выбор этого самого элемента и определение его местоположения в вёрстке обеих Activity. После этого в описание каждого View, отображающего выбранный элемент, нужно добавить атрибут android:transitionName, а также назначить им android:id, если таковой отсутствует.

В нашем случае это обычные ImageView следующего вида:

Здесь стоит отметить два важных момента. Во-первых, в обоих ImageView необходимо установить одинаковые transitionName, что логично. Во-вторых, коль скоро мы используем ImageView, то и содержимое у них должно быть одним и тем же, поскольку использование двух отличающихся ресурсов может привести к неожиданным последствиям (как минимум к морганию анимируемого View в начале и конце анимации).

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

Примечание. Под «второй» подразумевается запускаемая Activity, переход к которой должен быть осуществлён, а под «первой» — запускающая Activity.

Делается это следующим образом:

В приведённом листинге:

• R.id.auth_logo — ImageView из первой Activity, используемый в анимации;
• activity — первая Activity;
• R.string.email_auth_transition — метка, ранее оставленная в вёрстке обоих ImageView;
• SecondActivity.class — вторая Activity.

И сейчас внимательный читатель может испытать недоумение: во вступлении речь шла об использовании API level 19, в примере фигурировал API level 21, а в листинге выше стоит ограничение на API level 22. К сожалению, при написании кода выяснилось, что анимации перехода с общим элементом могут вести себя некорректно на телефонах c API level 21. Проявляется это в виде подтормаживаний анимации в целом и артефактов на анимируемом View в частности. Если вы уже знакомы с темой, знаете причины подобного поведения и/или способы решения описанной проблемы — расскажите нам об этом в комментариях.

На третьем шаге необходимо описать анимацию перехода, т.е. указать путь, проходимый анимируемым View, и трансформацию самого View. Для этого создадим отдельный файл projectName/src/main/res/transitions/email_auth_transition.xml со следующим содержимым:

Немного теории. Тег transitionSet предназначен для описания сразу нескольких трансформаций, применяемых к анимируемому View. Параметр transitionOrdering отвечает за порядок применения этих трансформаций. В нашем случае они применяются одновременно. Существует несколько типов готовых трансформаций, представленных в Transitions Framework. С полным списком можно ознакомиться на этой странице. Мы же остановимся на двух конкретных: changeBounds и changeImageTransform.

Первая предназначена для трансформации размера View. Вторая работает только с ImageView и в связке с первой позволяет изменять не только размер, но и форму ImageView. Использовав данные трансформации, получаем на выходе анимацию изменения размера изображения, представленную на рис. 2. Если не указывать тип движения анимируемого View, то он будет двигаться по кратчайшему пути. Более интересный способ передвижения рассмотрим во втором примере.

Последним шагом создания анимации является её объявление в темах обеих Activity. Для этого отредактируем описание тем следующим образом (или создадим новые в папке projectName/src/main/res/values-v22/theme.xml):

• android:windowActivityTransitions разрешает выполнение анимации перехода;
• android:windowSharedElementEnterTransition указывает на файл с описанием анимации перехода от первой Activity ко второй;
• android:windowSharedElementExitTransition указывает на файл с описанием анимации перехода при возвращении из второй Activity в первую.

Следует отметить, что для версий ОС ниже 5.1 необходимо создать темы с идентичными стилями, чтобы избежать вполне ожидаемых последствий в виде падения приложения. Например, поместим их в файл projectName/src/main/res/values/theme.xml:

Итак, для создания анимации перехода от Activity к Activity необходимо:

1. Описать анимации (в нашем случае в xml-файле);
2. Добавить эти анимации в xml-описание темы Activity;
3. Пометить анимируемый общий элемент (View) в разметке;
4. При запуске второй Activity указать в параметрах запуска, что для неё необходимо задействовать анимацию перехода.

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

Рис. 3. Анимация перехода из комментариев к профилю пользователя

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

В чём же сложность второго примера? В первом случае использовалось изображение из ресурсов самого приложения, а тут — картинка загружается из сети. К тому же для комментариев изображение аватара пользователя берётся в более низком разрешении, чем для профиля. Поэтому требуется не только дать второй Activity доступ к изображению, используемому в первой, но и по завершении анимации подгрузить требуемое изображение в более высоком качестве. Так и получается две проблемы.

Для решения первой можно было бы собственноручно закэшировать изображение на диск или же передать его адрес в параметре второй Activity. Однако решение данной проблемы переложили на используемую в приложении библиотеку для загрузки изображений — Glide. При загрузке изображения достаточно просто добавить параметр diskCacheStrategy(DiskCacheStrategy.SOURCE), и оно будет закэшировано самой библиотекой (актуально для Glide версии 3.x). Следовательно, при повторном обращении к данному ресурсу из второй Activity будет использоваться кэшированный файл, что поможет нам избежать моргания анимируемого ImageView.

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

Здесь происходит следующее:

1. С помощью getSharedElementEnterTransition().addListener() задаётся Listener для анимации появления Activity;
2. В методе setAvatar() производится попытка загрузки и установки аватара (который уже лежит в кэше).

Рассмотрим, как именно реализован Listener:

В методе onProfileUpdated() мы обновляем содержимое профиля, в т.ч. и аватар.

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

Рис. 4. Анимация возвращения из профиля в комментарии

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

В целом можно сказать, что Transitions Framework является простым и мощным инструментом для создания анимаций. Он не ограничивается только анимациями перехода между Activity — в статье был рассмотрен лишь частный случай его использования. Также стоит отметить, что помимо предоставляемых трансформаций имеется возможность создавать свои собственные, но это уже совсем другая история, достойная отдельного поста.

Источник

Shared Element Activity Transition

Traditionally transitions between different activities or fragments involved enter and exit transitions that animated entire view hierarchies independent to each other. Example of such transitions are a fade transition, slide transition or the newly introduced explode transition.

Default Activity Transition (without Shared Element Activity Transition):

However, many times, there are elements common to both activities and providing the ability to transition these shared elements separately emphasizes continuity between transitions and breaks activity boundaries as the user navigates the app.

The nature of this transition forces the human eye to focus on the content and its representation in the new activity instead of the actual activity frame sliding or fading which makes the experience a lot more seamless.

Note that the shared element transitions require Android 5.0 (API level 21) and above and will be ignored for any lower API versions. Be sure to check the version at runtime before using API 21 specific features.

Enable Window Content Transitions in your styles.xml file:

Assign a common transition name to the shared elements in both layouts. Use the android:transitionName attribute.

For e.g. in MainActivity.xml :

Note that it doesn’t matter if the android:id is different or where in the layout hierarchy the source and target views exist.

Start the target activity by specifying a bundle of those shared elements and views from the source.

Thats it! Specifying the source view along with the transition name ensures that even if you have multiple views with the same transition name in the source hierarchy, it will essentially be able to pick the right view to start the animation from.

To reverse the scene transition animation when you finish the second activity, call the Activity.supportFinishAfterTransition() method instead of Activity.finish() . Also, you will need to override the behavior of the home button in the ToolBar/ ActionBar for such cases:

Sometimes, you might want to animate multiple elements from the source view hierarchy. This can be achieved by using distinct transition names in the source and target layout xml files.

Note: By default android.util.Pair will be imported but we want to select the android.support.v4.util.Pair class instead.

Be careful to not overdo transitions between shared elements. While it can make sense to have one cohesive unit animate from one screen to another (which may or may not contain multiple shared elements), having too many shared elements will result in a distracting animation which makes the experience more jarring.

In Android L, shared elements transition defaults to a combination of ChangeBounds, ChangeTransform, ChangeImageTransform, and ChangeClipBounds. This works well for most typical cases. However, you may customize this behavior or even define your own custom transition.

The change_image_transform transition in this example is defined as follows:

To enable window content transitions at runtime instead, call the Window.requestFeature() method:

Often times you want to exclude from the animation sequence the use of the status bar, ActionBar, and navigation bar, especially if shared elements will be drawn on top of them (see this Google post for more details). You can exclude these elements by add a tag and specify the ID of the elements to exclude:

See this official guide on Defining Custom Animations for more details.

If the shared elements require data loaded by an AsyncTask, a Loader, or something similar before their final appearance within the called activity can be determined, the framework might start the transition before that data is delivered back to the main thread.

To overcome this, the Activity Transitions API gives us a way to temporarily delay the transition until we know for sure that the shared elements have been properly measured and laid out.

To temporarily prevent the shared element transition from starting, call postponeEnterTransition() (API >= 21) or supportPostponeEnterTransition() (API onCreate() method. Later, when you know for certain that all of your shared elements have been properly positioned and sized, call startPostponedEnterTransition() (API >= 21) or supportStartPostponedEnterTransition() (API OnPreDrawListener , which will be called after the shared element has been measured and laid out.

If you are running into issues with shared element transitions such as unreliable transitions, the problem likely lies with the order of operation or race conditions associated with loading asynchronous data. For example, if the shared element relies on an image being loaded by Picasso, then we need to properly time the transition to animate reliably:

Check out this article for a detailed look at scheduling postponed transitions.

The animation framework does not handle animations when your calling Activity is not in the onResume state. onActivityResult is called prior to onResume in the lifecycle, this means if we would like to start our Activity with our shared element transition we need to call it during or after onResume. We can do this with a simple flag that is set in our onActivityResult and then checked in onResume as follows. Remember to reset the flag once launching your new Activity. See this Stackoverflow post for more info.

Leveraging shared element transitions works with fragments too in a similar way as was shown above for activities.

Note that the shared element transitions require Android 5.0 (API level 21) and above and will be ignored for any lower API versions. Be sure to check the version at runtime before using API 21 specific features.

Within two fragments let’s assign a common transition name to the shared elements in both layouts. Use the android:transitionName attribute and put the view inside both FirstFragment and SecondFragment :

Add a transition to the res/transition folder named change_image_transform.xml with the following:

Now within the activity, we can trigger the transition as part of any FragmentTransaction :

Note that we need use methods on the exiting fragment such as setSharedElementReturnTransition and setExitTransition . On the entering fragment, we call setSharedElementEnterTransition and setEnterTransition . Finally we need to find the instance of the shared element and then call addSharedElement(view, transitionName) as part of building the FragmentTransaction . Additional external resources for fragment-to-fragment shared element transitions include:

With that you can apply these handy transitions to fragments as well as to activities.

Источник