Esperienza e interfaccia utente

  • Articolo

Le finestre ridimensionabili offrono agli utenti un maggiore controllo sull'utilizzo della tua app. Le nuove funzionalità consentono di sfruttare al meglio il riquadro dell'app. Gli aggiornamenti di funzioni di ricerca, funzioni di condivisione e accessi consentono di creare un'esperienza generale più coerente per gli utenti.

Funzionalità nuove o aggiornate in Windows 8.1

  • Finestre ridimensionabili
  • Aggiornamenti dei riquadri
  • Aggiornamenti delle funzioni di ricerca
  • Aggiornamenti delle funzioni di condivisione
  • Accessi utilizzabili da tutte le schermate
  • Integrazione con contatti ed eventi
  • Sintesi vocale
  • Aggiornamenti alla gestione delle attività in background
  • Supporto delle app di avviso nella schermata di blocco
  • Aggiornamenti alla pianificazione degli elementi di lavoro

Finestre ridimensionabili

[Recupera ora gli esempi Visualizzazione applicazioni, Visualizzazioni multiple e Gestione proiezione.]

In Windows 8.1 sono state apportate diverse modifiche alle dimensioni e alla posizione delle finestre. Ecco gli aspetti principali da tenere presenti quando si sviluppano app per Windows 8.1:

  • Windows 8.1 non prevede stati di visualizzazione a larghezza fissa. Gli utenti possono ora ridimensionare ripetutamente le app fino a una larghezza minima. La larghezza minima predefinita di un'app è 500 pixel. Pertanto, non sono più disponibili gli stati di visualizzazione ancorato e di riempimento. Devi pertanto sviluppare l'app in modo che risulti funzionale e ben strutturata a qualsiasi dimensione, fino a quella minima.

    Nota  La visualizzazione ancorata in Windows 8 è di larghezza pari a 320 pixel. La larghezza minima predefinita di 500 pixel è maggiore di quella della visualizzazione ancorata di Windows 8.

  • Se la tua app funziona bene con le dimensioni più piccole e vuoi incoraggiare gli utenti a mantenere l'app sullo schermo, puoi ridurre la larghezza minima fino a 320 pixel.

  • Gli utenti possono tenere più di due app sullo schermo contemporaneamente. Un'app può quindi trovarsi tra due altre app e non adiacente al bordo sinistro o destro dello schermo.

  • È possibile aprire più finestre di un'app contemporaneamente.

  • Un'app può avviare un'altra app. In tal caso, lo schermo viene in genere suddiviso in parti uguali tra le due app se lo spazio è sufficiente. Puoi modificare questo comportamento in modo che l'app avviata sia più larga o più stretta di quella originale o addirittura che la sostituisca sullo schermo. Per modificare il comportamento predefinito, usa la proprietà DesiredRemainingView.

Le app devono occupare per intero l'altezza dello schermo, come in Windows 8. L'altezza minima di un'app è 768 pixel.

Requisiti in pixel per la larghezza minima e le dimensioni minime predefinite di un'app

Linee guida sulla progettazione di finestre ridimensionabili

Quando progetti un'app per Windows 8.1, devi:

  • Accertarti che il layout e tutti i controlli dell'app possano adattarsi alla dimensione minima. Considera, in particolare, l'impatto delle dimensioni dell'app su questi controlli:

  • Progettare l'app affinché usi in modo efficiente lo spazio sugli schermi di grandi dimensioni e sia provvista di un layout in grado di adattarsi automaticamente a dimensioni inferiori. Non lasciare ampi spazi vuoti.

  • Se imposti la larghezza minima su 320 pixel, progetta l'app in modo che si adatti alle dimensioni minime (ovvero quelle di larghezza compresa tra 320 e 500 pixel) nei modi seguenti:

Sono disponibili ulteriori esempi di layout per finestre che si ridimensionano con una larghezza di 320 pixel e finestre la cui altezza supera la larghezza. Per altre informazioni sull'uso degli accessi per un'app indipendentemente dalle dimensioni dell'app, vedi Accessi utilizzabili da tutte le schermate.

Impostazione della larghezza minima

Se desideri impostare la larghezza minima di un'app su un valore diverso da quello predefinito di 500 pixel, specifica l'attributo MinWidth dell'elemento ApplicationView nel manifesto dell'app.

<Application>
   <VisualElements>
      <ApplicationView MinWidth=”width320” />
   </VisualElements>
</Application>

Per ulteriori informazioni sul manifesto dell'app, vedi Manifesto di pacchetto dell'app.

Aggiornamenti alla classe ApplicationView

In Windows 8.1, lo spazio dei nomi Windows.UI.ViewManagement include queste nuove enumerazioni:

La classe ApplicationView presenta inoltre queste nuove proprietà:

ApplicationView e i nuovi metodi:

In Windows 8.1, questi membri sono stati deprecati:

Aggiornamenti dei riquadri

[Accedi agli esempi di riquadri e notifiche delle app e di riquadri secondari ora.]

In Windows 8.1 sono state introdotte le modifiche seguenti ai riquadri e al loro uso.

Nuove dimensioni dei riquadri

In Windows 8 sono previste due tipologie di dimensioni per i riquadri:

  • Riquadri quadrati (150×150 pixel al plateau di ridimensionamento 1x).
  • Riquadri larghi (310×150 pixel al plateau 1x).

In Windows 8.1 sono previste due tipologie di dimensioni aggiuntive:

  • Riquadri piccoli (70×70 pixel al plateau 1x).
  • Riquadri grandi (310×310 pixel al plateau 1x).

Poiché tre dei quattro tipi di modello sono ora quadrati, i riquadri denominati "quadrati" in Windows 8 (150×150 al plateau 1x) vengono ora chiamati riquadri "medi". Il set completo include quindi i riquadri piccoli, medi, larghi e grandi. Ecco alcuni esempi delle quattro tipologie.

Esempio delle quattro possibili dimensioni dei riquadri nella schermata Start

Un utente può tenere quattro riquadri piccoli nello spazio che occuperebbe un riquadro medio. I riquadri piccoli non supportano le notifiche dei riquadri animati, ma supportano le notifiche normali. Un riquadro grande occupa la quantità di spazio di due riquadri larghi e supporta le notifiche dei riquadri animati esattamente come i riquadri di Windows 8.

Nuove convenzioni di denominazione per i modelli di riquadro

Con l'aggiunta delle nuove dimensioni dei riquadri, sono state aggiornate le convenzioni di denominazione di Windows 8 per i modelli di riquadro. Le nuove convenzioni usano le dimensioni in pixel assolute al plateau di ridimensionamento 1×. Le quattro tipologie di riquadro sono associate ai nuovi nomi seguenti. Ogni categoria dispone di numerosi modelli:

  • Piccolo = Square70x70
  • Medio = Square150x150
  • Largo = Wide310x150
  • Grande = Square310x310

Analogamente, l'attributo SmallLogo è ora denominato Square30x30Logo nel manifesto dell'app.

Tutti i modelli di riquadro esistenti sono stati rinominati in base alle nuove convenzioni.

Nome precedente Nuovo nome Esempio
TileSquare* TileSquare150x150* TileSquareImage (nome precedente)/TileSquare150x150Image (nuovo nome)
TileWidexxx TileWide310x150xxx TileWideImageAndText01 (nome precedente) / TileWide310x150ImageAndText01 (nuovo nome)

 

Per motivi di compatibilità, i nomi precedenti sono comunque riconosciuti. Usa tuttavia i nuovi nomi per le attività di sviluppo future.

Modifiche correlate ai riquadri nel manifesto dell'app

Nel manifesto dell'app occorre dichiarare le proprietà predefinite del riquadro principale dell'app, ovvero le dimensioni supportate, il nome visualizzato e il colore.

Inclusione delle nuove dimensioni dei riquadri

In Windows 8 si sceglie di includere il supporto del riquadro largo specificando un apposito asset nel manifesto dell'app. In Windows 8.1 si sceglie di includere il supporto del riquadro grande (Square310x310) specificando un apposito asset nel manifesto.

Nota  L'app può supportare un riquadro grande solo se supporta anche quello largo.

Tutte le app supportano i riquadri medi (Square150x150) e piccoli (Square70x70). Puoi specificare asset di riquadri piccoli nel manifesto. Se l'app non dispone di un'immagine di riquadro piccolo, attraverso operazioni di ridimensionamento o mediante un asset distinto, Windows 8.1 ridimensiona automaticamente l'immagine del riquadro medio.

Come per Windows 8, consigliamo di specificare per ogni dimensione di riquadro supportata asset distinti per i quattro plateau di ridimensionamento (0,8x, 1x, 1,4x e 1,8x). In questo modo, i riquadri risultano sempre nitidi e senza difetti dovuti al ridimensionamento. Per migliorare l'accessibilità, puoi specificare asset di immagine per il tema a contrasto elevato.

Visualizzazione del nome dell'app per le diverse dimensioni dei riquadri

In Windows 8 si usa il manifesto dell'app per specificare i tipi di riquadro in cui visualizzare il nome dell'app. Ciò vale anche in Windows 8.1, ma il formato da usare è diverso. Tieni presente che non puoi visualizzare il nome dell'app nel riquadro piccolo (Square70x70).

Dichiarazione delle dimensioni di aggiunta predefinite

In Windows 8 le app vengono aggiunte alla schermata Start con il riquadro grande, se disponibile, o con il riquadro medio in caso contrario. In Windows 8.1, puoi ignorare questo comportamento predefinito e dichiarare il riquadro medio o largo (ma non quello piccolo o quello grande) come dimensione di aggiunta predefinita. Non dimenticare che in Windows 8.1 le app non vengono aggiunte automaticamente alla schermata Start al momento dell'installazione. Esse vengono incluse nella visualizzazione Tutte le app da cui l'utente può scegliere di aggiungerle alla schermata Start.

Modifiche allo schema del manifesto dell'app

Ora puoi specificare nel manifesto uno spazio dei nomi aggiuntivo, "https://schemas.microsoft.com/appx/2013/manifest", per includere gli elementi dello schema che dichiarano la nuova funzionalità che abbiamo illustrato. L'esempio seguente mostra alcuni degli attributi nuovi e rinominati presenti nel manifesto. Puoi notare l'asset di riquadro grande incluso nell'elemento DefaultTile, che dichiara inoltre in modo esplicito una dimensione predefinita preferita. È inoltre possibile scegliere di visualizzare il nome dell'app solo nei riquadri medi e larghi e non in quello grande.

<Package 
    xmlns="https://schemas.microsoft.com/appx/2010/manifest" 
    xmlns:wb="https://schemas.microsoft.com/appx/2013/manifest">
    
...

<wb:VisualElements 
    DisplayName="Your app name" 
    Description="App description" 
    BackgroundColor="#464646" 
    ForegroundText="light" 
    ToastCapable="true" 
    Square150x150Logo="Assets\Medium150x150Tile.png" 
    Square30x30Logo="Assets\APVLogo.png">
    
    <wb:DefaultTile 
        Square70x70Logo="Assets\Small70x70Tile.png" 
        Wide310x150Logo="Assets\Wide310x150Tile.png" 
        Square310x310Logo="Assets\Large310x310Tile.png" 
        ShortName="App" 
        DefaultSize="square150x150Logo">
        
        <wb:ShowNameOnTiles>
            <wb:ShowOn Tile="square150x150Logo"/>
            <wb:ShowOn Tile="wide310x150Logo"/> 
        </wb:ShowNameOnTiles>
    </wb:DefaultTile>
    
    <wb:LockScreen 
        Notification="badgeAndTileText" 
        BadgeLogo="Assets\badge.png"/>
    
    <wb:SplashScreen Image="Assets\SplashScreen.png"/>
</wb:VisualElements>

Modifiche alle notifiche dei riquadri

Per l'invio di notifiche dei riquadri, tieni presente che possono essere ricevute sia su Windows 8.1 che su Windows 8. Poiché i nuovi nomi dei modelli esistenti sono riconosciuti solo da Windows 8.1, nello schema è stato aggiunto un attributo fallback. Includendo l'attributo fallback, nel payload della notifica è possibile specificare un modello di Windows 8.1 insieme a un modello di Windows 8 nell'eventualità che la notifica venga ricevuta su un sistema Windows 8. Per usare i nuovi nomi dei modelli e l'attributo fallback, includi il nuovo attributo version e impostalo sul valore 2 nell'elemento visual, come illustrato qui.

<tile>
  <visual version="2">
    <binding template="TileSquare150x150Image" fallback="TileSquareImage" branding="None">
      <image id="1" src="Assets/Images/w6.png"/>
    </binding>
    <binding template="TileWide310x150Image" fallback="TileWideImage" branding="None">
      <image id="1" src="Assets/Images/sq5.png"/>
    </binding>
    <binding template="TileSquare310x310Image" branding="None">
      <image id="1" src="Assets/Images/sq6.png"/>
    </binding>
  </visual>
</tile>

Tieni presente che non puoi usare l'attributo fallback con i riquadri grandi perché essi non esistono in Windows 8. Le notifiche di Windows 8 funzionano correttamente su Windows 8.1 senza necessità di modifiche, ma non sono compatibili con i riquadri grandi.

Nota  L'eventuale modello di riquadro grande (Square310x310) incluso nel payload deve essere l'ultima associazione in elenco. Nei sistemi Windows 8, infatti, l'analisi della notifica viene interrotta se si rileva un'associazione non riconosciuta tramite il nome di modello o di fallback. Pertanto, essa si interrompe sempre quando viene rilevata l'associazione 310×310.

Impostazione delle dimensioni dei riquadri per la coda di notifica

Quando in Windows 8 abiliti la coda di notifica, l'abilitazione si applica ai riquadri medi e larghi. In Windows 8.1 alla classe TileUpdater sono stati aggiunti metodi che permettono di abilitare la coda di notifica per dimensioni di riquadro specifiche.

Nuove dimensioni dei riquadri e logo alternativi nei riquadri secondari

In Windows 8.1, il riquadro a comparsa visualizzato quando gli utenti aggiungono contenuti come riquadro secondario consente di scorrere e scegliere le dimensioni e le tipologie disponibili come riquadri secondari. Il riquadro secondario può essere di qualsiasi dimensione supportata dai riquadri dell'app. Se non specifichi un'immagine di riquadro piccola per il riquadro secondario, verrà ridimensionata e usata l'immagine del riquadro quadrato.

Oltre all'immagine del riquadro secondario predefinita, puoi specificare fino a tre versioni alternative per ogni dimensione di riquadro, per un massimo di 12 versioni. Usando il metodo AlternateVisualElements, puoi anche specificare un logo piccolo alternativo per ognuna delle tre dimensioni di riquadri che supportano i logo (quadrato, largo e grande).

Stringa fonetica più accurata per l'ordinamento dei riquadri secondari

In alcune lingue basate su caratteri come il giapponese l'ordinamento nell'interfaccia utente si basa sull'ortografia fonetica dei caratteri che costituiscono il nome visualizzato dell'app. L'ortografia fonetica rappresenta una stringa distinta dal nome visualizzato. Quando si aggiunge un riquadro secondario, gli utenti possono specificare un nome visualizzato nel riquadro a comparsa per l'aggiunta a Start ma non possono specificare un'ortografia fonetica. Windows tenta di individuare la stringa fonetica, tuttavia la supposizione del sistema non sempre è corretta.

Le app talvolta conoscono la stringa fonetica corretta perché l'utente l'ha definita tramite un controllo personalizzato disponibile nell'app stessa. In Windows 8.1, l'app può quindi passare tale stringa al sistema tramite la nuova proprietà SecondaryTile.PhoneticName. Tieni presente che la stringa del nome fonetico è legata al nome visualizzato predefinito associato al riquadro secondario. Pertanto, se l'utente cambia il nome visualizzato nel riquadro a comparsa per aggiungere a Start, viene usata invece l'ortografia fonetica individuata in base alla supposizione del sistema.

Aggiornamenti delle funzioni di ricerca

[Recupera ora l'esempio del controllo SearchBox.]

In Windows 8.1 è stato introdotto un nuovo controllo casella di ricerca per agevolare la restituzione dei risultati: Windows.UI.Xaml.Controls.SearchBox per le app in XAML e WinJS.UI.SearchBox per le app in JavaScript.

Le app possono ora includere la casella di ricerca come elemento del markup. Il nuovo controllo supporta modelli e stili.

In Windows 8.1, l'esperienza di ricerca dell'app viene controllata completamente dall'app stessa. La casella di ricerca è integrata con il contratto Ricerca per migliorare le prestazioni e consentire una profonda personalizzazione. In questo modo, le app possono offrire esperienze di ricerca su misura per le esigenze degli utenti.

La casella di ricerca supporta i risultati e i suggerimenti di ricerca offerti dall'app, la cronologia di ricerca specifica dell'app nonché le interazioni con tocco, tastiera e mouse.

Ecco come appare il layout della casella di ricerca.

Controllo casella di ricerca in-app per app di Windows Store

Ecco un esempio di risultati visualizzati nel controllo casella di ricerca.

Esempio di risultati della casella di ricerca per MSFT.

Il controllo casella di ricerca supporta l'integrazione di IME (Input Method Editor).

Controllo di ricerca in-app con IME.

Con un IME, i suggerimenti vengono aggiornati durante la digitazione. I suggerimenti includono ideogrammi cinesi basati su un input fonetico parziale. L'interfaccia utente dei candidati IME non nasconde il riquadro a comparsa dei suggerimenti di ricerca. La casella di ricerca consente l'uso dell'input da tastiera per lo spostamento nella casella di testo, nell'elenco dei candidati IME e nei suggerimenti di ricerca.

Aggiornamenti delle funzioni di condivisione

[Accedi agli esempi di condivisione dell'origine di contenuto e di condivisione della destinazione di contenuto ora.]

Ecco le modifiche introdotte in Windows 8.1 per l'esperienza di condivisione e la modalità di utilizzo del contratto di condivisione nelle app.

Aggiunta di nuovi formati di dati a DataPackage

In Windows 8.1 le app di origine per il contratto di condivisione possono fornire più modalità per risalire al contenuto condiviso. Windows 8.1 suddivide il formato Uri in due nuovi formati di dati in DataPackage e introduce quattro nuove proprietà fortemente tipizzate in DataPackagePropertySet. Per DataPackage, il formato Uri è deprecato e sostituito dai formati WebLink e ApplicationLink.

WebLink è condiviso quando l'utente non seleziona nulla, pertanto l'app di origine condivide una selezione implicita del contenuto visualizzato. Popolando questo formato, l'app di origine condivide il contenuto della pagina corrente come URI (Uniform Resource Identifier). Il collegamento condiviso fa riferimento alla pagina Web visualizzata dall'utente, pertanto questo formato inizia sempre con http o https.

Anche ApplicationLink viene condiviso quando l'utente non seleziona nulla, quindi anche in questo caso l'app di origine condivide una selezione implicita del contenuto visualizzato. Popolando questo formato, l'app di origine condivide il contenuto della pagina corrente come URI. Lo schema dell'URI condiviso è gestito dall'app di origine. Quando l'app di origine viene attivata con questo protocollo URI, visualizza lo stesso contenuto attualmente visitato. Questo formato rappresenta il contenuto condiviso offrendo un modo per tornare al contenuto mediante un protocollo dell'app.

I formati WebLink e ApplicationLink non si escludono a vicenda. WebLink collega il contenuto sul Web e ApplicationLink collega il contenuto in un'app. Un'app per la lettura di notizie, ad esempio, può presentare contenuti in entrambi i formati, con un URI che consente di tornare all'articolo nell'app o un URI per visualizzare il medesimo articolo su un sito Web. La scelta della modalità di gestione dell'URI dipende dall'app di destinazione. Ad esempio, l'app Mail può usare il formato WebLink perché il collegamento può essere inviato a Internet e utilizzato da un sistema non Windows. L'app di lettura delle notizie invece può usare il formato ApplicationLink in modo da riattivare l'app di origine e riportare l'utente al contenuto originale.

ContentSourceWebLink è una proprietà complementare usata per attribuire il contenuto condiviso. La condivisione viene applicata se l'app fornisce un link Web al contenuto condiviso. Se l'utente effettua una selezione esplicita, il formato WebLink non viene popolato perché il valore del formato WebLink non corrisponde alla selezione dell'utente. Il popolamento di queste informazioni non implica che la selezione dell'utente corrisponda alla pagina Web, bensì che il contenuto provenga da tale pagina.

ContentSourceApplicationLink è la seconda proprietà complementare usata per attribuire il contenuto condiviso. La condivisione viene applicata quando è importante che l'utente torni al contenuto attualmente visualizzato nell'app. Se l'utente effettua una selezione, il formato ApplicationLink non viene popolato perché il valore del formato ApplicationLink non corrisponde in questo caso alla selezione dell'utente. Il popolamento di queste informazioni non implica che il collegamento diretto nell'app rappresenti la selezione dell'utente, bensì che il contenuto provenga da tale selezione.

Supponi ad esempio che un utente stia leggendo un articolo in un'app di lettura di notizie. L'utente seleziona una frase e la condivide con OneNote. Per attribuire la frase all'articolo, l'app di lettura non usa il formato WebLink o ApplicationLink, perché l'articolo non equivale alla frase condivisa. L'app usa invece le proprietà ContentSourceWebLink e ContentSourceApplicationLink. OneNote aggiunge il testo selezionato con l'attribuzione dell'origine. Successivamente, in OneNote l'utente può leggere la frase e tornare all'app di lettura o alla pagina Web per leggerne il contesto.

Miglioramento delle prestazioni di condivisione

In Windows 8.1, le app che usano il contratto di condivisione possono migliorare le prestazioni ignorando il riquadro di condivisione a livello di codice.

Chiama il nuovo metodo DismissUI per chiudere il riquadro di condivisione. La chiamata a DismissUI ha un effetto analogo a quando l'utente chiude il riquadro di condivisione toccando un punto al suo esterno. Se l'operazione di condivisione richiede troppo tempo, l'app continua a essere eseguita. Se l'esecuzione dell'operazione non si prolunga, vi sono 10 secondi di attesa prima che venga terminata.

L'app di destinazione non può essere in questo momento spostata fuori dalla schermata. Pertanto, quando si avvia un'operazione di condivisione, l'app in genere mostra un indicatore di stato e l'utente attende che l'attività venga completata (anche se non è necessario intervento da parte dell'utente). Sebbene sia sicuro chiudere il riquadro a comparsa con un tocco leggero, gli utenti tendono a pensare che chiuderlo prima del completamento dell'operazione possa causare una perdita di dati, pertanto in genere non lo fanno. DismissUI consente di chiudere il riquadro a comparsa automaticamente.

Nome della famiglia di pacchetti

In Windows 8.1, le app di origine per il contratto di condivisione possono specificare un nome della famiglia di pacchetti alle app di destinazione in modo che queste ultime possano offrire un'esperienza di fallback all'avvio dell'app specificata da ApplicationLink.

Il nome della famiglia di pacchetti è l'identificatore univoco di un pacchetto di app. Quando un'app di origine fornisce questo identificatore all'app di destinazione, quest'ultima può offrire un'esperienza di fallback chiamando il metodo LaunchUriAsync con il ApplicationLink specificato. Se lo schema dell'URI non è gestito perché ad esempio l'utente ha disinstallato l'app oppure l'URI è in comune con un altro dispositivo in cui l'app non è installata, viene visualizzata una finestra di dialogo che richiede di cercare un'app in Windows Store. Per impostazione predefinita, l'utente viene portato allo Store, ma non all'app richiesta. Se si include il nome della famiglia di pacchetti nell'oggetto LauncherOptions passato a LaunchUriAsync, viene richiesto all'utente di installare un'app specifica e viene visualizzata la pagina apposita dello Store.

Il formato Uri è stato deprecato

Come accennato in precedenza, in Windows 8.1 il formato Uri è suddiviso in due nuovi formati di dati in DataPackage e sono state introdotte quattro nuove proprietà fortemente tipizzate in DataPackagePropertySet. Per DataPackage, il formato Uri è deprecato e sostituito dai formati WebLink e ApplicationLink. Il formato Uri rimane come alias per il formato WebLink.

Accessi utilizzabili da tutte le schermate

Quando in Windows 8 sono presenti più app sullo schermo e l'utente richiama gli accessi, il sistema visualizza gli accessi per l'app che occupa più spazio sullo schermo. In Windows 8.1, invece, il sistema visualizza gli accessi per l'ultima app con cui ha interagito l'utente, indipendentemente dal numero di app presenti sullo schermo e dall'eventuale uso di più schermi. Se ad esempio l'utente seleziona l'accesso alle impostazioni, viene visualizzato il riquadro a comparsa Impostazioni relativo all'ultima app usata.

Puoi progettare quindi la tua app in modo che funzioni con gli accessi indipendentemente dalle dimensioni dell'app. In particolare, la larghezza dell'accesso alle impostazioni deve essere inferiore o uguale alla larghezza corrente dell'app.

Creare app integrate con contatti ed eventi

[Vedi ora gli esempi API Gestione contatti, API Appuntamenti e Gestione delle azioni relative ai contatti.]

Windows 8.1 consente di usare contatti ed eventi nelle app. Puoi consentire agli utenti della tua app di cercare informazioni sui contatti noti e di interagire integrando esperienze di comunicazione come la messaggistica, l'email, le chiamate, le videochiamate e così via. Puoi inoltre favorire la permanenza degli utenti nell'app consentono loro di visualizzare rapidamente il calendario e aggiungere eventi.

Usa queste nuove API per abilitare la visualizzazione di schede contatto e la gestione degli eventi nella tua app:

  • ShowContactCard metodo

    Consente alle app di eseguire query sul sistema operativo per recuperare un contatto dell'utente e visualizzarne i dati in una scheda contatto.

  • AppointmentsProvider namespace

    Supporta l'aggiunta, la sostituzione e la rimozione di richieste di appuntamento tramite attivazioni con cui interagisce un provider di appuntamenti.

  • AppointmentManager class

    Consente alle app di interagire con il provider di appuntamenti per aggiungere, sostituire e rimuovere eventi. Mostra inoltre l'interfaccia utente primaria del provider di appuntamenti.

  • Activation namespace

    Consente a un'app di gestire i parametri di attivazione per i nuovi provider di appuntamenti e i contratti di contatto supportati da Windows.

Sintesi vocale

[Recupera ora l'esempio di sintesi vocale.]

In Windows 8.1 è stata introdotta l'API Windows.Media.SpeechSynthesis che supporta la sintesi vocale, nota anche come riconoscimento vocale, nelle app di Windows Store.

Usa la sintesi vocale per richiedere input agli utenti, evidenziare notifiche e messaggi delle app, fornire istruzioni (ad esempio per la navigazione dettagliata) e leggere contenuti quali messaggi di testo o email, feed RSS, libri e risultati di ricerca.

Windows 8.1 include diversi motori di sintesi vocale, denominati voci. Ogni voce ha un nome intuitivo, ad esempio Microsoft David (en-US, maschile), Microsoft Zira (en-US, femminile) e Microsoft Hazel (en-UK, femminile), che può essere specificato nell'app e selezionato dall'utente nel pannello di controllo Lingua.

Le funzionalità di sintesi vocale supportate da Windows 8.1 consentono di:

  • Impostare sesso, voce e lingua della sintesi vocali.

  • Generare output vocale da stringhe di testo normale usando le caratteristiche e le proprietà predefinite della voce corrente.

  • Generare output vocale da una stringa contenente SSML (Speech Synthesis Markup Language) per personalizzare le caratteristiche della voce, la pronuncia, il volume, il tono, la velocità, l'enfasi e così via.

  • Leggere e scrivere dati audio generati dal motore di sintesi vocale in un flusso ad accesso casuale.

Generare output vocale da testo normale

In questo esempio viene illustrata la modalità di utilizzo di un oggetto SpeechSynthesizer in un'app di Windows Store per creare un flusso audio e quindi generare l'output vocale in base a una stringa di testo normale.

// The object for controlling and playing audio.
var audio = new Audio();

// The object for controlling the speech-synthesis engine (voice).
var synth = new Windows.Media.SpeechSynthesis.SpeechSynthesizer();

// Generate the audio stream from plain text.
synth.synthesizeTextToStreamAsync("hello World").then(function (markersStream) {

    // Convert the stream to a URL Blob.
    var blob = MSApp.createBlobFromRandomAccessStream(markersStream.ContentType, markersStream);

    // Send the Blob to the audio object.
    audio.src = URL.createObjectURL(blob, { oneTimeOnly: true });
    audio.play();
});

// The media object for controlling and playing audio.
MediaElement mediaElement = this.media;

// The object for controlling the speech-synthesis engine (voice).
var synth = new Windows.Media.SpeechSynthesis.SpeechSynthesizer();

// Generate the audio stream from plain text.
SpeechSynthesisStream stream = await synth.SynthesizeTextToStreamAsync("Hello World");

// Send the stream to the media object.
mediaElement.SetSource(stream, stream.ContentType);
mediaElement.Play();

Generare output vocale da SSML (Speech Synthesis Markup Language)

Nell'esempio successivo viene illustrata la modalità di utilizzo di un oggetto SpeechSynthesizer in un'app di Windows Store per creare un flusso audio e quindi generare l'output vocale in base a una stringa di testo SSML.

// The string to speak with SSML customizations.
var Ssml = "<speak version='1.0' " +
    "xmlns='http://www.w3.org/2001/10/synthesis' xml:lang='en-US'>" +
    "Hello <prosody contour='(0%,+80Hz) (10%,+80%) (40%,+80Hz)'>World</prosody> " + 
    "<break time='500ms' />" +
    "Goodbye <prosody rate='slow' contour='(0%,+20Hz) (10%,+30%) (40%,+10Hz)'>World</prosody>" +
    "</speak>";

// The object for controlling and playing audio.
var audio = new Audio();

// The object for controlling the speech-synthesis engine (voice).
var synth = new Windows.Media.SpeechSynthesis.SpeechSynthesizer();

// Generate the audio stream from SSML.
synth.synthesizeSsmlToStreamAsync(Ssml).then(function(synthesisStream){

    // Convert the stream to a URL Blob.
    var blob = MSApp.createBlobFromRandomAccessStream(synthesisStream.ContentType, synthesisStream);

    // Send the Blob to the audio object.
    audio.src = URL.createObjectURL(blob, { oneTimeOnly: true });
    audio.play();
});

// The string to speak with SSML customizations.
string Ssml =
    @"<speak version='1.0' " +
    "xmlns='http://www.w3.org/2001/10/synthesis' xml:lang='en-US'>" +
    "Hello <prosody contour='(0%,+80Hz) (10%,+80%) (40%,+80Hz)'>World</prosody> " + 
    "<break time='500ms' />" +
    "Goodbye <prosody rate='slow' contour='(0%,+20Hz) (10%,+30%) (40%,+10Hz)'>World</prosody>" +
    "</speak>";

// The media object for controlling and playing audio.
MediaElement mediaElement = this.media;

// The object for controlling the speech-synthesis engine (voice).
var synth = new Windows.Media.SpeechSynthesis.SpeechSynthesizer();

// Generate the audio stream from SSML.
SpeechSynthesisStream stream = await synth.synthesizeSsmlToStreamAsync(Ssml);

// Send the stream to the media object.
mediaElement.SetSource(stream, stream.ContentType);
mediaElement.Play();

Aggiornamenti alla gestione delle attività in background

[Accedi all'esempio di attività in background ora.]

Windows 8.1 aggiunge diverse nuove funzionalità per le attività in background:

Ore in modalità silenziosa e attività in background

Le ore in modalità silenziosa sono una nuova funzionalità di Windows 8.1 che consente all'utente di designare determinate ore del giorno in cui non essere disturbato con le notifiche. Questa funzionalità interrompe anche la maggior parte delle attività in background associate alle app di Windows Store, per evitare che l'utente venga disturbato ed estendere potenzialmente la durata dello standby connesso del dispositivo.

Quando il sistema attiva le ore in modalità silenziosa, le attività in background vengono inserite nella coda e conservate fino al termine di tali ore. Attualmente l'esecuzione delle attività in background viene annullata quando le ore in modalità silenziosa vengono attivate.

Una volta trascorse queste ore, sarà possibile riavviare le attività in background. Ogni attività in background viene nuovamente avviata secondo un intervallo casuale prima che il sistema esca dalle ore in modalità silenziosa. Questo garantisce che le attività in background non si riattivino tutte contemporaneamente, determinando un inutile carico sulle risorse del sistema e sulle risorse del server remoto. Il sistema non attiverà le notifiche finché le ore in modalità silenziosa designate non saranno terminate.

Per impostazione predefinita, sono consentite 2 eccezioni alle ore in modalità silenziosa: chiamate in ingresso provenienti da un'app che supporta la nuova funzionalità di chiamata alla schermata bloccata e avvisi configurati dall'utente nell'app degli avvisi designata predefinita. Se l'app supporta le chiamate alla schermata bloccata e l'opzione IncomingCall è impostata su TRUE, l'attività in background verrà eseguita e la notifica verrà recapitata. Le notifiche generate da avvisi configurati dall'utente nell'app degli avvisi designata predefinita verranno recapitate durante le ore in modalità silenziosa.

Per impostazione predefinita, le ore in modalità silenziosa sono abilitate dalla mezzanotte alle 6.00, ma durante questo intervallo di tempo le chiamate in ingresso sono consentite. Gli utenti possono modificare queste impostazioni o disabilitare le ore in modalità silenziosa nella scheda delle notifiche della sezione delle app di Modifica impostazioni PC. Le ore in modalità silenziosa sono disponibili in tutti i sistemi.

Annullamento delle attività di stato inattivo

Oltre ai vincoli delle risorse per le attività in background, l'infrastruttura delle attività in background di Windows rileva le attività in background che sono inattive o bloccate. Un'attività in background è considerata inattiva o bloccata se non ha utilizzato la quantità minima della quota di risorse di rete o CPU entro un intervallo di tempo minimo, che varia a seconda dello stato del sistema. Se viene rilevata un'attività in background inattiva o bloccata, viene inviata una notifica di annullamento in modo che l'attività possa interrompere l'esecuzione e terminare. Se l'attività in background non interrompe l'esecuzione e si chiude entro 5 secondi, l'app viene considerata bloccata e viene interrotta automaticamente dal sistema.

In Windows 8.1 è consigliabile evitare che l'app venga interrotta a causa di un'attività in background inattiva o bloccata. In questi casi, associa sempre un gestore di annullamento in modo che venga annullata secondo la normale procedura. Per informazioni dettagliate e frammenti di codice, vedi Come gestire attività in background inattive o bloccate.

Suggerimento per il costo del lavoro dell'attività in background

Windows 8.1 fornisce un suggerimento relativo alla disponibilità delle risorse per le attività in background. Quando viene attivata, un'attività in background può usare questo suggerimento per decidere quanto lavoro svolgere. Possono essere segnalati tre stati di disponibilità delle risorse in background: bassa, media e alta. Per ulteriori informazioni, vedi BackgroundWorkCost e BackgroundWorkCostValue.

Cmdlet di PowerShell per le attività in background

Gli sviluppatori possono usare i nuovi comandi AppBackgroundTask di PowerShell e il nuovo modulo della finestra di progettazione del cmdlet BackgroundTasksManager per recuperare info sull'esecuzione delle attività in background. Questa operazione può essere molto utile durante l'implementazione e il debug delle attività in background. Per ulteriori informazioni, vedi Cmdlet di PowerShell per le attività in background.

Supporto delle app di avviso nella schermata di blocco

[Recupera ora l'esempio delle notifiche di avviso.]

In Windows 8.1 uno degli slot della schermata di blocco viene usato ora per le app di avviso. Le app di avviso usano la classe AlarmApplicationManager per richiedere all'utente l'autorizzazione per diventare app di avviso di sistema. Se l'utente concede l'autorizzazione (o posiziona l'app nello slot di avviso corrispondente usando il Pannello di controllo), l'app occupa lo slot e diventa l'app di avviso di sistema. Le notifiche di avviso generate dall'app di avviso di sistema vengono quindi mostrate all'utente con la precisione di un secondo. Solo l'app che occupa lo slot di avviso può generare notifiche di avviso. Le notifiche di avviso generate da altre app vengono gestite come normali notifiche.

Per pianificare notifiche di avviso puoi creare notifiche di tipo avviso popup con l'elemento commands. Usando l'elemento audio puoi inoltre specificare il suono dell'avviso, che viene riprodotto quando viene generata la notifica anche se l'audio del sistema è disattivato.

Aggiornamenti alla pianificazione degli elementi di lavoro

L'API CoreDispatcher (Windows::UI::Core:CoreDispatcher) assicura ora un maggiore controllo sulle priorità nella pianificazione di elementi di lavoro.

In Windows 8.1, le priorità di invio del lavoro sono ora in quest'ordine:

  1. SendMessage (priorità massima)
  2. CoreDispatcherPriority.High
  3. CoreDispatcherPriority.Normal (include chiamate COM e di messaggi di finestra)
  4. Qualsiasi messaggio di input di dispositivo
  5. CoreDispatcherPriority.Low
  6. CoreDispatcherPriority.Idle (priorità minima per le attività in background)

Per modificare le priorità delle attività, usa questi nuovi membri nel tipo CoreDispatcher:

  • Metodo CoreDispatcher::ShouldYield (2 overload)—Esegue query per rilevare se il chiamante deve dichiarare l'eventuale presenza di elementi nella coda delle attività con la priorità specificata o superiore.

  • Proprietà CoreDispatcher::CurrentPriority—Ottiene o imposta la priorità corrente dell'attività più recente gestita da CoreDispatcher. Quando un'app elabora operazioni con una priorità specifica e vengono ricevute richieste di priorità superiore, imposta questa priorità per aumentare la priorità dell'attività corrente in modo che ShouldYield restituisca risultati più accurati.