L'implementazione della Push API e il supporto per la sincronizzazione in background hanno reso il comportamento delle Web application più simile a quello delle applicazioni native, grazie a queste interfacce è stato infatti superato un modello che vedeva i siti Internet eseguire quasi esclusivamente operazioni direttamente osservabili dall'utenza. Ma i processi in background sono spesso il risultato di interazioni o la conseguenza dell'elaborazione di richieste, come gestire le notifiche in questi casi?
La risposta più semplice a questa domanda risiede probabilmente nella definizione di uno standard, ecco perché il Web Platform Incubator Community Group, che è parte integrante della community del W3C, ha recentemente deciso di pubblicare una bozza delle specifiche riguardanti la cosiddetta Web Budget API; per capire di cosa si tratta è necessario ricordare come gli sviluppatori dei browser Web più diffusi hanno deciso di gestire il problema delle notifiche relative alle operazioni in Background.
Tradizionalmente il team di Google Chrome ha privilegiato un approccio che promuovesse la visualizzazione di notifiche in risposta ai messaggi, per quanto riguarda Mozilla Firefox si è invece preferito assegnare un "budget" basato sul livello di engagement: in sostanza ogni notifica ha un "costo" in termini di tempo, tale costo permette di stabilire un livello di priorità, le richieste a livello di network possono non produrre delle notifiche nel caso in cui il budget disponibile sia in esaurimento.
La scelta di Mozilla si è rivelata più congeniale e quindi anche Chrome, con il rilascio della versione 52, ha deciso di adottare un modello simile. Rimane però il problema della standardizzazione che la Web Budget API tenta ora di superare. Per ora quest'ultima fa riferimento in particolare alla Push API, e quindi i service worker, che consente di gestire notifiche in modalità asincrona come risposta ai messaggi del server.
Fondamentalmente la Web Budget API dovrebbe consentire di:
- stabilire se visualizzare o meno una notifica in risposta ad un messaggio dalla priorità non elevata quando l'operazione più importante da eseguire è la sincronizzazione dei dati;
- utilizzare un'ipotetica API per la schedulazione con cui definire dei timer per le esecuzioni;
- gestire gli aggiornamenti della cache per i dati sincronizzati;
- valutare il budget disponibile e decidere quali notifiche evitare sulla base di esso;
- stabilire eventuali limiti per le operazioni in background.
Il fatto che per il momento la Web Budget API venga implementata per la Push API non significa che essa non possa supportare presto ulteriori interfacce.
Via WICG
