1) Regarding the bounty:
Existing answers on SO suggest subclassing the FrameLayout...
If you want to use an ObjectAnimator
you have no choice but to subclass the View
you want to animate. You need to provide the ObjectAnimator
with the necessary getter and setter methods to do its magic as it essentially just calls those getter and setter methods to perform the Animation
.
The question you are linking to (Animate the transition between fragments) is subclassing FrameLayout
to add a setXFraction()
and a getXFraction()
method. They are implemented in a way to set the x value relative to the width of the FrameLayout
. Only by doing this can the ObjectAnimator
do anything else besides animating between absolute values.
So to summarise, the ObjectAnimator
itself doesn't actually do much animating, it just calls getter and setter methods through reflection.
Is there really no way to get the actual screen pixel dimensions (not
just dp) into the xml file?
With an ObjectAnimator
there is no way to achieve that. ObjectAnimators
just interpolate from a start value to and end value. As I explained above, the setter method defines what actually happens.
For example, calling a custom function that returns the width would be
fine, or defining a constant that code can set, having code set said
constant to equal the screen width, then accessing that constant from
the xml would be equally useful.
You cannot insert any value from code into any xml resource. Everything contained in your xml files is compiled into your APK when you build it and cannot be changed at runtime. And that is also an answer to your other question: There is no resource or constant or anything which would be accessible in xml which contains the current screen size. Dynamic values like the screen size of the device the app is installed on cannot be a part of those resources since everything in them is compiled into your app when you build it.
2) Possible Solution: View Animations
One possible solution is to use view animations instead of an ObjectAnimator
. With view animations you can specify fractions instead of just absolute values:
<set xmlns:android="http://schemas.android.com/apk/res/android">
<translate android:fromYDelta="-100%" android:toYDelta="0%" android:duration="1000"/>
</set>
This would animate a View
from -100%
to 0%
of the screen height. In other words from completely of the screen to the position of the View
. You can use it like this:
Animation animation = AnimationUtils.loadAnimation(getApplicationContext(), R.anim.slide_down);
view.startAnimation(animation);
I realise that this might not be of any help to you. There are cases in which one has to use ObjectAnimators
and cannot use view animations. But as long as you are able to use view animations this should pretty much solve your problem.
3) Best practice
What we really should be addressing here is what I think is a misconception on your part. As you already noticed every animation you define in xml has absolute start and end values. Those values are static and cannot be changed after compiling your app.
If you look at how the resources work with the many available selectors and also with dp, sp... then you will realise that it is designed to do one thing:
You can for example define an animation that moves a View
by 100dp. Dp is a measurement of physical size, 100dp will be the exact same physical size one any screen with any pixel density. Through selectors you could alter this animation for devices with smaller or bigger screens where the animation may be moving the View
too much or too little. But you can only fill in static values. Aside from working with selectors you cannot customise the animation for each device.
So you see, the resources are really just designed for anything that's static and unchanging. It works great for dimensions or string translations but sometimes with animations it can be a bit of a pain. As I said above only view animations provide a way around the static nature by providing the option of specifying fractions instead of absolute values. But in general you cannot define anything dynamic in xml.
To futher corroborate this argument look at Google's excellent DevBytes videos about animation:
Then you will notice that not a single animation in those examples is ever defined in xml. Sure one could argue that they don't define them in xml because they want to have an easier time explaining and showing the code, but in my opinion this once again proves one point:
You cannot define an animation in static resources which depends on a purely dynamic value
Since the screen width/height will be different from device to device you need different animations for each device. Only view animations provide a way around that since they allow you to define fractions instead of absolute values. In any other case you are going to need to define the animations programmatically. Fortunately that's not difficult with ObjectAnimators
:
Animator animator = ObjectAnimator.ofFloat(view, View.X, startValue, endValue);
animator.start();
This would animate the x position of the View
from the start to the end value in pixels. You can pass in the width of the View
to animate it like you want to:
Animator animator = ObjectAnimator.ofFloat(view, View.X, -view.getWidth(), 0.0f);
animator.start();
This would animate the View
to slide in from the left. It starts completely off screen and stops in its final position. You could also just do this:
view.animate().x(targetValue);
This would animate the View
from its current x position to the target x value.
But please don't misunderstand me, you should still try to define as much as possible - be it animations or anything else - in the resources. Hardcoding animations or any other value should be avoided as much as possible, unless it's necessary like in your case.
4) Summary
So to summarise:
- You cannot do what you want to do with
ObjectAnimators
without adding the getter and setter methods you need to the View
you want to animate.
- If possible use view animations. With them you can define animations based on fractions of the width or height of the
View
.
- If the above doesn't work or is not applicable to your situation then define the animations programmatically, this will work in any case.
I hope I could help you and if you have any further questions feel free to ask!