It looks like both Animations and Animators allow me to animate properties (position, opacity, scale, rotation, etc) on objects, and I'm having a hard time differentiating between the use case for both. When should I use an animator versus an animation and vice versa?
Animations are older versions of Animators. Animators where introduced in 3.0 to help overcome some short-coming that Animations have.
Animations only change the visual representation of an object. This is fine if you're just changing opacity, but it causes issues when you translate, rotate, or scale objects. In the old days before Animators, if you translated the object, you had to perform a re-layout with the new coordinates. It could be rather difficult depending on where the object moved.
Animators on the other hand change the physical properties of the objects. This means that if you move a View to a new location, the touch coordinates will be mapped at the new location without any other intervention.
Personally, I don't use Animations much anymore unless I'm developing at API's 2.3 or less. Thankfully that's becoming less of an issue. There are also some old classes that still use Animations API especially when it comes to using xml resources such as the android.support.v4.app.FragmentTransaction class (the normal FragmentTransaction supports Animators instead).
As a side note, the project NineOldAndroids was developed to mimic functionality of Animators but using Animations so you can make apps that work all the way to 1.6.
An Animation object animate the view's image. If you use this for example, to move a button around the screen you will not be able to click on it at the new visible position because it was not truly moved, but only his bitmap representation was translated. You will also not be able to change the proportions of it since you are making modifications to a bitmap. If you use xml files, place them at anim folder.
An Animator object animate the view's property (like the margin or width). If you use this to move a button around the screen you will be able to capture clicks on it in the new visible positions. If you use xml files, place them at animator folder.
If you only need cosmetic effects, like fade in or small appearance translation, using a Animation will be more efficient because it does not call layout() or measure() methods. If you do need to capture actions like click events, use a Animator.
Related
It looks like both Animations and Animators allow me to animate properties (position, opacity, scale, rotation, etc) on objects, and I'm having a hard time differentiating between the use case for both. When should I use an animator versus an animation and vice versa?
Animations are older versions of Animators. Animators where introduced in 3.0 to help overcome some short-coming that Animations have.
Animations only change the visual representation of an object. This is fine if you're just changing opacity, but it causes issues when you translate, rotate, or scale objects. In the old days before Animators, if you translated the object, you had to perform a re-layout with the new coordinates. It could be rather difficult depending on where the object moved.
Animators on the other hand change the physical properties of the objects. This means that if you move a View to a new location, the touch coordinates will be mapped at the new location without any other intervention.
Personally, I don't use Animations much anymore unless I'm developing at API's 2.3 or less. Thankfully that's becoming less of an issue. There are also some old classes that still use Animations API especially when it comes to using xml resources such as the android.support.v4.app.FragmentTransaction class (the normal FragmentTransaction supports Animators instead).
As a side note, the project NineOldAndroids was developed to mimic functionality of Animators but using Animations so you can make apps that work all the way to 1.6.
An Animation object animate the view's image. If you use this for example, to move a button around the screen you will not be able to click on it at the new visible position because it was not truly moved, but only his bitmap representation was translated. You will also not be able to change the proportions of it since you are making modifications to a bitmap. If you use xml files, place them at anim folder.
An Animator object animate the view's property (like the margin or width). If you use this to move a button around the screen you will be able to capture clicks on it in the new visible positions. If you use xml files, place them at animator folder.
If you only need cosmetic effects, like fade in or small appearance translation, using a Animation will be more efficient because it does not call layout() or measure() methods. If you do need to capture actions like click events, use a Animator.
I'm doing some research in utilizing Android's resource directories appropriately and the following isn't clear to me:
What is the difference between the android animator resource directory and the android anim resource directory?
http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources
Moreover I guess the question I'm asking is what is the difference between property animations and tween animations?
I honestly think Google have done a very good job explaining the differences in their Property Animations API guide (see below).
TL;DR the main differences are:
Tween animations are succinct and allow for the manipulation of no more than the location (translation), size (scale), angle (rotation) and translucency (alpha) of views. The property animations framework is more generic and flexible: It generalizes the former case by allowing for real-time updating of any property (e.g. "foobar") of animations' target-object -- provided it has a setFoobar() method. setScaleX(), setAlpha(), etc. are just a specific case when it comes to views.
Accordingly, implementing tween animations is often easier and the code is more lightweight.
Property animations can be used over target objects of any type, not just views: the only thing that matters is the definition of setFoobar() methods as explained earlier (reflection based method look-up).
Tween animations merely perform adjustments over views' configurations, while property animations effectively modify the object. A common flaw of the former approach is that when using animations for moving views around, the associated clickable area doesn't get updated throughout the animation and gets out-of-sync with the view's effective location on the screen.
To quote from the guide:
How Property Animation Differs from View Animation
The view animation system provides the capability to only animate View objects, so if you wanted to animate non-View objects, you have to implement your own code to do so. The view animation system is also constrained in the fact that it only exposes a few aspects of a View object to animate, such as the scaling and rotation of a View but not the background color, for instance.
Another disadvantage of the view animation system is that it only modified where the View was drawn, and not the actual View itself. For instance, if you animated a button to move across the screen, the button draws correctly, but the actual location where you can click the button does not change, so you have to implement your own logic to handle this.
With the property animation system, these constraints are completely removed, and you can animate any property of any object (Views and non-Views) and the object itself is actually modified. The property animation system is also more robust in the way it carries out animation. At a high level, you assign animators to the properties that you want to animate, such as color, position, or size and can define aspects of the animation such as interpolation and synchronization of multiple animators.
The view animation system, however, takes less time to setup and requires less code to write. If view animation accomplishes everything that you need to do, or if your existing code already works the way you want, there is no need to use the property animation system. It also might make sense to use both animation systems for different situations if the use case arises.
Basically Tween animations are standard animation,
for eg: Scale, Rotate, Translate, etc. (These can be applied to any type of views)
Where are Property Animations as the name suggest are used to change the Property of any View.
For eg: Changing Alpha of ImageView, in lollipop changing translationZ value of fab button, etc.
Hope that clarifies.
Check Android View Tween Animation
A tween animation can perform a series of simple transformations (position, size, rotation, and transparency) on the contents of a View object. So, if you have a TextView object, you can move, rotate, grow, or shrink the text. If it has a background image, the background image will be transformed along with the text. The animation package provides all the classes used in a tween animation.
check this url for Property Animation
The property animation system is a robust framework that allows you to animate almost anything. You can define an animation to change any object property over time, regardless of whether it draws to the screen or not. A property animation changes a property's (a field in an object) value over a specified length of time. To animate something, you specify the object property that you want to animate, such as an object's position on the screen, how long you want to animate it for, and what values you want to animate between.
Try this shorter answer:
res/anim -
Any view Tween Animation (scale, rotate, translate).
res/animator -
Certain views Property Animation (ImageView - change alpha, FAB - set Z-order).
Now i am developing an android app, and there are lots of animations and image resources, the ui design and the logic are also very complex. I tried to use the Tween animation and android layout to implement, but the code is very complex, and i also can't implement some parts of animations. Anyone know how to handle such complex animation at the android platform? Dose android have some tool like as flash tool to design the animation?
In android three type of anmiations.
1)TranslateAnimation
An animation that controls the position of an object
2)ScaleAnimation
An animation that controls the scale of an object. You can specify the point to use for the center of scaling.
3)AlphaAnimation
An animation that controls the alpha level of an object. Useful for fading things in and out. This animation ends up changing the alpha property of a Transformation
Check this for some example.
You can use droidQuery for complex animations. For example, to animate all your ImageViews to double their current size, do:
$.with(this).selectByType(ImageView.class)
.animate("{width:200%, height:200%}",
new AnimationOptions().easing($.Easing.BOUNCE).duration(400));
You can highly customize your animation with chained methods on the AnimationOptions Object - from the duration and interpolator to callbacks for progress, errors, success, and completion, etc.
So I see there are three animation mechanisms in Android:
1) android.view.animation.Animation
2) android.animation.Animator
3) View.animate()
What are differences between those three? How should I decide which to use? What are benefits of using each of them?
You can read more here. In short, there are three types of animations...
View Animations
Simple tween animations.
Can only modify position, size, rotation, and transparency.
Limited to View objects.
Property Animations
Can animate any property of a View (not limited to size, rotation, position, and transparency).
Not limited to just View objects.
Drawable Animations
Animate a set of drawables in sequence.
Similar to sprites.
What you decide to use, is totally up to you and dependent on what you're trying to achieve. With this information in mind, use your best judgement.
EDIT
To clarify on your specific examples...
Animation is a base class for other Animation types like AlphaAnimation. It provides you the necessary methods to create your own Animation if you wish. This class has existed since API 1.
Animator is part of a newer set of animation tools. ObjectAnimator is an example implementation of Animator. I can't say much about it since I did not write it, but Animator and Animation seem to be very similar in that they both provide a way to create animations.
ViewPropertyAnimator is also part of the new animation tools providing an even easier way to animate View objects. It's also optimized to handle multiple animations.
For simple animations, View Animations are just fine. For more complex animations, Property Animations would be the way to go.
Without going into too much detail, I want to be able to 'slide' elements in a ListView similar to the 'slide to archive' feature in GMail. I'm fine with the onTouchListener and all that, my question is regarding the slide animation.
The first two things that come to mind are..
view.setPadding(slideOffset, 0, 0, 0);
and..
view.setX(slideOffset);
The former is very buttery, even on the emulator.
The latter is a bit janky on my Galaxy Nexus.
My questions:
* Regardless of what I've tried, what's the correct way to do this?
Why is setX less smooth than setPadding?
Does one approach conform to Android best practices more than the other?
Are tweened translation animations an option? If so, can you provide a brief example to point me in the right direction please?
Edit:
To be clear, I am attaching an image of the effect I am trying to emulate.
I'm pretty sure the setX() is slower because it affects its parents. When changing the X of a view, it calls the onLayout/onMeasure of the parent every time you update the value. That's because the X value of the child may cause other items on the parent to move, therefor the parent needs to redraw itself.
You can test this easily by extending the ViewGroup and writing to the log on those methods. Then, you can use both approaches, padding vs. setX, and see what happens.
Are you trying to animate the item? Or do you want the user to move it like on Gmail? You can use the ObjectAnimator to handle the "X" value of your item. Combined with a "hardware layer" for your item, it will create a smoother experience. You can find more details about how to do that here: http://developer.android.com/guide/topics/graphics/hardware-accel.html
Yeah, if you're targeting higher APIs, ViewPropertyAnimator is probably a great solution. If you have to support lower APIs, my thought process for implementation would be (and I haven't implemented this myself personally, but this should be good for performance) to:
In your touch handler, once you've determined that the user is "sliding", set the View's visibility to INVISIBLE, and store the drawing cache into a separate bitmap (Bitmap bmp = myView.getDrawingCache();)
Draw that bitmap in the same place as the view, and use the Canvas translate methods to shift the position according to the x-position of the user's touch point.
After the user lets go, translate back (preferably smoothly with an animation), recycle the bitmap, and set the view back to VISIBLE.
Check out the 3 devBytes posted on AndroidDev:
https://www.youtube.com/watch?v=8MIfSxgsHIs&list=PLWz5rJ2EKKc_XOgcRukSoKKjewFJZrKV0&index=12
https://www.youtube.com/watch?v=NewCSg2JKLk&list=PLWz5rJ2EKKc_XOgcRukSoKKjewFJZrKV0&index=11
https://www.youtube.com/watch?v=NewCSg2JKLk&list=PLWz5rJ2EKKc_XOgcRukSoKKjewFJZrKV0&index=11
https://www.youtube.com/watch?v=YCHNAi9kJI4&list=PLWz5rJ2EKKc_XOgcRukSoKKjewFJZrKV0&index=4
https://www.youtube.com/watch?v=PeuVuoa13S8&list=PLWz5rJ2EKKc_XOgcRukSoKKjewFJZrKV0&index=3