Vi dico brevemente la mia in base ad un paio di esperimenti condotti qualche tempo fa.
Prima di tutto, se è il client ad interrogare il server (magari ogni x minuti come effetto di un timer) dovremmo parlare di "pull" e potrebbe essere poco efficiente in determinate circostanze (es. centinaia di richieste per sapere a chi tocca la prossima mossa in un gioco multi-player).
Per il sistema "push" sono stati proposti nel tempo diversi server. Il più recente è MQTT.
Essendo opensource si può installare su un proprio server (anche un Raspberry) oppure ci si può iscrivere ad un servizio online (es. CloudMqtt).
Una volta che si ha un account ad un push-server, le API consentono di "iscriversi" ad uno o più canali e di conseguenza essere oggetto di messaggi di aggiornamento.
Con questo sistema, il client non si pone in attesa di un messaggio eseguendo un loop, ma attende una notifica di evento e poi utilizza le API per vedere cosa gli è stato trasmesso (cambi di stato, messaggi..).
Personalmente ho utilizzato sia PushBullet.com che CloudMqtt.com; il secondo mi è parso più promettente.
C'è un esempio di B4x chat che può essere adattato all'utilizzo con MQTT. Qui ilvantaggio del push è evidente; quando un partecipante alla chat scrive un messaggio, questo viene automaticamente inoltrato a tutti gli iscritti a quella chat. Tocca al server sapere chi è attivo e chi no, gestire connessioni/disconnessioni etc...
Infine per rispondere al quesito di Demetrio dell'app che riceve notifiche mentre non è in esecuzione: bisogna che si registri per ricevere uno static broadcast riferito ad un implicit intent (definito nel Manifest). In pratica tocca ad Android svegliare l'app e passare il messaggio broadcast. A tale scopo bisognerebbe utilizzare un service quale elemento dell'app da "svegliare" tramite broadcast.