Erstellen verbundener Windows Store-Apps

Benutzer sind ständig von Geräten umgeben, die mit einem Netzwerk verbunden sind. Selbst die neuesten Kühlschränke und Waschmaschinen können eine Verbindung mit dem Internet oder mit einem Heimnetzwerk herstellen. Daher ist es nicht überraschend, wenn Endbenutzer erwarten, dass ihre Apps ebenfalls über eine Verbindung verfügen. Diese „verbundenen Apps“ rufen aktuelle Inhalte aus dem Web ab – soziale Medien, digitale Medien, Blogs und andere Inhaltstypen. Die Entwicklung verbundener Apps ist mittlerweile zur Regel geworden. Dennoch kann die Bewältigung häufiger Probleme wie Unterbrechungen der Netzwerkverbindung, die Kosten getakteter Netzwerke oder unzureichende Leistung eine Herausforderung darstellen. Mit Windows 8 ist es einfacher als je zuvor, eine verbundene App zu erstellen.

In diesem Beitrag werden einige nützliche Tipps erläutert, die Sie beim Entwickeln schneller, flüssiger, benutzerfreundlicher und verbundener Windows Store-Apps unterstützen:

• Auswählen der passenden API für Ihre Szenarien
• Auswählen der richtigen Netzwerkfunktionen
• Anpassen des App-Verhaltens für getaktete Netzwerke
• Reagieren auf Änderungen des Netzwerkstatus
• Zwischenspeichern von Inhalten für eine flüssige Darstellung

Sehen wir uns jeden dieser Tipps genauer an.

Auswählen der passenden API

Wenn Sie ein Haus bauen, sollten Sie dazu geeignete Werkzeuge verwenden: einen Hammer zum Einschlagen von Nägeln, eine Säge zum Zersägen von Brettern und einen Schraubendreher zum Befestigen von Schrauben. Gleichermaßen sollten Sie beim Entwickeln einer verbundenen Windows Store-App die passenden Netzwerk-APIs einsetzen. Windows 8 stellt eine Vielzahl von Netzwerk-APIs zur Verfügung, die von Ihrer App für die Kommunikation mit anderen Computern und Geräten genutzt werden können, ob über das Internet oder in privaten Netzwerken. Zunächst sollten Sie also überlegen, welche Netzwerkfunktionen von Ihrer App benötigt werden.

Eines der häufigsten Netzwerkszenarien ist der Zugriff auf eine Website, um Informationen abzurufen oder zu speichern. Ein einfaches Beispiel hierfür könnte ein Spiel sein, das eine Website verwendet, um Benutzerinformationen und Spielstände zu speichern. Ein komplexeres Beispiel könnte eine App darstellen, die eine Verbindung mit einem REST-basierten Webdienst herstellt, um eine vom Dienst bereitgestellte Bibliothek zum Abrufen und Speichern von Informationen zu nutzen. Windows 8 beinhaltet verschiedene APIs zum Herstellen von Verbindungen mit Webdiensten und Websites. Mithilfe dieser APIs kann Ihre App auf Webdienste mit REST-Unterstützung zugreifen oder grundlegende HTTP-Protokollbefehle (wie GET und POST) an einen Webserver senden. Die jeweilige für den Webzugriff benötigte API hängt von der Sprache ab, die Sie bei der Entwicklung der App verwenden:

• In JavaScript und HTML geschriebene Apps: XMLHTTPRequest und WinJS.xhr
• In C# oder Visual Basic .NET und XAML geschriebene Apps: HttpClient
• In C++ und XAML geschriebene Apps: XML HTTP Request 2 (IXHR2)

Im folgenden Code wird das Ausführen einer grundlegenden Anforderung und Antwort mit einem REST-basierten Webdienst dargestellt. Beispielsweise könnte in diesem Fall ein ASP.NET-Skript auf dem Webserver vom Webdienst ausgeführt werden.

JavaScript

 function makeXHRCall() {
    WinJS.xhr({ uri: "https://www.microsoft.com/en-us/default.aspx” }).done(
        function onComplete(result) {
            print(result.responseText);
        },
        function onError(err) {
            print("Error: " + err.responseText);
        });
}

C#

 private async void MakeHttpCall()
{
    HttpClient httpClient = new HttpClient();
    try {
        string response = await httpClient.GetStringAsync("https://www.microsoft.com/en-us/default.aspx");
    }
    catch (Exception) {
        // Handle exception.
    }
}

Weitere Informationen zu WinJS.xhr finden Sie unter Herstellen einer Verbindung mit Webdiensten (Windows Store-Apps mit JavaScript und HTML). Weitere Informationen zu HttpClient finden Sie unter Schnellstart: Verbinden mit HttpClient (Windows Store-Apps mit C#/VB/C++ und XAML) und unter HttpClient sample.

Ein weiteres häufiges Netzwerkszenario besteht im Herunterladen oder Hochladen von Dateien, wobei die Dateiübertragung etwas Zeit in Anspruch nehmen kann. Ein Beispiel hierfür sind Kamera- oder Fotogalerie-Apps, die einen Webdienst zum Hochladen oder Herunterladen von Fotos oder Fotoalben verwenden. Diese Übertragungen beanspruchen möglicherweise viel Zeit, daher macht es wenig Sinn, den Benutzer auf das Fertigstellen der Übertragung warten zu lassen. Die Windows.Networking.BackgroundTransfer-API ermöglicht das Herunterladen oder Hochladen von Dateien, auch wenn die App nicht mehr ausgeführt wird. Die App startet die Übertragung, während sie im Vordergrund ausgeführt wird und sich im Fokus befindet. Anschließend setzt Windows 8 die Übertragung im Hintergrund fort, auch wenn die App nicht mehr ausgeführt wird.

Ein weiteres, spezielleres Szenario ist der Zugriff auf Inhalte von Fremdanbietern. Die Windows.Web.Syndication-API kann Feeds im RSS- oder Atom-Format abrufen. Zudem kann eine App mithilfe der Windows.Web.AtomPub-API Daten in verschiedenen AtomPub-Formaten veröffentlichen.

Für Szenarien, in denen spezifische übergeordnete Netzwerkprotokolle nicht von APIs bereitgestellt werden können, unterstützt die Windows-Runtime zudem TCP- und UDP-Sockets (zusammen mit Multicast). Die Windows.Networking.Sockets-API stellt einen StreamSocket (TCP) und DatagramSocket (UDP) zum Implementieren anderer, übergeordneter Protokolle zur Verfügung.

Hinweis: Mit Windows 8 wird ein neuer Socket-Typ mit der Bezeichnung WebSocket eingeführt. Weitere Informationen zu WebSockets und deren Verwendungsmöglichkeiten finden Sie unter Verbinden mit WebSockets.

In der folgenden Tabelle finden Sie eine ausführlichere Liste unterstützter Netzwerkfunktionen sowie Links zu weiteren Informationen.

 

APIs	Funktionen	Beispiele
Windows.Web.Syndication Windows.Web.AtomPub	Abrufen von Feeds im RSS- oder Atom-Format in verschiedenen Versionen. Durch diese APIs wird die Implementierung von Unterstützung neuerer Formate wie beispielsweise OData erleichtert. Die Windows-Runtime unterstützt außerdem das Atom Publishing Protocol und ermöglicht so das Veröffentlichen von Atom-Auflistungen. Weitere Informationen finden Sie unter Zugreifen auf und Verwalten von Inhalten von Fremdanbietern.	Syndication sample AtomPub sample RSS-Reader
Windows.Networking.BackgroundTransfer	Kostenbewusstes und wiederaufnehmbares Herunterladen und Hochladen von Inhalten ohne Unterbrechungen, auch wenn die aufrufende App nicht im Vordergrund ausgeführt wird. Diese API unterstützt die Übertragung von Inhalten mithilfe der HTTP-, HTTPS- und FTP-Protokolle. Weitere Informationen finden Sie unter Übertragen von Daten im Hintergrund.	Background Transfer sample SkyDrive Xbox Video
XMLHTTPRequest (JavaScript ) WinJS.xhr (JavaScript) HttpClient (C#) XML HTTP Request 2 (IXHR2) (C++)	Interaktion mit REST-basierten Webdiensten und anderen HTTP-basierten Protokollen. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit Webdiensten.	XHR, handling navigation errors, and URL schemes sample HttpClient sample Bing Maps
Windows.Networking.Proximity	Erkennung der unmittelbaren räumlichen Nähe zweier Geräte, damit Apps mithilfe von Socket-APIs eine Netzwerkverbindung dazwischen herstellen können. Weitere Informationen finden Sie unter Unterstützen von Näherung und Kopplung.	Proximity sample Spiele Apps für die Zusammenarbeit
Windows.Storage.Pickers	Kommunikation mit Remotedateifreigaben. Weitere Informationen finden Sie unter Zugreifen auf Daten und Dateien.	File picker sample Xbox Music Fotos
Windows.Networking.Sockets	Herstellen einer Verbindung mit einem Dienst, der ein Protokoll verwendet, das von den bisher genannten APIs nicht unterstützt wird (z. B. SMTP, MAPI oder Telnet), bzw. mit einem anderen Gerät im selben lokalen Netzwerk. Wird ebenfalls für Apps verwendet, die socketähnliche Semantik (asynchron, bidirektional) erfordern, um über das Web (einschließlich HTTP-Proxys) eine Verbindung mit einem neuen Dienst herzustellen. Weitere Informationen finden Sie unter Verbinden mit Sockets.	StreamSocket sample DatagramSocket sample Connecting with WebSockets sample ControlChannelTrigger samples Lync, Whiteboards zur Zusammenarbeit oder Stockpicker
Windows.Storage.ApplicationData	Windows 8 überträgt automatisch bestimmte Anwendungsdaten zwischen Benutzergeräten. Das Roaming von Anwendungsdaten ist für Apps vorteilhaft, die von Benutzern auf mehreren Geräten verwendet (beispielsweise einem Büro-PC und einem privaten Tablet) und installiert werden. Weitere Informationen finden Sie unter Richtlinien für das Roaming von Anwendungsdaten.	Application data sample

Auswählen der richtigen Netzwerkfunktionen

Netzwerkisolation ist eine Komponente des App-Sicherheitsmodells von Windows 8. Windows erkennt aktiv Netzwerkgrenzen und erzwingt Zugriffseinschränkungen zwecks Netzwerkisolation. Wenn Sie diese Funktionen richtig bereitstellen, können Sie Benutzer und Apps vor böswilligen Angriffen schützen.

Apps müssen Netzwerkisolationsfunktionen deklarieren, um das Ausmaß des Netzwerkzugriffs festzulegen. Ohne Deklaration dieser Funktionen kann die App nicht auf Netzwerkressourcen zugreifen. Weitere Informationen zum Erzwingen der Netzwerkisolation für Apps durch Windows finden Sie unter So wird's gemacht: Festlegen von Netzwerkfunktionen.

Beachten Sie, dass Netzwerkfunktionen nicht als Kommunikationsmechanismus zwischen den Prozessen einer Windows Store-App und einer Desktop-App verwendet werden können, die sich auf demselben Gerät befinden. Beispielsweise ist es nicht möglich, IP-Loopbackadressen für eine Windows Store-App zu nutzen. Zu Entwicklungszwecken gelten bestimmte Ausnahmen, die die Verwendung von IP-Loopbackadressen im Visual Studio-Debugger ermöglichen. Weitere Informationen finden Sie unter So wird's gemacht: Aktivieren von Loopback und Problembehandlung bei der Netzwerkisolation.

Netzwerkzugriffsanforderungen werden in die folgenden beiden Kategorien unterteilt:

1. Ausgehende, vom Client initiierte Anforderungen: Die App fungiert als Client und initiiert den Netzwerkzugriff durch das Senden einer ersten Netzwerkanforderung an einen Remotecomputer, in der Regel einen Server. Die App sendet eine oder mehrere Anforderungen an den Server, und der Server gibt eine oder mehrere Antworten zurück. Der gesamte Datenverkehr zwischen einer Webclient-App und einem Webserver ist ein Beispiel für diese Kategorie.
2. Eingehende, unaufgeforderte Anforderungen: Die App übernimmt die Rolle eines Netzwerkservers und lauscht nach eingehenden Netzwerkanforderungen von einem Remotecomputer. Der Remotecomputer initiiert den Netzwerkzugriff durch das Senden einer ersten Anforderung an die App, die als Server fungiert. Der Remotecomputer sendet eine oder mehrere Anforderungen an die App, die eine oder mehrere Antworten an den Remotecomputer zurückgibt. Ein Beispiel für diese Kategorie wäre eine App, die als Medienserver dient.

Gehen Sie nach dem Prinzip der geringsten Rechte vor, und fügen Sie Ihrer App ausschließlich benötigte Funktionen hinzu. Möglicherweise sind für Ihre App nur ausgehende, vom Client initiierte Anforderungen erforderlich. Es kann jedoch auch sein, dass eingehende unaufgeforderte Anforderungen empfangen werden können müssen. Für einige Apps kann zwecks Authentifizierung über ein Netzwerk auch der Zugriff auf Anmeldeinformationen von Benutzern und Zertifikate erforderlich sein.

In der folgenden Tabelle werden die Netzwerkisolationsfunktionen und weitere ähnliche Funktionen aufgeführt, die häufig für verbundene Apps benötigt werden. Bei den ersten drei Funktionen handelt es sich um die primären in verbundenen Apps eingesetzten Netzwerkisolationsfunktionen. Tatsächlich muss in einer verbundenen App mindestens eine dieser ersten drei Funktionen aktiviert sein. Die anderen Einträgen in der Tabelle stellen zusätzliche Funktionen dar, die häufig für einige verbundene Apps erforderlich sind.

 

Netzwerkfunktion	Beschreibung	App-Beispiele
Internet (Client)	Stellt ausgehenden Zugriff auf das Internet und öffentliche Netzwerke bereit, z. B. auf Flughäfen oder in Cafés. Diese Funktion muss für die meisten Apps deklariert werden, die Internetzugang benötigen.	RSS-Reader Soziale Netzwerke Spiele
Internet (Client und Server)	Stellt sowohl eingehenden als auch ausgehenden Zugriff auf das Internet und öffentliche Netzwerke bereit, z. B. auf Flughäfen oder in Cafés. Eingehender Zugriff auf wichtige Ports wird stets blockiert. Diese Funktion beinhaltet die gesamte Internet (Client)-Funktion, es müssen daher nicht beide deklariert werden.	P2P-Apps Multiplayer-Spiele, in denen Spieler per Multicast erkannt werden
Private Netzwerke (Client und Server)	Stellt eingehenden und ausgehenden Netzwerkzugriff an privaten, vertrauenswürdigen Standorten bereit. Hierbei handelt es sich in der Regel um Heim- oder Unternehmensnetzwerke. Eingehender Zugriff auf wichtige Ports wird stets blockiert.	Apps mit Zugriff auf NAS (Network Attached Storage)-Inhalte Branchen-Apps Multiplayer-Spiele, in denen Spieler in einem privaten Netzwerk (Heimnetz oder Unternehmensnetzwerk) per Multicast erkannt werden
Näherung	Erforderlich für die Nahfeldkommunikation zwischen Geräten. Ermöglicht Apps den Netzwerkzugriff, um eine Verbindung mit einem Gerät in der unmittelbaren Umgebung herzustellen. Die Benutzer müssen dem Senden oder Annehmen einer Einladung zustimmen.	Multiplayer-Spiele mit Personen in der näheren Umgebung
Unternehmensauthentifizierung	Bietet die Möglichkeit, auf Intranetressourcen von Unternehmen zuzugreifen, für die Domänenanmeldeinformationen erforderlich sind.	Branchen-Apps
Freigegebene Benutzerzertifikate	Bietet die Möglichkeit, zur Überprüfung der Benutzeridentität auf Software- und Hardwarezertifikate (z. B. Smartcardzertifikate) zuzugreifen. Wenn zugehörige APIs zur Laufzeit aufgerufen werden, muss der Benutzer eine Aktion ausführen (z. B. Karte einführen oder ein Zertifikat auswählen).	VPN-Apps Branchen-Apps

Anhand der folgenden Prüfliste können Sie sicherstellen, ob die Netzwerkisolation für Ihre App konfiguriert ist:

• Ermitteln Sie, welche Richtung des Netzwerkzugriffs für Ihre App erforderlich ist: ausgehende, vom Client initiierte Anforderungen, eingehende unaufgeforderte Anforderungen oder beide.
• Ermitteln Sie, mit welchen Arten von Netzwerkressourcen Ihre App kommunizieren soll: vertrauenswürdige Ressourcen in einem Heim- oder Unternehmensnetzwerk, Internetressourcen oder beiden.
• Konfigurieren Sie im App-Manifest die mindestens erforderlichen Netzwerkisolationsfunktionen. Verwenden Sie hierzu den App-Manifest-Designer in Microsoft Visual Studio 2012 oder fügen Sie sie manuell hinzu.
• Testen Sie die Bereitstellung und Ausführung Ihrer App, indem Sie die Netzwerkisolationstools für die Problembehandlung verwenden. Weitere Informationen finden Sie unter So wird's gemacht: Aktivieren von Loopback und Problembehandlung bei der Netzwerkisolation.

Im folgenden Screenshot wird veranschaulicht, wie die Netzwerkfunktionen mit dem App-Manifest-Designer in Microsoft Visual Studio 2012 aktiviert werden.

Auswählen der Netzwerkfunktionen für Ihre App im package.appxmanifest mit Visual Studio 2012

Anpassen des App-Verhaltens für getaktete Netzwerke

Vielleicht erinnern Sie sich daran, wie Sie das letzte Mal das monatliche Datenlimit erreicht haben oder im Ausland unterwegs waren. In diesen Situationen verwenden Benutzer ihre Geräte und Apps in der Regel sehr zurückhaltend, um unnötige Netzwerkgebühren zu vermeiden.

Unter Windows 8 wird dieses Problem behoben, indem das Überwachen der verfügbaren Netzwerkressourcen durch die Apps und ein entsprechendes Verhalten in getakteten Netzwerken ermöglicht wird. Um das Vertrauen der Benutzer in Ihre Apps zu stärken, können Sie dafür sorgen, dass Ihre App anfallende Verbindungskosten erkennt und sich so verhält, dass diese Kosten vermieden oder verringert werden.

Die Windows.Networking.Connectivity-API stellt Informationen zu Typen und Kosten von Netzwerkverbindungen bereit. Dadurch kann Ihre App ermitteln, in welcher Situation die Netzwerkressourcen normal, eher konservativ oder benutzerdefiniert verwendet werden sollten.

Ein ConnectionProfile stellt eine Netzwerkverbindung dar. Ihre App kann mit der ConnectionCost-Klasse einer ConnectionProfile-Klasse ermitteln, ob das Verhalten angepasst werden soll. Durch die NetworkCostType-Eigenschaft wird der Typ einer Netzwerkverbindung angegeben. Folgende vier Werte sind möglich:

• Unrestricted – Die Netzwerkverbindung kann uneingeschränkt verwendet werden. Es bestehen keine Limits bezüglich der Nutzungsgebühren oder Kapazität.
• Fixed – Die Netzwerkverbindung kann bis zu einem bestimmten Limit uneingeschränkt verwendet werden.
• Variable – Die Netzwerkverbindung ist getaktet (pro Byte).
• Unknown – Für diese Netzwerkverbindung sind keine Kosteninformationen verfügbar.

Mehrere zusätzliche boolesche Eigenschaften für die ConnectionCost-Klasse stellen noch mehr Informationen bereit.

• Roaming – Es wird eine Verbindung zu einem anderen Netzwerk als des Heimanbieters hergestellt.
• ApproachingDataLimit – Die Verbindung nähert sich dem Nutzungslimit des Datentarifs.
• OverDataLimit – Die Verbindung hat das Nutzungslimit des Datentarifs überschritten.

Gestalten Sie Ihre App so, dass sie angemessen auf die von diesen Eigenschaften angegebenen Informationen reagiert. Wenn eine Verbindung den Status Roaming aufweist, können sich aus der Netzwerknutzung hohe Datenkosten ergeben. Wenn die Eigenschaft NetworkCostType auf den Wert Variable festgelegt ist, handelt es sich um ein getaktetes Netzwerk, in dem der Benutzer für die Menge der im Netzwerk gesendeten oder empfangenen Daten bezahlt. Liegt der Wert für NetworkCostType bei Fixed, besteht Handlungsbedarf, wenn der Benutzer das Datenlimit überschritten hat oder sich diesem nähert.

Mithilfe dieser Informationen kann die App anhand der Richtlinien feststellen, wie Netzwerkressourcen am besten verwendet werden.

Verhalten	Verbindungskosten	App-Richtlinien	Beispiele
Normal	Der NetworkCostType ist Unrestricted oder Unknown, und ConnectionCost weist nicht den Wert Roaming auf.	Die App wendet keine Einschränkungen an. Sie behandelt die Verbindung als Unlimited in Bezug auf die Kosten und als uneingeschränkt in Bezug auf Nutzungsgebühren und Kapazitätslimits.	Die Media Player-App kann einen ganze HD-Film wiedergeben. Die App kann eine große Datei ohne Einschränkungen oder Eingabeaufforderungen herunterladen.
Konservativ	Der NetworkCostType ist Fixed oder Variable, und ConnectionCost ist nicht auf Roaming oder OverDataLimit festgelegt.	Die App nimmt Einschränkungen vor, um die Netzwerknutzung für Vorgänge in getakteten Netzwerken zu optimieren.	Die Media Player-App kann Filme in niedrigeren Auflösungen wiedergeben. Die App kann Downloads verzögern, die nicht unbedingt erforderlich sind.
Opt-In	Die ConnectionCost weist den Wert Roaming oder OverDataLimit auf.	Die App reagiert auf Ausnahmefälle, in denen die Kosten für den Netzwerkzugriff deutlich über denen des Tarifs liegen.	Die App fordert den Benutzer zum Netzwerkzugriff auf. Die App hält die gesamte Netzwerkdatennutzung im Hintergrund an.

In diesem Codebeispiel werden die Verbindungskosten überprüft. Anschließend werden Vorschläge für ein geeignetes Verhalten ausgegeben.

JavaScript

 var CostGuidance = { Normal: 0, Conservative: 1, OptIn: 2 };
// GetCostGuidance returns an object with a Cost (with value of CostGuidance), 
// CostName (a string) and Reason, which says why the cost is what it is.
function GetCostGuidance() 
{
    var connectionCost = Windows.Networking.Connectivity.NetworkInformation.getInternetConnectionProfile().getConnectionCost();
    var networkCostConstants = Windows.Networking.Connectivity.NetworkCostType;
    var Retval = new Object();
    if (connectionCost.roaming || connectionCost.overDataLimit)
    {
        Retval.Cost = CostGuidance.OptIn;
        Retval.CostName = "OptIn";
        Retval.Reason = connectionCost.roaming
            ? "Connection is roaming; using the connection may result in additional charge."
            : "Connection has exceeded the usage cap limit.";
    }
    else if (connectionCost.networkCostType == networkCostConstants.fixed
        || connectionCost.networkCostType == networkCostConstants.variable)
    {
        Retval.Cost = CostGuidance.conservative;
        Retval.CostName = "Conservative";
        Retval.Reason = connectionCost.networkCostType == NetworkCostType.fixed
            ? "Connection has limited allowed usage."
            : "Connection is charged based on usage. ";
    }
    else
    {
        Retval.Cost = CostGuidance.Normal;
        Retval.CostName = "Normal";
        Retval.Reason = connectionCost.networkCostType == networkCostConstants.unknown
            ? "Connection is unknown."
            : "Connection cost is unrestricted.";
    }

    return Retval;
}

C#

 public enum NetworkCost { Normal, Conservative, OptIn };
public class CostGuidance
{
    public CostGuidance()
    {
        var connectionCost = NetworkInformation.GetInternetConnectionProfile().GetConnectionCost();
        Init(connectionCost);
    }
    public NetworkCost Cost { get; private set; }
    public String Reason { get; private set; }


    public void Init(ConnectionCost connectionCost)
    {
        if (connectionCost == null) return;
        if (connectionCost.Roaming || connectionCost.OverDataLimit)
        {
            Cost = NetworkCost.OptIn;
            Reason = connectionCost.Roaming
                ? "Connection is roaming; using the connection may result in additional charge."
                : "Connection has exceeded the usage cap limit.";
        }
        else if (connectionCost.NetworkCostType == NetworkCostType.Fixed
            || connectionCost.NetworkCostType == NetworkCostType.Variable)
        {
            Cost = NetworkCost.Conservative;
            Reason = connectionCost.NetworkCostType == NetworkCostType.Fixed
                ? "Connection has limited allowed usage."
                : "Connection is charged based on usage. ";
        }
        else
        {
            Cost = NetworkCost.Normal;
            Reason = connectionCost.NetworkCostType == NetworkCostType.Unknown
                ? "Connection is unknown."
                : "Connection cost is unrestricted.";
        }
    }
}

In diesem network information sample erfahren Sie mehr über das Anpassen des App-Verhaltens an getaktete Netzwerke.

Zudem können Benutzer den Task-Manager ausführen, um anzuzeigen, in welchem Umfang Netzwerkdaten von den einzelnen App genutzt werden. Dieser Screenshot zeigt ein Beispiel.

Anzeige der Nutzung von CPU- und Netzwerkressourcen durch Apps aus der Registerkarte "App-Verlauf" im Task-Manager

Reagieren auf Änderungen des Netzwerkstatus

Für mobile Geräte ändert sich gelegentlich das Netzwerk. Beispielsweise können mobile 3G- oder 4G-Breitbandnetzwerke im Haus oder der Garage von Benutzern außer Reichweite sein, während das WLAN weiterhin verfügbar ist. Entsprechend kann beim Verlassen des Hauses die WLAN-Verbindung verloren gehen. Zudem kann es vorkommen, dass gar kein Netzwerk verfügbar ist. Angesichts der Verbreitung von WLAN- und mobilen Breitbandnetzwerken treten diese Netzwerkänderungen häufig auf.

In diesem Fall gibt ein NetworkStatusChanged-Ereignis an, dass sich möglicherweise die verfügbaren Kosten- oder Verbindungsoptionen geändert haben. Um auf derartige Änderungen des Netzwerkstatus zu reagieren und eine unterbrechungsfreie Verbindung zu gewährleisten, sollten Sie bei Ihren verbundenen Apps folgende szenariospezifische Richtlinien berücksichtigen.

Verbindungsverlust aufgrund eines Fehlers

Verbindungen können in der Regel wiederhergestellt werden, indem einfach der Netzwerkvorgang erneut ausgeführt wird. Schlägt dieser Versuch fehl, warten Sie auf ein NetworkStatusChanged-Ereignis. Wir empfehlen die Verwendung steigender Backoff-Intervalle zwischen den einzelnen Versuchen. Die App sollte mit einem Wert von 50 Millisekunden beginnen und das Intervall exponentiell steigern, wenn die Verbindung nicht hergestellt werden kann.

Verlust der Netzwerkverbindung

Informieren Sie den Benutzer darüber, dass die Verbindung getrennt wurde, und warten Sie nach einer entsprechenden Registrierung auf ein NetworkStatusChanged-Ereignis.

Verfügbarkeit eines neuen Netzwerks

Es kann vorkommen, dass ein Gerät mit mehreren Netzwerken verbunden ist. Angenommen, ein Benutzer chattet mit der Nachrichten-App von Windows 8 über eine mobile Breitbandverbindung mit Freunden, während er zu Hause ankommt und dort eine weitere Verbindung zum uneingeschränkten Netzwerk herstellt. Gemäß der Standardrichtlinie von Windows 8 ist ein uneingeschränktes Netzwerk einem getakteten Netzwerk vorzuziehen, und ein schnelleres Netzwerk einem langsameren. Allerdings wechseln Apps, die bereits über eine Verbindung verfügen, nicht automatisch zu einem neuen Netzwerk. Die App muss einbezogen werden, da nur so die richtige Entscheidung bezüglich eines Netzwerkwechsels getroffen werden kann.

Wenn z. B. ein Videostream kurz vor dem Abschluss steht, ist es wenig sinnvoll, in das neue Netzwerk zu wechseln. Sollte das aktuelle Netzwerk jedoch Pakete verlieren, zu langsam sein oder zusätzliche Zeit zum Beenden des Streams benötigen, bietet sich ein Wechsel in das neue Netzwerk an.

Wenn Sie den Wechsel des Netzwerks für Ihr App-Szenario in Erwägung ziehen, beachten Sie diese Richtlinien, falls ein neues Netzwerk erkannt wird:

1. Überprüfen Sie die Kosten des vorhandenen und des neuen Netzwerks. Wenn Sie den Wechsel in das neue Netzwerk für sinnvoll halten, versuchen Sie, eine neue Netzwerkverbindung herzustellen, und wiederholen Sie den Netzwerkvorgang gemäß der oben genannten Richtlinien. Windows wählt uneingeschränkte Netzwerke automatisch vor getakteten Netzwerken aus, und ein schnelleres Netzwerk wird einem langsameren bevorzugt (sofern vorhanden).
2. Nachdem die neue Netzwerkverbindung erfolgreich hergestellt wurde, verwenden Sie diese für Ihre App, und brechen Sie den ursprünglichen Vorgang im vorherigen Netzwerks ab, falls bereits eine Verbindung besteht.

Änderung der Netzwerkkosten

Die Netzwerkkosten können sich ändern, wenn der NetworkCostType den Wert Fixed aufweist und sich die Datennutzung dem Limit nähert oder dieses übersteigt. Zudem können sich die Netzwerkkosten ändern, wenn der Wert für NetworkCostType auf Variable festgelegt ist oder der Wert für Roaming zu „true“ wechselt. Passen Sie in diesen Fällen das App-Verhalten anhand der Richtlinien aus dem vorherigen Tipp an.

In den folgenden Codebeispielen wird das NetworkStatusChanged-Ereignis verwendet, um im Fall verschiedener Änderungen des Netzwerkstatus eine nahtlose Ausführung der App zu gewährleisten. In beiden Beispielen kommt die globale boolesche Variable registeredNetworkStatusNotification zum Einsatz, die zunächst auf false festgelegt ist.

JavaScript

 // Register for NetworkStatusChanged notifications, and display new 
// Internet ConnectionProfile info upon network status change.
function registerForNetworkStatusChange() {
    try {

        // Register for network status change notifications.
        if (!registeredNetworkStatusNotification) {
            var networkInfo.addEventListener("networkstatuschanged", onNetworkStatusChange);
            registeredNetworkStatusNotification = true;
        }
    }
    catch (e) {
        print("An unexpected exception occurred: " + e.name + ": " + e.message);
    }
}

// Event handler for NetworkStatusChanged event
function onNetworkStatusChange(sender) {
    try {
        // Get the ConnectionProfile that is currently used to connect 
        // to the Internet.
        var internetProfile = networkInfo.getInternetConnectionProfile();
        if (internetProfile === null) {
            print("Not connected to Internet\n\r");
        }
        else {
            internetProfileInfo += getConnectionProfileInfo(internetProfile) + "\n\r";
            print(internetProfileInfo);
        }
        internetProfileInfo = "";
    }
    catch (e) {
        print("An unexpected exception occurred: " + e.name + ": " + e.message);
    }
}

C#

 // Register for NetworkStatusChanged notifications, and display new 
// Internet ConnectionProfile info upon network status change.
void NetworkStatusChange()
{
    // Register for network status change notifications.
    try
    {
        var networkStatusCallback = new NetworkStatusChangedEventHandler(OnNetworkStatusChange);
        if (!registeredNetworkStatusNotification)
        {
            NetworkInformation.NetworkStatusChanged += networkStatusCallback;
            registeredNetworkStatusNotification = true;
        }
    }
    catch (Exception ex)
    {
        rootPage.NotifyUser("Unexpected exception occurred: " + ex.ToString(), NotifyType.ErrorMessage);
    }
}

// Event handler for NetworkStatusChanged event
async void OnNetworkStatusChange(object sender)
{
    try
    {
        // Get the ConnectionProfile that is currently used to connect 
        // to the Internet                
        ConnectionProfile InternetConnectionProfile = NetworkInformation.GetInternetConnectionProfile();

        if (InternetConnectionProfile == null)
        {
            await _cd.RunAsync(CoreDispatcherPriority.Normal, () =>
            {
                rootPage.NotifyUser("Not connected to Internet\n", NotifyType.StatusMessage);
            });
        }
        else
        {
            connectionProfileInfo = GetConnectionProfile(InternetConnectionProfile);
            await _cd.RunAsync(CoreDispatcherPriority.Normal, () =>
            {
                rootPage.NotifyUser(connectionProfileInfo, NotifyType.StatusMessage);
            });
        }
        internetProfileInfo = "";
    }
    catch (Exception ex)
    {
        rootPage.NotifyUser("Unexpected exception occurred: " + ex.ToString(), NotifyType.ErrorMessage);
    }
}

Weitere Informationen zum NetworkStatusChanged-Ereignis finden Sie unter Schnellstart: Verwalten von Verbindungsereignissen und Änderungen der Verfügbarkeit und auf der Seite Network information sample.

Zwischenspeichern von Inhalten für eine flüssige Darstellung

Durch das Zwischenspeichern von Inhalten auf einen Datenträger können Sie für eine schnelle und flüssige Ausführung Ihrer App sorgen. Eine RSS-Reader-App kann beispielsweise Feeds unmittelbar anzeigen, die in einer vorherigen Sitzung auf einem Datenträger zwischengespeichert wurden. Sobald die neue Feeds verfügbar sind, wird der Inhalt der App aktualisiert. Durch das Zwischenspeichern wird sichergestellt, dass Benutzer bereits beim Start Inhalte nutzen können, während neue Inhalte von der App abgerufen werden.

Windows 8 stellt die Klasse ApplicationData im Namespace Windows.Storage bereit. Diese Klasse ermöglicht den Zugriff auf den App-Datenspeicher. Der Datenspeicher besteht aus Dateien und Einstellungen, die sich entweder lokal auf dem Gerät befinden, zwischen mehreren Geräten geroamt werden oder temporär sind.

Dateien eignen sich optimal zum Speichern von großen Datensätzen, Datenbanken oder Daten mit gleichem Format. Die Dateien können sich im Roaming-, Lokal- oder Temporär-Ordner befinden. Dies bedeutet Folgendes:

• Roaming-Dateien werden auf mehreren Computern und Geräten synchronisiert, auf denen die Benutzer mit verbundenen Konten angemeldet sind. Das Roaming der Dateien erfolgt nicht unmittelbar, da das System zunächst mehrere Faktoren überprüft, um den Zeitpunkt der Datenübertragung festzulegen. Halten Sie die Nutzung von Roamingdaten unterhalb des Kontingents (verfügbar über die RoamingStorageQuota-Eigenschaft). Bei einer Überschreitung des Kontingents wird das Datenroaming angehalten. Das Roaming von Dateien, in die gerade von der App geschrieben wird, ist nicht möglich. Achten Sie also darauf, die Dateiobjekte Ihrer App zu schließen, wenn diese nicht benötigt werden.
• Lokale Dateien werden nicht auf mehreren Computern synchronisiert. Sie verbleiben auf dem Computer, auf dem sie erstellt wurden.
• Temporäre Dateien werden entfernt, wenn sie nicht verwendet werden. Um festzustellen, ob eine temporäre Datei entfernt werden soll, überprüft das System Faktoren wie die verfügbare Datenträgerkapazität und das Alter einer Datei.

In den folgenden Codebeispielen werden Inhalte auf dem Datenträger zwischengespeichert. Durch das Zwischenspeichern der Serverantwort kann die App Inhalte unmittelbar nach dem Beenden und Neustart anzeigen. Der Einfachheit halber wird in diesen Beispielen nicht gezeigt, wie Einstellungen in den App-Datenspeicher geschrieben und wie auf Roaming-Ereignisse geantwortet wird. Informationen hierzu finden Sie unter Application data sample.

JavaScript

 var roamingFolder = Windows.Storage.ApplicationData.current.roamingFolder;
var filename = "serverResponse.txt";

function cacheResponse(strResponse) {
    roamingFolder.createFileAsync(filename, Windows.Storage.CreationCollisionOption.replaceExisting)
        .done(function (file) {
            return Windows.Storage.FileIO.writeTextAsync(file, strResponse);
        });
}

function getCachedResponse() {
    roamingFolder.getFileAsync(filename)
        .then(function (file) {
            return Windows.Storage.FileIO.readTextAsync(file);
        }).done(function (response) {
            print(response);
        }, function () {
            // getFileAsync or readTextAsync failed. 
            // No cached response.
        });
}

C#

 MainPage rootPage = MainPage.Current;
StorageFolder roamingFolder = null;
const string filename = "serverResponse.txt";

async void cacheResponse(string strResponse)
{
    StorageFile file = await roamingFolder.CreateFileAsync(filename, CreationCollisionOption.ReplaceExisting);
    await FileIO.WriteTextAsync(file, strResponse);
}

async void getCachedResponse()
{
    try
    {
        StorageFile file = await roamingFolder.GetFileAsync(filename);
        string response = await FileIO.ReadTextAsync(file);
    }
    catch (Exception)
    {
        // getFileAsync or readTextAsync failed.
        // No cached response.
    }
}

Weitere Informationen zum App-Datenspeicher finden Sie im Beitrag Roaming von App-Daten und im Application data sample.

Zusammenfassung

Verwenden Sie die Richtlinien dieses Beitrags beim Entwerfen Ihrer Windows Store-Apps. Auf diese Weise können Sie faszinierende, benutzerfreundliche und unterbrechungsfreie Apps bereitstellen. Diese Tipps sollen Ihren Entwicklungsprozess vereinfachen und gleichzeitig die Flexibilität und das Vertrauen der Benutzer in Ihre Apps stärken.

– Suhail Khalid, Programmmanager II, Windows

Unter Mitarbeit von: Steven Baker und Peter Smith