Ah, I see how it is. I thought the device ID will remain valid as long the user does not uninstall the app.

Have the client (the game code running on the player's device) fetch the current game state from the server (since push notifications are not 100% reliable, the last PN you received might not contain the most recent game state).

So, the client shall "spam" the server with requests? Is there a number for what is healthy? I mean, every second delay-time between a fetch-request would result in a "lag"-incremental. The most recent game state? So, Pushes actually do carry bits of information? That sounds weird, I always thought they just inform me about actual changes.

E.g. from a different game-type, you build your own city and construct a house that requires 5 hours. After 5 hours, you will get a push, telling you your is done. If I swipe the push and just click back to the app myself compared to clicking the push isn't the same?

Since my game is turn-based, a push will always carry the most updated game-state of a game. What might be is, that a player plays with multiple games, e.g. with player 2 and another game with player 100. So there might be two pushes at once on the screen.

About multiple devices, I think I won't support to continue playing a game in-action from a different device. Have to look into that : )

The device ID does stay valid, but that's not sufficient for the reasons Nypyren pointed out (1. It doesn't locate the device, 2. It doesn't tell you whether the user has opted out).

Push notifications can be designed just as visual popups for a user, or as data messages to your app. e.g. https://firebase.google.com/docs/cloud-messaging/concept-options#notifications_and_data_messages

You don't need to spam the server with requests; the suggestion was that you ask for the latest state when you start up the application. Then, during play, you stay updated using whatever system you were going to use anyway (regardless of push notifications).

'Regardless of' doesn't mean "without using". I'm just saying that whether you have push notifications or not, you're still going to have communication with the server. You know, the web API you mentioned above. You're going to want to do that when you open the app anyway; the push notifications don't factor into it.

You're not understanding the essential detail that if the app is not running, you don't need to know or care what the most up-to-date state is. :)

So, if the app is idling in the background, and hasn't got the latest game state... who cares? The player can't see it.

It would be like worrying about rendering an up-to-date game world when the window is minimised. You don't need to do it.

Fall back to email if the user doesn't reply in a reasonable timespan. Ultimately you don't get to control the player's notification settings so all you can do is try different channels of communication and be prepared to deal with the case where the user simply doesn't respond or open the app at all.