Come impostare le opzioni di connettività in background (HTML)

Articolo
12/11/2015

[ Questo articolo è rivolto agli sviluppatori per Windows 8.x e Windows Phone 8.x che realizzano app di Windows Runtime. Gli sviluppatori che usano Windows 10 possono vedere Documentazione aggiornata ]

Questo argomento illustra le funzionalità di connettività di rete in background disponibili per le app di Windows Runtime scritte in JavaScript e HTML e spiega come configurare le opzioni di connettività in background.

Cosa sapere

Tecnologie

IXMLHTTPRequest2

Abilita l'accesso alle risorse Web usando un'estensione dell'oggetto XMLHttpRequest.
System.Net.Http

Abilita la connessione a servizi Web mediante un client Web moderno.

Prerequisiti

Le informazioni seguenti si applicano a qualsiasi app di Windows Runtime connessa o in grado di riconoscere la rete che dipenda da connessioni di rete per essere sempre attiva. Questo argomento riguarda le app scritte in JavaScript e HTML per Windows 8.1, Windows Phone 8.1 e Windows Server 2012 R2. Per altre informazioni sulle attività in background che interessano le app scritte in JavaScript, vedi Supporto dell'app con le attività in background.

Per altre informazioni su altre app di Windows Store connesse o presenti in rete scritte in C++/XAML e app che usano .NET Framework 4.5 in C#, VB.NET o C++ gestito in Windows 8.1 e Windows Server 2012, vedi l'argomento sucome mantenere la connessione in background.

Modello del ciclo di vita per le app di Windows Store

Windows 8 e le versioni successive includono un nuovo modello del ciclo di vita per le app di Windows Runtime, che si differenzia dal modello usato per le app desktop in Windows 8 e nelle precedenti versioni di Windows. Per impostazione predefinita, un'app di Windows Runtime viene completamente sospesa quando viene spostata in background. Esistono però alcune eccezioni alla sospensione dell'app, ad esempio quando l'app sta eseguendo un'operazione di stampa, sta accedendo a un flusso audio o sta trasferendo file in background tramite Windows.Networking.BackgroundTransfer. Per alcune di queste eccezioni (ad esempio Windows.Networking.BackgroundTransfer), è possibile che l'app venga comunque sospesa, ma Windows prosegue il trasferimento di rete in un processo separato.

Il nuovo modello per le app di Windows Runtime velocizza la risposta dell'app eseguita in primo piano e riduce il consumo energetico complessivo del sistema. Un consumo energetico ridotto contribuisce a prolungare la durata della batteria del sistema tra una ricarica e l'altra. Per le app che devono essere necessariamente eseguite in background, ad esempio VoIP (Voice over Internet Protocol), messaggistica immediata (IM) e email, questo nuovo modello fornisce inoltre un meccanismo che assicura all'utente finale un'esperienza di connessione continua. In altre parole, l'app che dipende da una connessione di lunga durata a un server remoto può comunque continuare a funzionare quando viene sospesa. Si tratta quindi di conciliare due esigenze opposte: da un lato la richiesta di connessione continua da parte di un'app in tempo reale, dall'altro la riduzione del consumo energetico e la velocità di risposta dell'app.

Per abilitare le connessioni di rete in tempo reale per un'app di Windows Runtime scritta in JavaScript che deve essere sempre connessa, è possibile usare diverse nuove funzionalità introdotte in Windows 8:

Attività in background
Trigger di sistema per SessionConnected
Trigger a tempo
Servizi di notifica Push Windows (WNS)
Notifiche push non elaborate

Queste funzionalità forniscono supporto alle app sempre connesse che devono ricevere notifiche push non elaborate quando un'app di Windows Runtime è sospesa. Queste app hanno la caratteristica di essere sempre raggiungibili. Questo argomento tratta soprattutto di come uno sviluppatore può usare WNS e le notifiche push non elaborate per creare un'app in tempo reale sempre connessa. Queste funzionalità richiedono che l'app sia nella schermata di blocco.

Un'app di rete può usare anche altre funzionalità per le attività in background. Alcuni dei trigger che possono essere usati con un'app di Windows Runtime sono:

Trigger di manutenzione (eventi tempo periodici per la manutenzione)
Trigger di sistema per utenti e sessioni (sessione utente connessa/disconnessa, utente presente/assente e cambio di ID in linea)
Trigger di sistema per lo stato della rete (cambio di stato della rete, Internet disponibile/non disponibile)
Trigger di sistema per la schermata di blocco (aggiunta/rimozione dell'app)

Il trigger a tempo può essere usato quando un'app non necessita di connettività in tempo reale, ma deve essere eseguita per un breve periodo di tempo a determinati intervalli. Il trigger di sistema può essere usato quando un'app deve poter riconoscere gli eventi (ad esempio, la disponibilità della connettività a Internet o la presenza dell'utente). In un'app è possibile usare una combinazione di trigger, che consentono di prevedere svariati scenari. Per altre informazioni, vedi Supporto dell'app con le attività in background.

Per la maggior parte delle app di Windows Runtime non sarà necessario usare le notifiche push, descritte in dettaglio in questo argomento. Un'app può dare l'impressione all'utente di essere sempre in esecuzione in background lasciando visibile un riquadro animato o usando un riquadro animato con notifiche push (che non siano notifiche push non elaborate) da WNS. Per poter usare un riquadro animato, non è necessario che l'app sia aggiunta alla schermata di blocco (vedi la descrizione più avanti in questo argomento), né che sia eseguita in background. Tuttavia, per poter usare un riquadro animato con notifiche push non elaborate, l'app deve essere stata aggiunta alla schermata di blocco.

Requisiti per la connessione ininterrotta

Per avere un'app sempre connessa e raggiungibile servono in genere due elementi:

Un processo di lunga durata per assicurare che tutte le notifiche di rete in entrata vengano ricevute e possano essere elaborate rapidamente dall'app.
Una connessione di rete di lunga durata a un endpoint remoto che possa ricevere e inviare dati all'occorrenza.

Nelle versioni precedenti di Windows. le app restano in esecuzione quando non soon attive (in background). Quando sono in background, le app possono mantenere aperte connessioni di lunga durata poiché possono inviare e ricevere dati e messaggi keep-alive. Lasciare le app in esecuzione in background comporta però un consumo di risorse notevole, che può pregiudicare la velocità di risposta delle altre app e la durata della batteria.

App di Windows Runtime e schermata di blocco

In Windows 8 è stato incluso un nuovo modello software che sospende le app di Windows Runtime quando vengono spostate in background. Quando un'app viene sospesa, può succedere che eventuali pacchetti ricevuti dal sistema non vengano consegnati immediatamente e che eventuali pacchetti di rete in entrata vengano eliminati. Mentre l'app è sospesa non vengono inviati nuovi pacchetti e di conseguenza è possibile che le connessioni di rete esistenti vengano chiuse.

Per essere sempre connessa, un'app deve essere aggiunta alla schermata di blocco. L'app aggiunta alla schermata di blocco è uno speciale tipo di app in grado di visualizzare notifiche nella schermata di blocco ed eseguire codice in background quando non è in primo piano. Solo le app che prevedono una o più attività in background possono essere aggiunte alla schermata di blocco.

Le app nella schermata di blocco possono:

Ricevere una notifica push da WNS che esegue codice alla ricezione della notifica.
Eseguire codice in presenza di un trigger a tempo.
Eseguire codice all'avvio di una sessione utente.

Quando sono in background, le app nella schermata di blocco possono segnalare all'utente la presenza di nuove informazioni tramite l'aggiornamento e la visualizzazione di un'icona di notifica in corrispondenza delle nuove informazioni nella schermata di blocco. Queste app possono inoltre visualizzare una notifica su schermo all'arrivo di un messaggio. Se l'utente tocca o fa clic sulla notifica, viene invitato a sbloccare il dispositivo. Quando il dispositivo è sbloccato, l'app cui fa riferimento la notifica viene avviata con informazioni contestualizzate.

Le app nella schermata di blocco devono rispettare alcune limitazioni. La schermata di blocco può includere al massimo sette app alla volta. L'utente può aggiungere o rimuovere un'app dalla schermata di blocco in qualsiasi momento.

Le app della schermata di blocco sono perfette per mostrare all'utente le informazioni che potrebbero essergli sfuggite mentre si trovava lontano dal dispositivo, oltre che per visualizzare sullo schermo notifiche di eventi che possono richiedere un intervento tempestivo, ad esempio una telefonata in arrivo, un messaggio immediato o un'email urgente.

La maggioranza delle app non deve essere aggiunta alla schermata di blocco. Quando un'app è sospesa in background, puoi usare le notifiche push (diverse dalle notifiche push non elaborate) da WNS per aggiornare un riquadro animato e dare agli utenti l'impressione che l'app è in esecuzione e che il contenuto viene costantemente rinnovato. Le app possono usare WNS anche per generare una notifica di tipo avviso popup in qualsiasi momento o per aggiornare il conteggio delle notifiche nel riquadro di un'app.

Poiché gli spazi a disposizione delle app nella schermata di blocco sono limitati, dovresti programmare l'app in modo tale da poter funzionare anche senza le autorizzazioni per le app nella schermata di blocco. L'utente deve acconsentire in modo esplicito all'aggiunta di un'app alla schermata di blocco. La tua app dovrebbe funzionare sempre quando è visibile in primo piano. Se un'app è stata aggiunta alla schermata di blocco, significa semplicemente che può supportare alcuni degli stessi scenari mentre è in background.

C'è una funzionalità che consente a un'app scritta in JavaScript e in HTML di ricevere pacchetti di rete in ingresso quando è eseguita in background

Notifiche push non elaborate ricevute dal sistema che, conseguentemente, eseguono un'attività in background nell'app. Con questa funzionalità l'app riceve i dati non elaborati dai Servizi notifica Push Windows (WNS). I contenuti di questi dati devono essere compresi dall'app. L'app deve effettuare la registrazione a WNS per ricevere le notifiche push non elaborate.

Molti dei meccanismi descritti di seguito possono servire per abilitare gli scenari in tempo reale per le app che vengono aggiunte alla schermata di blocco. Ognuno presenta vantaggi e svantaggi. Questi meccanismi non si escludono a vicenda e possono essere combinati insieme in alcune app.

Uso di WNS nelle app di Windows Store

WNS è un servizio cloud di Microsoft per Windows 8 che può essere usato dalle app di Windows Runtime per ricevere notifiche in grado di eseguire codice, aggiornare un riquadro animato o generare una notifica su schermo. Per poter usare WNS, è necessario che il computer locale sia connesso a Internet in modo da poter comunicare con il servizio WNS. Per altre informazioni, vedi Panoramica delle notifiche push.

Un'app di Windows Runtime in primo piano può usare WNS per aggiornare riquadri animati, generare notifiche per l'utente o aggiornare notifiche badge. Per poter accedere a WNS, non è necessario che l'app sia stata aggiunta alla schermata di blocco. Se hai necessità di eseguire codice in risposta a una notifica push, prendi in considerazione la possibilità di usare WNS nella tua app.

Per le app che non devono essere necessariamente aggiunte alla schermata di blocco (cioè per la maggioranza delle app), WNS può servire per fornire un aggiornamento del riquadro animato.

Se aggiungi la tua app di Windows Runtime alla schermata di blocco e usi WNS in background, l'app può ricevere notifiche push non elaborate da WNS in tempo reale e visualizzarle nella schermata di blocco come aggiornamento di una notifica badge o come notifica. Quando una notifica push non elaborata viene consegnata a un'app della schermata di blocco, l'app può eseguire codice in risposta alla notifica. L'uso di WNS può essere energeticamente più efficiente rispetto all'uso dei trigger disponibili per le app di Windows Store scritte in C++/XAML e le app che usano .NET Framework 4.5 in C#, VB.NET o C++ gestito in Windows 8.1 e Windows Server 2012 R2.

I vantaggi offerti da WNS sono molteplici:

WNS offre il meccanismo più efficiente sul piano energetico per la consegna di notifiche in tempo reale alle app nella schermata di blocco.
WNS semplifica il modello di sviluppo per la tua app. Nella maggioranza degli scenari, gli sviluppatori non devono scrivere nessuna attività in background, perché è il sistema operativo a eseguire il rendering di riquadri o avvisi popup. In una piccola minoranza di scenari, se la tua app deve eseguire un'attività in background dovrà registrare solo la notifica push non elaborata e l'attività in background da eseguire.
Non serve mantenere nessuna connessione persistente del socket tra l'app client e un server remoto, in quanto è Windows a preservare la connessione a WNS. Di conseguenza non è previsto alcun sovraccarico per l'invio di messaggi keep-alive.
Basta una sola connessione WNS tra il client e il servizio cloud per supportare tutte le app nel computer locale, con un potenziale prolungamento della durata della batteria per il client.
I costi operativi per il servizio lato server possono diminuire perché non è necessario mantenere molte connessioni al socket TCP disattivate tra il client e il servizio remoto.
Non è necessario che la tua app sia in memoria in ogni momento, perché può essere interrotta e WNS continuerà comunque ad aggiornare il riquadro, a generare un avviso popup o ad attivare un'attività in background che verrà eseguita alla ricezione di una notifica push non elaborata in entrata.
Le attività in background che usano notifiche push possono essere scritte in C++/XAML e con .NET Framework 4.5 in C#, VB.NET o C++ gestito in Windows 8.1 e Windows Server 2012 R2.

La funzionalità trigger di rete con ControlChannelTrigger non è disponibile in JavaScript.

Nota ControlChannelTrigger non è supportato in Windows Phone

La connettività di rete in background che usa i trigger di rete può essere scritta solo in C++/XAML e con .NET Framework 4.5 in C#, VB.NET o C++ gestito in Windows 8 e Windows Server 2012. Per altre informazioni, vedi Come mantenere la connessione in background.

WNS deve rispettare alcune limitazioni che possono influenzare negativamente le app. WNS non è disponibile per un computer locale connesso a una rete privata domestica o aziendale che blocca l'accesso pubblico a Internet. Inoltre WNS può essere bloccato da alcuni firewall di rete anche quando l'accesso a Internet è disponibile. Forse vale la pena riflettere su alcuni svantaggi legati all'uso di WNS. Nello specifico, la consegna delle notifiche si basa sul principio del best effort e non è sempre garantita. Le dimensioni massime del payload di una notifica push non elaborata sono pari a 5 kilobyte.

Alla luce dei vantaggi offerti, consigliamo agli sviluppatori di app VoIP, IM o email di prendere in considerazione l'uso delle notifiche WNS per le app nella schermata di blocco e di pensare a soluzioni alternative qualora i requisiti necessari non possano essere soddisfatti.

Non serve creare un'app da aggiungere alla schermata di blocco se basta aggiornare il riquadro animato o generare un avviso popup tramite WNS. L'app nella schermata di blocco è necessaria con WNS solo se serve una notifica push non elaborata per attivare un'attività in background da eseguire.

Uso dei trigger a tempo o dei trigger evento di sistema nelle app di Windows Runtime

Le app nella schermata di blocco possono essere configurate in modo tale da eseguire codice periodicamente usando un trigger a tempo con un intervallo minimo di 15 minuti. Un esempio può essere il polling di nuovi messaggi email, magari quando un'app è connessa a un server email POP3 o IMAP.

Le app nella schermata di blocco possono anche usare un trigger evento di sistema per eseguire codice quando l'utente accede al computer locale (trigger di sistema per avvio sessione). Un esempio può essere l'accesso dell'utente a un servizio di messaggi immediati all'avvio della sessione utente, abilitando la ricezione dei messaggi immediati.

In questo argomento ci concentriamo sulla creazione di app della schermata di blocco che usano notifiche push non elaborate con WNS o con la funzionalità trigger di rete. Per altre informazioni sull'uso di un timer, vedi Come eseguire un'attività in background mediante timer. Per altre informazioni sulle attività in background, vedi Supporto dell'app con attività in background.

Attività in background e sandboxing

La durata dell'attività in background è determinata dalla funzione che implementa l'attività in background. Per assicurarsi che le attività in background non influiscano negativamente sulla durata della batteria, Windows applica un limite in termini di risorse CPU e risorse di I/O di rete utilizzabili dall'app durante le attività in background. Ogni app riceve periodicamente una quota di queste risorse e quando la esaurisce le attività in background dell'app vengono sospese. L'app deve essere resiliente alla sospensione per sandboxing.

Per altre informazioni, vedi Supporto dell'app con attività in background.

Altri passaggi

Per altre informazioni su come creare un'app della schermata di blocco per ricevere le notifiche di rete in background che utilizzano le notifiche push non elaborate, vedi Come creare un'app della schermata di blocco che usa notifiche push in background non elaborate.

Per altre informazioni sulla procedura di registrazione di un canale di notifica push e di invio al server, registra un'attività in background da attivare a partire da una notifica push, quindi invia una notifica push non elaborata al canale e attiva l'attività in background, vedi Come usare WNS per recapitare notifiche push non elaborate a un'app nella schermata di blocco.

Per altre informazioni su come scrivere un'attività in background per ricevere le notifiche di rete in background che utilizzano le notifiche push non elaborate, vedi Guida introduttiva: Come scrivere un'attività in background per le notifiche push non elaborate.

Per altre informazioni su linee guida ed elenchi di controllo per l'uso delle notifiche push non elaborate, vedi Linee guida ed elenco di controllo per le notifiche non elaborate.