I got two activities in my game application. One parent menu activity with two buttons, each having a onClick, and one child (game) activity containing the game loop.
When I press the back button from the game activity, the menu seems to be properly resumed: Both buttons are at the right position and look like before.
The problem is that the buttons don't work anymore. Same goes for the android's back button. Although the back button flashes up after clicking on it, nothing happens.
My guess is that it has something to do with android's memory management or the game loop. I destroy the game thread inside of my SurfaceView's surfaceDestroyed:
#Override
public void surfaceDestroyed(SurfaceHolder holder) {
boolean retry = true;
while (retry) {
try {
gameEngine.join();
retry = false;
} catch (InterruptedException e) {
}
}
}
I use no custom overriden methods for resuming and restarting. Since the activity's appearance resumes finely and the onResume() method is called on resuming to the menu activity, I see no way to debug into it deeper.
The problem was that the running thread in the child activity was not correctly stopped - I was missing a setRunning(false) before joining. I assume that the UI Threads did their work anyway. After fixing the thread, the back button works properly.
I'm currently developing a custom camera application which takes a video using MediaRecorder for 5 seconds. I have implemented a number countdown overlay which counts down from 5.
My problem is that I am not 100% sure how to implement surface methods and pause/resume methods. If I close my app half way through recording and then open it again, the app freezes, shows a black screen, and eventually crashes.
Should onPause and surfaceDestroyed be used in unison? (Same question applies to onResume and surfaceCreated) How does surfaceChanged fit into this?
I'm guessing I need to find a way to restart my CameraActivity every time it resumes. (As I don't want it resuming half way through a countdown).
You should look at Activity lifecycle onPause and onResume for creating and destroying camera.
http://developer.android.com/training/basics/activity-lifecycle/pausing.html#Pause
The problem is when my game is hidden, there is a delay when it's resumed. Each time game is resumed it takes longer. This happens on any screen set including splash screen where assets are being loaded. There is no difference in delay when game is resumed to game screen or splash screen, or menu screen. That means there is no problem with a lot of assets being loaded. I tested other game called "Cut the Rope 2" and there is no such delay, game resumes immediately.
I would like to add, that when I launch application first time, there is no such delay it jumps straight away to splash screen. Also when I press back button, it restarts the whole application and there is no delay also. That means that there is only a delay when application is resumed and there is no delay at all when application is launched first time or restarted.
UPDATE:
My problem is exactly like the one posted in the link below. Problem wasn't solved there. http://www.badlogicgames.com/forum/viewtopic.php?f=11&t=11433&p=51515&hilit=resume+slow#p51515
So the problem is that this is called when my game resumes:
assetManager.finishLoading();
I didn't put that code in resume(). From the link above, I read that it's called automatically. When you press "Back Button" on tablet and then you resume the game, it takes time to launch application. If you press "Lock Button" and then you resume the game it launches game immediately but it freezes. So there are two different behaviors according to the button which was pressed. I would prefer to launch game immediately and not freeze but play my loading screen. Is there any way to do this?
The solution to this problem is to call
Texture.setAssetManager(manager);
In this way AssetManager.finishLoading() will not be called automatically when game is resumed. Therefore it will not reload any assets. AssetManager.update has to be called manually.
Over the past months I have been developing a versatile real-time game engine, and I have learned a lot, but I still feel very naive when it comes to the application life cycle. Specifically, I am trying to implement an Activity which can be shuffled in to the background by the user, then properly resumed.
My current architecture is as such: I have a an XML menu launcher activity which can create a real-time Game activity using intent. Relevant data in this Game activity is referenced through static data structures and variables. The Game activity creates worker threads in the onSurfaceCreate() callback of my SurfaceView object.
When a user presses the back button, the activity is destroyed, and they are sent back to the XML menu in the launcher activity. Fine, good for now. When the user presses the home button, the Activity is sent to the background. OK, great. My problems arise when the user tries to find their way back in the Game activity once is has been sent to the background. When the user touches the launcher icon, the Game is destroyed and the menu is re-launched. Also, when the user resumes the game through the task manager, the onSurfaceCreate() callback fires and the worker threads are started, but the game is frozen.
So, I have two questions. First, how do I resume my activity through the launcher icon, instead of re-launching the game? Second, when I resume my activity, what actions are necessary to restart my worker threads while persisting the game data?
Thanks!
EDIT: By request, I am including some code below. My onSurfaceCreate is a little bit complicated, it sends a message to another thread, which then implements the callback. I have verified that this implementation function fires when the Game activity is resumed.
protected void surfaceCreate()
{
Log.e(TAG, "surfaceCreate");
Thread gameThread = createGameThread();
gameThread.start();
}
protected final void onResume()
{
super.onResume();
resume();
}
protected final void onPause()
{
super.onPause();
pause();
}
These cryptic pause() and resume() methods simply set a boolean variable which prevents some game logic from being executed, they do nothing to hinder the worker threads, which should continue looping.
EDIT: Thanks Mohammad, for solving my first (although smaller) problem. It turns out that the launcher icon behaves differently when not connected by USB to the IDE. The second problem remains unresolved.
EDIT: All working! The second problem turned out to be an issue unique to my code, I apologize for that. I hope that this question can still be useful for those dealing with the launcher and IDEs.
There are multiple possible problems/solutions listed in this post. This includes misunderstanding of activity lifecycle and launchMode settings.
First, how do I resume my activity through the launcher icon, instead
of re-launching the game?
You are most likely missing definition for your onResume() and onPause() methods. Examples are here:
http://developer.android.com/training/basics/activity-lifecycle/pausing.html
Straight from the API:
onPause() Called as part of the activity lifecycle when an
activity is going into the background, but has not (yet) been killed.
onResume() Called after onRestoreInstanceState(Bundle),
onRestart(), or onPause(), for your activity to start interacting with
the user.
Check the Android Activity Lifecycle out:
http://developer.android.com/reference/android/app/Activity.html
One theory on your issue may be is that you're most likely going to onStop() (by hitting the home button) and the Android OS is looking for your onRestart(), but can't find it hence freezing/restarting.
Second, when I resume my activity, what actions are necessary to
restart my worker threads while persisting the game data?
Careful how you use the word restart. You want to pause and resume the application (not restart). Save data in onPause() (use a database or any other save feature you'd like). Load data in onResume(). Although, the activity should resume as normal if you just fill up these methods.
Now, if you want to save state for when you restart the application, you should save states in onStop() and/or onDestroy(). You should load states in onStart(). In order to save states, you can check this out:
https://stackoverflow.com/a/151940/2498729
For those using Eclipse (or any other IDE to run/test your application):
From what have you described you probably have overridden
android:launchMode in AndroidManifest.xml or if you are testing by
"run as" from Eclipse try exiting the application after installing and
auto-starting. Then start again from the emulator and test the Home
button behavior. I suppose this is because Android does not put
Activities on the OS stack when started from Eclipse and then the Home
button behavior is not as usual. If this does not solve your problem,
try reading
http://developer.android.com/guide/topics/fundamentals.html#lmodes.
I had launchMode set in my StartupActivity. THen I removed that (it
was set to "singleTask", it behaves like I want it; the app is
"resumed" to the Activity I expect, ie not StartupActivity but
MainActivity.
Source:
https://stackoverflow.com/a/1619461/2498729
http://developer.android.com/guide/topics/manifest/activity-element.html
According to this:
https://stackoverflow.com/a/3002890/2498729
You should change your andoird:launchMode to "Standard" (or "default").
Standard: A > B > HOME > B (what you want)
SingleTask: A > B > HOME > A (what you don't want)
I'm working on a game and use a WakeLock to keep the screen from going to sleep while the user is playing. However, I'm encountering some weird behavior when the screen is manually put to sleep..
My current approach is to store away the game info in OnPause() and load them back up when OnCreate() is called. This works fine if I hit the home button and start my app back up. However, turning the screen off seems to call OnPause() a couple times..in addition to some other funky behavior. Can anyone offer an explanation of why turning the screen off is different than hitting home?
According to Logcat, here's the sequence of events.
When Screen is turned off-OnPause is called; OnCreate is called; OnResume is called; OnPause is called again
When screen is turned back on- OnResume is called (before phone is even unlocked)