Notifiche che arrivano anche ad app chiusa

"Mi è arrivata la notifica anche se avevo tutto chiuso." Detta così sembra una piccola magia, e la prima reazione di chi la riceve è a metà fra il comodo e il sospettoso: se il sito può parlarmi quando non lo sto guardando, cos'altro può fare?

La risposta breve è: molto meno di quanto sembra. Vale la pena spiegare dove passa esattamente il confine, perché è il confine a spiegare tutto il resto — comprese le cose che, dal sito, non possiamo proprio fare.

Chi è che si sveglia

Una pagina web vive finché la scheda è aperta: chiudi, e il codice smette di esistere. Il pezzo che riceve le notifiche non è la pagina — è il service worker, un file di codice che il browser tiene da parte e che sa girare per conto suo, senza che nessuna scheda sia aperta.

Ma "sa girare" non vuol dire "gira sempre". Il service worker non decide da solo quando svegliarsi: viene risvegliato dal browser quando arriva un messaggio dal servizio di push. Da cui una scaletta che conviene conoscere:

Nell'ultima riga il messaggio non si perde: resta in custodia al servizio di push per un tempo definito e viene consegnato appena la macchina torna viva. È il motivo per cui, riaccendendo il portatile la mattina, ti trovi la notifica di ieri sera.

La riga rossa e cosa c'entra l'utente

La quarta riga della tabella è l'unica che non dipende da noi. Se il browser è completamente terminato, non c'è nessuno da risvegliare — e nessuna API web può metterlo in moto.

Qui arriva la domanda che ci hanno fatto più volte: "non potete far partire l'app da sola all'accensione del PC?" No, e non è una limitazione da aggirare: è esattamente ciò che i browser impediscono di proposito. Un sito che può mettersi in avvio automatico è un sito che può farlo anche se non lo volevi.

L'avvio a login lo decide la persona che usa quella macchina, dalle impostazioni delle app installate, o l'amministratore di sistema per tutte le postazioni in un colpo solo. Il sito può dichiarare di essere un'app installabile — è il compito del manifest — ma la decisione resta di chi possiede il computer, ed è giusto così.

Una funzione che non puoi implementare perché la piattaforma la vieta va documentata come tale, non riprovata in modo più creativo. Il divieto quasi sempre protegge lo stesso utente a cui vorresti fare un favore.

Il permesso, e perché lo chiediamo tardi

Le notifiche richiedono un consenso esplicito del browser, uno di quei pannelli che compaiono in alto a sinistra. È un permesso che si concede una volta sola: se lo neghi, il browser si ricorda del no e non ripropone più la domanda. Rimediare vuol dire andare nelle impostazioni del sito e riabilitarlo a mano, cosa che nessuno fa.

Per questo la richiesta non parte all'ingresso, quando l'utente non sa ancora di cosa gli stiamo parlando e la risposta più economica è chiudere. Arriva dopo, da un banner che spiega in una riga a cosa servono, e solo se lo si accetta si passa al pannello del browser. Chiedere tardi costa qualche adesione in meno; chiedere subito costa dei "no" definitivi.

Cosa ne resta a chi la usa

Che le notifiche non sono un canale garantito. Un messaggio importante non può esistere solo come notifica: deve stare anche dentro l'applicazione, dove lo ritrovi comunque, anche se quel giorno il PC era spento e il push è scaduto.

La notifica è un modo più veloce di accorgersene, non il posto in cui l'informazione vive. Trattarla per quello che è — un avviso opportunistico sopra a un dato che sta al sicuro da un'altra parte — evita l'unico errore davvero grave: dare per consegnato qualcosa che nessuno ha mai letto.

Se ti interessa il ragionamento sulle promesse fatte all'utente, lo stesso principio torna qui.