Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (538)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (601)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Libgdx android activity lifecycle  (Read 4704 times)
0 Members and 1 Guest are viewing this topic.
Offline LiquidNitrogen
« Posted 2014-04-24 03:02:12 »

I had assumed that when an app is pushed to the background or the user hits the back button, that it can later be resumed in the last state that it was in, because this seems to be what most apps do. But after reading about the activity lifecycle, it appears that this mostly has to be done manually.

What would be the least complicated way to achieve this for a game? Is serializing most of the game state something to look at? Is there some tutorial on the specifics of this topic? it seems like there is an awful lot of various data in my game that i would have to save in order to recreate the game state.

Offline opiop65

JGO Kernel


Medals: 161
Projects: 7
Exp: 4 years


JumpButton Studios


« Reply #1 - Posted 2014-04-24 03:12:51 »

LibGDX should handle most of that for you, as far as I can remember. The only thing you need to watch for is unmanaged textures (textures that are generated at run time or have changed since they were loaded in initially). But if you don't mess with your textures they are actually managed internally by GDX. What kind of data are you working with?

Also, just so you know when the user hits the back button on Android, the app is sent into a very weird state. The app may be eaten by the GC and the memory released back to the Android framework for use by other apps. Special steps are needed when dealing with the back button, although the home button doesn't do the same thing.

Offline LiquidNitrogen
« Reply #2 - Posted 2014-04-24 05:07:22 »

hmm youre right, the home button works -the game gets restored. the back button just kills it.

the only data im working with is basic game state variables and arrays of objects which there are many of .. but then theres things like which libgdx screen is currently set..

it seems like the home button is putting the game into the stopped state, not actually calling onSaveInstanceState().

back is destroying the app, which would call onSaveInstanceState() which is where i need to add in my own state data.. it would be nice if there was a fully automated way to do this, but then some apps could have GB of data in memory which doesnt need saving to disk, and it wouldnt know how to decide which things to save.

savedInstanceState.putInt() is expecting key/value pairs, this isnt going to work for saving the state of my world map.. perhaps this is a case of "it would be easier if i had read about this before even starting my project"

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline KatacombStudios

Senior Newbie


Projects: 1



« Reply #3 - Posted 2014-04-24 10:49:42 »

savedInstanceState.putInt() is expecting key/value pairs, this isnt going to work for saving the state of my world map.. perhaps this is a case of "it would be easier if i had read about this before even starting my project"

Well you cannot know everything from the start  Tongue

I'll take my game Nekronoid as an example, I was thinking of implementing some way of saving the state to prevent the recycling of the activity when the user opens a lot of apps. In my game I don't need a lot of data, just the player info (size, velocity, ball velocity, current weapons, lifes and I think that's all), current stage info, and "accumulated" info (basically scores). From my point of view, there are things "not so important", like music exact position, animations time elapsed, etc. so I would just not save this data.
I don't know how many info are you saving, but if you make it a little bit simpler or just forget things like I was going to do you will be able to resume your game... What kind of game are you developing??

By the way, did you try overriding back button functionality? I don't have enough experience with libgdx so I can't help you with that, but if home button is working maybe you can try to mimic its behaviour...

Offline LiquidNitrogen
« Reply #4 - Posted 2014-04-24 12:01:55 »

catching the back button is a good idea, as users would expect the back button to take them back through the menu system, rather than to the home page, anyway.

Theres a few web pages dealing with this topic:
http://www.badlogicgames.com/forum/viewtopic.php?f=11&t=12310
http://www.steventrigg.com/libgdx-save-game-state-and-local-data-persistence/

basically we want to save all the dynamic data necessary to recreate the game state.. im not quite sure yet whether to do this in the pause() method, or in the destroy() method..
and then to reload it all, i think, in the create() method. it now seems obvious that when my app starts, it starts from the begining when the create() method is first called, because there is nothing there to put it back to its former state after having been destroyed.

this comes down to planning from the begining and knowing what data you will need to save, so that it is easy to save. and also designing your classes so that there is a minimum of data that needs to be saved. it is a bit confusing how the home button puts the game in the background, where the back button destroys it, it seems more natural for the opposite to happen.

Offline cfmdobbie

Senior Devvie


Medals: 1


Who, me?


« Reply #5 - Posted 2014-04-29 10:28:46 »

basically we want to save all the dynamic data necessary to recreate the game state.. im not quite sure yet whether to do this in the pause() method, or in the destroy() method..
and then to reload it all, i think, in the create() method. it now seems obvious that when my app starts, it starts from the begining when the create() method is first called, because there is nothing there to put it back to its former state after having been destroyed.

Don't forget that in the Android world apps can get destroyed without any notification - do not rely on onDestroy ever being called.  It is best to persist your app state as early as possible to avoid losing data.  Also note that it's best to spot equivalent points in any lifecycle at which to build up and tear down.  With that in mind:

- If you're working with Activities, I recommend saving state in onPause() and restoring in onResume().

- If you're working with libGDX, there are some very odd decisions they made to do with lifecycles, so tread carefully!  Note that lifecycle on desktop is sometimes different from Android.  It's all wonky enough that I wouldn't be surprised if it all changes in the future, so I recommend logging everything and testing the app flow to see what gets called when for all your target platforms in the version of the library you're using.

Some specific advice if you're using Game and Screen in version 0.9.9: in Screen.show() just call Screen.resume(); implement your build up/tear down in Screen.resume()/Screen.pause(); note that Screen.resize() may be called multiple times, and may be called before and/or after Screen.show()/Screen.resume().

Hellomynameis Charlie Dobbie.
Offline badlogicgames

« JGO Bitwise Duke »


Medals: 74
Projects: 2



« Reply #6 - Posted 2014-04-30 12:38:44 »

What's wonky about this? https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/ApplicationListener.java

http://www.badlogicgames.com - musings on Android and Java game development
Offline cfmdobbie

Senior Devvie


Medals: 1


Who, me?


« Reply #7 - Posted 2014-05-03 19:49:35 »

The interface is straightforward, but it's in the implementations and in the Game/Screen structure where I've been caught out.  If you'd like some specifics, here a few things that have caused me to stumble recently: Wink

* On app start, create() is called on the Game, in which you'll call setScreen() on your first Screen - this calls show() then resize().  Then create() returns and the next line calls resize() on the Game, which calls resize() on the Screen again.  Lesson is, you can rely on resize() being called on the Game instance before the Screen almost all the time, just not on first creation.

* On Android pressing home then re-running an app is essentially equivalent to minimize/restore on desktop.  However, on Android the calls are resize() then resume(), but on the desktop you get resume() then resize().

* On desktop, pause() might mean just unfocused, while on Android pause() is seen when the activity moves into the stopped state.  An activity in stopped state may be terminated without a call to onDestroy(), so you've got to persist any data you need before then, so lesson is to persist in pause() and restore in resume().  But just need to consider that the desktop app may still be visible and rendering in between these calls.

I haven't dug much into the internals of libGDX so I don't know for sure, but the second item doesn't look intentional to me; that's why I suggested testing lifecycle on the specific platforms and the specific version people are using, just in case this kind of thing changes between releases.

Hellomynameis Charlie Dobbie.
Offline badlogicgames

« JGO Bitwise Duke »


Medals: 74
Projects: 2



« Reply #8 - Posted 2014-05-04 07:51:08 »

* resize: the docs say resize can be called at any time. this is what you see., reason being that Android's EGL implementations are a little silly.

* same thing, resize may be called at any time, depending on the platform.

* i guess we should explicitely mention to save state in pause. the desktop app behaviour is wonky though!

you should report such things on the tracker so we can have a look and possibly fix things.

http://www.badlogicgames.com - musings on Android and Java game development
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (29 views)
2014-12-15 09:26:44

Mr.CodeIt (20 views)
2014-12-14 19:50:38

BurntPizza (42 views)
2014-12-09 22:41:13

BurntPizza (76 views)
2014-12-08 04:46:31

JscottyBieshaar (37 views)
2014-12-05 12:39:02

SHC (50 views)
2014-12-03 16:27:13

CopyableCougar4 (47 views)
2014-11-29 21:32:03

toopeicgaming1999 (114 views)
2014-11-26 15:22:04

toopeicgaming1999 (102 views)
2014-11-26 15:20:36

toopeicgaming1999 (30 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!