EDIT: After some debugging, I found that the answer is 'yes'. The current screen always has a memory allocation on the heap, and when a new screen is switched to, and simply replaces the old one.
ORIGINAL QUESTION:
How are screen instances maintained when not being displayed?
I'm attempting to create a function that can perform screen switching between screens independent of the methods of any one specific screen. This is to reduce the number of interactions required to switch between screens, and to put a level of abstraction on top of the specific screens themselves.
A problem that I can't get my head around is how to store the screen instances in a globally accessible data layer. Since the easiest way (at least from what I have found) to do this is letting the View class pass a sliced version (i.e. the Screen class) of itself to that data layer.
The code to perform this operation once for every new screen is put in the constructor of the View class.
But the View class constructor seems to be run at screen switches, not when the app as a whole is initialized. Furthermore, the constructor is run at screen switches even though the screen in question has already been created. This makes me wonder if the screens are destroyed when switching to another screen?
So, is it even possible to do screen switching to screens that are no longer being displayed?
