Users are, and have always been, drawn to visual elements of an interface, particularly when that visual element is something animated. There have been a lot of studies, typically conducted by marketing departments for larger companies, that highlight the importance of moving visual design, such as in videos or animation and how they interact positively with human brain chemistry in a way that is appealing from a marketing and design perspective.
The fact is that animation draws attention to itself in the minds of most users, and including animation as a part of an app’s design can greatly increase its appeal and functionality. An example of this is a form where users can search with various terms and then hide the form when the search is executed, leaving the search results in its place. The idea behind most animation is to create a kind of visual continuity. It is meant to promote a workflow and keep the user’s attention directed in a way that meshes well with how the app is intended to work. This article is an overview of how to add animation to your Android app in order to promote workflow and appeal to users.
For the purposes of including animation in its apps, Android features the transitions framework, which is a tool that lets you animate changes between two view hierarchies, such as sub menus or different halves of a swipe menu. It includes built-in animations for common types of animation effects that you might need, like swiping menus, fading things in and out, and moving icons around. In general, the purpose of the transitions framework is to help you animate these changes between different levels of an app’s function, and to do so in a way that is smooth and natural. To that end, there are a few features that it has, such as group level animations, which apply one or more animation effects to an entire view hierarchy, transition and built-in animations that run animations based on changes in property values or that are attached to common effects such as a fade out or movement. The transitions framework also includes resources file support and lifecycle callbacks for more particular control over the hierarchy change process.
In general, the process for putting animations into an Android app is to first create a scene, then apply a transition, and then, if you want, creating a customized transition with more particular effects than the standard type. This section of the article is an overview of the process for each of these three steps.
A scene is essentially a storage unit for a view hierarchy, which includes all of its property values, settings, and looks.
It is a static image that represents the beginning or ending point of a transition framework, which changes between the starting and ending scenes over the course of its run time. Creating a scene can be done by instancing directly from a layout resource file. Using this technique makes a scene that is relatively static and attached to the layout of the app’s general user interface rather than anything separate, which is covered in the customized transitions section below.
You can also define scenes by generating them from layouts or by coding them directly. The end result, however, is a stable image of the app before and after a transition occurs. You can also create scene actions which serve as custom actions that run when entering or exiting a scene. These can animate views and objects that aren’t in the same hierarchy, or they can animate things that a transitions framework otherwise couldn’t touch, such as ListView objects.
When applying the transitions framework, the animations create a series of frames that show the change between the original and ending scenes. The framework for the transition contains the information about how the animation objects function and how they are controlled through the transition process. There are, roughly speaking, three different types of standard transitions.
- The first is an AutoTransition, which is the most standard transition type. It fades out the old scene, moves and resizes the scene, and fades in the new view, precisely in that order. It’s kind of boring, but it’s functional and usually suits most apps.
- The second is the Fade, which fades the old view out and the new view in simultaneously for a cross-fade type of feel that’s more instant and meshes the two scenes more directly on top of each other.
- The last type of transition is ChangeBounds, which doesn’t actually fade anything, but instead moves and resizes views for the particular functionality of not removing things but still diminishing one UI feature in favor of another. You can also create transitions from a resource file or from an instance in your code.
Creating a custom transition is something that lets you use an animation or process that isn’t available in the standard transition types discussed above. Like the standard transitions, a custom transition is a series of frames that are displayed between one scene and another. Unlike standard transitions, however, you have to provide customized code to capture the property values and generate the animations for whatever you want to do that is non-standard about the animation. There are a lot of ways to accomplish this and the options for what you can do with it are practically limitless in terms of configuring the view and putting in whatever custom animations or actions you’d like. Although there are still considerations of memory and loading speed that need to be taken into account, but there really are very few constraints on using custom animations to do a lot of things.