LibGDX: The relationship between Screen interface and Game class

Question

I want to understand the relationship between the Game class and the Screen Interface. In the textbook I am reading, it states that the Game class delegates the functions from ApplicationListener to a screen object. And somehow this allows you to switch screens. I don't get it, why does this happen and how does it work?

My current understanding: Game implements Life Cycle methods from ApplicationListener(Create(), Render(), etc...). But the reason you don't just implement from ApplicationListener directly is because the Game class will allow you to make multiple screens if you extend from the Game class instead.

Answer 1

The "core" of LibGDX is always your ApplicationListener class.
It contains all the Lifecycle-Hooks the different platforms offer (including create , dispose and so on).
The class Game is just one implementation of the ApplicationListener , containing the most usual behavior. For most of the games this class does a great job, if you need some speicial behavior, you need to override it or implement ApplicationListener yourself.
The Screen interface isn't as important, but it is also pretty usefull.
It allowes you to separate your game into different parts.
For example you could have a MenuScreen and a GameScreen .
The MenuScreen shows a simple menu with "Settings", "Highscores" and ofc a "Play"-Button.
The GameScreen then contains the actualy game-logic and rendering.
However, by default Screen s don't do anything, they don't even get notified about the Lifecycle-Hooks.
And thats where the Game -class comes in:
The Game -class contains a single Screen -instance, the active Screen . It then notifies the current Screen about Lifecycle-Events, like render . The Screen can then take car about this event.
If you want to switch Screen , you can simply call Game.setScreen(newScreen) . The Game -class then calls hide for the current Screen (you might want to dispose some assets here, or save the users progress) and then show for the new Screen (here you can load some assets and initialize the new Screen ).

TL;DR
The ApplcationListener is the entry point of your game. Each game has exactly one ApplicationListener , which gets notified about Lifecycle-Events by the LibGDX framework.

Screen s are different parts of your game, which contain different logik and view (for example a MenuScreen and the GameScreen ).
The Screen -classes encapsulate the logic for a single Screen .

The Game -class is somehow the default implementation of the ApplicationListener interface and delegates most of the work to the current Screen . It also contains the logik for switching the Screen .

Answer 2

ApplicationListener is just an Interface and you can implement it directly with your class. Game class is implementing that ApplicationListener Interface. Inside Game class it consists a Screen interface that will allow you to change Screens. Here is what inside the Game class fro Libgdx.

public abstract class Game implements ApplicationListener {
protected Screen screen;

@Override
public void dispose () {
    if (screen != null) screen.hide();
}

@Override
public void pause () {
    if (screen != null) screen.pause();
}

@Override
public void resume () {
    if (screen != null) screen.resume();
}

@Override
public void render () {
    if (screen != null) screen.render(Gdx.graphics.getDeltaTime());
}

@Override
public void resize (int width, int height) {
    if (screen != null) screen.resize(width, height);
}

/** Sets the current screen. {@link Screen#hide()} is called on any old screen, and {@link Screen#show()} is called on the new
 * screen, if any.
 * @param screen may be {@code null} */
public void setScreen (Screen screen) {
    if (this.screen != null) this.screen.hide();
    this.screen = screen;
    if (this.screen != null) {
        this.screen.show();
        this.screen.resize(Gdx.graphics.getWidth(), Gdx.graphics.getHeight());
    }
}

/** @return the currently active {@link Screen}. */
public Screen getScreen () {
    return screen;
}

}