A very odd issue that I'm not able to diagnose or figure out, so I'm hoping that someone else has seen this and might have a clue as to what's going on.
All Activities inherit from AppCompatActivity.
The scenario is as this:
Activity 1 (extends AppCompatActivity) starts Activity 2
Activity 2 performs some action after user input and then exits via onBackPressed
Activity 1 displays a Snackbar based on the action performed with Activity 2 as a means of confirmation
The problem is that the Snackbar doesn't show at all or is delayed and flickers on as it is dismissing. If I touch the screen and interact with Activity 1, the Snackbar becomes immediately visible.
I also turned on "Show layout boundaries" via the Developer Options and I can see that the Snackbar isn't actually being displayed (invisible) until I touch the screen (or until it starts to animate out).
I created a sample application and it seems to be working fine there, but no such luck in our production application. Activity 1 itself is displaying a lot of information and content in a ScrollView, but I wouldn't think that this would cause an issue, unless there are rendering passes that are happening that I can't tell and that is causing the delay in display.
I've created a project that you can use to demonstrate this problem. I believe that this is a bug, and you can work around it by not using your own transitions. Though I also believe that not all transition animations will cause the issue. I think the hold animation in this case is the culprit.
Here is a brief outline of the issue:
Activity 1 and 2 both have Scroll Views with a bunch of content.
Activity 2 opens Activity 2 using overridePendingTransition( slide_up, slide_down), though this isn't necessary for this example.
Activity 3 displays content and then is closed:
a) using overridePendingTransition( hold, slide_down ). In order to see the Snackbar in this scenario, you will need to touch the screen and interact with Activity 1.
b) using no Transition. The Snackbar should be visible.
My solution to this issue was to remove overridePendingTransition. Please comment if you have additional ideas about this.
Related
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.
I noticed something strange today and i'm not sure the best way to describe it.
I have two activities (A and B). I'm on A and start a new intent for B. I override the pending transition to be a slow slide up. This part is fine.
When B is sliding up I noticed that I can still tap on the screen where B's buttons would be and use their actions. (example, there is a close button to close B. When I tap on it's destination area it will close B even though it hasn't completely gone up).
My current solution is to disable all of the buttons until the animation is done. This is working fine, however I'd be interested to know if there is a better (more standard) solution. If anyone can explain (and confirm my suspicions) then that'd be a nice plus!
This is the expected behavior. Android is simply animating a transition and not actually moving the views from one physical location to another.
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?
I have tried and tried to get a transparent, floating Activity to show up (as an overlay), but allow whatever is behind it to still show AND update. Right now it seems that if the Activity behind mine is closed or a new one opens (could be either in this case), the new underneath Activity does not shine through my Activity to the user.
I have tried every combination of Flags I can come up with, and at this point I'm assuming Flags are not the answer. Can anyone help me find the proper code to do such a thing?
Before anyone asks, I have a valid use case for this type of Activity; no, I don't plan to annoy the user with it.
As far as I know, this is not possible. It should be possible to create an activity using the theme Theme.Dialog or Theme.Translucent (see http://developer.android.com/guide/topics/ui/themes.html) to have whatever activity is beneath it still show at least partially. The problem is, is that the Activity below will be Paused (it's onPause will have fired, but it's onStop will not have) and I don't believe it is possible in any way to have it run any code.
I have not investigated in making a transparent Activity but I don't think it's possible in an Activity way. This seems to be logical since even if you have a transparent Activity it's still relying on the View inside it - the View makes the transparent part, not the Activity. This means you're probably gonna end up with a transparent View instead.
If you have a "front" Activity with a transparent View and then a "back" Activity, the "back" Activity would not be visible to the user - and that's because you're in another Activity.
So, the correct way is to use a transparent View.
It is possible to update the activity below by implementing a Broadcast receiver on it, and sending Broadcasts from whenever you want.
Sorry, I know that this topic has been covered a bit. I've read the related posts and am still a bit confused. I am working on an app that while the prototype will have 3 main screens, it will eventually have dozens. Each screen will present either dynmically changing status or take user input. To visualize, it is required to be laid out similar to how MS Word or a typical PC is. It has a status bar at the top and a navigation bar at the bottom that is common to all screens (slight tweaks for some screens, like different icons) in the middle is what I would call a view pane that needs to be updated with a applicable layout.
The status, nav bar, and each screen are defined in their own layout xml file. For my first swag at it I just used a ViewFlipper and loaded the 3 screen layouts into it. However that means that currently I have one main Activity which will not be maintainable as I continue to add screens.
It feels right to me that each screen layout should have an associated Activity class that understands how to control that screen. I need to figure out how to load that into the center pane dynamically. However I thought I read in another post that using multiple Activities can be a CPU and RAM drain.
Currently I tried making one of the screens it's own Activity and kick that off from the main Activity by creating an Intent and than calling startActivity. However that causes the new screen Activity to reside on top of the main Activity. The interesting thing is that then pressing the back button dismissed that activity and returns me to the main.
So far I haven't figured out how to setup having a different Activity control what happens in the center pane.
If I continue down the multiple Activity path, should my main Activity be inheriting from ActivityGroup?
Are using View classes more applicable in this case?
I know this has been a long post. I'd appreciate any advice.
Thanks!
CB
As you noticed, Android will implicitly track a stack of started activities in a task, and the 'back' button ends the top one, reactivating the next one down. I would advise you to think about which kinds of things the user might expect the back button to do, and make it so that activities are separated along those lines.
I haven't played with ActivityGroup so I can't advise you there. If you go with completely separate activities, you can have them all use the same "shell" content view with the common nav/status bar. Have a superclass or utility class handle populating and managing that from there. Then use a a LayoutInflater (you can call getLayoutInflater()) to fill in the middle with your Activity-specific view.
If you want one of the activities to have multiple screens, you might still end up with a ViewFlipper in the center slot. Again, you want to have an Activity transition wherever you want the user to be able to go "back"; that also means you may NOT want to have a change of activities in cases where screens are closely related or part of the same logical thing-being-done. (You can override the back button's behavior, but unless you have a good reason to, it's best to just arrange the app so that Android's basic setup helps your app's UI rather than working at cross purposes.)
If you want to use activities in the fashion you talked about, you might look into using a tab activity. It actually works in the way you want, you just need to hide the tab widget and put your navigation bar there instead. Or, you could go a little deeper and make you own similar tab-like ActivityGroup like Walter mentioned if you have more time.
You could use a view pager with fragments to accomplish the flip between the different views but still allow your activity to have full control over it. The activity can control the menus while the fragment controls your viewing area. This way your back button will properly dismiss the activity containing all pages related to the activity instead of walking down the stack.