I'm really struggling here, and it's holding me back.
What is the correct way to handle OpenGL, and an Activity - which launches sub-activities, or goes back to the home screen. And have it resume just exactly where it was.
I have it semi-working as it stands, textures/VBOs are reloaded at onResume() when needed.
But sometimes, when launching sub-activities and returning, or going to home screen and returning, onCreate is being triggered again. This messes up the whole thing, and I end up with a black screen.
I'm sure I'm doing the whole thing wrong. Can someone explain how one should handle an Activity like this?
What platform are you working with?
The reason I ask is that prior to Eclair this whole area was riddled with bugs with the result that suspending/resuming OpenGL basically only worked by accident. However, these do seem to have been fixed by Eclair and our app seems to be suspending and resuming fairly reliably.
What you're supposed to do is to register a callback to your SurfaceHolder so you get notified when the surface appears and disappears. In the surfaceDestroyed() method you shut down EGL completely, and then in your surfaceCreated() method you reinitialise it. You shouldn't be doing any of this from your Activity's onCreate()/onResume() methods, as the surface may not appear and disappear at the same time.
That said, our application was designed for Cupcake, when things were pretty primitive. I gather that these days there are utility classes available that do all the heavy lifting for you, so if you're using one of those things may work differently; and if you're not, you may want to look into them.
Related
I'm considering building my first iOS app in the following months. This is going to a hybrid app:
https://fanmixco.github.io/toastmasters-timer-material-design/
At this point is fully migrated to Android and Windows 10. However, one of my greatest challenges in Android was the screen rotation:
Why the android activity get's destroyed on rotation?
What is the advantage of letting an activity be destroyed on rotation?
This situation was quite complex to handle since each time my app was rotated the activity was destroyed and I needed to add several workarounds in order to keep the app running, restoring the previous states, colors, stop the timers before the rotation because they kept running in background, etc.
I didn't experience anything similar in Windows 10 and I'd like to know if the iOS View Life-Cycle behaves closely, are the views destroyed during the rotation of any device? Because my workarounds are reusable, but they add certain complexity and reduce performance.
These are some of the sites that I read:
iOS View Controller Life Cycle
View Controller Lifecycle iOS applications
iOS > Android: View Life Cycle
Nevertheless, I haven't found anything precise about this topic.
P.S.
I'd like to find if there is any documentation or examples since I invested a considerable amount of time in the Android Specific Situation to avoid finding at the last minute that I needed to reuse the workarounds.
I'm not sure if this question should be here or in Software Engineering. If I should move it just let me know and I'm going to do it.
When the screen is rotated the views are not destroyed. However it is re-laid out/re-drawn based on the constraints on the view. But this won’t destroy properties or mess with state on the view.
I have an activity where entering it is time-costly (around 1 second).
I tried using DDMS to track what was happening during activity transition.
I started the track, press the button where it starts the new activity, and then stop the tracking.
However, I cannot find any suspicious method in method profiling.
So... to conclude, I may lay out my question this way:
Did I use traceview correctly? I always sort by Excl Cpu time to see if any method is taking up the most time. However, in the trace above, the slowest method takes less than 83ms.
If you have similar experience (i.e. Activity transition is slow, but you cannot find anything in traceview), how do you end up solving it?
So I am making an android game, and so far it's working fairly well. I was using System.exit(0) to kill it, but I know that is an improper way to do it. So I used finish() instead, which does close the program. The problem is, that when I reopen it, the screen is blank. It seems that for some reason, the glSurfaceView isn't being released, and continues to run, and that upon reopening the game, it loses focus of it? The sounds and everything play, and my Logcats display information, so the game is in fact running, but just not the screen. Now before people start jumping on the (just let android take care of closing your app bandwagon) I have my reasons for doing so. For one, telling me that android is efficient enough to do this is a lie, otherwise we would not have the need to restart the devices every other day. Nothing more bothersome that a lag driven phone that can barely even handle an incoming call because it has so much shit on it running. So yea, I would like to be able to close the app.
So yea, how does one correctly to the glSurfaceView that it is time to close itself down? or to tell the Activities class that it needs to release it's handle to the glSurfaceView since closing the app sure doesn't do that.
I am developing an Android app. I have already crossed more than 20 Activities. So I am bit concerned about it. I mean if there are more Activities in an Android app, does it affect the performance of App like Speed, Memory or any other issue?
Though it is not a standard question but still I feel its something which might help others too
Yes Suraj more activities will affect performance
An activity is the equivalent of a Frame/Window in GUI toolkits. It takes up the entire drawable area of the screen (minus the status and title bars on top). Activities are meant to display the UI and get input from the user
An Activity (calling-Activity) can spawn another Activity (sub-Activity) in 2 ways:
Fire and forget – create an event (Intent) and fire it
Async callback – create an event (Intent), fire it, and wait for it’s response in a callback method (of the calling-Activity).
So the effect of activities will depend on performance of your device, its processor and memory etc.
Even if any activity will remain in stack and not finish then it affects device performance.
Even you have to take a look at security measures.
I have an Android app that in the onCreate() method, preloads a lot of graphics.
When I test my app on my HTC Aria and launch it, it runs fine. However, if I press the back button to exit my app, and then launch the app again, it crashes with an OutOfMemoryError: bitmap size exceeds VM budget. If I then launch the app for the third time (right after it has crashed) it launches fine. Then if I close and re-launch it, it crashes again with out of memory. It continues this every-other-time-crashing pattern forever if I keep trying.
I checked to see what life cycle methods were being called and onStop() and onDestroy() are both being called when I exit the app, yet I have a feeling that something is not yet being cleaned up and that by "crashing" the app when I try to launch it the second time, it somehow free's the memory.
Any thoughts on what could be happening or how to remedy this? Please let me know if you need me to post more info. Thanks!
Info:
My app is fairly simple and only has 1 activity that plays some frame animations.
Maybe you are unnecessarily holding onto Context references? Check Avoiding memory leaks for some tips, as well as Attacking memory problems.
It sounds like something in the Activity life cycle is not quite right. Are you sure you have every start covered? http://developer.android.com/reference/android/app/Activity.html
You have onStop but do you have onDestroy? You're probably missing one of those that you need.
You may find some useful information the many answers to this question:
Strange out of memory issue while loading an image to a Bitmap object
Also, I second the "Avoiding Memory Leaks" blog post. Especially if you can trigger the same problem with orientation changes. Using "this" context when creating display objects is a sneaky way to leak the Activity context. In my own app, I managed to leak a whole chain of contexts, and would very rapidly run out of memory when doing orientation changes.