In my LibGDX game for android, if the user backs out of the game (either by pressing the home button or switching to another application) LibGDX's built in pause() method is supposed to run. Now, this is fine, and it works fine as well. My problem is that if I back out of the game to do whatever, and then rejoin the game, it has restarted the app completely (kind of like if every time you exited and rejoined in the middle of a game of Pacman your score would be zero and all the dots would be back). For my screen switching, it is necessary that the game NOT restart every time the user exits, but simply enter the corresponding state to actually simulate the 'paused' game. How do I stop LibGDX/Android from killing the game altogether upon user exit, but simply pausing it?
The libGDX application lifecycle matches the lifecycle of the Android Activity as documented in the ApplicationListener interface so you should expect the same behavior. When you press the home button while in a libGDX game then the pause method will be called, which is the same as onPause in Android. The game will go to the background but will stay in memory. However this is not guaranteed and the OS might release the games memory for other applications, there really is no way to get around this. In the case when the game comes back to the foreground and the game restarts you'll need to load the games state from when it was paused.
I've written my own article on how to save and load the game state using Json in libGDX, maybe that will be useful to you.
You should use Asset Manager to prevent it, here a good tutorial :
http://code.google.com/p/libgdx/wiki/AssetManager
the official doc :
http://code.google.com/p/libgdx/wiki/AssetManager
Load all of your textures with assets manager
I have the same problem, but I found the solution by:
Disable option in Developer options called
- Don't keep activities (Destroy every activity as soon as the user leaves it)
Related
I'm new to android app development and just creating a simple application for my workplace that allows video playback control from a web panel, so the app pings the panel on a loop and if it gets a request to play a video, it plays it. If it gets a request to stop the video or play something else, then it does that.
From MainActivity I'm using startActivity to start an instance of ExoPlayer, I know how to pass variables to the activity, but how do I send information the other way or control the playback? Basically that loop that runs constantly to check for new actions is running in MainActivity, once the player is started I have no ability to stop playback, get stream metrics or do anything with that instance at all. I realise I'm probably doing things backwards and should have a background service do the checks, but I still have no idea how to pass information back and forth.
Does anyone have any tips or suggestions? Thank you!
Instead of using two activities, you have to use an acitivty (the main) and a fragment (the video player). Then define a callback interface which will implement the activity and thus manage the communication between fragment and activity
See this https://blog.mindorks.com/how-to-communicate-between-fragments/
I have a recurring task. I schedule it in the standard way (Timer is the libgdx one: com.badlogic.gdx.utils.Timer):
Timer.schedule(myTask, 2, 2);
When the user wants to pause the game, I call:
Timer.instance().stop();
to pause the execution of the task. When the user resumes the game I call:
Timer.instance().start();
This works well, but if the user:
Pauses the game
Makes the game to loose focus (e.g, by focusing on a different window)
Resumes the game
the task is never fired again. Any ideas how this can be solved?
Update
I've opened this issue as a possible bug in libgdx: https://github.com/libgdx/libgdx/issues/3181
Turns out this was indeed a bug in libgdx. It was fixed and now this issue is gone (I'm using libgdx 1.6.2-SNAPSHOT version).
Thanks go to the great team of libgdx!
I am using libgdx's render() function to update scene with time delta, and then draw the scene. However, when the app goes invisible, the render() function is no longer being called, which causes the scene to stop updating, E.g., an animation will stuck at the last frame, until app goes back to foreground.
The problem is that I am building an online real-time game which cannot be 'paused' on client. When the app switches to background, the game must keep updating the scene even without drawing the scene, so that when the user switches back to the app, he can see the most up-to-date scene, instead of a pause-and-resume scene that lags back.
My question is how to achieve this in libgdx, so that the scene keeps updating even when app goes background? Does anyone experience the same problem as mine?
In a Libgdx app, the render thread is only invoked when rendering, thus only when it has the screen. For most games this is the only time the game should be doing any computations, so combining the update and render makes a lot of sense.
In Android, an app generally only gets CPU cycles assigned to it by the OS when its "foreground". To run an app in the background requires using a different platform API (See, for example, https://developer.android.com/training/best-background.html.) Simply creating additional threads will not be sufficient to keep your app running in the background (the OS may decide to terminate it completely if it wants the RAM back for something else).
Generally, users do not expect an Android application to continue running (and using battery) when not in the foreground.
Additionally, even if your app is coded to run in the background correctly, when the foreground app is using the CPU significantly, your background app may not be run.
You can hook into the suspend and resume events to pause your game and then "fast-forward" your game state as necessary. Or, do your computations in the cloud if you require that they run in real-time.
You can try to update your scene from other thread if it doesn't need GL context in it.
Or you can override onPause() method in your AndroidApplication class in Android projects, and keep using render() method for updating.
In onPause() method of AndroidApplication graphics are told to stop rendering.
Maybe you can create interface class to update your scene, without constant rendering when the app is paused, concerning the battery life.
This is the code from onPause() method.
Maybe this will lead you to correct solution.
#Override
protected void onPause () {
boolean isContinuous = graphics.isContinuousRendering();
graphics.setContinuousRendering(true);
graphics.pause();
input.onPause();
if (isFinishing()) {
graphics.clearManagedCaches();
graphics.destroy();
}
graphics.setContinuousRendering(isContinuous);
graphics.onPauseGLSurfaceView();
super.onPause();
}
I am developing an android emergency app and I want to add a feature that can call a certain method from my activity class when the screen is locked. Is there anyway for my app to detect any kind gestures like shake, screen tap pattern or any kind of movement when the screen is locked?
Not sure if it will work, but I think you can put a listener in a service and put the servicee in the foreground. I have no clue what exactly youwant to achieve but this is what I can think of right now. BTW -- pass information from a service the foreground activity
I'm making a game in Android and I'm trying to add a set of menu screens. Each screen takes up the whole display and has various transitions available to other screens. As a rough summary, the menu screens are:
Start screen
Difficult select screen
Game screen.
Pause screen.
Game over screen.
And there are several different ways you can transition between screen:
1 -> 2
2 -> 3
3 -> 4 (pause game)
4 -> 1 (exit game)
4 -> 3 (resume game)
3 -> 5 (game ends)
Obviously, I need some stored state when moving between screens, such as the difficulty level select when starting a game and what the player's score is when the game over screen is shown.
Can anyone give me some advice for the easiest way to implement the above screens and transitions in Android? All the create/destroy/pause/resume methods make me nervous about writing brittle code if I'm not careful.
I'm not fond of using an Activity for each screen. It seems too heavy weight, having to pass data around using intents seems like a real pain and each screen isn't a useful module by itself. As the "back" button doesn't always go back to the previous screen either, my menu layout doesn't seem to fit the activity model well.
At the moment, I'm representing each screen as an XML layout file and
I have one activity. I set the different buttons on each layout to call setContentView to update the screen the main activity is showing (e.g. the pause button changes the layout to the pause screen). The activity holds onto all the state needed (e.g. the current difficulty level and the game high score), which makes it easy to share data between screens. This seems roughly similar to the LunarLander sample, except I'm using multiple screens.
Does what I have at the moment sound OK or am I not doing things the typical Android way? Is there a class I can use (e.g. something like ViewFlipper) that could make my life easier?
By the way, my game screen is implemented as a SurfaceView that stores the game state. I need the state in this view to persist between calls to setContentView (e.g. to resume from paused). Is the right idea to create the game view when the activity starts, keep a reference to it and then use this reference with setContentView whenever I want the game screen to appear?
This question has been asked a lot. Did you read these other posts?
Android: What is better - multiple activities or switching views manually?. This link in particular talks about the Android Design Guidelines which "don't mention switching Views at all; it's centered around an Activity-as-View design."
Android - Should I use multiple activities or multiple content views
Android app with multiple activities
How to pass the values from one activity to previous activity
I'm not sure what you mean by the back button not always going back to the right screen correctly. I've got a game with a similar structure to yours, and the back button always takes the user correctly up the chain of activities.
Furthermore, using the onResume, onPause etc is somewhat necessary. What happens to your application if the phone rings? (Yes I know, some people still do strange things like using their phone to receive calls! :P) The OS tries to call the onPause method in your activity, but if that isn't implemented then your application won't act as expected. Another useful thing with onResume is it lets you update your tables as soon as the user returns to the view. For example, your player has just completed a level and is then brought back to the select difficulty screen. If you simply recover the previous screen from memory, it might not have been updated to take into account that a the level was just completed. However, if you put some code in onResume to handle that, then that will always be executed before the player sees the screen.
Lastly, you say transferring data around activities is a pain with intents - yes, that's probably true. But I usually find transferring any kind of complex data a pain, no matter how you do it. Are intents really that much worse, or is it just that things aren't as easy as you'd hoped? I don't mean any offense with that; I also often find things which intuitively seem easy to be rather frustrating to implement in code.