In a nutshell, I use regular views for all my application except for on that uses a GLSurfaceView.
the UI flow works well. I can navigate form one to the over
except whith the GLSurfaceView
when I open the first time the GLSurfaceView everything works fine, but when I switch to another view and come back (pause menu) my view is completly black...
I tried several things and the closest I got from fixing it is to recreate the GLSurfaceView completly (but that takes too much time ...)
What I want is be able to do this:
if(glView){
activity.setContentView(mView);
}else{
activity.setContentView(id);
}
(id being an xml layout)
can somebody tell me what I'm doing wrong or point me to a tutorial that explain how to swap form GLViews to regular views
thanks a lot
Jason
after playing around a bit I figured out that when I load a new view my ogl context gets destroyed.
since I couldn't see a way to prevent this and that regenerating all the texture took too much time I witch everything to ogl
Related
When I rotate the screen on a tablet, my widget's list view disappears and the buttons become unclickable. I'm not sure what happening with the most recent remote view to cause this. Any suggestions?
Here is my onUpdate function
onUpdate
Since we do not have the full code, it's kind of hard to give an actual answer to your problem.
However, I might have an idea & the cause of your problem could be in your .XML file. The same way your app looks great in a certain rotation, most surely on the one you originally designed your work on, it is very possible that it might result in problems when you changed the rotation.
However, it all depends of the layouts you are using & how they are used. I would advise to share your entire code so we can go through it.
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'm experimenting with ways to do classical mobile game paradigm: a selector of levels, followed by a game screen.
I fully understand that there are plenty of ways to do that, but i was wondering about what goes wrong when i try this particular one (for learning purposes):
I have an activity, which holds references to my own GLSurfaceView child. On the activity start it loads a default 'level' and perfectly plays it. I can see Render thread started.
I implemented an OptionsMenu item, which after activation inflates a GridView with proper adapter, which allows user to select a level; and sets this inflated Layout to Activity by using setContentView. This is when GLThread dies.
Now i also implemented the OnClick's of that menu so that after click it loads a level in the game engine (works fine, btw) and brings back GLSurfaceView by using setContentView with saved (in 1.) reference.
And that's how i get a blank screen. Everything works fine, menu still works, i can go back to level selector, but in debugger i can see Render Thread doesn't exist.
Please, could someone explain to me what exactly goes wrong here? I'm totally not sure about this OpenGL intrinsic.
I'm working on a multimedia video processing application for Android, and I've run into a bit of a problem. I'm using the FragmentPagerAdapter class with a number of different fragments inside for various steps of video processing.
My first Fragment contains a SurfaceView and a MediaPlayer that feeds it, along with various playback controls. My problem happens when I swipe from fragment 1 (with the SurfaceView) to fragment 2 (empty at the moment). If I haven't yet called start(), nothing unusual happens, and I'm able to swipe between fragments normally. Once I call start() however, the entire screen starts flashing on and off when I swipe to the next Fragment, even if I've put the MediaPlayer in the idle state and it's not feeding frames to SurfaceView. The only thing that stops this is destroying the surface along with the containing view by swiping to the third Fragment so the FragmentPagerAdapter destroys Fragment one, or exiting the application via the home or back button so the view is destroyed.
I can't for the life of me figure out why this is happening, other than that perhaps the SurfaceView rendering thread is somehow interfering with the main UI thread. Nothing unusual appears on LogCat, either, so I'm a bit stuck. I'm running a Galaxy Nexus with android 4.1 as my test hardware.
Any help would be appreciated!
JT
UPDATE: I've managed to find a workaround for now by overriding the setPrimaryItem() method in the FragmentPagerAdapter to call a method that removes the SurfaceView from the hierarchy (using removeView() on its LinearLayout container) when the video player Fragment ceases to be displayed, and then reinstates the SurfaceView when it's active again. There's still a bit of a blink when this happens, unfortunately, so if anyone has additional thoughts, I'd be grateful!
From the Android Developers Blog
This widget[SurfaceView] works by creating a new window placed behind your application’s window. It then punches a hole through your application’s window to reveal the new window.
Because a SurfaceView’s content does not live in the application’s window, it cannot be transformed (moved, scaled, rotated) efficiently. This makes it difficult to use a SurfaceView inside a ListView or a ScrollView.
The Solution is to use a TextureView if you're building for 4.0 or above. If youre interested in using a TextureView to display video this thread might be helpful
I'm new to android programming and I'm having a little trouble with the following.
I'm trying to make a menu for a game, and I'd like to have an OpenGL view running in the background (with a running demo of the game) and then have the various menu screens change over the top of this; without reloading or affecting the OpenGL view.
At first glance it appears I have a choice of two methods: the first to use separate activities for each screen and then load each individual menu from xml layouts. This obviously reloads a new instance of the OpenGL view per activity. The second option would be to use a single activity and inflate each XML layout on request, leaving the OpenGL view running untouched.
If possible I'd like to use the first method, but as stated all the views end when a new activity is loaded. The second method I think should work - but then I have all the code for the entire menu in a single file. I'm pretty sure I'm missing something.
If anyone can recommend the best approach for this it would be appreciated.
Thanks.
P.S - I guess the desired result is that similar to the Angry Birds menu which has the continually scrolling landscape in the background.
Use Fragments. You can keep one Activity (you'd have to re-initialise openGL for each activity otherwise), and then have different fragments pop up over your openGL stuff.