I just wrote a simple custom Transition, that animates elevation.
However if I run the transition again via TransitionManager.beginDelayedTransition during the previous one already running, I do observe the previous animator still running, i.e. they both are running at the same time. Visually its not a problem since the second transition always seems to overwrite the value set but the previous animator.
But' this for sure can break in some more complex scenario, so I'd best like to cancel the previous transition animators before starting the new.
Is there an api for that? I see there is protected cancel() but I don't see any of its usage. Also, I've looked at the stock transitions like ChangeBounds and also they don't seem to care
Related
I want to achieve an effect of doing an activity transition where the user can see the previous activity while the transition is happening. As far as I understand, using overridePendingTransition(enterAnim, exitAnim) can achieve this effect, but these animations must be xml files that affect the entire activity (e.g. sliding the entire activity in), but I have a navigational bar that I want to be fixed, so this solution won't work. I also can't make my activities translucent because these animations would ideally be used in the entire app.
What I realized after playing with transitions is that even if you don't specify an activity to be translucent, the Android OS will let you see the previous activity while a transition is happening (e.g. a slide animation on an activity will let you see the previous activity while the slide happens). So I tried setting an "empty transition" by using overridePendingTransition(R.id.keep, R.id.keep) where R.id.keep references an anim xml which is a fade from 1.0 alpha to 1.0 alpha, and doing a view animation in a ValueAnimator in the onCreate of the next activity. The idea is that while the activity transition happens, the OS will let you see the previous activity, and we can take advantage of this time frame of transparency by doing a ValueAnimator on the view of the next activity (after the activity transition happens, the OS won't let you see the previous activity and will show a black screen even if you set the window background colour to be transparent, but the ValueAnimator finishes before that).
The technique I used above works well on Nougat, but it seems for API 23 and below, the UI doesn't change during the empty activity transition even though a ValueAnimator is running, and the ValueAnimator can only update the UI after the activity transition finishes. I didn't really expect this behaviour, so I'm not sure how to fix it.
Admittedly my way of doing view-level animations while being able to see the previous activity is a bit hacky, does anyone know a better way of achieving the effect I want, or some insight into why my technique works on Nougat but not on API below that?
In my app, there are 2 activities. To make the transition seem smooth I animated elements of the first and second activity and disabled transition between the 2 activities. An example of what happens is in the video below:
https://youtu.be/L85HfIUPQuk
The problem as you might see is that, once the animations in the first activity end, there is a period, less than a second but still noticeable, where the screen hangs on the empty white background. Only after that does the second activity and animations start.
The animations are simple alpha and translate effects, nothing fancy.
Any suggestions how to get rid of the hanging period?
You should use Activity Transition.
I think what you need is Shared Elements Transition, since the list from first screen is also on the second screen. Checkout the documentation:
http://developer.android.com/training/material/animations.html
I am starting off some animations as soon as my Activity is created.
However, by the time the Activity is fully visible the animation has already half completed.
I originally had it in onCreate but have now moved in into onWindowFocusChanged and only start the activity once I know onResume has also been called (I'm setting a boolean in onResume)
Is there anyway of knowing when an Activity is fully visible? Or am I going to have to set a 1 second delay? (This seems extremely hacky and potentially still won't work on slower phones/tablets)
If your intention is to display your animations to the user, one way you could guarantee they see the entire animation is by triggering it with an onClickListener() for the whole screen, and just wait for them to touch it?
for layout animations you can use LayoutAnimation, here is the link here
As of API level 21, you can implement the Activity#onEnterAnimationComplete() callback. Unfortunately, it seems like there's no AppCompat equivalent at this point.
What I want to achieve is a flip animation when going from activity to activity.
I've seen a recommendation somewhere on SO, that I should use appropriate layout animation in one activity, switch to next one without any animation whatsoever and then execute the second half of the animation in the second activity.
I guess it could work, not tried it yet. But what bothers me is more general aspect - I believe it should be possible to achieve the same effect with activity transition animation, but...
Somewhere (I guess it was SO, but I can't find it now) I've read that during the activity transition animation the background should always be fully covered by the animated activities. I'm not sure why - I can see the background is always black on all my devices, and making it visible during the animation appears to be harmless.
But perhaps it is not guaranteed? Can someone confirm that requirement? Is it officially stated anywhere?
The main activity of my app is defined in the Android manifest file with the following attribute:
android:theme="#style/Theme.Translucent.NoTitleBar"
This makes the activity transparent, which in turn makes it possible to control the transparency of my app in code by manipulating the main View object (e.g., by invoking setVisibility(View.INVISIBLE) on the main view). This works fine.
However, one undesirable consequence of this approach is that when the app is launched there is no visible response until my main View is displayed. Normally, the default black background of an app's main activity is immediately visible when an app is launched, which provides immediate confirmation that the app is starting to run in response to the user tapping its icon in the launcher. But with a transparent background, the user continues to look through the background at the display from which the app is being launched until the main view is displayed, and so it appears (during that interval) as if nothing has occurred.
Even on a device with mediocre performance (e.g., the Motorola Droid) my view comes up in about one second, which is not too bad. However, on a really slow device (e.g., the G1) it can take almost four seconds. While this is not a disaster, I'd prefer an immediate response so that the user is not left wondering whether the app was in fact triggered.
I have tried removing the transparent theme, which results in immediate confirmation via a black background, as usual. However, I've been unable to set the activity background to transparent in code once the app has been initialized.
I've invoked setTheme() on the activity just prior to calling setContentView() for the first time, passing it a transparent theme, but this does not make the activity transparent.
I've also tried this in onCreate() (again, just prior to calling setContentView()):
ColorDrawable transparentDrawable = new ColorDrawable(Color.TRANSPARENT);
getWindow().setBackgroundDrawable(transparentDrawable);
This also appears to have no effect.
I've also tried using a theme in my manifest that has android:windowBackground set to a drawable that is a mostly transparent PNG, but with some text (e.g., the app's name) superimposed on the transparent background that would provide a cue to the user that the app was loading. Unfortunately, the moment I use a drawable as part of the theme, the background fails to display at all until after the main view is initialized.
All time-consuming initializations are already being done in a worker thread, so I'm not looking for advice on how to accomplish that. The view itself just takes a certain amount of time to display, and while it is fairly quick, nothing beats the instantaneous response of seeing the main activity's background as soon as the app is launched.
Even on a device with mediocre performance (e.g., the Motorola Droid) my view comes up in about one second, which is not too bad. However, on a really slow device (e.g., the G1) it can take almost four seconds.
It should come up in milliseconds. Make sure you are not doing excessive work on the main application thread.
The view itself just takes a certain amount of time to display, and while it is fairly quick, nothing beats the instantaneous response of seeing the main activity's background as soon as the app is launched.
Then initially display something else that is cheaper to bring up (e.g., ProgressBar), replacing it with your regular UI when it is ready.
I've upvoted CommonsWare's answer, because he pointed me in the right direction, which is away from trying to change the transparency of the main activity after it is launched (something I'm beginning to suspect cannot be easily done).
However, that advice cannot itself be the accepted answer, given that it is only a pointer in the right direction.
The answer I decided upon, given this guidance, was to create a splash display. However, I could not find a truly good android splash example anywhere. So, I devised one, and it is working very well for me, and completely solves my problem.
Because creating a splash display is a more general question than the one I started out with, I have placed my detailed description of how that can be done as an answer to a question about how to implement a splash screen, and have linked to that answer below:
Create a true splash screen