I thought i pretty much understood what setScreen does, until i came upon this paragraph:
Say we have a main menu Screen where we check if the Play button is pressed in the update() method. If that is the case, we’ll want to transition to the next Screen, and we can do so by calling the AndroidGame.setScreen() method from within the MainMenu.update() method with a brand-new instance of that next Screen. The MainMenu screen will get back control after the call to AndroidGame.setScreen(), and should immediately return to the caller, as it is no longer the active Screen. In this case the caller is the AndroidFastRenderView in the main loop thread. If you check the portion of the main loop responsible for updating and rendering the active Screen, you’ll see that the update() method would be called on the MainMenu class, but the present() method would be called on the new current Screen. This would be bad, as we defined the Screen interface in a way that guarantees that the resume() and update() methods will be called at least once before the Screen is asked to present itself. And that’s why we call these two methods in the AndroidGame.setScreen() method on the new Screen. All is taken care of for us by the mighty AndroidGame class.
I'm having trouble understanding this paragraph. Kept re-reading and refering to the codes but I'm getting all confused.
Is there a simpler explanation, a visual explanation, or perhaps an analogy to help me grasp the concept of what this paragraph is trying to portray?
And btw, which is the 'main loop' that the text is referring to?
And that´s what these frameworks are for: to enable us to go straight down to programming our games! And it really worked for me: not much Java knowledge, I just took the Mr. Nom framework and crafted a little game. Huzza!