Wenn Sie beim Schreiben von Windows Store-Apps in JavaScript asynchrone APIs verwenden, werden Sie Konstrukte verwenden, die als Zusagen („Promise“) bezeichnet werden. Das Schreiben von Zusagenketten für sequenzielle asynchrone Vorgänge wird schnell zur Routine.

Im Rahmen Ihrer Entwicklungsarbeit werden Sie es jedoch wahrscheinlich noch mit anderen Anwendungen von Zusagen zu tun haben, deren Funktion nicht klar ersichtlich ist. Ein gutes Beispiel hierfür ist das Optimieren der Elementrenderingfunktionen für ein ListView-Steuerelement, wie unter HTML ListView optimizing performance sample dargestellt. Wir werden darauf in einem späteren Beitrag genauer eingehen. Sehen Sie sich auch dieses kleine Kunststück an, das Josh Williams auf der //build 2012 in seinem Vortrag Deep Dive into WinJS vorstellte (leicht geändert):

list.reduce(function callback (prev, item, i) {
    var result = doOperationAsync(item);
    return WinJS.Promise.join({ prev: prev, result: result}).then(function (v) {
        console.log(i + ", item: " + item+ ", " + v.result);
    });
})

Durch dieses Snippet werden Zusagen für parallele asynchrone Vorgänge zusammengefügt, deren Ergebnisse sequenziell in der mit list festgelegten Reihenfolge bereitgestellt werden. Wenn Sie die Funktionalität dieses Codes auf Anhieb verstehen, können Sie den Rest dieses Beitrags getrost überspringen. Falls nicht, gehen wir genauer auf die eigentliche Funktionsweise von Zusagen und deren Bedeutung in WinJS (der Windows-Bibliothek für JavaScript) ein, um ein besseres Verständnis dieser Muster zu entwickeln.

Was genau ist eine Zusage? Zusagenbeziehungen

Fangen wir mit einer grundlegenden Wahrheit an: Bei einer Zusage handelt es sich im Wesentlichen nur um ein Codekonstrukt bzw. eine Aufrufkonvention. Zusagen haben daher keine besondere Beziehung zu asynchronen Vorgängen, sie sind diesbezüglich nur äußerst nützlich. Eine Zusage ist lediglich ein Objekt, das einen Wert darstellt, der möglicherweise zukünftig verfügbar wird oder schon verfügbar ist. Gewissermaßen haben Zusagen also die gleiche Bedeutung wie im normalen Sprachgebrauch. Wenn ich Ihnen zusage, ein Dutzend Donuts zu bringen, muss ich diese Donuts in diesem Moment nicht unbedingt besitzen, nehme jedoch mit Sicherheit an, dass ich sie erhalten werde. Sobald ich die Donuts habe, liefere ich.

Eine Zusage impliziert also eine Beziehung zwischen zwei Parteien: dem Urheber, der die Zusage für eine Warenlieferung tätigt, und dem Verbraucher, der sowohl die Zusage als auch die eigentlichen Waren erhält. Die Beschaffung der Waren fällt in die alleinige Verantwortung des Urhebers, und auch der Verbraucher kann mit der Zusage und den gelieferten Waren beliebig verfahren. Er kann die Zusage sogar mit anderen Verbrauchern teilen.

Die Beziehung zwischen Urheber und Verbraucher weist außerdem zwei Phasen auf, Erstellung und Erfüllung. Sämtliche dieser Aspekte werden in folgendem Diagramm dargestellt.

Wenn wir dem Diagrammfluss folgen, wird deutlich, weshalb Zusagen aufgrund der beiden Beziehungsphasen gut für eine asynchrone Bereitstellung geeignet sind. Das Wichtigste ist, dass der Verbraucher nach Erhalt der Anforderungsbestätigung (der Zusage) anderen Aufgaben nachgehen kann (asynchron), anstelle zu warten (synchron). Der Verbraucher kann so die Zeit, während der er auf die Erfüllung der Zusage wartet, für Anderes nutzen, z. B. zum Beantworten weiterer Anforderungen. Dies ist der eigentliche Zweck asynchroner APIs. Falls die Waren bereits verfügbar sind, kann die Zusage unmittelbar erfüllt werden, wodurch der gesamte Vorgang zu einer Art synchroner Aufrufkonvention wird.

Natürlich müssen im Zusammenhang mit dieser Beziehung noch einige weitere Aspekte berücksichtigt werden. Sie haben sicherlich im wirklichen Leben schon Zusagen getätigt und erhalten. Sicher wurden viele dieser Zusagen erfüllt, einige jedoch auch nicht eingehalten: Der Pizzalieferant kann auf dem Weg zu Ihnen durchaus in einen Unfall verwickelt werden! Nicht eingehaltene Zusagen sind unumgänglich und können weder im echten Leben noch bei der asynchronen Programmierung vermieden werden.

In Bezug auf die Zusagenbeziehung benötigt der Urheber daher eine Möglichkeit zur Mitteilung, dass er die Zusage nicht einhalten kann, und der Verbraucher muss darüber informiert werden können. Zudem werden Verbraucher möglicherweise auch ungeduldig, wenn Zusagen längere Zeit nicht erfüllt werden. Wenn der Urheber also den Fortschritt bis zur Erfüllung der Zusage nachverfolgen kann, ist auch eine entsprechende Methode zum Informieren des Verbrauchers erforderlich. Drittens ist es außerdem möglich, dass der Verbraucher den Auftrag abbricht und dem Urheber mitteilt, dass die Waren nicht mehr benötigt werden.

Wenn diese Anforderungen im Diagramm berücksichtigt werden, ergibt sich ein Bild der vollständigen Beziehung:

Betrachten wir nun, wie diese Beziehungen in Code umgesetzt werden.

Das Zusagenkonstrukt und Zusagenketten

Tatsächlich gibt es für Zusagen eine Reihe verschiedener Vorschläge oder Spezifikationen. In Windows und WinJS werden als Common JS/Promises A bezeichnete Zusagen verwendet, wobei eine Zusage (der Rückgabewert eines Urhebers, der einen zukünftig bereitzustellenden Wert repräsentiert) ein Objekt mit einer then genannten Funktion darstellt. Die Verbraucher abonnieren die Einhaltung der Zusage durch das Aufrufen von then. (Für Zusagen in Windows wird auch die ähnliche Funktion done unterstützt, die wie in Kürze erläutert in Zusagenketten verwendet wird.)

An diese Funktion werden vom Verbraucher in folgender Reihenfolge bis zu drei optionale Funktionen als Argumente übergeben:

1. Ein Completed-Handler. Diese Funktion wird vom Urheber aufgerufen, sobald der zugesagte Wert zur Verfügung steht. Ist dieser Wert bereits verfügbar, wird der Completed-Handler unmittelbar (synchron) innerhalb von then aufgerufen.
2. Ein optionaler Fehlerhandler, der aufgerufen wird, falls der zugesagte Wert nicht beschafft werden kann. Nach einem Aufruf des Fehlerhandlers wird für die entsprechende Zusage nie der Completed-Handler aufgerufen.
3. Ein optionaler Progress-Handler, der bei entsprechender Unterstützung durch den Vorgang regelmäßig für Zwischenergebnisse aufgerufen wird. (In WinRT bedeutet dies, dass die API den Rückgabewert IAsync[Action | Operation]WithProgress aufweist, im Gegensatz zu jenen mit IAsync[Action | Operation].)

Beachten Sie, dass für jedes dieser Argumente null übergeben werden kann, beispielsweise wenn Sie statt eines Completed-Handlers nur einen Fehlerhandler hinzufügen möchten.

Auf der anderen Seite der Beziehung können Verbraucher beliebig viele Handler für dieselbe Zusage abonnieren, indem sie mehrfach then aufrufen. Die Zusage kann auch mit anderen Verbrauchern geteilt werden, die ebenso häufig wie gewünscht then aufrufen können. Dies wird vollständig unterstützt.

Für Zusagen bedeutet dies, dass Listen aller empfangener Handler verwaltet werden müssen, um diese zum jeweils richtigen Zeitpunkt aufzurufen. Wie in der vollständigen Beziehung dargestellt, ist bei Zusagen außerdem eine Möglichkeit zum Abbrechen erforderlich.

Aus der Promises A-Spezifikation ergibt sich die zusätzliche Anforderung, dass die then-Methode selbst eine Zusage zurückgeben muss. Diese zweite Zusage gilt als erfüllt, sobald der an die erste promise.then-Methode übergebene Completed-Handler zurückgegeben wird. Der Rückgabewert wird hierbei als das Ergebnis der zweiten Zusage bereitgestellt. Gehen Sie diesen Codeausschnitt durch:

var promise1 = someOperationAsync();
var promise2 = promise1.then(function completedHandler1 (result1) { return 7103; } );
promise2.then(function completedHandler2 (result2) { });

Die Ausführungskette hierbei verläuft folgendermaßen: Zunächst wird someOperationAsync gestartet und gibt promise1 zurück. Während dieses Vorgangs wird die promise1.then-Methode aufgerufen, die unmittelbar promise2 zurückgibt. Berücksichtigen Sie stets, dass completedHandler1 erst aufgerufen wird, wenn das Ergebnis des asynchronen Vorgangs bereits verfügbar ist. Nehmen wir an, dass noch auf das Ergebnis gewartet wird. Daher gehen wir direkt zum Aufruf von promise2.then über, wobei zu diesem Zeitpunkt completedHandler2 auch hier nicht aufgerufen wird.

Etwas später wird someOperationAsync mit einem Wert von beispielsweise 14618 abgeschlossen. Da promise1 nun erfüllt ist, wird mit diesem Wert completedHandler1 aufgerufen, sodass result1 14618 beträgt. Jetzt wird completedHandler1 ausgeführt und gibt den Wert 7103 zurück. Zu diesem Zeitpunkt ist promise2 erfüllt, sodass completedHandler2 mit dem Wert result2 von 7103 aufgerufen wird.

Was jedoch geschieht, wenn ein Completed-Handler eine weitere Zusage zurückgibt? Dieser Fall wird etwas anders verarbeitet. Angenommen, der im obigen Code aufgeführte completedHandler1 gibt eine Zusage zurück, z. B. so:

var promise2 = promise1.then(function completedHandler1 (result1) {
    var promise2a = anotherOperationAsync();
    return promise2a;
});

In diesem Fall ist result2 in completedHandler2 nicht promise2a selbst, sondern der fulfillment-Wert von promise2a. Da der Completed-Handler eine Zusage zurückgegeben hat, hat dies zur Folge, dass promise2, wie von promise1.then zurückgegeben, mit den Ergebnissen aus promise2a erfüllt wird.

Genau dieses Merkmal ermöglicht die Verkettung sequenzieller asynchroner Vorgänge, wobei die Ergebnisse jedes Vorgangs in der Kette vom nachfolgenden Vorgang genutzt werden. Ohne Zwischenvariablen oder benannte Handler weisen Zusagenketten häufig dieses Muster auf:

operation1().then(function (result1) {
    return operation2(result1)
}).then(function (result2) {
    return operation3(result2);
}).then(function (result3) {
    return operation4(result3);
}).then(function (result4) {
    return operation5(result4)
}).then(function (result5) {
    //And so on
});

Wahrscheinlich werden die empfangenen Ergebnisse von den jeweiligen Completed-Handler noch weiter verarbeitet, alle Ketten verfügen jedoch über diese Kernstruktur. Ebenso trifft zu, dass hier sämtliche then-Methoden direkt nacheinander ausgeführt werden, da sie lediglich den entsprechenden Completed-Handler speichern und eine weitere Zusage zurückgeben. Am Codeende wurde also lediglich operation1 gestartet. Completed-Handler wurden nicht aufgerufen. Im Rahmen der zahlreichen then-Aufrufe wurde jedoch eine Reihe von Zwischenzusagen erstellt und untereinander verknüpft, um die Kette beim Fortsetzen der sequenziellen Vorgänge zu verwalten.

Bemerkenswerterweise kann die gleiche Sequenz durch das Schachteln aller nachfolgenden Vorgänge im vorherigen Completed-Handler erzielt werden, wobei die gesamten return-Anweisungen entfallen. Verschachtelungen dieser Art führen jedoch zu sehr komplizierten Einzugsszenarien, insbesondere, wenn Sie bei jedem then-Aufruf Progress- und Fehlerhandler hinzufügen.

Eine Funktion von Zusagen in WinJS ist außerdem, dass Fehler in einem beliebigen Kettenabschnitt automatisch an das Kettenende verteilt werden. Sie müssen also dem letzten then-Aufruf einfach nur einen einzigen Fehlerhandler hinzufügen, ohne Handler auf jeder Ebene zu verwenden. Der Haken ist jedoch, dass diese Fehler aus verschiedenen komplexen Gründen verloren gehen, wenn es sich beim letzten Kettenabschnitt um einen then-Aufruf handelt. Deshalb stellt WinJS für Zusagen außerdem eine done-Methode bereit. Diese Methode akzeptiert dieselben Argumente wie then, gibt jedoch an, dass die Kette abgeschlossen ist. (Anstelle einer weiteren Zusage wird undefined zurückgegeben.) Falls done ein Fehlerhandler hinzugefügt wurde, wird dieser für alle Fehler in der gesamten Kette aufgerufen. Weiterhin löst done eine Ausnahme auf App-Ebene aus, wenn kein Fehlerhandler verfügbar ist, die durch window.onerror von WinJS.Application.onerror-Ereignissen behandelt werden kann. Kurz gesagt: Im Idealfall sollten alle Ketten mit done enden, um sicherzustellen, dass Ausnahmen zum Vorschein kommen und ordnungsgemäß behandelt werden.

Wenn Sie natürlich eine Funktion schreiben, deren Zweck darin besteht, die letzte Zusage aus einer langen Kette von then-Aufrufen zurückzugeben, verwenden Sie am Ende weiterhin then. Für die Fehlerbehandlung ist dann die aufrufende Funktion zuständig, von der diese Zusage möglicherweise in einer vollkommen anderen Kette verwendet wird.

Erstellen von Zusagen: die WinJS.Promise-Klasse

Sie können zwar jederzeit auf Grundlage der Promises A-Spezifikation eigene Promise-Klassen erstellen, tatsächlich ist dies jedoch mit beträchtlichem Arbeitsaufwand verbunden, weshalb sich eine Bibliothek hierfür besser eignet. WinJS stellt daher die stabile, ausführlich getestete und flexible Promise-Klasse WinJS.Promise bereit. So können Sie mühelos Zusagen für verschiedene Werte und Vorgänge erstellen, ohne die Feinheiten der Urheber/Verbraucher-Beziehungen oder das Verhalten der then-Methode verwalten zu müssen.

Bei Bedarf können (und sollten) Sie die neue WinJS.Promise-Klasse (oder eine geeignete Hilfsfunktion, wie im nächsten Abschnitt erläutert) verwenden, um Zusagen sowohl für asynchrone Vorgänge als auch für bestehende (synchrone) Werte zu erstellen. Denken Sie daran, dass eine Zusage lediglich ein Codekonstrukt ist: Zusagen müssen weder einen asynchronen Vorgang noch beliebige andere asynchrone Elemente umschließen. Ebenso führt das einfache Umschließen eines Codeabschnitts mit einer Zusage nicht automatisch zur asynchronen Ausführung. Für dieses Verhalten müssen Sie weiterhin selbst sorgen.

Als einfaches Beispiel für eine direkte Verwendung von WinJS.Promise nehmen wir an, dass eine lange Berechnung ausgeführt werden soll (eine einfache Addition von Zahlen, beginnend bei 1 bis zu einem Maximalwert), jedoch als asynchroner Vorgang. Wir könnten einen eigenen Callbackmechanismus für eine derartige Routine entwickeln, wenn wir jedoch eine Zusage als Umschließung einsetzen, kann sie mit Zusagen anderer APIs verkettet oder verknüpft werden. (Auf ähnliche Weise umschließt die WinJS.xhr-Funktion das asynchrone XmlHttpRequest-JavaScript-Objekt mit einer Zusage, damit Sie sich nicht mit der besonderen Ereignisstruktur des Objekts befassen müssen.)

Für lange Berechnungen kann natürlich auch ein JavaScript-Worker verwendet werden, zur Veranschaulichung bleiben wir jedoch im UI-Thread und nutzen setImmediate, um den Vorgang in Schritte zu unterteilen. Gehen Sie folgendermaßen vor, um eine Zusagenstruktur mit WinJS.Promise zu implementieren:

function calculateIntegerSum(max, step) {
    //The WinJS.Promise constructor's argument is an initializer function that receives 
    //dispatchers for completed, error, and progress cases.
    return new WinJS.Promise(function (completeDispatch, errorDispatch, progressDispatch) {
        var sum = 0;

        function iterate(args) {
            for (var i = args.start; i < args.end; i++) {
                sum += i;
            };

            if (i >= max) {
                //Complete--dispatch results to completed handlers
                completeDispatch(sum);
            } else {
                //Dispatch intermediate results to progress handlers
                progressDispatch(sum);
                setImmediate(iterate, { start: args.end, end: Math.min(args.end + step, max) });
            }
        }
            
        setImmediate(iterate, { start: 0, end: Math.min(step, max) });
    });
}

Beim Aufrufen der neuen WinJS.Promise-Klasse erhält deren Konstruktor als einziges Argument eine Initialisiererfunktion (in diesem Fall anonym). Der Initialisierer kapselt den auszuführenden Vorgang. Beachten Sie jedoch stets, dass sich diese Funktion im UI-Thread synchron selbst ausführt. Falls wir also an dieser Stelle eine lange Berechnung ausführen, ohne setImmediate zu verwenden, wäre der UI-Thread während des ganzen Zeitraums blockiert. Auch in diesem Fall wird der Code durch das Umschließen mit einer Zusage nicht automatisch asynchron ausgeführt. Dies muss mithilfe der Initialisierungsfunktion festgelegt werden.

Als Argumente empfängt die Initialisiererfunktion drei Verteiler für die von Zusagen unterstützten Fälle Completed, Fehler und Progress. Wie Sie sehen, werden diese Verteiler während des Vorgangs zu geeigneten Zeitpunkten mit den richtigen Argumenten aufgerufen.

Ich bezeichne diese Funktionen als „Verteiler“, da sie sich von den Handlern unterscheiden, mit denen Verbraucher die then-Methode (bzw. done) der Zusage abonnieren. Hinter den Kulissen werden von WinJS Arrays dieser Handler verwaltet, weshalb eine beliebige Anzahl von Verbrauchern so viele Handler wie gewünscht abonnieren kann. Wenn Sie einen der Verteiler aufrufen, durchläuft WinJS die interne Liste und ruft sämtliche entsprechenden Handler für Sie auf. WinJS.Promise stellt außerdem sicher, dass von der then-Methode eine zum Verketten erforderliche weitere Zusage zurückgegeben wird.

Kurz gesagt: WinJS.Promise stellt alle erforderlichen Elemente im Zusammenhang mit Zusagen bereit. So können Sie sich auf den durch die Zusage dargestellten, von der Initialisiererfunktion gekapselten Kernvorgang konzentrieren.

Hilfsfunktionen zum Erstellen von Zusagen

Die statische WinJS.Promise.as-Methode stellt die primäre Hilfsfunktion zum Erstellen einer Zusage dar, da mit dieser Methode ein beliebiger Wert von einer Zusage umschlossen werden kann. Ein solcher Wrapper um einen bereits vorhandenen Wert wird einfach direkt in umgekehrter Richtung ausgeführt und ruft alle an then übergebenen Completed-Handler auf. Hierdurch können insbesondere beliebige bekannte Werte als Zusagen behandelt werden, um sie mit anderen Zusagen zu mischen oder zusammenzufassen (durch Verknüpfen und Verketten). Wenn Sie as auf eine bestehende Zusage anwenden, wird lediglich diese Zusage zurückgegeben.

Bei der anderen statischen Hilfsfunktion handelt es sich um WinJS.Promise.timeout, einen praktischen Wrapper für setTimeout und setImmediate. Außerdem können Sie eine Zusage erstellen, die eine zweite Zusage abbricht, falls letztere nicht innerhalb einer bestimmten Anzahl von Millisekunden erfüllt wird.

Berücksichtigen Sie, dass die timeout-Zusagen um setTimeout und setImmediate ebenfalls durch undefined erfüllt werden. Es stellt sich daher die Frage, wie nach dem Timeout von diesen Zusagen ein anderer Wert bereitgestellt werden kann. Dies ist aufgrund der Tatsache möglich, dass then eine weitere Zusage zurückgibt, die durch den Rückgabewert des Completed-Handlers erfüllt wird. Betrachten Sie beispielsweise diese Codezeile:

var p = WinJS.Promise.timeout(1000).then(function () { return 12345; });

Dieser Code erstellt die Zusage p, die nach einer Sekunde durch den Wert 12345 erfüllt wird. Anders ausgedrückt: WinJS.Promise.timeout(…).then(function () { return <value>} ) stellt ein Muster dar, um nach dem angegebenen Timeout <value> bereitzustellen. Wenn es sich zudem bei <value> um eine weitere Zusage handelt, dient das Muster zum Bereitstellen des Erfüllungswerts aus dieser Zusage an einem Zeitpunkt nach dem Timeout.

Abbrechen von Zusagen und Fehlergenerierung

Vielleicht sind Ihnen die beiden Schwachstellen im oben dargestellten Code aufgefallen. Erstens besteht keine Möglichkeit, den Vorgang abzubrechen, sobald er gestartet wurde. Der zweite Mangel ist die unzureichende Fehlerbehandlung.

In beiden Fällen liegt die Lösung darin, dass zusagengenerierende Funktionen wie calculateIntegerSum immer eine Zusage zurückgeben müssen. Wenn ein Vorgang nicht abgeschlossen oder nicht einmal gestartet werden kann, weist diese Zusage den sogenannten Fehlerzustand auf. Dies bedeutet, dass die Zusage weder jetzt noch irgendwann über ein Ergebnis verfügt, das an Completed-Handler übergeben werden kann – es werden stets ausschließlich die Fehlerhandler der Zusage aufgerufen. Tatsächlich wird, falls ein Verbraucher then für eine sich bereits im Fehlerzustand befindende Zusage aufruft, von der Zusage unmittelbar (synchron) der an then übergebene Fehlerhandler aufgerufen.

Ein WinJS.Promise-Objekt wechselt aus zwei Gründen in den Fehlerzustand: Entweder ruft der Verbraucher die cancel-Methode des Objekts auf, oder der Fehlerverteiler wird durch den Code innerhalb der Initialisierfunktion aufgerufen. In diesem Fall wird jeglicher Fehlerwert, der in der Zusage aufgefangen oder propagiert wurde, an die Fehlerhandler übergeben. Beim Erstellen eines Vorgangs innerhalb eines WinJS.Promise-Objekts können Sie auch eine Instanz von WinJS.ErrorFromName verwenden. Hierbei handelt es sich einfach um ein JavaScript-Objekt mit einer name-Eigenschaft, die den Fehler identifiziert, und einer message-Eigenschaft für weitere Informationen. Beispielsweise empfangen Fehlerhandler beim Abbrechen einer Zusage ein Fehlerobjekt, in dem sowohl name als auch message auf „Abgebrochen“ festgelegt sind.

Welche Möglichkeiten bestehen jedoch, wenn der Vorgang überhaupt nicht gestartet werden kann? Wenn Sie beispielsweise calculateIntegerSum mit falschen Argumenten (wie 0, 0) aufrufen, sollte die Funktion direkt eine Zusage im Fehlerzustand zurückgeben, anstatt mit der Zählung zu beginnen. Dies ist der Zweck der statischen WinJS.Promise.wrapError-Methode. Diese Methode akzeptiert eine WinJS.ErrorFromName-Instanz und gibt eine Zusage zurück, die in diesem Fall anstelle einer neuen WinJS.Promise-Instanz zurückgegeben würde.

Der zweite Aspekt, der in diesem Zusammenhang berücksichtigt werden muss, ist folgender: Zwar versetzt das Aufrufen der cancel-Methode einer Zusage diese in den Fehlerzustand, wie jedoch kann der asynchrone Vorgang beendet werden, der gerade ausgeführt wird? In der vorherigen Implementierung ruft die calculateIntegerSum-Funktion einfach solange setImmediate, bis der Vorgang abgeschlossen ist, unabhängig vom Zustand der erstellten Zusage. Tatsächlich wird, falls der Vorgang nach dem Abbrechen der Zusage den Abschlussverteiler aufruft, dieser Abschluss von der Zusage einfach ignoriert.

Die Zusage benötigt daher eine Möglichkeit zur Benachrichtigung des Vorgangs, dass die Verarbeitung beendet werden kann. Hierfür akzeptiert der WinJS.Promise-Konstruktor ein zweites Funktionsargument, das beim Abbruch der Zusage aufgerufen wird. In unserem Beispiel müsste das Aufrufen dieser Funktion den nächsten Aufruf von setImmediate verhindern und dadurch die Berechnung stoppen. Zusammen mit ordnungsgemäßer Fehlerbehandlung ergibt sich so der folgende Code:

function calculateIntegerSum(max, step) {
    //Return a promise in the error state for bad arguments
    if (max < 1 || step < 1) {
        var err = new WinJS.ErrorFromName("calculateIntegerSum", "max and step must be 1 or greater");
        return WinJS.Promise.wrapError(err);
    }

    var _cancel = false;

    //The WinJS.Promise constructor's argument is an initializer function that receives 
    //dispatchers for completed, error, and progress cases.
    return new WinJS.Promise(function (completeDispatch, errorDispatch, progressDispatch) {
        var sum = 0;

        function iterate(args) {
            for (var i = args.start; i < args.end; i++) {
                sum += i;
            };

            //If for some reason there was an error, create the error with WinJS.ErrorFromName
            //and pass to errorDispatch
            if (false /* replace with any necessary error check -- we don’t have any here */) {
                errorDispatch(new WinJS.ErrorFromName("calculateIntegerSum (scenario 7)", "error occurred"));
            }

            if (i >= max) {
                //Complete--dispatch results to completed handlers
                completeDispatch(sum); 
            } else {
                //Dispatch intermediate results to progress handlers
                progressDispatch(sum);

                //Interrupt the operation if canceled
                if (!_cancel) {
                    setImmediate(iterate, { start: args.end, end: Math.min(args.end + step, max) });
                }
            }
        }
            
        setImmediate(iterate, { start: 0, end: Math.min(step, max) });
    },
    //Cancellation function for the WinJS.Promise constructor
    function () {
        _cancel = true;
    });
}

Insgesamt gesehen bietet das Erstellen von WinJS.Promise-Instanzen vielfältige Anwendungsmöglichkeiten. Wenn z. B. eine Bibliothek über eine andere asychrone Methode mit einem Webdienst kommuniziert, können Sie diese Vorgänge mit Zusagen umschließen. Sie können auch mehrere asynchrone Vorgänge (oder andere Zusagen!) aus verschiedenen Quellen in einer neuen Zusage kombinieren, für den Fall, dass die Steuerung aller beteiligten Beziehungen erforderlich ist. Selbstverständlich können Sie eigene Handler für andere asynchrone Vorgänge und deren Zusagen in den Code eines Initialisierers des WinJS.Promise-Objekts einfügen. Sie können diese zum Kapseln automatischer Wiederholungsmechanismen bei Netzwerktimeouts o. Ä. verwenden, als Hook in eine generische Fortschrittsanzeige-Benutzeroberfläche einfügen oder für versteckte Protokollierung oder Analysen einsetzen. Bei jeder dieser Anwendungen benötigt der restlichen Code keine Informationen zu den Details und kann einfach nur Zusagen von der Verbraucherseite verarbeiten.

Auf ähnliche Weise kann ein JavaScript-Worker ohne großen Aufwand von einer Zusage umschlossen werden, wodurch dessen Darstellung und Verhalten anderen asynchronen WinRT-Vorgängen entspricht. Bekanntermaßen stellen Worker ihre Ergebnisse durch einen postMessage-Aufruf bereit, der im Worker-Objekt in der App ein message-Ereignis auslöst. Der folgende Code verknüpft dieses Ereignis anschließend mit einer Zusage, die unabhängig von den Ergebnissen der jeweiligen Meldung erfüllt ist:

// This is the function variable we're wiring up.
var workerCompleteDispatch = null;

var promiseJS = new WinJS.Promise(function (completeDispatch, errorDispatch, progressDispatch) {
    workerCompleteDispatch = completeDispatch;
});

// Worker is created here and stored in the 'worker' variable

// Listen for worker events
worker.onmessage = function (e) {
    if (workerCompleteDispatch != null) {
        workerCompleteDispatch(e.data.results); /* event args depends on the worker */
    }
}

promiseJS.done(function (result) {
    // Output for JS worker
});

Zum Erweitern dieses Codes zur Behandlung von Workerfehlern können Sie den Fehlerverteiler in einer anderen Variablen speichern, die Ereignisargumente des message-Ereignishandlers auf Fehlerinformationen überprüfen lassen und dann je nach Ergebnis den Fehlerverteiler anstelle des Abschlussverteilers aufrufen.

Verknüpfen paralleler Zusagen

Da Zusagen häufig zum Umschließen asynchroner Vorgänge verwendet werden, ist es durchaus möglich, dass mehrere Vorgänge parallel ausgeführt werden. In diesen Fällen muss ggf. ermittelt werden können, wann eine Zusage bzw. alle Zusagen in einer Gruppe erfüllt sind. Diesem Zweck dienen die statischen Funktionen WinJS.Promise.any und WinJS.Promise.join.

Beide Funktionen akzeptieren ein Wertearray oder ein Objekt mit Werteigenschaften. Bei diesen Werten kann es sich um Zusagen und beliebige andere, von WinJS.Promise.as umschlossene Werte handeln, sodass das ganze Array oder Objekt aus Zusagen besteht.

Merkmale von any:

• Durch any wird eine einzelne Zusage erstellt, die bei der Erfüllung oder beim Auftreten eines Fehlers in einer der anderen Zusagen erfüllt wird (ein logisches OR). Im Grunde fügt any all diesen Zusagen Completed-Handler hinzu. Sobald dann ein Completed-Handler aufgerufen wird, ruft dieser alle von der any-Zusage selbst empfangenen Completed-Handler auf.
• Nach Erfüllung der any-Zusage (d. h. bei Erfüllung der ersten Zusage auf der Liste) werden die anderen Vorgänge auf der Liste weiter ausgeführt und rufen jegliche Completed-, Fehler- oder Progress-Handler auf, die diesen Zusagen individuell zugeordnet sind.
• Wenn Sie die any-Zusage abbrechen, werden auch alle Zusagen auf der Liste abgebrochen.

Merkmale von join:

• Durch join wird eine einzelne Zusage erstellt, die bei der Erfüllung oder beim Auftreten eines Fehlers in allen anderen Zusagen erfüllt wird (ein logisches AND). Im Grunde fügt join all diesen Zusagen Completed- sowie Fehlerhandler hinzu und wartet dann auf den Aufruf sämtlicher dieser Handler. Erst dann ruft join alle selbst empfangenen Completed-Handler auf.
• Die join-Zusage meldet auch den Fortschritt an alle angegebenen Progress-Handler. In diesem Fall handelt es sich beim Zwischenergebnis um ein Array der Ergebnisse aller bislang erfüllten Zusagen.
• Wenn Sie die join-Zusage abbrechen, werden auch alle noch ausstehenden Zusagen abgebrochen.

Neben any und join sollen an dieser Stelle noch zwei weitere praktische, statische WinJS.Promise-Methoden erwähnt werden:

• is ermittelt, ob es sich bei einem beliebigen Wert um eine Zusage handelt, und gibt einen booleschen Wert zurück. Im Grunde stellt die Methode sicher, dass es sich um ein Objekt mit einer als „then“ bezeichneten Funktion handelt. Tests in Bezug auf „done“ erfolgen nicht.
• theneach wendet Completed-, Fehler- und Progress-Handler auf eine Gruppe von Zusagen an (mithilfe von then) und gibt die Ergebnisse als eine weitere Wertegruppe innerhalb einer Zusage zurück. Jeder der Handler kann NULL sein.

Parallele Zusagen mit sequenziellen Ergebnissen

Durch WinJS.Promise.join und WinJS.Promise.any können parallele Zusagen verwendet werden, also parallele asynchrone Vorgänge. Die von join zurückgegebene Zusage wird wie bereits erwähnt erfüllt, wenn alle Zusagen in einem Array erfüllt sind. Diese Zusagen werden jedoch wahrscheinlich in zufälliger Reihenfolge abgeschlossen. Was wäre, wenn Sie über eine Reihe von auf diese Weise ausführbaren Vorgängen verfügen, deren Ergebnisse jedoch in wohldefinierter Reihenfolge verarbeitet werden sollen, und zwar der Reihenfolge der jeweiligen Zusagen in einem Array?

Hierfür muss jede nachfolgende Zusage mit der join-Methode aller vorherigen Zusagen verknüpft werden. Der Codeausschnitt am Anfang dieses Beitrags bewirkt genau dies. Hier ist der gleiche Code, jedoch für explizite Zusagen umgeschrieben. (Stellen Sie sich vor, list sei ein Array beliebiger Werte, die als Argumente für einen hypothetischen, zusagengenerierenden asynchronen doOperationAsync-Aufruf dienen):

list.reduce(function callback (prev, item, i) {
    var opPromise = doOperationAsync(item);
    var join = WinJS.Promise.join({ prev: prev, result: opPromise});

    return join.then(function completed (v) {
        console.log(i + ", item: " + item+ ", " + v.result);
    });
})

Um ein Verständnis dieses Codes zu entwickeln, sollten wir uns zunächst mit der Funktionsweise der reduce-Methode des Arrays vertraut machen. reduce ruft für jedes Element im Array das hier als callback bezeichnete Funktionsargument auf, das vier Argumente empfängt (wovon im Code nur drei verwendet werden):

• prev – Der Wert, der vom vorherigen Aufruf von callback zurückgegeben wurde (NULL für das erste Element).
• item – Der aktuelle Wert aus dem Array.
• i – Der Index des Elements in der Liste.
• source – Das ursprüngliche Array.

Für das erste Element auf der Liste erhalten wir eine opPromise₁ genannte Zusage. Da prev den Wert NULL aufweist, verknüpfen wir [WinJS.Promise.as(null), opPromise₁]. Beachten Sie, das nicht join selbst zurückgegeben wird. Stattdessen fügen wir dieser Verknüpfung einen Completed-Handler (mit der Bezeichnung completed) hinzu und geben die Zusage von then zurück.

Denken Sie daran, dass die von then zurückgegebene Zusage bei Rückgabe des Completed-Handlers erfüllt wird. Deshalb gibt callback eine Zusage zurück, die erst erfüllt wird, wenn der completed-Handler die Ergebnisse von opPromise₁ verarbeitet hat. Wenn Sie zudem an das Ergebnis einer Verknüpfung zurückdenken, wird diese durch ein Objekt mit den Ergebnissen der Zusagen auf der ursprünglichen Liste erfüllt. Dies bedeutet, dass der Erfüllungswert v sowohl eine prev-Eigenschaft als auch eine result-Eigenschaft aufweist, wobei letztere das Ergebnis von opPromise₁ ist.

Beim nächsten list-Element wird von callback ein prev-Wert mit dem vorherigen join.then-Ergebnis empfangen. Anschließend erstellen wir eine neue Verknüpfung zwischen opPromise₁.then und opPromise₂. Das Ergebnis: Diese Verknüpfung wird erst abgeschlossen, wenn sowohl opPromise₂ erfüllt ist und der Completed-Handler für opPromise₁ zurückgegeben wird. Voila! Der completed₂-Handler, den wir nun dieser join-Methode hinzufügen, wird erst nach Rückgabe von completed₁ aufgerufen.

Die gleichen Abhängigkeiten bauen sich für jedes Listenelement weiter auf: Die von join.then für Element n zurückgegebene Zusage wird erst bei Rückgabe von completed_n erfüllt. Dies stellt sicher, dass die Completed-Handler in der gleichen Reihenfolge wie list aufgerufen werden.

Zusammenfassung

In diesem Beitrag haben wir erläutert, dass eine Zusage lediglich ein (wenn auch leistungsstarkes) Codekonstrukt oder eine Aufrufkonvention ist. Sie stellt die Beziehung zwischen einem Urheber dar, der zu einem beliebigen späteren Zeitpunkt Werte liefern muss, und einem Verbraucher, der über den Verfügbarkeitszeitpunkt dieser Werte informiert werden möchte. Hierbei sind Zusagen sehr gut zum Darstellen von Ergebnissen asynchroner Vorgänge geeignet und werden umfassend für in JavaScript geschriebene Windows Store-Apps verwendet. Die Spezifikation für Zusagen ermöglicht außerdem das sequenzielle Verketten asynchroner Vorgänge, in denen das Zwischenergebnis jedes Kettenglieds an das nächste übermittelt wird.

Die Windows-Bibliothek für JavaScript WinJS ermöglicht das stabile Implementieren von Zusagen, mit denen Sie beliebige Arten eigener Vorgänge umschließen können. Außerdem bietet sie Hilfsfunktionen für allgemeine Szenarien wie das Verknüpfen von Zusagen für parallele Vorgänge. Dank WinJS können auf diese Weise asynchrone Vorgänge sehr effizient und effektiv genutzt werden.

Kraig Brockschmidt
Programmmanager, Windows Ecosystem Team
Autor, Programming Windows 8 Apps in HTML, CSS, and JavaScript

Für viele Windows Store-Apps in JavaScript, die Collections verwenden, ist es entscheidend, dass sie mit dem WinJS ListView-Steuerelement gut zusammenarbeiten, um eine gute App-Leistung zu erreichen. Dies ist nicht verwunderlich: Wenn potenziell tausende von Elementen verwaltet und angezeigt werden müssen, fällt jede noch so kleine Optimierung für diese Vorgänge ins Gewicht. Am wichtigsten ist dabei, wie jedes dieser Elemente gerendert wird, d. h. wie und wann jedes Element im ListView-Steuerelement im DOM erstellt und in der App angezeigt wird. Insbesondere das Wann wird zum entscheidenden Faktor, wenn ein Benutzer schnell durch eine Liste schwenkt und erwartet, dass dies verzögerungsfrei geschieht.

Elementrendering wird in einer ListView entweder durch eine in HTML definierte deklarative Vorlage oder durch eine benutzerdefinierte JavaScript-Renderingfunktion ausgeführt, die für jedes Element in der Liste aufgerufen wird. Auch wenn die deklarative Vorlage am einfachsten ist, bietet sie nicht die Flexibilität für eine spezifische Steuerung des Prozesses. Mit einer Renderingfunktion können Sie andererseits das Rendering für jedes einzelne Element anpassen und eine Reihe von Optimierungen umsetzen, die unter HTML ListView optimizing performance sample dargestellt werden. Die Optimierungen sind Folgende:

• Ermöglichen einer asynchronen Bereitstellung der Elementdaten und eines gerenderten Elements, wie es von einfachen Renderingfunktionen unterstützt wird.
• Trennen der Elementformerstellung für das allgemeine ListView-Layout von den internen Elementen. Dies wird durch einen Platzhalterrenderer unterstützt.
• Wiederverwenden eines zuvor erstellten Elements (und dessen untergeordneten Elementen) durch Ersetzen der Daten mit einem Recycling-Platzhalterrenderer. Dadurch erübrigen sich die meisten Elementerstellungsschritte.
• Verzögern von anspruchsvollen Anzeigevorgängen wie Laden von Bildern oder Animationen, bis das Element tatsächlich angezeigt wird und die ListView nicht mehr schnell geschwenkt wird. Dies wird mit einem mehrstufigen Renderer erreicht.
• Zusammenfassen ähnlicher visueller Vorgänge durch einen mehrstufigen Batchverarbeitungsrenderer, um das erneute Rendern des DOM zu minimieren.

In diesem Beitrag werden all diese Schritte und deren Interaktion mit dem Elementrenderingprozess der ListView erläutert. Wie Sie sich vorstellen können, sind bei Optimierungen des Wann des Elementrenderings viele asynchrone Vorgänge involviert, d. h. viele Zusagen (Promises). Daher wird auch das Konzept der Zusagen verständlicher, das auf dem Beitrag All about promises in diesem Blog aufbaut.

Im Allgemeinen gilt für alle Renderer, dass die Kernzeit (ohne zurückgestellte Prozesse) zum Rendern von Elementen auf ein Minimum reduziert sein sollte. Da die effektive Leistung der ListView stark davon abhängt, wie gut die Aktualisierungsintervalle mit den Bildschirmaktualisierungsintervallen abgestimmt sind, können bei einem Elementrenderer ein paar Millisekunden zu viel die Gesamtrenderingzeit der ListView über das nächste Aktualisierungsintervall verzögern, was zu verlorenen Frames und stotternder Anzeige führt. Klarer ausgedrückt, bei Elementrenderern ist es wirklich entscheidend, den JavaScript-Code zu optimieren.

Einfache Renderer

Beginnen wir mit einem kurzen Überblick, wie eine Elementrenderingfunktion, hier als Renderer bezeichnet, aussieht. Ein Renderer ist eine Funktion, die der itemTemplate-Eigenschaft der ListView anstelle eines Vorlagennamens zugewiesen wird. Diese Funktion wird bei Bedarf für Elemente aufgerufen, die die ListView in den DOM aufnehmen soll. (Eine grundlegende Dokumentation für Renderer ist auf der Seite itemTemplate verfügbar, aber erst im Beispiel werden die Optimierungen ersichtlich.)

Vielleicht erwarten Sie, dass eine Elementrenderingfunktion einfach ein Element aus der Datenquelle der ListView erhält. Sie sollte dann die HTML-Elemente erstellen, die für ein bestimmtes Element erforderlich sind, und das Stammelement zurückgeben, das die ListView dem DOM hinzufügen kann. Dies geschieht tatsächlich, allerdings gibt es zwei zusätzliche Überlegungen. Erstens können die Elementdaten selbst asynchron geladen werden, daher ist es sinnvoll, die Elementerstellung an die Verfügbarkeit der Daten zu knüpfen. Zweitens kann der Prozess des Elementrenderings selbst andere asynchrone Vorgänge beinhalten, wie z. B. das Laden von Bildern von Remote-URIs oder das Lesen von Daten aus anderen Dateien, die in den Elementdaten angegeben sind. Die verschiedenen Stufen der hier gezeigten Optimierung ermöglichen genau diese asynchronen Prozesse zwischen der Abfrage der Elemente und der tatsächlichen Bereitstellung dieser Elemente.

Daher spielen Zusagen wieder eine Rolle. Die ListView übergibt dem Renderer die Elementdaten nämlich nicht einfach direkt, sie übergibt vielmehr eine Zusage für diese Daten. Und die Funktion gibt nur einer Zusage für das Stammelement des Elements zurück, nicht das Element selbst. Dadurch kann die ListView viele Elementrenderingzusagen zusammenfassen und (asynchron) warten, bis eine ganze Seite von Elementen gerendert wurde. Dies wird zur intelligenten Erstellung verschiedener Seiten auch durchgeführt: zuerst wird die Seite mit den angezeigten Elementen erstellt, dann die zwei nicht sichtbaren Seiten davor und dahinter, zu denen der Benutzer wahrscheinlich schwenken wird. Außerdem kann die ListView dank dieser zusammengefassten Zusagen das Rendern unfertiger Elemente einfach abbrechen, wenn der Benutzer wegschwenkt. Dadurch wird eine unnötige Elementerstellung vermieden.

So werden dieses Zusagen in der simpleRenderer-Funktion des Beispiels verwendet:

function simpleRenderer(itemPromise) {
    return itemPromise.then(function (item) {
        var element = document.createElement("div");
        element.className = "itemTempl";
        element.innerHTML = "<img src='" + item.data.thumbnail +
            "' alt='Databound image' /><div class='content'>" + item.data.title + "</div>";
        return element;
    });
}

In diesem Code wird zuerst ein Completed-Handler an itemPromise angehängt. Der Handler wird aufgerufen, wenn die Elementdaten verfügbar sind, und er erstellt daraufhin die tatsächlichen Elemente. Beachten Sie jedoch wieder, dass die Elemente nicht direkt zurückgegeben werden, es wird eine Zusage zurückgegeben, die für dieses Element erfüllt wird. Das heißt, der Rückgabewert von itemPromise.then() ist eine Zusage, die mit element erfüllt wird, wenn die ListView es benötigt.

Durch die Rückgabe einer Zusage können bei Bedarf andere asynchrone Prozesse abgearbeitet werden. In diesem Fall kann der Renderer diese vorläufigen Zusagen einfach aneinanderreihen und die Zusage vom letzten then in der Kette zurückgeben. Zum Beispiel:

function someRenderer(itemPromise) {
    return itemPromise.then(function (item) {
        return doSomeWorkAsync(item.data);
    }).then(function (results) {
        return doMoreWorkAsync(results1);
    }).then(function (results2) {
        var element = document.createElement("div");
        // use results2 to configure the element
        return element;
    });
}

Beachten Sie, dass am Ende der Kette nicht done verwendet wird, da die Zusage des letzten then-Aufrufs zurückgegeben wird. Die ListView behandelt alle eventuell auftretenden Fehler.

Platzhalterrenderer

In der nächsten Stufe der ListView-Optimierung wird ein Platzhalterrenderer verwendet, der die Elementerstellung in zwei Ebenen aufteilt. Dadurch kann die ListView nur die Elementteile abfragen, die zur Definition des allgemeinen Listenlayouts erforderlich sind, ohne gleichzeitig alle Elemente in jedem Element erstellen zu müssen. Im Ergebnis kann die ListView den Layoutdurchgang schnell ausführen und auf weitere Eingaben schnell reagieren. Die übrigen Bestandteile des Elements können dann später abgefragt werden.

Ein Platzhalterrenderer gibt anstelle einer Zusage ein Objekt mit zwei Eigenschaften zurück:

• element Das Element der höchsten Ebene in der Elementstruktur, mit dem die Größe und Form definiert werden kann und das nicht von den Elementdaten abhängig ist.
• renderComplete Eine Zusage, die erfüllt wird, wenn die restlichen Elementinhalte erstellt werden. Es wird die Zusage der Kette zurückgegeben, die mit itemPromise.then beginnt, wie zuvor beschrieben.

Die ListView kann ermitteln, ob der Renderer eine Zusage (einfacher Fall wie bisher) oder ein Objekt mit den Eigenschaften element und renderComplete (komplexere Fälle) zurückgibt. Der entsprechende Platzhalterrenderer (im Beispiel) für den vorherigen simpleRenderer sieht folgendermaßen aus:

function placeholderRenderer(itemPromise) {
    // create a basic template for the item that doesn't depend on the data
    var element = document.createElement("div");
    element.className = "itemTempl";
    element.innerHTML = "<div class='content'>...</div>";

    // return the element as the placeholder, and a callback to update it when data is available
    return {
        element: element,

        // specifies a promise that will be completed when rendering is complete
        // itemPromise will complete when the data is available
        renderComplete: itemPromise.then(function (item) {
            // mutate the element to include the data
            element.querySelector(".content").innerText = item.data.title;
            element.insertAdjacentHTML("afterBegin", "<img src='" +
                item.data.thumbnail + "' alt='Databound image' />");
        })
    };
}

Die element.innerHTML-Zuweisung könnte in renderComplete verschoben werden, da die itemTempl-Klasse in der Datei „css/scenario1.css“ des Beispiels die Breite und Höhe des Elements direkt angibt. Der Grund, warum sie in der element-Eigenschaft steht, ist, dass sie den Standardtext „…“ im Platzhalter enthält. Sie könnten genauso gut ein img-Element verwenden, das sich auf eine kleine Paketressource bezieht, die mit allen Elementen geteilt wird (und deshalb schnell gerendert wird).

Recycling-Platzhalterrenderer

Die nächste Optimierung, der Recycling-Platzhalterrenderer, fügt Zusagen nichts Neues hinzu. Er macht den Renderer vielmehr auf einen zweiten Parameter mit dem Namen recycled aufmerksam, der das Stammelement eines zuvor gerenderten aber nicht mehr angezeigten Elements darstellt. Das bedeutet, dass für das recycelte Element bereits untergeordnete Elemente zur Verfügung stehen. Sie können dann einfach die Daten ersetzen und evtl. Änderungen an diesen Elementen vornehmen. Dadurch werden leistungsintensive Aufrufe zur Elementerstellung vermieden, die für neue Elemente erforderlich wären, und es wird für den Renderingprozess ziemlich viel Zeit gespart.

Die ListView kann eine recyceltes Element bereitstellen, wenn ihr loadingBehavior auf „randomaccess“ festgelegt wird. Wenn recycled angegeben ist, können Sie die Daten einfach aus dem Element (und dessen untergeordneten Elementen) löschen, das Element als Platzhalter zurückgeben und dann Daten einfügen und ggf. weitere zusätzliche untergeordnete Elemente in renderComplete erstellen. Wenn ein Recycled-Element nicht vorhanden ist (z. B. bei der ersten Erstellung der ListView oder wenn das loadingBehavior „inkrementell“ ist), müssen Sie das Element neu erstellen. Hier ist der Code aus dem Beispiel für diese Variante:

function recyclingPlaceholderRenderer(itemPromise, recycled) {
    var element, img, label;
    if (!recycled) {
        // create a basic template for the item that doesn't depend on the data
        element = document.createElement("div");
        element.className = "itemTempl";
        element.innerHTML = "<img alt='Databound image' style='visibility:hidden;'/>" +
            "<div class='content'>...</div>";
    }
    else {
        // clean up the recycled element so that we can reuse it 
        element = recycled;
        label = element.querySelector(".content");
        label.innerHTML = "...";
        img = element.querySelector("img");
        img.style.visibility = "hidden";
    }
    return {
        element: element,
        renderComplete: itemPromise.then(function (item) {
            // mutate the element to include the data
            if (!label) {
                label = element.querySelector(".content");
                img = element.querySelector("img");
            }
            label.innerText = item.data.title;
            img.src = item.data.thumbnail;
            img.style.visibility = "visible";
        })
    };
}

Überprüfen Sie renderComplete auf das Vorhandensein von Elementen, die Sie nicht für einen neuen Platzhalter erstellen, wie z. B. label, und erstellen Sie diese ggf. hier.

Wenn Sie recycelte Elemente allgemeiner leeren möchten, können Sie der resetItem-Eigenschaft der ListView eine Funktion bereitstellen. Diese Funktion enthält einen ähnlichen Code wie den oben gezeigten. Dasselbe gilt für die resetGroupHeader-Eigenschaft, da die Vorlagenfunktionen für Gruppenkopfzeilen genauso verwenden können wie für Elemente. Gruppenkopfzeilen haben wir bisher nicht thematisiert, da sie viel seltener sind und nicht die gleichen Leistungsanforderungen haben. Nichtsdestotrotz haben sie diese Funktion.

Mehrstufige Renderer

Die vorletzte Optimierung ist der mehrstufige Renderer. Er erweitert den Recycling-Platzhalterrenderer insoweit, dass Bilder und andere Medien so lange verzögert werden, bis der Rest des Elements vollständig im DOM repräsentiert ist. Er verzögert auch Effekte wie Animationen so lange, bis das Element tatsächlich auf dem Bildschirm angezeigt wird. Dies berücksichtigt, dass Benutzer oft ziemlich schnell in einer ListView hin- und herschwenken. Und daher ist es sinnvoll, die leistungsintensiven Prozesse asynchron zu verzögern, bis die ListView in eine ruhige Position kommt.

Die ListView bietet die erforderlichen Hooks als Mitglied des item-Ergebnisses aus itemPromise: eine Eigenschaft namens ready (eine Zusage) sowie die zwei Methoden loadImage und isOnScreen, die beide weitere Zusagen zurückgeben. Das heißt:

renderComplete: itemPromise.then(function (item) {
    // item.ready, item.loadImage, and item.isOnScreen available
})

So werden sie verwendet

• ready gibt diese Zusage aus dem ersten Completed-Handler in Ihre Kette zurück. Diese Zusage wird erfüllt, wenn die vollständige Struktur des Elements gerendert wurde und angezeigt wird. Das bedeutet, dass Sie ein weiteres then mit einem Completed-Handler anhängen können, in dem Sie nach der Anzeige andere Prozesse, wie das Laden von Bildern, verarbeiten können.
• loadImage lädt ein Bild von einem URI herunter und zeigt es im vorhandenen img-Element an, wobei eine Zusage zurückgegeben wird, die mit demselben Element erfüllt wird. Sie können einen Completed-Handler an diese Zusage anhängen, die selbst wiederum die Zusage von isOnScreen zurückgibt. Beachten Sie, dass loadImage ein img-Element erstellt, wenn keines vorhanden ist, und dieses dem Completed-Handler bereitstellt.
• isOnScreen gibt eine Zusage zurück, deren Erfüllungswert ein boolescher Wert ist und angibt, ob das Element sichtbar ist. Bei aktuellen Implementierungen ist dieser Wert bekannt, sodass die Zusage synchron erfüllt wird. Durch Einschließen in eine Zusage kann er jedoch in einer längeren Kette verwendet werden.

All dies wird in der multistageRenderer-Funktion des Beispiels veranschaulicht, in der der Abschluss des Ladens eines Bilds zum Starten einer Einblendanimation verwendet wird. Hier wird gezeigt, was von der renderComplete-Zusage zurückgegeben wird:

renderComplete: itemPromise.then(function (item) {
    // mutate the element to update only the title
    if (!label) { label = element.querySelector(".content"); }
    label.innerText = item.data.title;

    // use the item.ready promise to delay the more expensive work
    return item.ready;
    // use the ability to chain promises, to enable work to be cancelled
}).then(function (item) {
    // use the image loader to queue the loading of the image
    if (!img) { img = element.querySelector("img"); }
    return item.loadImage(item.data.thumbnail, img).then(function () {
        // once loaded check if the item is visible
        return item.isOnScreen();
    });
}).then(function (onscreen) {
    if (!onscreen) {
        // if the item is not visible, don't animate its opacity
        img.style.opacity = 1;
    } else {
        // if the item is visible, animate the opacity of the image
        WinJS.UI.Animation.fadeIn(img);
    }
})

Auch wenn sich hier viel abspielt, ist dies lediglich eine einfache Zusagekette. Der erste asynchrone Vorgang im Renderer aktualisiert einfache Teile der Elementstruktur, wie z. B. Text. Dann gibt er die Zusage in item.ready zurück. Wenn diese Zusage erfüllt ist, wird die asynchrone loadImage-Methode des Elements verwendet, um einen Bilddownload zu starten, und die item.isOnScreen-Zusage von diesem Completed-Handler wird zurückgegeben. Das heißt, dass das onscreen-Sichtbarkeitsflag an den letzten Completed-Handler in der Kette übergeben wird. Wenn diese isOnScreen-Zusage erfüllt ist (das Element wird angezeigt), können wichtige Vorgänge wie Animationen ausgeführt werden.

Das Wenn ist hier entscheidend, da es wiederum wahrscheinlich ist, dass der Benutzer in der ListView herumschwenkt, während all dies geschieht. Wenn all diese Zusagen aneinandergekettet sind, kann die ListView wie gesagt die asynchronen Vorgänge abbrechen, sobald dieses Elemente aus der Ansicht und/oder gepufferten Seiten weggeschwenkt werden. Es genügt der Hinweis, dass das ListView-Steuerelement vielen Leistungstests unterzogen wurde!

Sie sollten auch daran denken, dass das then in all diesen Ketten verwendet wird, da immer noch eine Zusage aus der Renderingfunktion in der renderComplete-Eigenschaft zurückgegeben wird. In diesen Renderern gibt es kein Ende der Kette, daher wird am Ende niemals ein done verwendet.

Miniaturansicht-Batchverarbeitung

Die letzte Optimierung ist wahrhaft das Husarenstück für das ListView-Steuerelement. In der Funktion namens batchRenderer befindet sich diese Struktur für renderComplete (der meiste Code wurde weggelassen):

renderComplete: itemPromise.then(function (item) {
    // mutate the element to update only the title
    if (!label) { label = element.querySelector(".content"); }
    label.innerText = item.data.title;

    // use the item.ready promise to delay the more expensive work
    return item.ready;
    // use the ability to chain promises, to enable work to be cancelled
}).then(function (item) {
    // use the image loader to queue the loading of the image
    if (!img) { img = element.querySelector("img"); }
    return item.loadImage(item.data.thumbnail, img).then(function () {
        // once loaded check if the item is visible
        return item.isOnScreen();
    });
}).then(function (onscreen) {
    if (!onscreen) {
        // if the item is not visible, don't animate its opacity
        img.style.opacity = 1;
    } else {
        // if the item is visible, animate the opacity of the image
        WinJS.UI.Animation.fadeIn(img);
    }
})

Es ist fast dasselbe wie der multistageRenderer, nur dass dieser mysteriöse Aufruf der Funktion thumbnailBatch zwischen dem item.loadImage-Aufruf und der item.isOnScreen-Überprüfung eingefügt wurde. Das Einfügen von thumbnailBatch in der Kette gibt an, dass ihr Rückgabewert ein Completed-Handler sein muss, der wiederum eine andere Zusage zurückgibt.

Sind Sie verwirrt? Eine Erklärung folgt sogleich, zunächst aber müssen wir die Hintergründe dafür klären, was eigentlich erreicht werden soll.

Wenn nur eine ListView mit einem einzigen Element vorhanden wäre, wären die verschiedenen Ladeoptimierungen nicht bemerkbar. In ListViews befinden sich jedoch normalerweise viele Elemente, und die Renderingfunktion wird für jedes dieser Elemente aufgerufen. Im multistageRenderer des vorherigen Abschnitts startet das Rendern jedes Elements einen asynchronen item.loadImage-Vorgang, um die entsprechende Miniaturansicht von einem beliebigen URI herunterzuladen, und jeder Vorgang kann eine beliebige Zeit lang dauern. Für die gesamte Liste gibt es also eine Reihe von gleichzeitigen loadImage-Aufrufen, und das Rendern jedes Elements wartet auf die Vervollständigung der entsprechenden Miniaturansicht. So weit, so gut.

Eine wichtige Eigenschaft, die im multistageRenderer überhaupt nicht sichtbar ist, ist jedoch, dass sich das img-Element für die Miniaturansicht bereits im DOM befindet, und die loadImage-Funktion legt das src-Attribut des Bilds fest, sobald der Download abgeschlossen ist. Dies wiederum löst eine Aktualisierung im Renderingmodul aus, sobald wir von der übrigen Zusagekette zurückkehren, die danach im Wesentlichen synchron abläuft.

Es ist dann möglich, dass eine Reihe von Miniaturansichten in kurzer Zeit in den UI-Thread zurückkommen. Dies wird dann eine übermäßige Beanspruchung im Renderingmodul und somit eine schlechte visuelle Leistung verursachen. Um diese Überlastung zu vermeiden, sollten diese img-Elemente vollständig erstellt werden, bevor sie sich im DOM befinden, und dann sollten sie Batches hinzugefügt werden, damit sie in einem einzigen Renderingdurchlauf verarbeitet werden können.

Im Beispiel wird dies durch einen raffinierten Zusagecodeabschnitt, nämlich mit der Funktion createBatch erreicht. createBatch wird für die gesamte App nur einmal aufgerufen, und das Ergebnis, eine andere Funktion, wird in der Variable thumbnailBatch gespeichert:

var thumbnailBatch;
thumbnailBatch = createBatch();

Ein Aufruf dieser thumbnailBatch-Funktion wird in die Zusagekette des Renderers eingefügt. Der Zweck dieser Einfügung ist, wie es der Batchverarbeitungscode im Folgenden zeigen wird, einen Satz von geladenen img-Elementen zu gruppieren und diese Gruppen dann in geeigneten Intervallen zur weiteren Verarbeitung freizugeben. In der Zusagekette des Renderers muss ein Aufruf von thumbnailBatch() eine Completed-Handler-Funktion zurückgeben, die wiederum eine Zusage zurückgibt, und der Erfüllungswert dieser Zusage (im nächsten Schritt der Kette) muss ein img-Element sein, das dann dem DOM hinzugefügt werden kann. Durch das Hinzufügen der Bilder zum DOM nach der Batchverarbeitung wird die gesamte Gruppe im selben Renderingdurchlauf zusammengefasst.

Dies ist ein wichtiger Unterschied zwischen dem batchRenderer und dem multistageRenderer des vorherigen Abschnitts: Bei letzterem ist das img-Element der Miniaturansicht bereits im DOM vorhanden, und es wird als zweiter Parameter an loadImage übergeben. Wenn also loadImage das src-Attribut des Bilds festlegt, wird eine Renderingaktualisierung ausgelöst. Im batchRenderer wird jedoch dieses img-Element separat in loadImage (wo auch src festgelegt wird) erstellt, das img ist jedoch noch nicht im DOM. Es wird erst nach dem Abschluss des thumbnailBatch-Schritts dem DOM hinzugefügt und so zum Mitglied einer Gruppe eines einzigen Layoutdurchlaufs.

Wie funktioniert also die Batchverarbeitung? Im Folgenden ist die vollständige createBatch-Funktion dargestellt:

function createBatch(waitPeriod) {
    var batchTimeout = WinJS.Promise.as();
    var batchedItems = [];

    function completeBatch() {
        var callbacks = batchedItems;
        batchedItems = [];
        for (var i = 0; i < callbacks.length; i++) {
            callbacks[i]();
        }
    }

    return function () {
        batchTimeout.cancel();
        batchTimeout = WinJS.Promise.timeout(waitPeriod || 64).then(completeBatch);

        var delayedPromise = new WinJS.Promise(function (c) {
            batchedItems.push(c);
        });

        return function (v) {
            return delayedPromise.then(function () {
                return v;
            });
        };
    };
}

createBatch wird wie gesagt nur einmal aufgerufen, und dessen thumbnailBatch-Ergebnis wird für jedes gerenderte Element in der Liste aufgerufen. Der Completed-Handler, der von thumbnailBatch erzeugt wird, wird immer dann aufgerufen, wenn ein loadImage-Vorgang abgeschlossen wird.

Dieser Completed-Handler könnte genauso gut direkt in die Renderingfunktion eingefügt werden, es soll jedoch hier versucht werden, die Aktionen über mehrere Elemente hinweg und nicht nur für ein einzelnes Element zu koordinieren. Diese Koordination wird mithilfe der zwei Variablen erreicht, die zu Beginn von createBatch erstellt werden: batchedTimeout wird als leere Zusage initialisiert, und batchedItems wird als Array von Funktionen initialisiert, der zunächst leer ist. createBatch deklariert die Funktion completeBatch, die einfach batchedItems leert, indem sie jede Funktion im Array aufruft:

function createBatch(waitPeriod) {
    var batchTimeout = WinJS.Promise.as();
    var batchedItems = [];

    function completeBatch() {
        var callbacks = batchedItems;
        batchedItems = [];
        for (var i = 0; i < callbacks.length; i++) {
            callbacks[i]();
        }
    }

    return function () {
        batchTimeout.cancel();
        batchTimeout = WinJS.Promise.timeout(waitPeriod || 64).then(completeBatch);

        var delayedPromise = new WinJS.Promise(function (c) {
            batchedItems.push(c);
        });

        return function (v) {
            return delayedPromise.then(function () {
                return v;
            });
        };
    };
}

Folgendes passiert nun in thumbnailBatch (die von createBatch zurückgegebene Funktion), die wieder für jedes zu renderndes Element aufgerufen wird. Zuerst werden alle vorhandenen batchedTimeout abgebrochen und gleich wieder neu erstellt:

batchTimeout.cancel();
        batchTimeout = WinJS.Promise.timeout(waitPeriod || 64).then(completeBatch);

In der zweiten Zeile steht das zukünftige Bereitstellungs-/Erfüllungsmuster, das im Beitrag „All About Promises“ <TODO: link>beschrieben ist: completeBatch muss nach einer Verzögerung von waitPeriod Millisekunden (Standardwert 64 ms) aufgerufen werden. Das heißt, dass so lange wie thumbnailBatch innerhalb der waitPeriod eines vorhergehenden Aufrufs wieder aufgerufen wird, batchTimeout auf eine andere waitPeriod zurückgesetzt wird. Und da thumbnailBatch nur nach dem Abschluss eines item.loadImage-Aufrufs aufgerufen wird, bedeutet dies im Ergebnis, dass alle loadImage-Vorgänge, die innerhalb der waitPeriod des vorhergehenden Aufrufs abgeschlossen werden, in denselben Batchvorgang aufgenommen werden. Wenn eine Pause länger als waitPeriod eintritt, wird die Batchverarbeitung gestartet, d. h. die Bilder werden dem DOM hinzugefügt, und der nächste Batchvorgang beginnt.

Nach Verarbeitung dieses Timeoutcodes erstellt thumbnailBatch eine neue Zusage, die einfach die Abschlussverteilerfunktion in den batchedItems-Array übergibt:

var delayedPromise = new WinJS.Promise(function (c) {
         batchedItems.push(c);
     });

Sie erinnern sich an den Beitrag „All About Promises“<TODO: link>, in dem erläutert wird, dass eine Zusage lediglich ein Codekonstrukt ist, und so ist es hier auch. Die neu erstellte Zusage zeigt keinerlei asynchrones Verhalten: Es wird lediglich die Abschlussverteilerfunktion c zu batchedItems hinzugefügt. Da aber der Verteiler nichts macht, bis batchedTimeout asynchron abgeschlossen ist, besteht de facto eine asynchrone Beziehung. Wenn das Timeout eintritt und der Batch (in completeBatch) geleert wird, werden alle anderen vorhandenen Completed-Handler für delayedPromise.then aufgerufen.

Die letzten Zeilen des Codes in createBatch stellen die Funktion dar, die von thumbnailBatch zurückgegeben wird. Diese Funktion ist genau der Completed-Handler, der in die gesamte Zusagekette des Renderers eingefügt wird:

return function (v) {
           return delayedPromise.then(function () {
               return v;
           });
       };

Wenn dieser Codeabschnitt direkt in die Zusagekette eingefügt wird, sehen Sie die daraus resultierenden Beziehungen:

return item.loadImage(item.data.thumbnail);
          }).then(function (v) {
              return delayedPromise.then(function () {
                  return v;
              });
          ).then(function (newimg) {

Jetzt sehen Sie, dass das Argument v das Ergebnis von item.loadImage ist, das wiederum das erstellte img-Element ist. Wenn auf die Batchverarbeitung verzichtet wird, könnte einfach return WinJS.Promise.as(v) angegeben werden, und die gesamte Kette würde trotzdem funktionieren: v würde dann synchron übergeben und im nächsten Schritt als newimg erscheinen.

Wir übergeben jedoch eine Zusage von delayedPromise.then, die mit v so lange nicht erfüllt wird, bis das aktuelle batchedTimeout erfüllt ist. Wenn dann wieder eine Pause von waitPeriod zwischen loadImage-Vorgängen eintritt, werden diese img-Elemente dem nächsten Schritt in der Kette übergeben, in dem sie dem DOM hinzugefügt werden.

Das war's!

Zusammenfassung

Die fünf verschiedenen Renderingfunktionen in HTML ListView optimizing performance sample haben alle eines gemeinsam: Sie zeigen, wie die asynchrone Beziehung zwischen der ListView und dem Renderer, die durch Zusagen ausgedrückt wird, dem Renderer eine immense Flexibilität dafür verleiht, wie und wann Elemente für Listenelemente erstellt werden. Beim Schreiben Ihrer eigenen Apps hängt die Strategie für ListView-Optimierungen stark davon ab, wie groß die Datenquelle, wie komplex die Elemente selbst und wie groß die Menge der asynchron abgerufenen Daten für diese Elemente ist (z. B. Herunterladen von remoten Bildern). Natürlich werden Sie Elementrenderer so einfach wie möglich konstruieren, um Ihre Leistungsziele zu erreichen. Aber jetzt haben Sie alle erforderlichen Tools an der Hand, um der ListView und Ihrer App zur Höchstleistung zu verhelfen.

Kraig Brockschmidt
Programmmanager, Windows Ecosystem Team
Autor, Programming Windows 8 Apps in HTML, CSS, and JavaScript

Spiele sind besonders wichtige Apps im Windows Store. Wir unterstützen Sie mit dem Virtual Game Building Event bei der Entwicklung von Windows Store-Spielen. Dieses Event ist kostenlos und steht sowohl neuen als auch erfahrenen Spieleentwicklern offen.

Wir zeigen Ihnen anhand von GameMaker: Studio von YoYo Games wie Sie hochwertige Spiele schneller entwickeln und veröffentlichen. GameMaker: Studio verfügt über zahlreiche integrierte Entwicklungsfunktionen und Drag & Drop-Tools, die den Einstieg erleichtern, wenn Sie über noch keine Idee für ein Spiel oder Entwicklungserfahrung verfügen. Und erfahrene Spieleentwickler können mit den erweiterten Tools einzigartige Spiele erstellen.

Die Onlineveranstaltung beginnt am Samstag, den 15. Juni um 10:00 Uhr PDT mit einer Einführung und einem Live-Chat. Sie lernen verschiedene Spieltypen kennen, erfahren, wie Grafiken, Level und Sounds in einfache Spiele eingefügt werden, und machen sich mit Möglichkeiten zum individuellen Anpassen des Spiels vertraut. Im Laufe der Woche erhalten Sie in den GameMaker-Foren weitere persönliche Unterstützung.

Ob Ersteinsteiger, Anfänger oder erfahrener Profi: Dieses Event ist der perfekte Einstieg in die Bereiche Erstellen, Hochladen und Veröffentlichen von Windows Store-Spielen. Unter http://msdnevents.com/gameon/ können Sie sich registrieren und erhalten weitere Informationen sowie kostenlose Tools und Ressourcen.

– Robert Rodriguez-Lawson, Senior Content Publishing Manager, Windows Developer Content

Wenn Sie bisher noch nichts vom Schließfach für Anmeldeinformationen, das für Windows Store-Apps verfügbar ist, mitbekommen haben, dann wird es jetzt langsam Zeit. Warum? Das Schließfach vereinfacht nicht nur die Aufgabe des Speicherns und Abrufens der Anmeldeinformationen, sondern es bietet dabei zusätzlich Sicherheit, und die Anmeldeinformationen sind per Microsoft-Konto überall kostenlos verfügbar.

Angenommen, Sie haben eine App, die sich mit einem Dienst zum Zugriff auf geschützte Ressourcen verbindet, wie z. B. Mediendateien, soziale Netzwerke usw., und Ihr Dienst benötigt für jeden Benutzer Anmeldeinformationen. Sie haben also eine Benutzeroberfläche in Ihre App integriert, mit der Benutzername und Kennwort eines Benutzers abgerufen werden. Diese Informationen werden dann zur Anmeldung des Benutzers beim Dienst verwendet. Alles funktioniert wie geschmiert.

Sie möchten jetzt jedoch Ihren Funktionsumfang erweitern und es den Benutzern möglich machen, ihre Anmeldeinformationen sicher zu speichern, sodass diese sich nicht bei jedem Öffnen Ihrer App wieder anmelden müssen. Hier kommt das Schließfach für Anmeldeinformationen ins Spiel. Mit nur wenigen einfachen Aufrufen der zugehörigen API lassen sich Benutzername und Kennwort der Benutzer speichern und problemlos wieder abrufen, sodass der Benutzer beim nächsten Öffnen Ihrer App wieder angemeldet wird.

Sicheres Speichern

Der größte Vorteil des Schließfachs für Anmeldeinformationen für Ihre App liegt darin, dass die Anmeldeinformationen an einem sichern Ort gespeichert und bei der Speicherung auf einem Datenträger verschlüsselt werden. Sie könnten die Benutzerinformationen natürlich in einer Datei im lokalen Speicher Ihrer App speichern, das Speichern der Anmeldeinformationen in reiner Textform stellt jedoch ein erhebliches Sicherheitsrisiko dar. Wenn das System eines Benutzers auf irgendeine Art und Weise beeinträchtigt wurde, können Benutzername und Kennwort problemlos ausgelesen und manipuliert werden. Wenn Benutzername und Kennwort jedoch im Schließfach für Anmeldeinformationen gespeichert sind, erhält ein böswilliger Angreifer im Höchstfall nur eine verschlüsselte Datei.

Jeder Windows-PC-Benutzer hat sein eigenes Schließfach für Anmeldeinformationen und der Zugriff auf einen Satz von Anmeldedaten ist auf die App beschränkt, die den Anmeldedatensatz gespeichert hat. Das heißt, dass Sie nur Anmeldedaten abrufen können, die für Ihre App gespeichert wurden. Dies bedeutet andererseits auch, dass andere Apps nicht auf die Anmeldedaten zugreifen können, die für Ihre App im Schließfach gespeichert wurden.

Roaming der Anmeldeinformationen

Ein weiterer Vorteil beim Speichern von Benutzername und Kennwort mithilfe des Schließfachs für Anmeldeinformationen besteht für die Benutzer darin, dass die Anmeldedaten über das Microsoft-Konto auf jeden gewünschten sicheren Computer übertragen werden, den die Benutzer mit dem entsprechenden Microsoft-Konto verwenden. Dies macht Ihre App, neben der erhöhten Sicherheit, noch benutzerfreundlicher, da die Benutzer auf jedem vertrauenswürdigen Computer, auf dem Ihre App installiert wurde, mittels Verknüpfung des Microsoft-Kontos automatisch angemeldet werden können, ohne erneut zur Eingabe der Anmeldeinformationen aufgefordert zu werden.

Bei Domänenkonten sieht das jedoch ein wenig anders aus. Wenn mittels Microsoft-Konto gespeicherte Anmeldedaten vorhanden sind und dieses Konto mit einem Domänenkonto verknüpft wird (wie beispielsweise einem Konto am Arbeitsplatz), werden die Anmeldedaten auf dieses Domänenkonto übertragen. Neu Anmeldedaten, die während einer Domänenkontositzung hinzugefügt wurden, werden jedoch nicht übertragen. Dadurch wird sichergestellt, dass private Anmeldedaten für die Domäne nicht außerhalb der Domäne veröffentlicht werden.

Speichern von Benutzeranmeldeinformationen

Das Speichern der Benutzeranmeldeinformationen im Schließfach für Anmeldeinformationen ist ein einfaches Verfahren in zwei Schritten. Zunächst wird ein Verweis auf das Schließfach für Anmeldeinformationen mithilfe des PasswordVault-Objekts aus dem Windows.Security.Credentials-Namespace abgerufen. Anschließend erstellen Sie ein PasswordCredential-Objekt, das einen Bezeichner für Ihre App, den Benutzernamen und das Kennwort enthält. Dieses Objekt wird an die PasswordVault.Add()-Methode übergeben, um den Anmeldedatensatz an das Schließfach zu übergeben.

C#

var vault = new Windows.Security.Credentials.PasswordVault();
vault.Add(new Windows.Security.Credentials.PasswordCredential(
    "My App", username, password));

JavaScript

var vault = new Windows.Security.Credentials.PasswordVault();
vault.add(new Windows.Security.Credentials.PasswordCredential(
    "My App", username, password));

Abrufen von Benutzeranmeldeinformationen

Es gibt verschiedene Wege, Benutzerinformationen aus dem Schließfach für Anmeldeinformationen abzurufen, nachdem Sie einen Verweis auf das PasswordVault-Objekt erstellt haben.

• Sie können alle Informationen, die der Benutzer im Schließfach für Ihre App angegeben hat, mit der PasswordVault.RetrieveAll()-Methode abrufen.
• Wenn Sie den Benutzernamen der gespeicherten Anmeldeinformationen kennen, können Sie alle Anmeldedaten für diesen Benutzernamen mit der PasswordVault.FindAllByUserName()-Methode abrufen.
• Wenn Sie den Ressourcennamen für die gespeicherten Anmeldeinformationen kennen, können Sie alle Anmeldeinformationen für diesen Ressourcennamen mit der PasswordVault.FindAllByResource()-Methode abrufen.
• Als letzte Möglichkeit können Sie bei bekanntem Benutzer- sowie Ressourcennamen eines Anmeldedatensatzes ausschließlich die Anmeldeinformationen mit der PasswordVault.Retrieve()-Methode abrufen.

Sehen wir uns nun ein Beispiel an, bei dem der Ressourcenname global in einer App gespeichert wurde und bei dem der Benutzer automatisch angemeldet wird, wenn ein Anmeldedatensatz für diesen gefunden wird. Falls mehrere Anmeldedatensätze für einen Benutzer gefunden werden, wird eine Aufforderung zur Auswahl der Standardanmeldeinformationen für dessen Anmeldung angezeigt.

C#

private string resourceName = "My App";
private string defaultUserName;

private void Login()
{
    var loginCredential = GetCredentialFromLocker();

    if (loginCredential != null)
    {
        // There is a credential stored in the locker.
        // Populate the Password property of the credential
        // for automatic login.
        loginCredential.RetrievePassword();
    }
    else
    {
        // There is no credential stored in the locker.
        // Display UI to get user credentials.
        loginCredential = GetLoginCredentialUI();
    }

    // Log the user in.
    ServerLogin(loginCredential.UserName, loginCredential.Password);
}


private Windows.Security.Credentials.PasswordCredential GetCredentialFromLocker()
{
    Windows.Security.Credentials.PasswordCredential credential = null;

    var vault = new Windows.Security.Credentials.PasswordVault();
    var credentialList = vault.FindAllByResource(resourceName);
    if (credentialList.Count > 0)
    {
        if (credentialList.Count == 1)
        {
            credential = credentialList[0];
        }
        else
        {
            // When there are multiple usernames,
            // retrieve the default username. If one doesn’t
            // exist, then display UI to have the user select
            // a default username.

            defaultUserName = GetDefaultUserNameUI();

            credential = vault.Retrieve(resourceName, defaultUserName);
        }
    }

    return credential;
}

var resourceName = "My App";
var defaultUserName;

function login() {
    var loginCredential = getCredentialFromLocker();

    if (loginCredential != null) {
        // There is a credential stored in the locker.
        // Populate the Password property of the credential
        // for automatic login.
        loginCredential.retrievePassword();
    } else {
        // There is no credential stored in the locker.
        // Display UI to get user credentials.
        loginCredential = getLoginCredentialUI();
    }

    // Log the user in.
    serverLogin(loginCredential.userName, loginCredential.password);
}


function GetCredentialFromLocker() {
    var credential = null;

    var vault = new Windows.Security.Credentials.PasswordVault();
    var credentialList = vault.findAllByResource(resourceName);
    if (credentialList.length > 0) {
        if (credentialList.length == 1) {
            credential = credentialList[0];
        } else {
            // When there are multiple usernames,
            // retrieve the default username. If one doesn’t
            // exist, display UI to have the user select
            // a default username.

            defaultUserName = getDefaultUserNameUI();
            credential = vault.retrieve(resourceName, defaultUserName);
        }
    }

    return credential;
}

Löschen von Benutzeranmeldeinformationen

Das Löschen der Benutzeranmeldeinformationen im Schließfach für Anmeldeinformationen ist auch ein einfaches Verfahren, das zwei Schritte umfasst. Zunächst wird wieder ein Verweis auf das Schließfach für Anmeldeinformationen mithilfe des PasswordVault-Objekts aus dem Windows.Security.Credentials-Namespace abgerufen. Anschließend werden die zu löschenden Anmeldeinformationen an die PasswordVault.Remove()-Methode übergeben.

C#

var vault = new Windows.Security.Credentials.PasswordVault();
vault.Remove(new Windows.Security.Credentials.PasswordCredential(
    "My App", username, password));

JavaScript

var vault = new Windows.Security.Credentials.PasswordVault();
vault.remove(new Windows.Security.Credentials.PasswordCredential(
    "My App", username, password));

Einfach und sicher

Wie Sie sehen, handelt es sich beim Schließfach für Anmeldeinformationen um ein einfach zu verwendendes Feature, mit dem die Authentifizierung der Benutzer und das Speichern der Anmeldeinformationen auf äußerst sichere Art und Weise für die zukünftige Verwendung erleichtert wird.

Weitere Informationen zur Windows 8-App-Authentifizierung finden Sie u. a. im Artikel zum Webauthentifizierungsbroker, den Sie zum Abrufen eines Authentifizierungstokens von einer Website (z. B.: OAuth) verwenden können, und unter Personalisieren von Apps mit Live Connect (Windows Store-Apps mit JavaScript und HTML).

Weitere Informationen finden Sie unter:

• Verwalten von Benutzerinformationen (JavaScript)
• Verwalten von Benutzerinformationen (Windows Store-Apps mit C#/VB/C++ und XAML)
• Beispiel zum Schließfach für Anmeldeinformationen
• Windows.Security.Credentials

– Doug Rothaus, Senior Content Developer, Windows Developer Content

Besonderer Dank geht an Yashar Bahman für seine Hilfe und Beteiligung an diesem Blogbeitrag.

Sie können App-Benutzern ganz einfach Informationen über das Wetter, Sonderangebote, Sportveranstaltungen oder Konzerte in der Umgebung zukommen lassen, indem Sie den jeweiligen Aufenthaltsort mit der Geschäftslogik Ihrer App verknüpfen. Mit den Geolocation-Klassen von Windows 8 können Sie zusammen mit dem Bing Maps-SDK großartige standortabhängige Windows Store-Apps erstellen.

Lassen Sie uns näher betrachten, wie Ihre App den Positionsdienst einsetzen kann, um dem Benutzer standortabhängige Informationen auf Basis einer IP-Adresse, eines WiFi-Netzwerks oder GPS-Daten anzuzeigen. Wenn Sie die Position abgerufen haben, können Sie Benutzern über das Bing Maps-SDK anzeigen, wo sie sich gerade aufhalten.

Abrufen der Position

Die Position wird mit dem Windows.Devices.Geolocation-Namespace abgerufen. Zwei wesentliche Faktoren entscheiden, ob Sie GPS, ein WiFi-Netzwerk oder eine IP-Adresse zum Abrufen der Benutzerposition verwenden:

1. Die erforderliche Genauigkeit. Hier handelt es sich um den Grad an Genauigkeit, der die Anforderungen Ihrer App erfüllt.
2. Die Verfügbarkeit von Positionsdaten. Nicht alle Geräte verfügen über ein integriertes GPS. Ein Netzwerk oder eine WiFi-Verbindung ist beim Abrufen der Position möglicherweise nicht verfügbar.

Gewünschte Genauigkeit

Beim Abrufen einer Position sollte Ihre App die gewünschte Genauigkeit in der desiredAccuracy-Eigenschaft angeben, damit die Positionsdaten im entsprechenden Bereich so schnell wie möglich zurückgegeben werden können. Jeder Positionstyp verfügt über eine unterschiedliche Genauigkeit:

• GPS – GPS bietet die größte Genauigkeit (bis ungefähr zehn Meter). Wenn der GPS-Sensor jedoch zunächst „aufwachen“, Satellitendaten abrufen und anschließend triangulieren muss, kann das Zurückgeben der Positionsinformationen bis zu zwei Minuten dauern. Ist die GPS-Satellitenverbindungen jedoch bereits vorhanden, kann die nächste Position wesentlich schneller abgerufen werden. Doch die ständige Verwendung des GPS erhöht den Stromverbrauch. Die Geolocator.DesiredAccuracy-Eigenschaft muss auf „High“ festgelegt werden, damit das GPS Daten abrufen kann.
• WiFi – Über eine WiFi-Verbindung lässt sich eine Genauigkeit im Bereich von 300 bis 500 Metern erzielen. Ist eine Verbindung vorhanden, können die Positionsdaten schneller zurückgegeben werden, als über ein GPS, das zuerst eine Satellitenverbindung herstellen muss. Legen Sie die „DesiredAccuracy“-Eigenschaft auf „Default“ fest, um die Position über WiFi abzufragen.
• IP – Die Auflösung auf IP-Basis hat eine Genauigkeit von ungefähr einem Kilometer. Bei bestehender Netzwerkverbindung können die Positionsdaten schneller zurückgegeben werden, als über ein GPS, das zuerst eine Satellitenverbindung herstellen muss. Legen Sie die „DesiredAccuracy“-Eigenschaft ebenfalls auf „Default“ fest, um die Position über die IP-Adresse abzufragen. Der Positionsdienst gibt die maximal verfügbare Genauigkeit zurück und gibt diese in der Geocoordinate.Accuracy-Eigenschaft an.

Bedenken Sie die gewünschte Genauigkeit sorgfältig. Sie kann die Leistung Ihrer App und den Stromverbrauch des Geräts wesentlich beeinflussen. Wenn Ihre App beispielsweise eine Wettervorhersage bietet, benötigen Sie sicher nicht die Genauigkeit von GPS-Daten. Stellen Sie gleichzeitig sicher, die Genauigkeit Ihrer Daten zu veranschaulichen, indem Sie einen Fehlerbereich auf Basis der Genauigkeit der gelieferten Daten anzeigen. Hier der C#-Code zum Festlegen der gewünschten Genauigkeit:

C#

Geolocator geolocator = new Geolocator();
geolocator.DesiredAccuracy = Windows.Devices.Geolocation.PositionAccuracy.High;

C#

Geoposition pos = await geolocator.GetGeopositionAsync().AsTask(token);

Hier der JavaScript-Code, der eine Instanz der „Geolocator“-Klasse erstellt, die gewünschte Genauigkeit festlegt und anschließend die derzeitige Position abruft. Beachten Sie, dass die unten verwendete „promise“-Variable ein WinJS.Promise-Objekt ist. Sie müssen die done-Methode für den Zugriff auf die Daten von getGeopositionAsync verwenden.

JavaScript

var geolocator = Windows.Devices.Geolocation.Geolocator();
geolocator.desiredAccuracy =
Windows.Devices.Geolocation.PositionAccuracy.high;

// Get the geoposition, capturing the request in a 'promise' object.
var promise = geolocator.getGeopositionAsync();

Bing Maps

Die Karten-App ist ein gutes Beispiel für eine App, die sich an die Genauigkeit der verfügbaren Positionsdaten anpasst. Auf einem Desktop-PC, der üblicherweise nicht über GPS oder WiFi verfügt, wird der Standort auf Basis der IP-Adresse ermittelt und auf Regionsebene gezoomt. Auf einem Laptop, der üblicherweise über eine WiFi-Karte verfügt, wird diese zur genaueren Bestimmung der Position verwendet und die Anzeige der aktuellen Position vergrößert dargestellt. Wenn der Benutzer die Darstellung weiter vergrößert, zeigt das Symbol für den aktuellen Standort einen Fehlerbereich an. Auf einem GPS-Gerät kann Bing Maps die Position mit der höchsten Genauigkeit ermitteln und eine recht genaue Position darstellen.

Bing Weather

Wie bereits erwähnt, benötigt eine App wie beispielsweise die Wetter-App lediglich Positionsdaten für die Umgebung. Daher kann sie festlegen, dass sie nur Daten mit geringer Genauigkeit benötigt, um sehr schnell einen Positionswert zu erhalten. Auf diese Weise reagiert die App schneller auf Benutzereingaben. Andere Apps, die nur eine geringe Genauigkeit benötigen, sind beispielsweise Informationen zu Radiosendern, Sonderangeboten oder lokale Nachrichten-Feeds.

Anzeigen von Positionsdaten mit dem Bing Maps-SDK

Wenn Sie die Positionsdaten über den Aufruf von GetGeopositionAsync erhalten haben, möchten Sie diese auf einer Karte darstellen.

• Konvertieren Sie mit dem folgenden Code zunächst die Geoposition in eine Location, die mit Bing Maps verwendet werden kann:

C#

Location location = new Location(pos.Coordinate.Latitude, pos.Coordinate.Longitude);

JavaScript:

promise.done(
  function (pos) {
    // Get the coordinates of the current location.
    var coord = pos.coordinate,
    location = new Microsoft.Maps.Location(coord.latitude, coord.longitude);
 
  },
  function (err) {
    // Handle the error.
  });

• Stellen Sie im nächsten Schritt die Position mit Bing Maps dar. Das Bing Maps-SDK erhalten Sie hier. Sie benötigen darüber hinaus einen Bing Maps Key, den Sie nach einer Registrierung auf dem Bing Maps-Portal und dem Durchführen der Schritte in der Anleitung Getting a Bing Maps Key erhalten. Achten Sie beim Registrieren darauf, dass Sie die Nutzungseinschränkungen für jeden Schlüsseltyp zur Kenntnis nehmen und den für Ihre App geeigneten Typ auswählen.
  Fügen Sie Ihrem Designer ein Bing Maps-Steuerelement hinzu und geben Sie Ihren Key in die Anmeldeinformationen ein.

<Page
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:SimpleMapping"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:Maps="using:Bing.Maps"
    x:Class="SimpleMapping.MainPage"
    mc:Ignorable="d">

    <Grid Background="{StaticResource ApplicationPageBackgroundThemeBrush}">
        <Maps:Map x:Name="Map" Margin="0,120,0,0" Credentials="Insert Your Bing Maps Key Here"/>
    </Grid>
</Page>

• Jetzt können Sie den folgenden Code auf der Seite verwenden, auf der die Karte dargestellt wird. Dieser legt des Vergrößerungsfaktor der Karte fest und zeigt die Position an. Mehr über Zoomstufen erfahren Sie unter So wird's gemacht: Anzeigen Ihrer Position auf einer Bing-Karte:

C#

double zoomLevel = 13.0f;

Map.SetView(location, zoomLevel);

<script type="text/javascript" 
   src="ms-appx:///Bing.Maps.JavaScript//js/veapicore.js">
/script>

Erstellen Sie anschließend ein <div>-Tag für die Karte und legen Sie das Attribut „id“ so fest, dass Sie darauf zugreifen können.

<div id=’map-div’></div>

Abschließend müssen Sie das Kartensteuerelement in der HTML-Seite initialisieren. Ein entsprechender Code in JavaScript:

// Load the Microsoft.Maps.Map module and then call getMap when the 
// module has loaded.
function initMap() {
  Microsoft.Maps.loadModule('Microsoft.Maps.Map', 
    { 
      callback: getMap, 
      culture: "en", 
      homeRegion: "US" 
  });
}

// Get the div to contain the map from the interface of the app.
function getMap() {

  // Create a new instance of the Map class, passing in the app ID.
  var map = new Microsoft.Maps.Map(
    document.getElementById(mapDivId), 
    { credentials: “Insert your credentials here” });

  // Set the initial zoom level and type of map.
  map.setView({
    mapTypeId: Microsoft.Maps.MapTypeId.road,
    zoom: 3
  });
}

• Und: Jede App, die den Positionsdienst verwendet, muss die Berechtigungseinstellungen des Benutzers respektieren, die sich jederzeit ändern können. Die Wetter-App verwendet die aktuelle Position zum Abrufen entsprechender Wetterdaten. Der Benutzer kann jedoch jederzeit die Einstellungen aufrufen und die Berechtigung deaktivieren. Ihre App muss jederzeit in der Lage sein, auf eine Deaktivierung der Positionsberechtigung zu reagieren. In diesem Fall wird von der Wetter-App eine Meldung wie „Ihre Position wurde nicht gefunden. Ändern Sie die Berechtigungen, um Wetter die Verwendung Ihrer Position zuzulassen.“ angezeigt. Weitere Informationen und Beispiele zum Umgang mit Positionsberechtigungen finden Sie in den Richtlinien für standortabhängige Anwendungen.
  

Ausführliche Informationen zum Verwenden von Geolocation und dem Bing Maps-SDK finden Sie in unserem neuen Video, im „Gewusst wie“-Thema und dem Codebeispiel, das Sie mit den Schritten zum asynchronen Abrufen von Positionsdaten vertraut macht, um anschließend das Bing Maps-SDK zur Anzeige des Aufenthaltsortes zu verwenden. Das Video, das „Gewusst wie“-Thema und das Beispiel zeigen Ihnen, wie die Positionsfunktion aktiviert wird, wie die Daten asynchron abgerufen werden, wie die Karte für die ermittelte Position eingerichtet wird und wie das Symbol für die Position auf Basis der Genauigkeit der Daten festgelegt wird. Weitere Informationen finden Sie auch unter Bing Maps für Windows Store-Apps.

Zusammenfassung

Positionsdaten ermöglichen leistungsstarke und zeitsparende App-Funktionen. Sie können dem Benutzer relevante Informationen zum aktuellen Aufenthaltsort bieten. Ob eine Liste der örtlichen Radiosender, Angebote, Verkehrsdaten oder ein Wetterbericht – Benutzer profitieren von der Möglichkeit einer individuellen Bereitstellung dieser Informationen. Da diese ohne Benutzereingriff automatisch erfolgen kann, sparen Benutzer Zeit und erkennen die Vorteile Ihrer App.

– Ross Heise, Senior Content Developer, Windows Developer Content

   Einen besonderen Dank an Jon Kay und Eric Schmidt für Ihre Hilfe und Beteiligung an diesem Blogbeitrag.

Seit dem Start des Windows Dev Centers im Oktober 2011 haben wir in enger Kooperation mit Entwicklern und Designern auf der ganzen Welt analysiert, wie wir App-Entwicklern optimale Anleitungen, Inspiration und Beispiele zur Verfügung stellen können. Mithilfe unzähliger Besucher und dank Ihres Feedbacks wurde ausgewertet, welche Komponenten gut funktionieren und welche Inhalte verbessert werden können.

Neues

Das Windows-Team setzt alle Hebel in Bewegung, um ein lebendiges und umfassendes App-Ökosystem zur Verfügung zu stellen. Dies wird durch drei Merkmale deutlich: hervorragende Apps, einzigartige wirtschaftliche Bedingungen und optimale Reichweite. Im neuen Dev Center können App-Entwickler, Designer und Unternehmen auf die Ressourcen zugreifen, die sie für das Erstellen hervorragender Apps und das Verwirklichen von Geschäftsideen mit Windows benötigen.

Folgende Bereiche des Dev Centers wurden zum Erreichen dieser Ziele weiterentwickelt:

1. Das Navigationsmodell wurde geändert, sodass Sie wichtige Inhalte in jeder Phase der App-Entwicklung problemlos finden.
2. Durch das Sitedesign werden die wichtigsten Aufgaben und Szenarios sowie neue Inhalte hervorgehoben.

Neben den Inhalten, Beispielen und Downloads, die für Entwickler erforderlich sind, wurde für Designer und Unternehmen der Zugriff auf Ressourcen vereinfacht.

Je nach Ihrem Entwicklungsvorhaben steht Ihnen einer von vier Bereichen zur Verfügung: Windows Store-Apps, Internet Explorer, Windows-Desktop und Hardware. In jedem Bereich werden die oben genannten Punkte auf neue Weise unterstützt. In diesem Beitrag werden die spezifischen Änderungen für Windows Store-Apps ausführlicher behandelt.

Die richtigen Inhalte für Ihre Rolle

Eine Website mit vielen Informationen ist nicht hilfreich, wenn gesuchte Inhalte nicht gefunden werden können. Die unzähligen Themen im Dev Center verdeutlichen, dass die Organisation und Strukturierung der Inhalte äußerst wichtig sind. Hinsichtlich der Entwicklung von Windows Store-Apps wurde daher der Schwerpunkt verstärkt auf Rolle und Szenario gelegt, sodass z. B. die Ressourcen für die ersten Schritte zentralisiert bereitgestellt werden und der Support für Designer und Unternehmen verbessert wurde. Dies sind die wichtigsten Neuerungen:

Entwickler

Wir haben die Inhalte, die zum Erstellen hervorragender Windows Store-Apps erforderlich sind, optimiert. Auf der Startseite für Windows Store-Apps werden folgende Komponenten angezeigt:

• Der Bereich „Wichtige Aufgaben und Inhalte“ wurde so prominent platziert, dass Sie problemlos zu den benötigten Inhalten navigieren können. Veranstaltungen in Ihrer Region und neue Ressourcen werden ebenfalls hervorgehoben.
• Außerdem finden Sie hier Downloads, mit denen Sie Code erstellen, auf Ressourcen für die ersten Schritte und auf ausführliche Anleitungen zum Platzieren Ihrer App im Windows Store zugreifen können.
• Wichtige Codebeispiele werden hervorgehoben. Praktische Leitfäden für die Entwicklung wurden noch benutzerfreundlicher gestaltet.
• Auf der Website finden Sie „One Dev Minute“-Videos, die einen Überblick über das Hinzufügen von Features in Apps bieten.

Designer

Der Bereich Design wurde umfassender und gleichzeitig benutzerfreundlicher gestaltet. Sie können jetzt einfacher auf hilfreiche Downloads und wiederverwendbare Designressourcen zugreifen. Designinspiration und Fallstudien statten Sie mit dem Rüstzeug aus, mit dem Sie einzigartige Features für Windows erstellen können. Ihnen stehen somit sämtliche Ressourcen, die Sie zum Erstellen einer ansprechenden, markanten App benötigen, auf einer Touchscreen-optimierten, benutzerfreundlichen Website zur Verfügung.

Unternehmen

Der Windows Store bietet äußerst attraktive Geschäftschancen. Das Wirtschaftsmodell ist dem der Konkurrenzplattformen überlegen, und dank der Flexibilität können Sie Ihre eigenen Geschäftsmodelle umsetzen. Im neuen Marktbereich der Website finden Sie hilfreiche Tipps für die Vermarktung Ihrer Apps, zur Evaluierung von Telemetriedaten und zum Bestehen der App-Zertifizierung. Wir konnten die Zertifizierung optimieren. Die entsprechenden Inhalte wurden verbessert, um den Vorgang für Sie weiter zu vereinfachen.

Selbstverständlich nehmen viele von Ihnen verschiedene Rollen ein. Wir sind sicher, dass die neu gestaltete Website auch diesem Aspekt gerecht wird. Die neue Siteorganisation hilft „Freizeitentwicklern“, Kreativagenturen und großen Softwareunternehmen beim Verwirklichen kreativer und geschäftlicher Visionen mit Windows.

Weitere Entwicklungen stehen an – wir sind gespannt auf Ihre Ideen

Die BUILD 2013 findet in weniger als einem Monat statt, und es gibt viele Themen. Wir arbeiten mit Hochdruck an der Erstellung neuer Inhalte, sodass auf der diesjährigen Veranstaltung ein breites Themenspektrum behandelt werden kann. Sie können sich nicht nur über diesen Blog, sondern auch mit folgenden Ressourcen auf dem Laufenden halten: @windevs auf Twitter und das Abonnement des Windows Store-Newsletters.

Mit jeder Veröffentlichung neuer Inhalte, die Sie beim Entwerfen, Entwickeln und Vermarkten von Windows Store-Apps unterstützen, möchten wir das Dev Center noch benutzerfreundlicher gestalten. Damit Sie uns noch einfacher Feedback geben können, stehen am Ende jeder Seite zwei neue Feedbackoptionen zur Verfügung. Ihr Feedback ist uns wichtig, und wir nehmen uns Ihre Einwände zu Herzen.

Keith Boyd, Content Publishing Manager, Windows Developer Content

In Teilen aus Ihrer App haben wir die Idee vorgestellt, Inhalte aus der Beispiel-App Food with Friends mit mehreren Ziel-Apps zu teilen, um funktionell umfangreiche End-to-End-Szenarien zu ermöglichen. Apps unter Windows 8 bieten interessante Inhalte, die Ihre Kunden wahrscheinlich mit Freunden und anderen Apps teilen möchten. Eine überzeugende und gut gestaltete Zielfreigabe rückt Ihre App in den Mittelpunkt der sozialen und vernetzen Aktivitäten Ihrer Kunden.

In diesem Beitrag beleuchten wir, wie Sie den Zielfreigabe-Vertrag in Ihren Apps verwenden, besonders für Apps wie Food with Friends. Mit diesem Vertrag kann Ihre App Inhalte von anderen Apps empfangen und so qualitativ hochwertigere eigene Inhalte bereitstellen. Wir möchten Ihnen dabei helfen, Ihre App zur besten in ihrer Kategorie zu machen.

Eine Ziel-App wird mithilfe des Zielfreigabe-Vertrags erstellt und ermöglicht schnelles und einfaches Teilen. Nicht jede App unter Windows ist als Freigabeziel geeignet. Wenn Ihre App jedoch empfangene Inhalte veröffentlichen, ändern, speichern oder auf andere Art verarbeiten kann, bietet das Erstellen eines Freigabeziels Vorteile.

• Ihr App wird stets in der Liste der Ziel-Apps angezeigt. Sie ist unmittelbar relevant und mit anderen Apps verknüpft, die die benötigten Daten teilen können.
• Der Freigabe-Vertrag bildet eine Brücke zwischen Ihrer App und einer beliebigen Quell-App, ohne dass die Apps wechselseitig integriert werden müssen.
• Da der Charm „Teilen“ im Betriebssystem stets vorhanden und verfügbar ist, erhält Ihre Ziel-App eine Präsenz im Betriebssystem, die über die Grenzen der App hinausreicht. So können Sie mit Ihrer App auch mehr potenzielle Kunden erreichen.

Empfangen geteilter Inhalte

Betrachten wir einige Beispiele für das Bereitstellen praktischer Funktionen mit einer Freigabeziel-App.

Wahrscheinlich sind Sie bereits mit den Apps Mail und Kontakte von Windows 8 vertraut. Mail stellt ein einfaches und persönliches Freigabeziel für den Empfang und das Teilen von Inhalten mit Freunden dar. Mit der Kontakte-App können Sie Inhalte in Ihren sozialen Netzwerken mit einer größeren Zielgruppe teilen. Zusätzlich zum Teilen in sozialen Netzwerken können Sie mit der Freigabe zuwischen Apps einen Schritt weitergehen. Produktivitäts-Apps wie SkyDrive können Dateien aus der gesamten Windows-Umgebung empfangen und in der Cloud speichern. Apps für Notizen können Text und ggf. auch Daten in zahlreichen anderen Formaten empfangen und diese für die spätere Verwendung archivieren. Wie Sie sehen ist jede Menge Raum für Kreativität vorhanden.

In den folgenden zwei Abbildungen sehen Sie den Freigabepfad beim Teilen eines Fotos von der Fotos-App mit PuzzleTouch, einer Spiele-App, die aus Fotos Bildpuzzles erstellt.

Abbildung 1: Quell-App auf der linken Seite, rechts eine gefilterte Liste mit Ziel-Apps, die Fotos empfangen können.
PuzzleTouch ist eines der Freigabeziele, die ein Bild von der Fotos-App empfangen können.

Abbildung 2: Ziel-App-Vorschau auf der rechten Seite, in der der Benutzer auswählen kann, welche Art Puzzle
er erstellen möchte. Der Puzzle ist fertig, wenn der Benutzer zur App zurückwechselt.

Was ist eine Freigabeziel-App?

Ein End-to-End-Freigabeszenario unter Windows besteht aus zwei Komponenten. Sie haben eine Quell-App, die ihre Inhalte unter Windows in verschiedenen Formaten zur Verfügung stellt. Zudem gibt es eine Freigabeziel-App, die sich für bestimmte Formate registriert und als Ziel für die geteilten Inhalte fungiert. Die Quell-App und die Freigabeziel-App kommunizieren mithilfe des Freigabe-Vertrags miteinander.

Bedenken Sie bei der Freigabe für Ihre App, dass die Freigabeziel-App im gehosteten Fenster „Teilen“ angezeigt wird. Gestalten Sie diese Oberfläche so, dass Benutzer rasch eine Vorschau der Inhalte erhalten und das Teilen in dieser Ansicht bestätigen können. Dieses Beispiel zeigt die Freigabeziel-App-Ansicht für Mail, in der ein Benutzer einen Link aus dem Browser rasch mit einem seiner Mail-Kontakte teilen kann.

Abbildung 3: Teilen eines Links aus der Fotos-App mithilfe der Ziel-App Mail

Szenarien für Food with Friends

Betrachten wir nun, wie Food with Friends als Freigabeziel-App praktische Funktionen umsetzt. Wenn Sie mit der App vertraut sind, kennen Sie auch die beiden Hauptfunktionen von Food with Friends: Planen und Hinzufügen eines Restaurants zur Wunschliste. Selbstverständlich gibt es auch noch andere Funktionen, beispielsweise das Verfassen einer Kritik, Anzeigen der Wunschlisten von Freunden usw. Diese Funktionen finden allerdings ausschließlich innerhalb der Haupt-App statt. Werfen wir einen Blick darauf, ob die beiden Hauptfunktionen mit Food with Friends als Ziel-App effizient umgesetzt werden können.

Erstellen eines Plans für den heutigen Abend

Obwohl dies eine der Kernfunktionen in der Haupt-App darstellt, handelt es sich nicht ein optimales Szenario für ein Freigabeziel. Der Grund ist folgender: Die Zielfreigabe soll schnell und einfach erfolgen. Das Erstellen eines Plans ist eine viel anspruchsvollere Aufgabe – ein Benutzer möchten wissen, welche anderen Restaurants ihre Freunde ausprobieren wollen, möchten einige Restaurants auf deren Wunschlisten vergleichen, Kritiken lesen usw. Da die Planung Details erfordert, die am besten in der Haupt-App präsentiert werden, ist die Zusammenfassung dieser Funktion in der Freigabeziel-App nicht sinnvoll.

Hinzufügen zur Wunschliste

Dies ist ein gutes Szenario, da es sich um eine kurze und direkte Aufgabe im Freigabeziel handelt. Einige Beispiele zu dieser App-Funktion:

• Benutzer entdecken Restaurants in anderen Apps, zum Beispiel in Apps für die Reiseplanung, Apps mit Empfehlungen zur Umgebung, Restaurant-Blogs usw. Food with Friends ist ein hervorragendes Ziel zum Sammeln von Restaurants auf der Wunschliste.
• Die Ziel-App-Ansicht einer App dient dazu, dass ein Benutzer rasch eine Aktion durchführen kann, während er eigentlich eine andere App verwendet. Daher ist das Hinzufügen eines Restaurants zur Wunschliste eine ideale Funktion für das Freigabeziel.
• Selbstverständlich könnte der Benutzer auch die App wechseln, die Suche nach dem Restaurant wiederholen und dieses anschließend zur Wunschliste hinzufügen – jedoch ist es wesentlich einfacher, kurz auf „Teilen“ zu tippen.

Die Wunschliste von Food with Friends ist eine Funktion in einer Freigabeziel-App, wie wir sie uns wünschen. Hier das End-to-End-Szenario, das wir uns vorstellen:

In einer App entdecke ich eine eine interessante Empfehlung zu einem Imbisswagen in der Nähe. Ich möchte den Imbisswagen aus dieser App zu meiner Wunschliste in Food with Friends hinzufügen, damit ich später einen Besuch planen kann.

Abbildung 4: App, die interessante Imbisswagen in der Nähe zeigt

Diese Abbildung zeigt die zu verwendende Freigabeziel-App-Ansicht:

Abbildung 5: Ansicht der Freigabeziel-App

Durch Ausführen der Aktion „Teilen“ in der Ziel-App-Ansicht können Benutzer Restaurants in Food with Friends sammeln, ohne den Kontext der aktuellen App verlassen zu müssen.

Implementieren eines Freigabeziels

Da Sie nun einige Beispiel für die Implementierung eines Freigabeziels kennengelernt haben, ist es an der Zeit, einen Blick auf die Umsetzung zu werfen. Entscheiden Sie zunächst, welche Datenformate Ihre App empfangen können soll.

Welche Datenformate möchten Sie unterstützen?

Mit „Teilen“ können entweder Daten in Standardformaten, z. B. Text, URI, HTML, Bitmap und Dateien, oder benutzerdefinierte Datenformate unterstützt werden, beispielsweise die unter http://schema.org aufgeführten Formate. Windows filtert die Ziel-Apps nach unterstützten Datenformaten, um die gefilterte Liste der Ziel-Apps im Bereich „Teilen“ anzuzeigen. Ihre App sollte die Datenformate unterstützen, die für die Funktionalität der App von Bedeutung sind. Wenn Ihre App beispielsweise zum Anzeigen von Fotos dient, ist die Unterstützung von Textformaten möglicherweise nicht sinnvoll. Wenn Sie die Unterstützung mehrerer Datenformate deklarieren, sollten Sie entscheiden, welches den freigegebenen Daten am ehesten entspricht, sodass dieses Format als erstes aus dem Datenpaket ausgewählt werden kann.

Da Food with Friends eine Freigabeziel-Funktion enthält, bei der Benutzer Restaurants für die App freigeben, verwenden wir das Datenformat Restaurant von http://schema.org. Food with Friends kann im Zielfreigabe-Vertrag für den Empfang dieses Datenformats registriert werden. Anschließend kann die App die Daten im empfangenen Paket in der Ziel-App-Ansicht überzeugend darstellen und Benutzern so ermöglichen, Restaurants zur Wunschliste hinzuzufügen.

Während einige Quell-Apps möglicherweise ausschließlich Daten im Format Restaurant freigeben, stellen andere Apps ähnliche Informationen ggf. in anderen Datenformaten wie Place, LocalBusiness und FoodEstablishment bereit, die Sie ebenfalls bei schema.org finden. Daher unterstützt Food with Friends im Freigabe-Vertrag den Empfang mehrere Datenformate, um mit einer größeren Anzahl von Quell-Apps kommunizieren zu können.

Food with Friends unterstützt in den Freigabeziel-Deklarationen des App-Manifests die folgenden Formate:

• Restaurant
• Place
• LocalBusiness
• FoodEstablishment

Wir konzentrieren uns der Übersichtlichkeit halber auf den Datentyp Restaurant. Das Konzept gilt jedoch ebenso für andere Datentypen.

Welche Datenformate und Szenarien möchten Sie ausschließen?

Food with Friends unterstützt das Hinzufügen des Restaurants zur Wunschliste des Benutzers nur, wenn die zum Restaurant empfangenen Informationen einem Restaurant entsprechen, dass in der App bereits bekannt ist. Dadurch werden mehrere Kopien des Restaurants in der App verhindert.

Wir unterstützen keine Standarddatentypen, da die meisten Quell-Apps, die Text, Dateien, Fotos, URIs oder HTML liefern, nicht für Restaurants oder Geschäfte in der Region relevant sind. Wenn Food with Friends beispielsweise den Empfang von Text unterstützte, würde die App auch in der Liste mit den Ziel-Apps einer Quell-App für Notizen aufgeführt. In diesem Fall müsste Food With Friends eine Fehlermeldung ausgeben, die den Benutzer darauf hinweist, dass diese App nicht mit der Quell-App zusammenarbeitet. Grundsätzlich bedeutet dies, dass Datenformate die sinnvolle Verknüpfung von Quell-Apps mit Ziel-Apps darstellen. Wenn die Datenformate nicht übereinstimmen, ist das Teilen von Daten nicht nützlich.

Stellen Sie sicher, dass Sie alle in Frage kommenden Datenformate berücksichtigen und diejenigen ausschließen, die die Freigabefunktion beeinträchtigen.

Unterstützen des Zielfreigabe-Vertrags

Zur Unterstützung von Datenformaten deklarieren Sie diese im Manifest-Designer von Visual Studio für Ihre App. Folgendes geschieht, wenn ein Benutzer Ihre App als Ziel einer Freigabeaktion auswählt:

1. Im Freigabeziel-Fenster über der Quell-App wird eine neue Instanz der App gestartet.
2. Ein ShareTargetActivated-Ereignis wird ausgelöst und die App erhält ein ShareOperation-Objekt.
3. Ihre App kann die Daten abrufen, die der Benutzer über dieses Objekt teilt.
4. Sie können diese Daten verwenden, um die Ziel-App-Ansicht darzustellen und die Benutzerfreigabe abzuschließen.

Weitere Informationen zum Erstellen dieser Funktionalität finden Sie in der Schnellstart-Anleitung Empfangen von geteilten Inhalten.

Visual Studio unterstützt außerdem eine Vorlage für Freigabeziele. Klicken Sie mit der rechten Maustaste auf Ihr Projekt, wählen Sie Element hinzufügen und Neues Element hinzufügen aus und klicken Sie in der Liste auf Zielfreigabe-Vertrag, um den Code für die Unterstützung des Vertrags hinzuzufügen. Das Codebeispiel zum Freigabeziel veranschaulicht den Empfang geteilter Inhalte.

Entwerfen einer angepassten Ziel-App-Ansicht

Wenn der Benutzer eine Ziel-App aus der App-Liste im Bereich „Teilen“ auswählt, startet Windows die App in der entsprechenden Freigabeziel-Ansicht. Bei der Ziel-App-Ansicht handelt es sich um eine spezielle, im Bereich „Teilen“ gehostete Ansicht, die sich von der Hauptansicht der App unterscheidet. Im Beitrag Aktivierung von Windows 8-Verträgen in Apps finden Sie weitere Informationen zu gehosteten Ansichten sowie zur Aktivierung dieser Ansichten. Die Ziel-App-Ansicht dient zum Abschließen der vom Benutzer eingeleiteten Freigabeaktion. In dieser Ansicht erhalten Benutzer eine übersichtliche Vorschau der Inhalte und können einfache Aktionen vornehmen sowie den Freigabevorgang bestätigen.

Bevor wir uns den Ziel-App-Entwurf für Food with Friends ansehen, werfen wir einen kurzen Blick auf eine Ziel-App, die Ihnen wahrscheinlich bereits vertraut ist. In der folgenden Abbildung wird die Ziel-App-Ansicht neben der vollständigen Ansicht der Mail-App von Windows 8 dargestellt.

Abbildung 6: Freigabe von der Fotos-App an die Ziel-App Mail auf der rechten Seite

Abbildung 7: Verfassen einer neuen E-Mail in der Hauptansicht der Mail-App

Beachten Sie, dass die Freigabeziel-App-Ansicht von Mail einfacher gestaltet ist als deren Hauptansicht. Diese Ansicht bietet eine übersichtliche, zusammenfassende Darstellung der Inhalte, die der Benutzer teilen möchte, in Form einer Miniaturansicht mit zugehörigem Text und HTML. Die Ansicht weist die Zeile An zum Hinzufügen von Empfängern, einen Eingabebereich zum Verfassen einer kurzen Nachricht sowie die Schaltfläche Senden zum Bestätigen des E-Mails-Versands auf.

Obwohl es sich um eine einfachere Ansicht handelt, ist die Ziel-App-Ansicht deutlich als Komponente der Mail-App zu erkennen. Dies verdeutlicht dem Benutzer das Ziel der geteilten Inhalte.

Food with Friends als Freigabeziel-App

Da Sie nun eine allgemeine Vorstellung über den Entwurf einer Ziel-App-Ansicht haben, lassen Sie uns erläutern, wie Food with Friends zu einer Ziel-App wird, in der Benutzer Restaurants zu ihrer Wunschliste hinzufügen können.

Wenn Food with Friends ein Datenpaket mit einem Restaurant von der Quell-App erhält, kann Food with Friends mithilfe der Informationen im Restaurant-Datenformat ermitteln, welches Restaurant in der vorhandenen Datenbank mit dem empfangenen Datenpaket übereinstimmt. Anschließend kann die App eine Vorschau dieses Restaurants in der Ziel-App-Ansicht anzeigen. Dadurch werden die geteilten Inhalte überzeugender dargestellt.

Diese Abbildung zeigt die Ziel-App-Ansicht von Food with Friends.

Abbildung 8: Ziel-App-Ansicht von Food with Friends

Wie Sie sehen, ist diese Ansicht von Food with Friends übersichtlich und für ihre Rolle in der Freigabeziel-App angepasst. Sie zeigt eine Vorschau des Restaurants, das der Benutzer teilen möchte, und eine einfache Aktionsschaltfläche zum Hinzufügen zur Wunschliste, die das Ziel der geteilten Inhalte in der Haupt-App verdeutlicht. Wenn der Benutzer auf diese Schaltfläche tippt bzw. klickt, wird der Freigabevorgang bestätigt. Durch die erforderliche Bestätigung wird ein unbeabsichtigtes Teilen verhindert und die allgemeine Zuverlässigkeit der Freigabefunktion verdeutlicht.

Wenn die App mehrere Restaurants findet, die den Informationen aus dem Datenpaket entsprechen, verwendet Food with Friends die Freigabeziel-App-Ansicht, um die verschiedenen teilbaren Optionen anzuzeigen, aus denen der Benutzer die gewünschte auswählen kann.

Abbildung 9: Ziel-App-Ansicht mit Optionen, aus denen der Benutzer die zu teilenden Elemente auswählen kann

Wenn die App ein Restaurant oder einen Satz gültiger Auswahloptionen anhand des empfangenen Datenpakets nicht genau bestimmen kann, sollten Sie die Ziel-App-Ansicht dazu verwenden, eine entsprechende Meldung anzuzeigen.

Erstellen von Direktlinks

Bei einem Direktlink handelt es sich um eine Bereitstellung der Share-API, mit der Benutzer Inhalte rasch mit bekannten Zielen in der Ziel-App teilen können. Eine Direktlink fungiert als an die Ziel-App angepasster Link, der eine bestimmte Aktion ermöglicht. Wenn Windows die Liste der für den Benutzer verfügbaren Ziel-Apps filtert, wird die Direktlinkliste oben im Bereich „Teilen“ als Liste verfügbarer Ziele angezeigt. Bei diesen vertrauten Zielen und Benutzeraktionen kann es sich beispielsweise um Speicherorte oder Kontakte handeln, die häufig über die Ziel-App geteilt werden. Beispielsweise gibt die Mail-App Direktlinks für Kontakte zurück, an die bereits zuvor E-Mails gesendet wurden. Auf die gleiche Weise können Sie Direktlinks zu Ordnern, Gruppen, Notizbüchern und Wiedergabelisten hinzufügen, die oft mit der Ziel-App geteilt werden.

Abbildung 10: Bereich „Teilen“ mit einem von der Ziel-App Mail bereitgestellten Direktlink für Kontakte,
an die bereits zuvor E-Mails gesendet wurden

Die Ziel-App kann einen Direktlink durch Aufrufen der reportCompleted-Methode des ShareOperation-Objekts bereitstellen. Jeder Direktlink muss über einen Titel, ein Symbol und eine ID verfügen. Der Titel (z. B. „E-Mail an Mama“) und das Symbol werden angezeigt, wenn der Benutzer auf den Charm „Teilen“ tippt. Die ID wird von der App verwendet, um auf benutzerdefinierte Informationen zuzugreifen, z. B. eine E-Mail-Adresse, den Speicherort eines Ordners usw. Weitere Informationen zu diesem Tool finden Sie unter Erstellen eines Direktlinks. 

Hinweis: Direktlinks sind hilfreich, wenn die App mehrere Aktionen der Ziel-App unterstützt. Da Food with Friends nur eine einzige Aktion im Freigabeziel unterstützt (das Hinzufügen zur Wunschliste), wurden in der App keine Direktlinks implementiert.

Erweiterte Freigabe und Fehlerberichterstellung

Manchmal werden aus Quell-Apps große Datenmengen wie Fotos, Videos oder Dateien geteilt, bei denen die Datenübertragung länger dauert. Diese Freigabevorgänge werden als erweiterte Freigaben bezeichnet, bei denen die Ziel-App möglicherweise mehr Zeit benötigt, um die Daten zu empfangen und zu verarbeiten.

Da die Freigabe so schnell und flüssig erfolgt und es sich bei der Ziel-App-Ansicht um eine vereinfachte, über der Haupt-App gehostete Darstellung handelt, schließen Benutzer möglicherweise die Ziel-App-Ansicht, um zur Haupt-App zurückzugelangen. Daher sollten Ziel-Apps keine zusätzlichen Benutzerinteraktionen erwarten oder erfordern, nachdem das Teilen gestartet wurde. Ziel-Apps können das ShareOperation-Objekt und dessen Methoden verwenden, um Windows darüber zu benachrichtigen, dass die App Daten verarbeitet.

• reportStarted – Rufen Sie diese Methode auf, um Windows darüber zu informieren, dass der Empfang der Daten durch die App im DataPackage-Objekt von der Quell-App begonnen hat.
• reportDataRetrieved – Rufen Sie diese Methode auf, um Windows darüber zu informieren, dass die Daten im Paket vollständig von der App empfangen wurden.
• reportCompleted – Rufen Sie diese Methode auf, um Windows darüber zu informieren, dass der Freigabevorgang von der App abgeschlossen wurde.

Wenn Ihre App Daten im Rahmen einer erweiterten Freigabe verarbeitet, sollten Sie den Fortschritt in der Ziel-App-Ansicht darstellen. Hierdurch wird der Benutzer darüber informiert, dass seine Anfrage bearbeitet wird und er einfach zu Ihrer App zurückkehren und den Fortschritt des Freigabevorgangs überprüfen kann. Unter Schnellstart: Hinzufügen von Statussteuerelementen finden Sie weitere Informationen zu Statussteuerelementen unter Windows 8.

Abbildung 11: Ziel-App Mail mit einem Statusanzeigering beim Abschließen einer erweiterten Freigabe wie dem Senden großer Anlagen

Wenn bei der Datenübertragung ein Fehler auftritt und der Freigabevorgang von der Ziel-App abgebrochen werden muss, können Sie reportError aufrufen, um eine Fehlermeldung an Windows zu senden. Der Benutzer erhält die Meldung, wenn er den Status der Freigabe im Bereich „Teilen“ überprüft. Nachdem der Fehler gemeldet wurde, wird die App geschlossen und das Teilen beendet. Der Benutzer muss die Freigabe der Inhalte für Ihre App erneut starten.

Im Zielfreigabebeispiel Food with Friends sollte die App einen Fehler ausgeben, wenn in der App-Datenbank kein Restaurant gefunden wird, das mit dem über die Quell-App im Restaurant-Datenformat geteilten Restaurant übereinstimmt.

Zusammenfassung

Das Teilen zwischen Apps bietet spannende Möglichkeiten für die Freigabe von Ziel-Apps. Indem Sie einer App den Empfang geteilter Inhalte ermöglichen, können Benutzer auch dann von der App profitieren, wenn sie anderweitig beschäftigt sind. Wir hoffen, dass wir zu einem besseren Verständnis der Entwurfsprinzipien sowie der Datentypen, Klassen und der Eigenschaften beitragen konnten, die für das Erstellen eines Freigabeziels erforderlich sind. Wir freuen uns auf die Umsetzung geteilter Inhalte in Ihren Apps, damit Sie Ihren Benutzern umfangreichere Funktionen zur Verfügung stellen können.

Weitere Informationen zur Freigabe finden Sie unter Freigeben und Austauschen von Daten und im Ziel-App-Beispiel zur Freigabe von Inhalten.

Ishita Kapur

Programmmanager

Windows-Benutzeroberfläche

Freigabe für Ziel-Apps

Freigeben von Apps, Ziel-Apps, geteilte Inhalte, Freigabeziel, Freigeben von Ziel-Apps

Nahfeldkommunikation (Near Field Communication, NFC) ist eine neue, immer häufiger verwendete Drahtlostechnologie mit kurzer Reichweite. Innerhalb einer Entfernung von genau 2 cm können Geräte von Benutzern physisch aneinander gekoppelt werden, um Inhalte zu senden bzw. zu empfangen. Kopplung bietet Ihnen die Möglichkeit, schnell etwas (oder jemanden) auswählen. Kopplung ist nicht nur schnell, es ist auch unkompliziert. Sobald Sie es einmal gesehen haben, haben Sie es verstanden – ganz ohne Handbuch.

Stellen Sie sich beispielsweise vor, Sie zeigen einer Freundin ein paar Fotos und sie möchte diese Bilder haben – mit NFC müssen Sie lediglich Ihr Gerät mit dem Computer Ihrer Freundin koppeln und können dann die Fotos versenden. So einfach ist das? Im Prinzip schon. NFC dient dazu, Inhalte schnell und einfach zwischen Geräten zu teilen.

Abbildung 1: Nokia 360° Lautsprecher teilt seine Bluetooth-
Kopplungsdaten mit einem Windows Phone

Bei NFC handelt es sich ähnlich wie bei Bluetooth oder WLAN um ein Standard-Drahtlosprotokoll, das vom NFC-Forum definiert wird. Ihr Computer muss über ein NFC-Radio verfügen. In zahlreichen Windows 8-PCs sind NFC-Radios bereits direkt integriert. Wenn Ihr PC noch nicht über NFC verfügt, können Sie NFC-Dongles erwerben, um diese am PC anzuschließen.

NFC bietet einige tolle Funktionen. Benutzer können Ihr Gerät mit anderen Geräten koppeln und Fotos versenden, mit einer Speisekarte koppeln und ein Essen in einem Restaurant bestellen oder sogar mit einem Bluetooth-Gerät koppeln. Die Verwendungsmöglichkeiten sind also vielfältig, aber in allen Fällen müssen zunächst Ihr Gerät und der Empfänger aneinander gekoppelt werden, auch „Tappen“ genannt. NFC macht das Verbinden von vielen unterschiedlichen Geräten – PCs, SmartPhones, Lautsprecher, Headsets, Drahtlosbildschirme – intuitiver und damit benutzerfreundlicher. Bei NFC kommen außerdem auch RFID-Tags zum Einsatz, sehr kostengünstige, leichtgewichtige passive Antennen, die eine beträchtliche Menge an Daten speichern und so gut wie überall befestigt werden können, am häufigsten auf Plakaten. Zum Beispiel könnten Sie eine Kinokarte erwerben, indem Sie einfach Ihr Gerät mit dem Filmplakat koppeln. Diese werden als NFC-Tags bezeichnet. Wir erläutern ein einfaches Beispiel einer Kopplung mit einem NFC-Tag, um einige grundlegende Konzepte der NFC-API zu demonstrieren.

Aber werfen wir zunächst einmal einen Blick darauf, was das Koppeln von Geräten eigentlich bedeutet.

Definieren einer Kopplung

Ob Sie Ihr Gerät mit einer Bluetooth-Maus koppeln oder mit einem anderen Gerät, um Fotos zu teilen: Für den Benutzer zählt, dass Geräte auf die gleiche Weise gekoppelt werden. Das „Tappen“, also das Koppeln eines PC mit einem anderen Gerät, ist für die meisten Benutzer neu und deshalb ungewohnt. Im Folgenden finden Sie einige Richtlinien für das Koppeln, mit deren Hilfe Benutzer informiert werden:

1. Wo müssen die Geräte gekoppelt werden – Verwenden Sie einen Berührungspunkt (auch als „Koppeln und Aktion“-Logo bekannt), der anzeigt, wo sich die NFC-Antenne befindet. Je nach PC-Modell erfolgt die Kopplung an einer unterschiedlichen Stelle des PCs. Beispielsweise erfolgt möglicherweise die Kopplung bei einem Tablet an der Rückseite, bei einem All-in-One jedoch an der Vorderseite. Im Folgenden ist das Logo abgebildet, das sich auf allen Windows 8-PCs mit vorhandenem NFC befindet:
   
   

   Abbildung 2: „Koppeln und Aktion“-Logo

2. Geräte kommunizieren miteinander – Während der Kopplung sollten die Benutzer darauf vertrauen können, dass tatsächlich etwas passiert, auch wenn Sie die Datenübertragung selbst nicht sehen. Deshalb wird von Windows ein Sound wiedergegeben, wenn sich Geräte innerhalb der Reichweite befinden und miteinander kommunizieren.

All das wird von Windows automatisch ausgeführt, sodass Sie sich darum keine Gedanken machen müssen. Weitere Informationen zu diesen Elementen der Benutzerfreundlichkeit finden Sie unter Windows 8 Near Field Proximity Implementation Specification. Sehen wir uns nun in Anbetracht dessen einige tollen Szenarien an, die Sie mit NFC erleben können.

Wann sollte NFC verwendet werden?

Verwenden Sie NFC, wenn in Ihrer App ein Benutzer etwas bzw. jemanden auswählen soll. NFC bietet eine intuitive Art und Weise des Auswählens, die häufig schneller (und interessanter) als die manuelle Suche ist. Durch die Kopplung wird ein Vorgang ausgelöst. Je nach App kann dies bedeuten, dass z. B. ein Foto empfangen oder eine Wiedergabeliste gestartet wird. Es gibt viele Möglichkeiten. Was nach der Kopplung passiert, hängt ganz von Ihrer App ab. Deshalb bezeichnen wir diese Vorgänge der Einfachheit halber als „Koppeln und Aktion“-Vorgänge.

Im Folgenden finden Sie ein paar Beispiele, um etwas mithilfe von NFC in einer App auszuwählen. Folgende Funktionen können mit Koppeln ausgeführt werden:

• Abrufen von Informationen von einem Plakat: NFC-Tags sind leichte, kostengünstige RFID-Tags. Ihre Kosten liegen zwischen 0,15 und 1,00 US-Dollar (Preis abhängig von den Druckkosten). Sie sind vergleichbar mit QR-Codes, jedoch einfacher und schneller zu verwenden. Es ist bequemer, sich an ein Tag zu koppeln, als ein Foto des Barcodes aufzunehmen (und darauf zu hoffen, dass sich die Kamera im richtigen Winkel befunden hat). In Bereichen mit hoher Verkehrsdichte, z. B. Flughäfen, U-Bahn-Stationen und Bushaltestellen, integrieren immer mehr Hersteller Tags in Plakate. Tags können 48 B bis 4 KB an Daten speichern. Sie können einen Tag so programmieren, dass Ihre App mit einer bestimmten Seite gestartet wird.

• Austauschen von Kontaktinformationen: Koppeln Sie Geräte zum Austauschen von Kontaktinformationen, anstatt sie einem Freund zu buchstabieren und zu hoffen, dass er sich an keiner Stelle verschreibt. Ähnlich wie oben können Sie Ihre Informationen in eine NFC-Visitenkarte bzw. in einen NFC-Tag programmieren oder sie direkt über eine App austauschen.
• Wiedergeben der Lieblingsmusikstation: Ganz gleich, ob Sie gerade mit dem Training anfangen, ins Auto steigen oder sich einfach nur zu Hause entspannen – verwenden Sie einen NFC-Tag, um einen Radiosender einzuschalten. Sie können sich sogar verschiedene Musiksender für verschiedene Tags programmieren, beispielsweise jeweils einen Tag für das Fitnesscenter, einen zum Entspannen und einen für die Schlafenszeit.
• Aufgeben von Bestellungen in einem gut besuchten Restaurant: In beliebten Restaurants müssen Sie manchmal bereits für das Aufgeben der Bestellung lange warten. Koppeln Sie stattdessen Ihr Gerät an einen Tag auf Ihrem Tisch, um das Essen zu bestellen.
• Spielen eines Multiplayer-Spiels mit einem Freund: Sie können problemlos Multiplayer-Spiele wie Schiffe versenken, Schach oder Scrabble mit einem Freund verbinden, indem Sie die Geräte aneinander koppeln. Nach dem Koppeln wird die Verbindung über einen Out-of-Band-Transport mit einer größeren Reichweite und einem größeren Durchsatz beibehalten, beispielsweise über Bluetooth oder Wi-Fi Direct.

Wir haben nun schon eine ganz gute Vorstellung davon, wie NFC funktioniert und wann es verwendet wird. Jetzt wird es spannend! Gehen wir in media res und erstellen eine App mithilfe unserer Windows 8-Näherungs (NFC)-APIs.

So implementieren Sie NFC

Wie Sie sehen, erleichtert NFC Endbenutzern viele alltägliche Aufgaben. Nehmen Sie die Einstellung eines Alarms als ein Beispiel. Ich bin mir sicher, dass beinahe jeder schon einmal versehentlich eine falsche Weckzeit für den nächsten Morgen eingestellt hat. Wenn es spät ist und man eigentlich nur noch einschlafen möchte, ist man gerne einmal etwas unaufmerksam. NFC macht dies leichter, da hier nur ein voreingestellter Tag getappt und bestätigt werden muss, um dann ohne Sorgen schlafen gehen zu können. Stellen wir uns also vor, dass Sie deshalb eine einfache Alarm-App geschrieben haben, mit der Benutzer einen Alarm mithilfe eines NFC-Tags einstellen können. Dabei lassen sich zwei Szenarien unterscheiden:

1. Einstellen eines Alarms im Tag: NFC-Tags können wiederverwendet werden, daher sollte die App dem Benutzer eine Möglichkeit bieten, einen Alarm zu programmieren. Beispielsweise möchte ein Benutzer vielleicht verschiedene Alarme programmieren, einen für Werktage, einen für das Wochenende. Dies wird allgemein als Veröffentlichen in einem Tag bezeichnet.
2. Einstellen eines Alarms vom Tag: Nachdem ein Benutzer einen Tag gekoppelt hat, sollte die App gestartet werden, um die Einstellung eines Alarms zu bestätigen. Dies bedeutet, dass die App mit Kontext oder Argumenten gestartet werden kann.

Die NFC-API bietet unterschiedliche Herangehensweisen für das gleiche Ziel, ich erläutere hier aber nur den einfachsten Weg zur Implementierung dieses Szenarios.

Im Folgenden werden die Schritte zum Einstellen eines Alarms auf einem NFC-Tag veranschaulicht:

1. Jens startet die Alarm-App und gibt eine Uhrzeit an, z. B. 07:00 Uhr. Ein ganz normaler Vorgang, bei dem NFC noch keine Rolle spielt.
2. Jens wählt die Option zum Einrichten eines Alarms in einem NFC-Tag aus. An dieser Stelle ruft App die NFC-APIs auf, um Daten an das NFC-Radio zu übertragen, genauer gesagt eine App-ID-Zeichenfolge: & 07:00. Bei NFC-Tags wird ein Standardnachrichtenformat mit der Bezeichnung NDEF (NFC Defined Exchange Format) verwendet. Die Formatierung der Daten in eine NDEF-Nachricht muss nicht von der App ausgeführt werden. Diesen Vorgang übernimmt Windows. Der Benutzer kann jetzt den NFC-Tag koppeln.
3. Jens koppelt den Tag mit dem PC und die Programmierung des Tags wird von der App bestätigt. Nach der Kopplung des Tags sollten die Benutzer unbedingt darüber informiert werden, dass der Tag erfolgreich von der App programmiert wurde. Wie bereits erwähnt, stellt die Kopplung von PCs für die meisten Anwender ein neues Konzept dar. Durch die Bestätigung erhalten die Benutzer Gewissheit, dass der Vorgang funktioniert. Durch die Registrierung eines MessageTransmittedHandlers erkennt die App, dass eine Nachricht erfolgreich übermittelt wurde.

Die NFC-APIs befinden sich im Windows.Networking.Proximity-Namespace. Diese APIs kommen in Schritt 2 zum Einsatz, nachdem der Benutzer die Option zum Einstellen eines Alarms auf einem NFC-Tag auswählt. Zunächst initialisiert die App ein Näherungs-Objekt. Anhand des Näherungs-Objekts kann ermittelt werden, ob sich ein Tag (oder Gerät) innerhalb oder außerhalb der Reichweite befindet. Anschließend wird der DeviceArrival-Ereignishandler hinzugefügt. Der Handler erkennt, ob der Tag gekoppelt wurde. Ist dies der Fall, können Informationen auf den Tag geschrieben werden. Die Benutzer sollten wissen, wenn auf den Tag geschrieben wird, damit sie ihn nicht außer Reichweite bewegen. Mit diesem Ereignis kann die Kopplung beliebiger Näherungs-Geräte erkannt werden.

Im folgenden Codeausschnitt wird das Initialisieren und Hinzufügen eines DeviceArrival-Ereignishandlers veranschaulicht.

JavaScript

var proximityDevice;

function initializeProximityDevice() {
    proximityDevice = Windows.Networking.Proximity.ProximityDevice.getDefault();

    if (proximityDevice) {
        proximityDevice.addEventListener("devicearrived", proximityDeviceArrived);
       
}
   else {
        // No NFC radio on the PC, display an error message
    }


function proximityDeviceArrived(device) {
        // Let the user know we’re ‘Writing to Tag’

}
}

private void InitializeProximityDevice()
{

Windows.Networking.Proximity.ProximityDevice proximityDevice;
    proximityDevice = Windows.Networking.Proximity.ProximityDevice.GetDefault();

    if (proximityDevice != null) {
        proximityDevice.DeviceArrived += ProximityDeviceArrived;
    
    }
    else
    {
        // No NFC radio on the PC, display an error message
    }
}

private void ProximityDeviceArrived(Windows.Networking.Proximity.ProximityDevice device)
{
            // Let the user know we’re ‘Writing to Tag’

}

Im nächsten Schritt veröffentlichen wir Informationen auf dem Tag. Die App veröffentlicht zwei Komponenten: eine App-ID-Zeichenfolge (bestehend aus einer App-ID und App-Plattform) und Startargumente. Unter Windows 8 lautet die App-ID <Name der Paketfamilie>!<App-ID> und die App-Plattform „Windows“. Sie müssen den App-ID-Wert aus dem ID-Attribut des Anwendungselements in das Paketmanifest für Ihre App kopieren. Das Startargument lautet „07:00“ (der vom Benutzer festgelegte Alarm). Bezeichnen wir dieses Argument als die Nachricht.

Für plattformübergreifende Apps ermöglicht Windows das Veröffentlichen alternativer App-IDs und -Plattformen, sodass Sie denselben Tag mit anderen NFC-kompatiblen Geräten koppeln können, z. B. Windows Phone 8. Weitere Informationen zu Alternativen IDs finden Sie auf MSDN.

Die Daten werden von der App mithilfe der publishBinaryMessage-Methode auf dem Tag veröffentlicht. Die Methode akzeptiert drei Parameter: „messageType“, „message“ und eine messageTransmittedHandler-Funktion. „messageType“ wird auf „LaunchApp:WriteTag“ festgelegt, woran Windows erkennt, dass die App Daten auf einen NFC-Tag schreiben möchte. Bei „message“ handelt es sich lediglich um die zuvor definierte Nachricht (App-ID-Zeichenfolge und Startargumente). Die Nachricht muss als binäre Nachricht in einem Puffer gespeichert werden. Die messageTransmittedHandler-Funktion registriert Rückrufe. Hierdurch erkennt die App, dass die Nachricht erfolgreich auf den Tag geschrieben wurde. Auf diese Weise kann dem Benutzer Folgendes mitgeteilt werden: Die Nachricht wurde erfolgreich auf den Tag geschrieben und der Tag muss sich nicht mehr in Reichweite befinden.

Nachrichten werden so lange veröffentlicht, bis die StopPublishingMessage-Funktion aufgerufen oder das ProximityDevice-Objekt freigegeben wird. In diesem Beispiel wird die Stop-Funktion verwendet. PublishBinaryMessage gibt eine Veröffentlichungs-ID zurück. Anhand dieser ID wird das Veröffentlichen der Nachricht auf dem NFC-Radio beendet.

Im nächsten Codeausschnitt wird das Schreiben von Daten auf einen NFC-Tag veranschaulicht:

JavaScript

var proximityDevice;

function getAlarmTime(){

    // Grab time set by the user, call this variable ‘Alarm’
    return Alarm;

}

function publishLaunchApp() {
    proximityDevice = Windows.Networking.Proximity.ProximityDevice.GetDefault();

if (proximityDevice) {
        // The format of the app launch string is: "<args>\tWindows\t<AppName>".
        // The string is tab or null delimited.

        // The <args> string can be an empty string ("").
        var launchArgs = getAlarmTime();

        // The format of the AppName is: PackageFamilyName!PRAID.
        var praid = "AlarmApp"; // The Application Id value from your package.appxmanifest.

        var appName = Windows.ApplicationModel.Package.current.id.familyName + "!" + praid;

        var launchAppMessage = launchArgs + "\tWindows\t" + appName;

        var dataWriter = new Windows.Storage.Streams.DataWriter();
        dataWriter.unicodeEncoding = Windows.Storage.Streams.UnicodeEncoding.utf16LE;
        dataWriter.writeString(launchAppMessage);
        var launchAppPubId =
             proximityDevice.publishBinaryMessage(
                 "LaunchApp:WriteTag", 
                 dataWriter.detachBuffer(), 
                 proximityWriteTagLaunchAppMessageTransmitCallback);
        
    if (launchAppPubId != -1) {
            // Stop publishing the message on NFC radio
        proximityDevice.stopPublishingMessage(launchAppPubId);
    }

     }
}

function proximityWriteTagLaunchAppMessageTransmitCallback() {
    // Inform the user that: the message has been successfully written to a tag & the tag no longer needs to be in range
}

Windows.Networking.Proximity.ProximityDevice proximityDevice;

private string GetAlarmTime(){

    // Grab time set by the user, call this variable ‘Alarm’
    return Alarm;
}

private void PublishLaunchApp()
{
    proximityDevice = Windows.Networking.Proximity.ProximityDevice.GetDefault();

if (proximityDevice != null)
    {
        // The format of the app launch string is: "<args>\tWindows\t<AppName>".
        // The string is tab or null delimited.

        // The <args> string can be an empty string ("").
        string launchArgs = getAlarmTime();

        // The format of the AppName is: PackageFamilyName!PRAID.
        string praid = "MyAppId"; // The Application Id value from your package.appxmanifest.

        string appName = Windows.ApplicationModel.Package.Current.Id.FamilyName + "!" + praid;

        string launchAppMessage = launchArgs + "\tWindows\t" + appName;

        var dataWriter = new Windows.Storage.Streams.DataWriter();
        dataWriter.UnicodeEncoding = Windows.Storage.Streams.UnicodeEncoding.Utf16LE;
        dataWriter.WriteString(launchAppMessage);
        var launchAppPubId =
        proximityDevice.PublishBinaryMessage(
            "LaunchApp:WriteTag", dataWriter.DetachBuffer(), 
            proximityWriteTagLaunchAppMessageTransmitCallback);
    
    if (launchAppPubId!= -1)
    {
        proximityDevice.StopPublishingMessage(launchAppPubId);
    // Stop publishing the message on NFC radio
    }

    }
}

private void proximityWriteTagLaunchAppMessageTransmitCallback(
    Windows.Networking.Proximity.ProximityDevice sender,
    long messageId)
{
        // Inform the user that: the message has been successfully written to a tag & the tag no longer needs to be in range
}

1. Jens betrachtet gerade den Startbildschirm, verfasst eine E-Mail, spielt ein Spiel oder nutzt Windows für eine beliebige andere Aufgabe, als ihm einfällt, dass er einen Alarm für Montag morgen einstellen muss. Er nimmt seinen „Wochentagsalarm“-Tag zur Hand und koppelt diesen mit seinem PC. Ein Aufforderung zum Starten der Alarm-App wird angezeigt. Bis zu diesem Punkt werden sämtliche Vorgänge von Windows ausgeführt, die App spielt noch keine Rolle.
2. Jens stimmt zu und die App zeigt einen Bildschirm zum Bestätigen des Alarms um 07:00 Uhr an. Daraufhin werden die Startargumente (wie im obigen Beispiel) von Windows während der Aktivierung an die App übergeben. Dieser Vorgang wird als kontextgebundener Start bezeichnet und gleicht dem direkten Starten einer bestimmten Seite der App.
3. Jens stellt den Alarm ein, ein ganz normaler Vorgang ohne Beteiligung von NFC.

Die Startargumente können problemlos vom NFC-Tag abgerufen werden. Der kontextgebundene Start über einen NFC-Tag muss jedoch von der App ausgeführt werden. Bei einem kontextgebundenen Start handelt es sich um eine andere Bezeichnung für das direkte Starten einer bestimmten Seite der App. In den Startargumenten ist der Alarm „07:00 Uhr“ angegeben, der von der App als Alarmvorschlag angezeigt wird. Fall die App nicht auf dem PC installiert ist, bietet Windows Jens außerdem die Option, die App automatisch aus dem Windows Store installieren zu lassen.

Im folgenden Codeausschnitt ist die Implementierung des kontextgebundenen Starts veranschaulicht.

JavaScript

app.onactivated = function (args) {
    if (args.detail.kind === activation.ActivationKind.launch) {
        if (args.detail.arguments == "Windows.Networking.Proximity.PeerFinder:StreamSocket") {
            //do nothing here.
        }
        else {
    // Use args.detail.arguments to parse out ’07.00’ string, and display to the user
        }

        args.setPromise(WinJS.UI.processAll());
    }
}

async protected override void OnLaunched(LaunchActivatedEventArgs args)
        {
            if (args.Arguments == "Windows.Networking.Proximity.PeerFinder:StreamSocket")
            {
                _isLaunchedByTap = true;
            }
            else
            {
// Use args.Arguments to parse out ’07.00’ string, and display to the user

            }
            Window.Current.Activate();
        }

Das ist alles, was eine App zur Unterstützung von Lese- und Schreibvorgängen auf einen NFC-Tag benötigt – ziemlich einfach für ein Szenario mit modernster Technologie. Vor der Zusammenfassung möchte ich noch auf einige schützende Maßnahmen eingehen – Fehlerbehandlung.

Fehlerbehandlung

Im Folgenden finden Sie einige häufige Fehler, die in dieser App auftreten können.

• Der gekoppelte Tag liegt nicht im NDEF-Format vor. Die automatische Neuformatierung eines Tags in NDEF wird von Windows 8 nicht unterstützt, daher müssen Sie eine NDEF-Formatierungsanwendung herunterladen und installieren.
• Der gekoppelte Tag ist schreibgeschützt. Einige NFC-Tags sind möglicherweise schreibgeschützt (ähnliche wie alte VHS-Kassetten).
• Der gekoppelte Tag ist zu klein und bietet nicht genügend Platz für sämtliche Daten.
• Der Benutzer-PC verfügt nicht über NFC. Wie anfangs erwähnt, handelt es sich bei NFC um eine neue, noch nicht weit verbreitete Technologie, die jedoch in zunehmendem Maße eingesetzt wird. Verwenden Sie die ProximityDevice.getDefault()-Methode, um zu ermitteln, ob Näherung von einem PC unterstützt wird. Wenn keine NFC-Radios installiert sind, gibt die Methode NULL zurück.

Einfach und intuitiv

NFC ist endlich für den Endverbrauchermarkt bereit, und Windows bietet das entsprechende Ökosystem sowie eine hervorragende Benutzerfreundlichkeit für sämtliche zugehörige Vorgänge. Die Technologie bietet ein enormes Potenzial zur Entwicklung unglaublich interaktiver Apps und Geräte – einfach und intuitiv.

NFC ist ein großer Themenbereich: Sie können also auf weitere Blogbeiträge über andere interessante Erfahrungen im Rahmen der NFC-Entwicklung unter Windows 8 gespannt sein.

Weitere Informationen zu NFC und Näherung finden Sie in den folgenden Ressourcen.

Ressourcen

Vielen Dank!

Priya Dandawate
Programmmanager, Devices and Networking

Unter Mitarbeit von: Max Morris, Marzena Makuta, Mike Loholt, Jake Sabulsky und Vishal Mhatre

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: "http://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("http://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.

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.

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.

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

Letzte Woche hat Steve Guggenheimer die //build/ 2013 angekündigt. Die Konferenz findet vom 26. bis 28. Juni 2013 im Moscone Center in San Francisco statt. Die //build/ ist die Gelegenheit, mehr über die Entwicklung von Windows Store-Apps zu erfahren. Auf der Konferenz finden zahlreiche Präsentationen, Vorführungen und Info-Veranstaltungen statt. Viele Mitglieder unseres Entwicklerteams kommen für diese Vorführungen nach San Francisco und beantworten Ihre Fragen. Es gibt keinen besseren Ort, um das Neueste und Wichtigste über die Entwicklung von Windows Store-Apps in Erfahrung zu bringen.

Die Registrierung beginnt am Dienstag, den 2. April. Alle Informationen zur Konferenz finden Sie unter www.buildwindows.com, wo Sie sich auch registrieren können.

Wir freuen uns auf Ihren Besuch!