[Solved] LibGDX: The relationship between Screen interface and Game class

Question

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 Screens 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.

Screens 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.

Accepted Answer

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 Screens 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.

Screens 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.