Windows-Apps
Inhaltsverzeichnis reduzieren
Inhaltsverzeichnis erweitern

UX/UI

Dank in Größe veränderbarer Fenster haben Benutzer größeren Einfluss auf die Verwendung der App. Neue Features ermöglichen eine flexiblere Nutzung der App-Kachel. Aktualisierungen für Suche, Teilen und Charms sorgen allgemein für eine einheitlichere Benutzerumgebung.

Neues oder Aktualisierungen in Windows 8.1

In der Größe veränderbare Fenster

[Laden Sie sich die Beispiele für Anwendungsansichten, mehrere Ansichten und Projektions-Manager herunter.]

Windows 8.1 ist mit verschiedenen Änderungen bei der Fenstergröße und -position verbunden. Beachten Sie beim Entwickeln von Apps für Windows 8.1 die folgenden wichtigen Punkte:

  • Windows 8.1 verfügt nicht über Ansichtszustände mit fester Breite. Benutzer können Apps jetzt kontinuierlich bis auf eine Mindestbreite verkleinern. (Die standardmäßige Mindestbreite einer App beträgt 500 Pixel.) Apps weisen also keine verankerten oder gefüllten Ansichtszustände mehr auf. Stattdessen entwerfen Sie die App so, dass sie bei allen Größen (einschließlich der Mindestgröße) funktioniert und gut aussieht.

    Hinweis  Die Breite der verankerten Ansicht in Windows 8 betrug 320 Pixel. Die standardmäßige Mindestbreite von 500 Pixel ist höher als die verankerte Ansicht von Windows 8.
  • Wenn Ihre App bei kleineren Größen gut funktioniert und Sie Benutzer dazu ermuntern möchten, Ihre App auf dem Bildschirm angezeigt zu lassen, können Sie die Mindestbreite auf 320 Pixel verringern.

  • Benutzer können auf dem Bildschirm gleichzeitig mehr als zwei Apps anzeigen. Es kann also sein, dass Ihre App zwischen zwei anderen Apps angezeigt wird, und nicht angrenzend an den linken oder rechten Rand des Bildschirms.

  • Für eine App kann gleichzeitig mehr als ein Fenster geöffnet sein.

  • Eine App kann eine andere App starten. Wenn dies der Fall ist, teilen sich die beiden Apps den Bildschirm gleichmäßig auf, sofern ausreichend Platz vorhanden ist. Sie können dies jedoch ändern, sodass die gestartete App breiter bzw. schmaler als die ursprüngliche App ist oder die ursprüngliche App auf dem Bildschirm ersetzt. Dieses Standardverhalten können Sie mit der DesiredRemainingView-Eigenschaft ändern.

Apps müssen die Höhe des Bildschirms vollständig ausfüllen, wie dies auch unter Windows 8 der Fall war. Die Mindesthöhe einer App beträgt 768 Pixel.

Pixelanforderungen für die schmale Mindestgröße und die standardmäßige Mindestgröße einer App

Gestaltungsrichtlinien für Websites mit in der Größe veränderbaren Fenstern

Beachten Sie beim Entwerfen einer App für Windows 8.1 Folgendes:

  • Stellen Sie sicher, dass das App-Layout und die Steuerelemente so skaliert werden, dass sie auch bei der Mindestgröße funktionieren. Achten Sie besonders darauf, wie sich die Größe der App auf die folgenden Steuerelemente auswirkt:

  • Entwerfen Sie die App so, dass der Platz auf einem großen Bildschirm effektiv genutzt wird, und verwenden Sie ein Layout, das automatisch dynamisch umgebrochen wird. Vermeiden Sie große leere Bereiche.

  • Wenn Sie die Mindestbreite in 320 Pixel ändern, sollte die App bei schmaler Breite entsprechend angepasst werden (also zwischen 320 und 500 Pixel):

    • Verwenden Sie eine vertikale Ansicht.
    • Verwenden Sie das kleinere Schaltflächenformat für die Schaltfläche "Zurück". Weitere Informationen zu den Größen der Schaltfläche "Zurück" finden Sie in der Symbolliste.
    • Legen Sie für den linken Rand eine Breite von 20 Pixel fest.
    • Verwenden Sie den Schriftgrad 20 Punkt für den App-Kopf.
    • Verwenden Sie kleinere Offsetwerte für Seitenübergangsanimationen und Inhaltsübergangsanimationen.

Weitere Layoutbeispiele sind für Fenster, deren Größe in eine Breite von 320 Pixel geändert werden kann, und Fenster, die höher als breit sind, verfügbar. Weitere Informationen zur Nutzung von Charms für eine App unabhängig von der Größe der App finden Sie unter Verwendbarkeit der Charms auf jedem Bildschirm.

Festlegen der Mindestbreite

Wenn Sie die Mindestgröße einer App ändern und den Standardwert von 500 Pixel ersetzen möchten, geben Sie im App-Manifest das MinWidth-Attribut des ApplicationView-Elements an.


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


Weitere Informationen zum App-Manifest finden Sie unter App-Paketmanifest.

Aktualisierungen der ApplicationView-Klasse

In Windows 8.1 verfügt der Windows.UI.ViewManagement-Namespace über die folgenden neuen Enumerationen:

Die ApplicationView-Klasse verfügt über die folgenden neuen Eigenschaften:

Auch ApplicationView verfügt über die folgenden neuen Methoden:

In Windows 8.1 gelten die folgenden Member als veraltet:

  • ApplicationView.Value-Eigenschaft: Nicht gültig, da Apps keine Ansichtszustände mit fester Breite mehr haben. Stattdessen können Sie die Orientation-Eigenschaft verwenden, um die Ausrichtung des App-Fensters abzurufen, und die Eigenschaften AdjacentToLeftDisplayEdge, AdjacentToRightDisplayEdge und IsFullScreen, um die Position der App abzurufen.

  • ApplicationView.TryUnsnap-Methode: Nicht gültig, da Apps keinen speziellen verankerten Ansichtszustand mehr haben und weil die standardmäßige Mindestbreite 500 Pixel beträgt.

  • ApplicationViewState-Enumeration: Nicht gültig, da die Größe von Apps jetzt kontinuierlich geändert werden kann und Apps keine Ansichtszustände mit fester Breite mehr haben.

Aktualisierungen für Kacheln

[Laden Sie sich das Beispiel für App-Kacheln und Signale und das Beispiel für Sekundärkacheln herunter.]

Mit Windows 8.1 werden die unten beschriebenen Änderungen an den Kacheln und ihrer Verwendung eingeführt.

Neue Kachelgrößen

Unter Windows 8 gab es zwei Kachelgrößen:

  • Quadratische Kacheln (150×150 Pixel bei Skalierungsebene 1x)
  • Breite Kacheln (310×150 Pixel bei Skalierungsebene 1x)

Unter Windows 8.1 gibt es zwei weitere Kachelgrößen:

  • Kleine Kacheln (70×70 Pixel bei Skalierungsebene 1x)
  • Große Kacheln (310×310 Pixel bei Skalierungsebene 1x)

Da drei der vier Vorlagentypen jetzt quadratisch sind, werden die Kacheln, die unter Windows 8 als "quadratisch" bezeichnet wurden (150×150 bei Ebene 1x), jetzt als "mittelgroße" Kacheln bezeichnet. Es gibt also kleine, mittelgroße, breite und große Kacheln. Unten sehen Sie Beispiele für alle vier Größen.

Beispiel für alle vier Kachelgrößen des Startbildschirms

Benutzer können vier kleine Kacheln anstelle einer mittelgroßen Kachel verwenden. Für kleine Kacheln werden Live-Kachelbenachrichtigungen nicht unterstützt. Signale werden jedoch unterstützt. Eine große Kachel nimmt genauso viel Raum wie zwei breite Kacheln ein, und Live-Kachelbenachrichtigungen werden unterstützt, wie dies für die Kachelgrößen unter Windows 8 auch der Fall war.

Neue Benennungskonventionen für Kachelvorlagen

Zusammen mit der Einführung neuer Kachelgrößen wurden die Windows 8-Benennungskonventionen für Kachelvorlagen aktualisiert. Bei den neuen Benennungskonventionen werden absolute Pixelgrößen für die Skalierungsebene 1× verwendet. Die vier Kachelgrößen sind den neuen Namen wie folgt zugeordnet, wobei jede Kategorie viele Vorlagen enthält:

  • Klein = Square70x70
  • Mittelgroß = Square150x150
  • Breit = Wide310x150
  • Groß = Square310x310

Außerdem trägt das SmallLogo-Attribut im App-Manifest jetzt die Bezeichnung Square30x30Logo.

Im Rahmen der neuen Benennungskonventionen wurden alle vorhandenen Kachelvorlagen umbenannt.

Alter NameNeuer NameBeispiel
TileSquare*TileSquare150x150*TileSquareImage (alter Name)/TileSquare150x150Image (neuer Name)
TileWidexxxTileWide310x150xxxTileWideImageAndText01 (alter Name)/TileWide310x150ImageAndText01 (neuer Name)

 

Aus Kompatibilitätsgründen werden die älteren weiterhin erkannt. Verwenden Sie für alle neuen Entwicklungen jedoch die neuen Namen.

Kachelbezogene Änderungen im App-Manifest

Sie deklarieren die Standardeigenschaften der primären App-Kachel – die unterstützten Größen, den Anzeigenamen und die Kachelfarbe – im App-Manifest.

Unterstützen neuer Kachelgrößen

Unter Windows 8 haben Sie die Unterstützung einer breiten Kachel für die App eingerichtet, indem Sie im App-Manifest eine Ressource für eine breite Kachel angegeben haben. Unter Windows 8.1 richten Sie die Unterstützung für eine große Kachel (Square310x310) ein, indem Sie im Manifest eine Ressource für eine große Kachel angeben.

Hinweis  Von der App können große Kacheln nur unterstützt werden, wenn auch Unterstützung für breite Kacheln vorhanden ist.

Mittelgroße (Square150x150) und kleine Kacheln (Square70x70) werden von allen Apps unterstützt. Ressourcen für kleine Kacheln können Sie ebenfalls im Manifest angeben. Wenn von der App kein Bild für eine kleine Kachel bereitgestellt wird, wird das Bild der mittelgroßen Kachel unter Windows 8.1 automatisch herunterskaliert, indem die Skalierungsschritte entweder selbst ausgeführt werden oder eine separate Ressource bereitgestellt wird.

Genau wie unter Windows 8 ist es ratsam, dass Sie für jede unterstützte Kachelgröße jeweils separate Ressourcen für die vier Skalierungsebenen (0,8x, 1x, 1,4x und 1,8x) bereitstellen. Damit wird sichergestellt, dass die Kacheln immer exakt aussehen und keine Skalierungsartefakte aufweisen. Zur besseren Unterstützung der Barrierefreiheit können Sie auch Bildressourcen für das Design mit hohem Kontrast bereitstellen.

Anzeigen des App-Namens für unterschiedliche Kachelgrößen

Unter Windows 8 wurde das App-Manifest verwendet, um anzugeben, mit welchen Kachelgrößen der App-Name angezeigt werden soll. Dies ist auch unter Windows 8.1 so, aber es ist ein neues Format verfügbar. Beachten Sie auch, dass das Anzeigen des App-Namens bei der kleinen Kachel (Square70x70) nicht möglich ist.

Deklarieren einer Standardgröße für das Anheften

Wenn von einer App unter Windows 8 eine breite Kachel unterstützt wurde, wurde diese an die Startseite als breite Kachel angeheftet. Andernfalls wurde sie als mittelgroße Kachel angeheftet. Unter Windows 8.1 können Sie dieses Verhalten optional außer Kraft setzen und entweder die mittelgroße oder die breite Kachel (nicht jedoch die kleine oder große Kachel) als Standardgröße für das Anheften deklarieren. Bedenken Sie jedoch, dass die App unter Windows 8.1 bei der Installation nicht automatisch an die Startseite angeheftet wird. Sie wird in der Ansicht Alle Apps aufgeführt, wo Benutzer die App explizit für das Anheften an die Startseite auswählen müssen.

Änderungen am App-Manifestschema

Nun geben Sie einen zusätzlichen Namespace ("http://schemas.microsoft.com/appx/2013/manifest") in Ihrem Manifest an, um die Schemaelemente einzubinden, die die neue Funktion deklarieren. Das folgende Beispiel enthält einige neue und umbenannte Attribute, die im Manifest verwendet werden. Beachten Sie, dass die Ressource für die große Kachel unter dem DefaultTile-Element angeordnet ist. Damit wird auch explizit eine bevorzugte Standardgröße deklariert. Für die App wird angegeben, dass der App-Name nur auf mittelgroßen und breiten Kacheln angezeigt werden soll, nicht auf der großen Kachel.



<Package 
    xmlns="http://schemas.microsoft.com/appx/2010/manifest" 
    xmlns:wb="http://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>

Änderungen an Kachelbenachrichtigungen

Bedenken Sie beim Senden einer Kachelbenachrichtigung, dass die App die Benachrichtigung während der Ausführung unter Windows 8.1 oder unter Windows 8 empfangen kann. Da die neuen Namen für vorhandene Vorlagen nur unter Windows 8.1 erkannt werden, wurde vom Schema ein fallback-Attribut hinzugefügt. Durch das Einbinden des fallback-Attributs kann für die Benachrichtigungsnutzlast eine Windows 8.1-Vorlage zusammen mit einer Windows 8-Vorlage angegeben werden, falls die Benachrichtigung auf einem System mit Windows 8 eingeht. Fügen Sie zum Verwenden der neuen Vorlagennamen und des fallback-Attributs das neue version-Attribut mit dem festgelegten Wert 2 wie hier dargestellt in das visual-Element ein.



<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>

Beachten Sie, dass Sie das fallback-Attribut nicht in Verbindung mit großen Kacheln nutzen können, da diese unter Windows 8 noch nicht vorhanden waren. Windows 8-Benachrichtigungen funktionieren unter Windows 8.1 gut, ohne dass Änderungen erforderlich sind, aber große Kacheln können dabei nicht verwendet werden.

Hinweis  Bei allen in die Nutzlast eingebundenen Vorlagen für große Kacheln (Square310x310) muss es sich um die zuletzt aufgeführte Bindung handeln. Unter einem System mit Windows 8 wird die Analyse einer Benachrichtigung gestoppt, wenn eine Bindung gefunden wird, die nicht anhand des Vorlagen- oder Fallbacknamens erkannt werden kann. Wenn eine 310×310-Bindung gefunden wird, wird der Vorgang also immer gestoppt.

Angeben von Kachelgrößen für die Benachrichtigungswarteschlange

Wenn Sie unter Windows 8 die Benachrichtigungswarteschlange aktiviert haben, war sie für mittelgroße und für breite Kacheln aktiviert. Unter Windows 8.1 werden Methoden der TileUpdater-Klasse hinzugefügt, mit denen Sie die Benachrichtigungswarteschlange für bestimmte Kachelgrößen aktivieren können.

Neue Kachelgrößen und alternative Logos in sekundären Kacheln

Unter Windows 8.1 können Benutzer mithilfe des Flyouts, das Benutzern beim Anheften von Inhalten als sekundäre Kachel angezeigt wird, alle verfügbaren Größen und Varianten sekundärer Kacheln durchblättern und eine Auswahl treffen. Von der sekundären Kachel können alle Kachelgrößen unterstützt werden, die von der dazugehörigen App-Kachel unterstützt werden. Wenn Sie für die sekundäre Kachel kein eigenes Bild für die kleine Kachelgröße angeben, wird von Windows 8.1 das Bild für die quadratische Kachel herunterskaliert und verwendet.

Zusätzlich zum Standardbild für die sekundäre Kachel können Sie bis zu drei alternative Versionen für jede Kachelgröße angeben, also maximal 12 Versionen. Außerdem können Sie mit der AlternateVisualElements-Methode ein alternatives kleines Logo für jede der drei Kachelgrößen (quadratisch, breit, groß) angeben, die Logos unterstützen.

Präzisere Unterstützung für phonetische Zeichenfolgen zum Sortieren von sekundären Kacheln

Bei bestimmten zeichenbasierten Sprachen, z. B. Japanisch, basiert die Sortierreihenfolge in der UI auf einer phonetischen Schreibweise der Zeichen, aus denen der Anzeigename der App besteht. Bei dieser phonetischen Schreibweise handelt es sich um eine andere Zeichenfolge als für den Anzeigenamen. Beim Anheften einer sekundären Kachel können Benutzer im Flyout einen Anzeigenamen für die Kachel angeben, jedoch keine phonetische Schreibweise. Unter Windows wird versucht, die phonetische Zeichenfolge zu erstellen, was jedoch nicht immer zu richtigen Ergebnissen führt.

Apps ist die richtige phonetische Zeichenfolge manchmal jedoch bekannt, weil sie vom Benutzer mithilfe eines benutzerdefinierten Steuerelements definiert wurde, das von der App bereitgestellt wird. Unter Windows 8.1 kann die Zeichenfolge von einer App mithilfe der neuen SecondaryTile.PhoneticName-Eigenschaft dann an Windows übergeben werden. Beachten Sie, dass dieser Name der phonetischen Zeichenfolge an den Standardanzeigenamen gebunden ist, der der sekundären Kachel zugeordnet ist. Wenn der Anzeigename vom Benutzer mithilfe des Flyouts für das Anheften geändert wird, wird stattdessen also die vom System erstellte phonetische Schreibweise verwendet.

Aktualisierungen für die Suche

[Laden Sie sich das Beispiel für das Suchfeldsteuerelement herunter.]

Mit Windows 8.1 wird ein neues Suchfeldsteuerelement eingeführt, um Ihnen das Bereitstellen von Suchergebnissen zu erleichtern: Windows.UI.Xaml.Controls.SearchBox für Apps mit XAML und WinJS.UI.SearchBox für Apps mit JavaScript.

Sie können in Apps das Suchfeld jetzt als Element im Markup einbinden. Für das neue Steuerelement werden Vorlagen und Formatvorlagen voll unterstützt.

Unter Windows 8.1 wird die App-Suchfunktion komplett von Ihren Apps gesteuert. Das Suchfeld ist auf den Vertrag "Suche" abgestimmt, um für eine bessere Oberfläche und eine eingehende Anpassung zu sorgen, damit das App-Erlebnis nach den Anforderungen der Benutzer ausgerichtet ist.

Vom Suchfeld werden Suchvorschläge und -ergebnisse unterstützt, die von der App bereitgestellt werden. Außerdem werden der App-spezifische Suchverlauf und Interaktionen per Toucheingabe, Tastatur und Maus unterstützt.

Das Layout des Suchfelds sieht wie folgt aus.

Steuerelement für die In-App-Suche für Windows Store-Apps

Unten sind Beispiele für Suchergebnisse zu sehen, die im Suchfeldsteuerelement angezeigt werden.

Beispielergebnisse im Suchfeld für MSFT

Für das Suchfeldsteuerelement wird die Integration in den Eingabemethoden-Editor (Input Method Editor, IME) unterstützt.

Steuerelement für die In-App-Suche mit IME

Beim Eingabemethoden-Editor werden die Vorschläge bei jedem Buchstaben geändert, der von Benutzern eingegeben wird. Die Vorschläge umfassen auch ideografische chinesische Zeichen, die auf einer teilweise phonetischen Eingabe basieren. Von der IME-Kandidaten-UI werden Suchvorschläge nicht verdeckt. Das Suchfeld unterstützt die Verwendung von Tastatureingaben, um im Textfeld, in der IME-Kandidatenliste und in den Suchvorschlägen navigieren zu können.

Aktualisierungen für das Teilen-Feature

[Laden Sie sich die Beispiele für Quelle für die Inhaltsfreigabe und Ziel für die Inhaltsfreigabe herunter.]

Mit Windows 8.1 werden die unten beschriebenen Änderungen am Feature zum Teilen und an der Nutzung des Freigabe-Vertrags in Ihren Apps eingeführt.

Hinzufügen neuer Datenformate zu DataPackage

Unter Windows 8.1 können von Quell-Apps für den Vertrag "Teilen" mehrere Wege bereitgestellt werden, um zu den geteilten Inhalten zurückzukehren. Für Windows 8.1 wurde das Uri-Format in zwei neue Datenformate in DataPackage aufgeteilt, und es werden vier neue stark typisierte Eigenschaften in DataPackagePropertySet eingeführt. Für DataPackage gilt das Uri-Format als veraltet und wird durch die Formate WebLink und ApplicationLink ersetzt.

WebLink wird geteilt, wenn vom Benutzer keine Auswahl getroffen wurde, sodass von der Quell-App eine implizite Auswahl des angezeigten Inhalts geteilt wird. Per Auffüllung dieses Formats werden die Inhalte der aktuellen Seite von der Quell-App in Form eines URI (Uniform Resource Identifier) geteilt. Mit dem geteilten Link wird auf die Webseite verwiesen, die vom Benutzer angezeigt wird, sodass dieses Format immer mit http oder https beginnt.

ApplicationLink wird geteilt, wenn vom Benutzer keine Auswahl getroffen wurde, sodass von der Quell-App eine implizite Auswahl des angezeigten Inhalts geteilt wird. Per Auffüllung dieses Formats werden die Inhalte der aktuellen Seite von der Quell-App in Form eines URI geteilt. Der geteilte URI verfügt über ein Schema, das von der Quell-App behandelt wird. Wenn die Quell-App mit diesem URI-Protokoll aktiviert wird, wird der gleiche Inhalt angezeigt, den Benutzer sich gerade ansehen. In diesem Format werden die geteilten Inhalte dargestellt, indem es ermöglicht wird, mithilfe eines App-Protokolls zu den Inhalten zurückzukehren.

Die Formate WebLink und ApplicationLink sind nicht ausschließend. WebLink ist die Verknüpfung mit den Inhalten im Web, und ApplicationLink ist die Verknüpfung mit den Inhalten in einer App. Eine Newsreader-App kann beispielsweise über Inhalte beider Formen mit einem URI verfügen, über den Benutzer zurück zum Artikel in der App oder zum gleichen Artikel auf einer Website gelangen können. Die Auswahl zur Behandlung des URI wird von der Ziel-App getroffen. Beispielsweise kann von der Mail-App das WebLink-Format verwendet werden, weil der Link über das Internet gesendet und von anderen Systemen als Windows-Systemen genutzt werden kann. Von der Reader-App wird jedoch unter Umständen das ApplicationLink-Format verwendet, sodass die Quell-App wieder aktiviert wird und Benutzer zu den Originalinhalten zurückgeleitet werden.

ContentSourceWebLink ist eine Begleiteigenschaft, die Sie zum Zuordnen der geteilten Inhalte verwenden können. Die Eigenschaft wird geteilt, wenn von der App ein Weblink zu den geteilten Inhalten bereitgestellt wird. Wenn Benutzer eine explizite Auswahl treffen, wird das WebLink-Format nicht aufgefüllt, weil der Wert für das WebLink-Format nicht der Auswahl des Benutzers entspricht. Das Auffüllen dieser Informationen bedeutet nicht, dass die Webseite die Auswahl des Benutzers ist, sondern lediglich, dass die Inhalte von dort stammen.

ContentSourceApplicationLink ist die zweite Begleiteigenschaft, die Sie zum Zuordnen der geteilten Inhalte verwenden können. Sie wird geteilt, wenn die App es für angemessen hält, dass der Benutzer zu den Inhalten zurückkehrt, die derzeit in der App angezeigt werden. Wenn Benutzer eine Auswahl treffen, wird das ApplicationLink-Format nicht aufgefüllt, weil der Wert für das ApplicationLink-Format in diesem Fall nicht der Auswahl des Benutzers entspricht. Das Auffüllen dieser Informationen bedeutet nicht, dass der tiefe Link in die App die Auswahl des Benutzers darstellt, sondern lediglich, dass die Inhalte von dort stammen.

Angenommen, ein Benutzer liest in einer Reader-App einen Artikel. Der Benutzer wählt ein Zitat aus und teilt es mithilfe von OneNote. Um das Zitat dem Artikel zuzuordnen, verwendet die Reader-App weder das WebLink-Format noch das ApplicationLink-Format, da der Artikel nicht dem Zitat entspricht, das geteilt wird. Stattdessen verwendet die App die Eigenschaften ContentSourceWebLink und ContentSourceApplicationLink. In OneNote wird der ausgewählte Text zusammen mit der Zuordnung der Quelle hinzugefügt. Später kann der Benutzer das Zitat in OneNote lesen und auf die Reader-App oder die Webseite zugreifen, um das Zitat im Kontext des Artikels anzuzeigen.

Verbessern der Reaktionsfähigkeit beim Teilen

Unter Windows 8.1 kann für Apps, die den Vertrag "Teilen" verwenden, die Reaktionsfähigkeit verbessert werden, indem der Bereich "Teilen" programmgesteuert geschlossen wird.

Rufen Sie die neue DismissUI-Methode auf, um den Bereich "Teilen" zu schließen. Das Aufrufen von DismissUI ähnelt dem Schließen des Bereichs "Teilen" durch Benutzer, wenn diese außerhalb des Bereichs tippen. Wenn der Teilen-Vorgang länger dauert, wird die Ausführung der App fortgesetzt. Falls der Vorgang nicht über eine längere Dauer verfügt, ist die Ausführung innerhalb von 10 Sekunden möglich, bevor er beendet wird.

Die Ziel-App kann derzeit nicht selbst das Ausblenden auf dem Bildschirm bewirken. Wenn ein Teilen-Vorgang gestartet wird, wird von der App also normalerweise eine Statusanzeige eingeblendet. Benutzer müssen dann warten, bis der Vorgang abgeschlossen ist (auch wenn keine Benutzerinteraktion zum Abschließen des Vorgangs mehr erforderlich ist). Obwohl Benutzer das Flyout per leichtem Tippen problemlos schließen können, sind Benutzer häufig der Meinung, dass das Schließen vor Abschluss des Teilen-Vorgangs zu Datenverlust führen kann. Daher vermeiden sie dies in der Regel. Mithilfe von DismissUI kann das Flyout von der App automatisch geschlossen werden.

Paketfamilienname

Unter Windows 8.1 können Quell-Apps für den Vertrag "Teilen" einen Paketfamiliennamen für Ziel-Apps bereitstellen, damit in Ziel-Apps eine Fallbackoberfläche bereitgestellt werden kann, wenn die mit ApplicationLink angegebene App gestartet wird.

Der Paketfamilienname ist der eindeutige Bezeichner eines App-Pakets. Wenn dieser Bezeichner von einer Quell-App an die Ziel-App übergeben wird, kann von der Ziel-App eine Fallbackoberfläche bereitgestellt werden, indem die LaunchUriAsync-Methode mit dem angegebenen ApplicationLink-Element aufgerufen wird. Falls das Schema des URI nicht behandelt wird, weil die App vom Benutzer beispielsweise deinstalliert wurde, oder wenn der URI an ein anderes Gerät weitergegeben wurde, auf dem die App nicht installiert ist, wird der Benutzer in einem Dialogfeld aufgefordert, im Windows Store nach einer App zu suchen. Der Benutzer wird standardmäßig an den Store weitergeleitet, jedoch nicht zur erforderlichen App. Wenn Sie den Paketfamiliennamen in das LauncherOptions-Objekt einfügen, das an das LaunchUriAsync-Element übergeben wird, erhält der Benutzer eine Aufforderung zur zu installierenden App und wird auf die Seite der App im Store weitergeleitet.

Ablauf des Uri-Formats

Wie bereits erwähnt, wurde das Uri-Format für Windows 8.1 unter DataPackage in zwei neue Datenformate aufgeteilt, und in DataPackagePropertySet werden vier neue stark typisierte Eigenschaften eingeführt. Für DataPackage gilt das Uri-Format als veraltet und wird durch die Formate WebLink und ApplicationLink ersetzt. Das Uri-Format bleibt als Alias für das WebLink-Format erhalten.

Verwendbarkeit der Charms auf jedem Bildschirm

In Windows 8 hat das System, wenn mehrere Apps auf dem Bildschirm waren und der Benutzer Charms aufgerufen hat, nur die Charms der App angezeigt, die den meisten Bildschirmplatz belegt hat. In Windows 8.1 zeigt das System die Charms für die letzte App an, mit der der Benutzer interagiert hat. Dabei spielt es keine Rolle, wie viele Apps sich auf dem Bildschirm befinden oder ob es mehrere Bildschirme gibt. Wenn der Benutzer zum Beispiel den Charm "Einstellungen" auswählt, zeigt das System das Einstellungen-Flyout für die letzte App an, die verwendet wurde.

Entwerfen Sie Ihre App so, dass sie mit den Charms funktioniert, unabhängig von der Größe der App. Insbesondere die Breite des Einstellungen-Flyouts muss kleiner oder gleich der aktuellen Breite Ihrer App sein.

Erstellen von Apps mit Integration von Personen und Ereignissen

[Laden Sie sich jetzt die Beispiele Kontakt-Manager-API, Termin-API und Behandeln von Kontaktaktionen herunter.]

Mithilfe von Windows 8.1 können Sie Informationen zu Personen und Ereignissen in die App einbinden. Benutzer Ihrer App können Informationen zu ihnen bekannten Personen in der App anzeigen und mit Personen in Kontakt treten, indem Kommunikationsfunktionen wie Chat, E-Mail, Anruf, Videoanruf usw. integriert werden. Sie können Benutzer auch in Ihrer App halten, indem Sie ihnen das schnelle Anzeigen ihrer Verfügbarkeit im Kalender und das Hinzufügen von Ereignissen zu ihrem bevorzugten Kalender ermöglichen.

Verwenden Sie diese neuen APIs, um für Ihre App das Anzeigen der Visitenkarten von Personen und das Verwalten von Ereignissen über die App zu ermöglichen:

  • ShowContactCard Methode

    Ermöglicht Apps das Abfragen des Kontakts eines Benutzers beim Betriebssystem und das Anzeigen der Kontaktdaten eines Benutzers in einer Visitenkarte.

  • AppointmentsProvider Namespace

    Unterstützt Anforderungen zum Hinzufügen, Ersetzen und Entfernen von Terminen mithilfe von Aktivierungen, mit denen ein Terminanbieter interagiert.

  • AppointmentManager Klasse

    Ermöglicht Apps das Interagieren mit dem Terminanbieter des Benutzers, um Ereignisse hinzufügen, ersetzen und entfernen zu können. Zeigt außerdem die primäre UI für den Terminanbieter an.

  • Activation Namespace

    Ermöglicht einer App das Behandeln der Aktivierungsparameter für den neuen Terminanbieter und Kontaktverträge, die von Windows unterstützt werden.

Sprachsynthese

[Laden Sie sich das Beispiel für Sprachsynthese herunter.]

Mit Windows 8.1 wird die Windows.Media.SpeechSynthesis-API eingeführt, mit der die Sprachsynthese – auch als Text-zu-Sprache (Text-to-Speech, TTS) bezeichnet – in Windows Store-Apps unterstützt wird.

Verwenden Sie die Sprachsynthese zum Auffordern von Benutzern zur Eingabe, Hervorheben von App-Benachrichtigungen und Meldungsdialogfeldern, Bereitstellen von Anleitungen (z. B. Turn-by-Turn-Navigation) und Lesen von Inhalten wie SMS- oder E-Mail-Nachrichten, RSS-Feeds, Bücher und Suchergebnisse.

Windows 8.1 enthält eine Reihe von Modulen für die Sprachsynthese, die als Stimmen bezeichnet werden. Jede Stimme verfügt über einen Anzeigenamen wie Microsoft David (en-US, männlich), Microsoft Zira (en-US, weiblich) und Microsoft Hazel (en-UK, weiblich), der in Ihrer App angegeben und von Benutzern auch im Steuerelement Sprache ausgewählt werden kann.

Mit den von Windows 8.1 unterstützten Sprachsynthesefunktionen haben Sie folgende Möglichkeiten:

  • Festlegen des Synthesizers für die Sprache auf ein bestimmtes Geschlecht, eine Stimme oder eine Sprache

  • Generieren von Sprachausgabe aus einer Nur-Text-Zeichenfolge unter Verwendung der Standardmerkmale und Eigenschaften der aktuellen Stimme

  • Generieren der Sprachausgabe aus einer Zeichenfolge, die Speech Synthesis Markup Language (SSML) enthält, um Stimmenmerkmale, Aussprache, Lautstärke, Stimmlage, Rate bzw. Geschwindigkeit, Betonung usw. anzupassen.

  • Lesen und Schreiben von Audiodaten, die vom Modul für die Sprachsynthese generiert werden, in bzw. aus einem Stream mit wahlfreiem Zugriff

Generieren von Sprache aus Nur-Text

In diesem Beispiel wird veranschaulicht, wie ein SpeechSynthesizer-Objekt von einer Windows Store-App verwendet wird, um einen Audiostream zu erstellen und anschließend basierend auf einer Nur-Text-Zeichenfolge Sprache zu generieren.



// 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();
});

Generieren von Sprachausgabe mithilfe von Speech Synthesis Markup Language (SSML)

Im nächsten Beispiel wird veranschaulicht, wie ein SpeechSynthesizer-Objekt von einer Windows Store-App verwendet wird, um einen Audiostream zu erstellen und anschließend basierend auf einer SSML-Textzeichenfolge Sprache zu generieren.



// 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();
});

Aktualisierungen für die Hintergrundaufgabenverwaltung

[Laden Sie das Beispiel für eine Hintergrundaufgabe herunter.]

In Windows 8.1 wurden verschiedene neue Features für Hintergrundaufgaben hinzugefügt:

Ruhezeiten und Hintergrundaufgaben

Bei "Ruhezeiten" handelt es sich um ein neues Feature in Windows 8.1, mit dem Benutzer bestimmte Tageszeiten definieren können, an denen Sie keine Benachrichtigungen erhalten möchten. Des Weiteren beendet dieses Feature die meisten Hintergrundaktivitäten für Windows Store-Apps, damit der Benutzer nicht gestört wird. Außerdem verlängert sich so unter Umständen die Zeit für den verbundenen Standbymodus des Geräts.

Wenn das System in den Ruhezeitenmodus versetzt wird, werden Hintergrundaufgaben bis zum Ende der Ruhezeiten in eine Warteschlange eingereiht. Aktuell ausgeführte Hintergrundaufgaben werden abgebrochen, wenn das System in den Ruhezeitenmodus versetzt wird.

Wenn die Ruhezeiten beendet sind, können Hintergrundaufgaben wieder gestartet werden. Jede Hintergrundaufgabe wird in einem zufälligen Intervall wieder gestartet, bevor das System den Ruhezeitenmodus verlässt. So wird gewährleistet, dass nicht alle Hintergrundaufgaben gleichzeitig reaktiviert werden, da dies die System- und Remoteserverressourcen unnötig belasten würde. Das System löst keine Benachrichtigungen vor der festgelegten Zeit für das Ende der Ruhezeiten aus.

Standardmäßig sind zwei Ausnahmen für Ruhezeiten erlaubt: eingehende Telefonanrufe von einer App, die die neue Funktion für Anrufe bei gesperrtem Bildschirm unterstützt, und vom Benutzer in der standardmäßig angegebenen Alarm-App festgelegte Alarme. Wenn die App Anrufe bei gesperrtem Bildschirm unterstützt und die Einstellung "IncomingCall" auf "TRUE" gesetzt ist, wird die Hintergrundaufgabe ausgeführt, und die Benachrichtigung wird angezeigt. Benachrichtigungen von Alarmen, die vom Benutzer in der standardmäßig angegebenen Alarm-App festgelegt wurden, werden auch in den Ruhezeiten angezeigt.

Der Ruhezeitenmodus ist standardmäßig von Mitternacht bis 6:00 Uhr aktiviert, wobei eingehende Anrufe erlaubt sind. Die Benutzer können diese Einstellungen ändern oder die Ruhezeiten auf der Benachrichtigungsregisterkarte im Bereich für Apps unter PC-Einstellungen ändern deaktivieren. Ruhezeiten sind auf allen Systemen verfügbar.

Abbrechen von im Leerlauf befindlichen Aufgaben

Die Windows-Hintergrundaufgabeninfrastruktur erkennt nicht nur Ressourcenbeschränkungen bei Hintergrundaufgaben, sondern auch im Leerlauf befindliche oder nicht mehr reagierende Hintergrundaufgaben. Wenn eine Hintergrundaufgabe nicht innerhalb einer bestimmten Mindestzeit ein Mindestkontingent an CPU- oder Netzwerkressourcen genutzt hat, gilt sie als im Leerlauf befindlich oder nicht mehr reagierend. Wird eine im Leerlauf befindliche oder nicht mehr reagierende Hintergrundaufgabe erkannt, wird ihr eine Abbruchbenachrichtigung gesendet, damit sie beendet und geschlossen werden kann. Wird die Hintergrundaufgabe nicht innerhalb von fünf Sekunden beendet und geschlossen, geht das System davon aus, dass die App nicht mehr reagiert, und beendet sie.

Vermeiden Sie in Windows 8.1, dass die App aufgrund einer im Leerlauf befindlichen oder nicht mehr reagierenden Hintergrundaufgabe beendet wird. Ordnen Sie immer einen Abbruchhandler zu, damit sie sauber abgebrochen wird. Siehe Details und Codeausschnitte in So wird's gemacht: Behandeln von Hintergrundaufgaben, die sich im Leerlauf befinden oder nicht mehr reagieren.

Arbeitskostenhinweis für Hintergrundaufgaben

Windows 8.1 bietet Hintergrundaufgaben einen Hinweis zur Ressourcenverfügbarkeit. Wenn eine Hintergrundaufgabe aktiviert wird, kann sie mithilfe dieses Hinweises entscheiden, welchen Teil der Arbeitsauslastung sie übernehmen soll. Es gibt drei Status für Hintergrundaufgaben, die gemeldet werden können: niedrig, mittel und hoch. Weitere Informationen finden Sie unter "BackgroundWorkCost" und "BackgroundWorkCostValue".

PowerShell-Cmdlets für Hintergrundaufgaben

Mit den neuen AppBackgroundTask-PowerShell-Befehlen und dem neuen BackgroundTasksManager-Cmdlet-Designermodul können Entwickler Informationen zu aktiven Hintergrundaufgaben abrufen. Dies kann beim Implementieren und Debuggen von Hintergrundaufgaben sehr hilfreich sein. Weitere Informationen finden Sie unter PowerShell-Cmdlets für Hintergrundaufgaben.

Unterstützung von Alarm-Apps auf dem Sperrbildschirm

[Laden Sie sich das Beispiel für Alarmbenachrichtigungen herunter.]

Bei Windows 8.1 wird jetzt einer der Sperrbildschirmplätze von Alarm-Apps belegt. Alarm-Apps verwenden die AlarmApplicationManager-Klasse, um vom Benutzer die Erlaubnis anzufordern, als System-Alarm-App zu fungieren. Wenn der Benutzer die Erlaubnis gibt (oder wenn der Benutzer die App mithilfe der Systemsteuerung in den Alarmplatz platziert), dann nimmt die App den Platz ein und wird zur Alarm-App des Systems. Alarmbenachrichtigungen, die von der System-Alarm-App ausgelöst werden, werden dem Benutzer dann innerhalb einer Sekunde angezeigt. Nur die App auf dem Alarmplatz kann Alarmbenachrichtigungen auslösen. Alarmbenachrichtigungen von anderen Apps werden als normale Benachrichtigungen behandelt.

Sie können Alarmbenachrichtigungen planen, indem Sie Popupbenachrichtigungen mit dem commands-Element erstellen. Mit dem audio-Element können Sie auch den Alarmsound festlegen, der ausgegeben werden soll, wenn die Benachrichtigung ausgelöst wird. Der Alarmsound ertönt selbst dann, wenn das System stummgeschaltet ist.

Aktualisierung der Planung von Arbeitsaufgaben

Mithilfe der CoreDispatcher-API (Windows::UI::Core:CoreDispatcher) haben Sie beim Planen von Arbeitsaufgaben jetzt eine bessere Kontrolle über die Prioritäten.

Unter Windows 8.1 gilt für Prioritäten in Bezug auf die Verteilung von Arbeit jetzt die folgende Reihenfolge:

  1. SendMessage (höchste Priorität)
  2. CoreDispatcherPriority.High
  3. CoreDispatcherPriority.Normal (enthält Fenstermeldungen und COM-Aufrufe (Component Object Model))
  4. Beliebige Geräteeingabemeldungen
  5. CoreDispatcherPriority.Low
  6. CoreDispatcherPriority.Idle (niedrigste Priorität, Verwendung für Hintergrundaufgaben)
Verwenden Sie zum Ändern der Aufgabenprioritäten diese neuen Member für den CoreDispatcher-Typ:
  • CoreDispatcher::ShouldYield-Methode (zwei Überladungen): Fragt ab, ob der Aufrufer zurücktreten soll, wenn in der Aufgabenwarteschlange Elemente mit der angegebenen Priorität oder höher enthalten sind.

  • CoreDispatcher::CurrentPriority-Eigenschaft: Ruft die aktuelle Priorität der Aufgabe ab (bzw. legt diese fest), die vom CoreDispatcher-Element zuletzt behandelt wurde. Wenn von einer App Arbeit einer bestimmten Priorität verarbeitet wird und Arbeit mit höherer Priorität eingeht, sollten Sie diese Eigenschaft so festlegen, dass die Priorität der aktuellen Aufgabe erhöht wird. Dies führt dazu, dass mit dem ShouldYield-Element genauere Ergebnisse erzielt werden.

 

 

Anzeigen:
© 2017 Microsoft