Android programming
Feb. 26th, 2018 09:20 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jackOK, I revisited my emoji matching android game. Now I think I understand what's going on better, both the way the author of the game I based it on laid out different files, and how android UI works.
I usually split my code into "backend" and "frontend", and frontend usually instantiates a backend class that does all the working out all the consequences. And this was similar, except backend was called "game" and frontend was called "gui" which is reasonable but I kept expecting things in a slightly different place than they actually were.
The frontend is mostly a list of lots of SomethingActivity classes, where in Android-development speak, an activity is one mode the app may present to the user, something which displays... something, and handles input, etc. So in this case the important one was PlayActivity, when the game is actually active, but there were a lot of others for importing, exporting, choosing a game from a list, etc, etc, which I didn't use.
The way multitasking is handled, there are functions called when your app resumes, pauses, starts up, is killed, etc. And you need to look at a big flow chart to make sure you get it right, but I mostly just copied the code already there. Basically, there's a "quick save" thing, where if your app is still running in theory but there's not enough memory for it, the OS calls a function with a variable in which it can stash its current state (including things like "are any menus open" etc), and then if it's switched to the front again, that is used in its initial start-up function and it's expected to reconstruct its current state from that info, as if it had never been swapped out.
But it *also* needs to do a real save when it's swapped out, because the phone might restart or kill its app completely before it's swapped in again, where it writes the current game layout to a database (but doesn't try and track things you wouldn't expect to be the same after you start it up again).
When you turn the phone sideways, these functions are also called: there's not a separate "reflow all the GUI elements" function, instead it temporarily saves the state, then restores it again in the new orientation.
And I added a cheat mode so I (or anyone who would like to), can test it out without walking around.
I usually split my code into "backend" and "frontend", and frontend usually instantiates a backend class that does all the working out all the consequences. And this was similar, except backend was called "game" and frontend was called "gui" which is reasonable but I kept expecting things in a slightly different place than they actually were.
The frontend is mostly a list of lots of SomethingActivity classes, where in Android-development speak, an activity is one mode the app may present to the user, something which displays... something, and handles input, etc. So in this case the important one was PlayActivity, when the game is actually active, but there were a lot of others for importing, exporting, choosing a game from a list, etc, etc, which I didn't use.
The way multitasking is handled, there are functions called when your app resumes, pauses, starts up, is killed, etc. And you need to look at a big flow chart to make sure you get it right, but I mostly just copied the code already there. Basically, there's a "quick save" thing, where if your app is still running in theory but there's not enough memory for it, the OS calls a function with a variable in which it can stash its current state (including things like "are any menus open" etc), and then if it's switched to the front again, that is used in its initial start-up function and it's expected to reconstruct its current state from that info, as if it had never been swapped out.
But it *also* needs to do a real save when it's swapped out, because the phone might restart or kill its app completely before it's swapped in again, where it writes the current game layout to a database (but doesn't try and track things you wouldn't expect to be the same after you start it up again).
When you turn the phone sideways, these functions are also called: there's not a separate "reflow all the GUI elements" function, instead it temporarily saves the state, then restores it again in the new orientation.
And I added a cheat mode so I (or anyone who would like to), can test it out without walking around.