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).
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.
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.
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.
I am implementing a animated book in Android and the animations are defined by an XML (not an Android XML). The images are positioned in fixed positions and when user touches in a element on the screen, the app plays a sound and animate the imagebutton, changing the image src and positions (X and Y).
I want to know how can I do that. As images dot not have the same size, I think the sprites solution is not a good way to solve it.
Its like the image 2:
Thank you
There are two types of animations:
View Animation and Proprety Animation.
The view animation can only animate View objects. It also lack a variety of animations, since it can do only stuff as scale, rotate, move... It cannot change background color, for example. Also, the dissadvantage of the View Animation is that it only change the position of where the View object is DRAWN. Phisically, it still stays in the same position. That's why the button is unclickable, after the View Animation is finished upon it.
Property Animation, in the other hand, can animate both View and non-View objects and it doesn't have constraints as the View Animation. When objects are moved, for example, with the property animation, they are not just drawn on some other position on the screen, but they are actually MOVED there.
Now, Property Animation is a lot more complex to write than the View Animation, so if you don't really need all the advantages of the Property Animation, it is suggested to use View Animation.
Source: Property vs ViewAnimation
Tutorial and SupportLybrary up to API 1: Nine Old Androids
Is it possible to rotate views in XML with APIs previous to Honeycomb - maybe with the support package? Or is the only way to create a custom class, like described here Vertical (rotated) label in Android
Edit: What I need is a statically rotated view (specifically a TextView, but I guess it's enough to know how to do it with a View). Starting with honeycomb there's a rotation attribute which can be used in XML. I need something like that.
The only thing I have found until now is use an animation with duration 0 but this still moves a bit at start and I don't want that. I tried setting the views invisible and attaching a listener to the animation which makes them visible on animation finished callback, but that made strange results... that changed the position of the views, for some reason.
The best way is with the custom subclass implementation that you linked to, where you can rotate the canvas and resize the view appropriately. This ensures that the view bounds are also set to match the text that is drawn.
The only method of transforming views externally prior to HC is the animation framework, and applying an Animation to the view with a duration of 0 and fillAfter set to true will work, but you may notice flickering on some devices as often the view will render normally on its first frame and then animated to its final position from that point onward. You can work around this by hiding the view and displaying it a bit late...but you can see how hacks are starting to stack up.
In addition, doing an Animation prior to HC will not transform the view bounds themselves, so you won't be able to neatly pack other views around this one because its position from a layout perspective will still be the rectangle calculated for the horizontal (non-rotated) text.
The simple subclass is definitely the preferred method.
HTH
Is it possible to rotate views in XML with APIs previous to Honeycomb
There is RotateAnimation. However, depending on what you are trying to accomplish, that may not meet your needs.