Alternative to overridePendingTransition() - Android - android

I just discovered the android overrivePendingTransition() method. It works fine but I have the following problem :
In the Settings/Dislpay menu, you can choose to show no animations, some animations or all animations, and the method only works when it is set to all animations.
Can I bypass that ?

The settings you're talking about are user preferences. If one of your users wanted to turn off all animations, why would you want to find a workaround to continue showing animations in your app? It doesn't seem very user-friendly.
At any rate, overridePendingTransition is used to animate between Activities, as opposed to Views which is part of why you can turn them off, and was introduced in Android 2.0. There isn't another SDK method available that does the same thing; however, you can try using a LayoutAnimation to animate the layout you provide for each Activity you're creating. It wouldn't be exactly the same as overridePendingTransition, but I think it's going to be one of the closest things you'll find to an alternative.
your_animation.xml:
<layoutAnimation xmlns:android="http://schemas.android.com/apk/res/android"
android:animation="#anim/THE_ANIMATION_YOU_WANT_TO_USE" />
your_layout.xml:
android:layoutAnimation="#anim/your_animation"

Related

Activity Return Transitions - Shared Elements - Killed Activity

Library used: appcompat-v7:22.2.1,design:22.2.1
Theme used:
Devices/Android versions reproduced on: Nexus 6
Issue: Return activity quickly redraws/appears then fades in with desired behaviour, only with "Don't keep activities alive".
I am wondering if this is a bug or expected behaviour. I have a very simple setup. Activity A contains a toolbar wrapped in an AppbarLayout and CoorindinatorLayout. The toolbar contains a Cardview and a TextView. Upon click of the TextView, Activity A launches Activity B. I am using shared elements and passing them through as Option's via ActivityCompat.StartActivity(bundle, options);
My shared elements work perfectly, even after device rotation. After reading about how I can PostPoneEnterTransition and combo it up with PreDrawListeners I am able to successfully achieve the desired transition even after rotation. My actual activity contains a Viewpager / TabLayout and 2+ fragments but for simplicity sake, I've stripped it back in the video as well as to see if something else was causing this issue.
While dealing with rotation and postponing of the enter transition back to Activity A, I decided to open developer options and check "Don't keep activities alive". The video depicts the app running with that option enabled. If you look closely, you can see upon return to Activity A, it is completely drawn and hidden very quickly and then the fade in occurs as well as the shared element transition.
I've also excluded the navigation bar and status bar in the animations so that I don't see those flicker (redraw redundantly).
My questions are:
Is this a bug, or am I missing a step in order to prevent this.
Why would the app/transitions behave differently with "Don't keep activities alive" vs a plain old device rotation (destroy/recreate).
I've noticed by playing around with some google apps, this behaviour does not occur, or at least that I could find. Is there a way to concretely check if the activity I am returning too is "completely destroyed" so I can cancel the animation? Or do something different?
I can include specifics and code samples if required but my setup is very simple, and reflects a bunch of boilerplate examples from the Android documentation / Stack-overflow.
Sorry I meant to respond to this earlier. What I ended up doing was recreating the example in a completely fresh project following code samples and tutorials as best I could. First making it work with a single image view, and then of course adding my custom layout which was a floating search bar. Everything worked as expected. I went back and reviewed my actual project source (which was littered with different attempts and commented out code while trying to debug this issue) and cleaned it up. I can't say for sure, but I believe it came down to two possible issues:
"Unless you do something unusual..." - Most likely I "was" doing something unusual by the time I created this issue do to my debugging efforts and lack of full comprehension of the shared elements transition framework and lifecycle.
I think what was happening was the shared element transition was failing do to views not being mapped properly. I was excluding the statusBarBackground inside a transition defined in XML. My statusBarBackground was set to transparent so that I had the nice overlay effect for an expanded drawer layout. I found out that while trying to add the statusbarbackground as a shared element via code, the view was actually null resulting in a crash (NPE). As well as I had set a background color (instead of transparent) to my drawer layout. I can't say for sure, but a combination of these mistakes lead to the strange behaviour.
To conclude, I would say that this issue should be closed and everything is working as intended. It would be nice to get a little more insight on handling a transparent status bar as a shared element.
Is this a bug, or am I missing a step in order to prevent this?
No. Everything is working as intended.
Why would the app/transitions behave differently with "Don't keep activities alive" vs a plain old device rotation (destroy/recreate)?
It doesn't. When everything is setup proper and your timing and mapping of shared elements is correct, "Don't keep activities alive" is a concrete way to test your transitions against configuration changes.
I've noticed by playing around with some google apps, this behaviour does not occur, or at least that I could find. Is there a way to concretely check if the activity I am returning too is "completely destroyed" so I can cancel the animation? Or do something different?
This is because the Google dev's did it right :)
For anyone struggling with shared elements, here is a bit of advice.
Start small. Use a single view first and confirm you are getting the correct behaviour in all circumstances, even after rotation and config changes, then you can add complexity.
Use SharedElementCallback to debug your transitions. You can check which views are mapped, which view failed etc.

Android Card flip Animation

Im trying to have a card flip animation between activities. I looked at the example given by google but i only got more confused on how it works. I want to be able to click a button and have the card flip animation between two activites. Is there any examples on how to do this using a button and two activities?
As per my knowledge,3D transitions are not supported by window manager.
Behind this there is a reason, that to achieve FLIP animation both views must be loaded to show mirror effect. While activities are stand alone processes in Android.
So If you want such animations better you use fragments rather activities.
But If you still want it with activities. Here is the alternative Click
You may again go through the developer site. They have used fragments. With the use of fragments it is easily achievable. You need a one activity and other fragments to achieve the desire functionality.

How do I learn to design a UI like this?

I was recently using the app Secret and was observing the amazing user-interface that it has. If you are opening Secret's webpage, please scroll down a little to see the UI.
Being someone who is still a novice in Android and wants to learn, I would like to ask how that UI has been designed. I could ask a lot many questions in this one post but I will limit myself to just one for now.
Whenever you click on one of those tiles, it opens up and shows the comments for that particular tile. The other tiles below and above disappear. When you click on the tile again, it smoothly animates back to its position and the tiles above and below come into view. How is this achieved?
What have I tried so far? Nothing, because it is a "where do I begin?" question.
This is probably an instance of a custom activity transition (and a particularly well polished one).
In general, you can use the overridePendingTransition() to specify an animation that must be run when the current activity is changed (a classic example is sliding in a new Activity from a direction, while the previous Activity exits in the opposite direction). However, these transitions generally do not share UI elements.
Chet Haase has done a few DevBytes (in particular this one) to "simulate" an activity transition that shares an UI element (i.e. a view) between the caller and called activities. For example, if you have a Gallery, and you click on an image to show it full-screen, you would probably want the image to "grow" smoothly until it occupies this new position. The trick to achieve this is to actually disable the standard transitions entirely and include in the Intent used to start the activity the information about the current position and dimensions of the view that you want to "share":
Intent subActivity = new Intent(this, PictureDetailsActivity.class);
subActivity.putExtra(PACKAGE + ".left", screenLocation[0]);
subActivity.putExtra(PACKAGE + ".top", screenLocation[1]);
subActivity.putExtra(PACKAGE + ".width", v.getWidth());
subActivity.putExtra(PACKAGE + ".height", v.getHeight());
startActivity(subActivity);
overridePendingTransition(0, 0);
Therefore, the new activity can extract this data, and with this information and the knowledge of where on the screen the view should end up, can build and execute an animation that simulates the desired effect.
This technique can be difficult to implement if you want a complex animation, so in Android L this was baked into the platform itself: Activity Transitions can handle this automatically and provide a few built-in animations to act on the remaining (i.e. non shared) views. For example, the explode transition seems to be very much like the one you describe.
Regarding layouts:
You might find it helpful to use hierarchy viewer, which offers a function to capture the layers of the UI and store them in a Photoshop file. This gives you a good idea how the layout of a particular app you are was created and what kind of views were used.
Regarding animations:
Checkout videos by Chet Haase and Romain Guy who discuss graphics and animations in detail.
You can start with the Android training guides.
This one is an overview of designing with media and animation, but this one uses a ViewPager to achieve the effect you want.

Create android actvity with divider between 2 views

I don't know exactly how to describe it, but I want to create something like this:
Basically it is an activity with 2 views, and you can reveal/hide more of one view by sliding the "slider" up and down.
I have an idea of how I would implement this on my own, but I am wondering if there is some built in widget for this. The inspiration came from my Sony Experia, where I swipe down to reveal a drawer of notifications.
I thought maybe it was the SlidingDrawer, but that has depreciated in API 17.
There is no Splitpane or something similar in the current Android API (19 at writing).
But there are existing user created views you could use. For Example this one.

CoronaSDK Two scenes on the screen at the same time

I'm using the Corona SDK and I'm still fairly new to it. I am using the Storyboard api to navigate scenes. I have a main page with a button on it. The button listener uses gotoScene to open another scene that has a tab bar. When I run the app, the button works, but the new scene is created on top of the first scene. The problem is that both scenes are being displayed simultaneously. I tried implementing destroyScene with a simple print("destroyScene called") to see if it was even being called and it wasn't. Does anyone know what I'm doing wrong? I feel like I'm missing some fundamental functionality of the storyboard api.
you can find all the answers to your questions about Storyboard API in Corona SDK by referring this sample-code
Destroy Scene is only called when you run out of memory.
You need to use exitScene to turn off the visibility of the things instead (also remove inside exitScene any event listener, so you don't trigger it by accident, and add those back on enterScene).

Categories

Resources