I've just started to rebuild my app for Android 5.0, using the appcompat support library. I've just finished implementing a transition featuring shared elements. It seems to work well, untill I add a webview.
I've made a video to demonstrate the glitch.
https://www.youtube.com/watch?v=MuuGZc0Vwow
As you can see, all's fine when I open the activity. When I close it, the glitch occurs. As you can see all elements fade out like they should, except for the webview. Which just hangs there until the animation is over, kinda ruining the entire smoothness of the animation.
How do I fix this? If it could be related to the way I've set things up I'd be happy to share some code.
Thanks in advance.
The reason why this glitch occurs is because WebView extends AbsoluteLayout. By default ViewGroups that are not "transition group"s and that have no background drawable will not be animated by the activity's window content transition. In order to fix the glitch with the WebView, you will need to call webView.setTransitionGroup(true) (or set the attribute in XML using android:transitionGroup="true"). This should cause the WebView to fade away as part of the activity transition instead of simply sitting there until being abruptly removed at the end of the transition.
As for the "Unable to create layer for WebView" error you are receiving, I imagine that is because the transition framework automatically creates a hardware layer for the WebView during the transition and for some reason the framework is crashing when it is trying to create the layer. This sounds like a totally separate issue related to Android's internal graphic pipeline though... I'm not sure I can give you a good answer about why the crash occurs without more information.
This issue is also discussed in the bottom of this blog post.
I have facing exactly this kind of random crash problem in webview in Marshmallow version. I have add attribute android:transitionGroup="true". but crash is happening, after that i have added android:hardwareAccelerated="false" in manifest where that activity is declared. After that random crash has solved in Marshmallow version and lower version too.
Related
We have an app that currently uses systemUiVisibility to toggle the SYSTEM_UI_FLAG_LIGHT_STATUS_BAR settings. As this is deprecated we want to move to using the new WindowCompat.setDecorFitsSystemWindows and windowInsetsControllerCompat.isAppearanceLightStatusBars instead. But we’ve hit a weird issue which seems to be a bug on API 28 — on API 29 we don't see the problem.
The app also has an OnApplyWindowInsetsListener on the root of our Activity layout to adjust for the IME being displayed, and between two of our Fragments we use shared element transitions. Putting all of these together seems somehow to break layout, such that the Fragment’s root view gets set to width/height of 0.
It’s the kind of thing that's easier to demonstrate than to explain, so I’ve made a very simple sample app to reproduce the issue, and put it on github.
Here’s an animation of what happens — when we should see the second fragment again, we see nothing:
So I have this situation where I can't seem to get android studio to show my navigation graph layout visualization. Navigation editor used to work normally when there were 10 or so screens, but as I kept adding screens I started to notice that my editor would stop working and I would have to invalidate caches and restart for it to work again. But as I added even more screens to the graph, I can no longer get it to work. And to make matters worse, if I accidentally open navigation.xml, all layout preview windows stop working which is getting really annoying. I tried allocating more memory for android studio, but that didn't seem to help. I have layout attributes on each fragment/dialog and I can see placeholders in preview, but it just won't render layouts.
Any ideas?
EDIT: this happens in AS3.5. Things get worse with AS3.6 preview as no graph is rendered at all.
Screenshot of current graph:
I would suggest refactoring some smaller, logically related sections of that navigation graph out into nested navigation graphs. You can use an <include app:graph="#navigation/nested_graph" /> tag much like you can do with layouts. I recommend trying to pull out smaller features wherever it makes sense in your code.
This doesn't fix the problem of Android Studio not being able to handle a graph of that size, but it should work around it.
I've been trying Rajawali to develop some apps, but, while it seems pretty good, I've ran into some trouble.
The main issue is that when i call a RajawaliActivity, and in every other activity called after it, the background of normal Android Views do not show, including the background of the layout being used.
As normal, I am using a RajawaliRenderer to show the 3d models, setting the surfaceView of the mRenderer, as shown in the sample apps and the tutorials.
Has anyone encountered the same problem or knows how to fix it?
In the manifest file set
android:hardwareAccelerated="false"
for each non 3D activity.
that solved the problem for me.
courtesy https://github.com/jwoolston
I'm using this library that allows flipping between views like the "FlipBoard" app.
It works quite well.
The problem is that I need to put a few views on top of it, so I've put it inside a FrameLayout, and the rest of the views after it.
It looks ok, but it has a problem:
When flipping, the views that are on top of it change their transparency (and even become hidden) till the flip is over.
How can I handle this problem?
EDIT: I've found this library which doesn't have this problem, but it has a weird color transition while flipping that I wish to avoid.
EDIT: I've found out that this is a known issue (#49) . Would love to know if anyone else has an idea of how to overcome this.
I don't know how to fix this library, but it seems this library works fine :
https://github.com/emilsjolander/android-FlipView
Not sure though how customizable it is compared to the one i've tested.
If I do setAlpha(0.5f) on a few (image) views, my app gets horribly slow, at least on my Android 4.+ tablets.
If I remove the setAlpha calls, the app (scrolling and paging) works smoothly.
Is there an alternative/faster method for making my views semitransparent?
If you provide some code I can try to see what is wrong, there is no reason and explanation of slowing the app, there must be other thing in the code/project/layouts to make your app work slower
Try creating a custom view that calls Canvas.saveLayerAlpha() before drawing its children. Android 3.0+ versions there is a View.setAlpha() api..
Also you can create transparent or opaque background.Here is the link
http://zaman91.wordpress.com/2010/03/22/android-how-to-create-transparent-or-opeque-background/
Hope it helps.