Windows Dev Center

Richtlinien für die Erstellung benutzerdefinierter Datenformate

Benutzer geben im Internet zahlreiche Informationen frei. Erfolgreiche Apps analysieren die am häufigsten freigegebenen Informationstypen und verpacken diese Informationen so, dass sie von den Empfänger-Apps richtig verarbeitet werden können. In vielen Fällen weisen die von Benutzern freigegebenen Informationen eines der sechs von Windows unterstützten Standardformate auf. Es gibt aber auch Situationen, in denen speziellere Datentypen besser geeignet sind. Für diese Fälle kann Ihre App benutzerdefinierte Datenformate unterstützen.

Beispiel

Das folgende Beispiel veranschaulicht die Verwendung von benutzerdefinierten Formaten.

Im fiktiven Unternehmen Fabrikam schreibt ein Entwickler eine App zum Freigeben von online gespeicherten Dateien. Eine Option wäre die Verwendung von StorageItems mit Streamunterstützung. Dies könnte allerdings zeitraubend und ineffizient sein, weil die Ziel-App die Dateien zum Lesen lokal herunterladen müsste. Stattdessen entscheidet sich der Entwickler für die Erstellung eines benutzerdefinierten Formats, das für diese Dateitypen verwendet werden soll.

Zunächst legt der Entwickler die Definition des neuen Formats fest. In diesem Fall handelt es sich um eine Zusammenstellung beliebiger Datentypen (z. B. Dokumente, Bilder), die online gespeichert sind. Da sich die Dateien im Web statt auf dem lokalen Computer befinden, gibt der Entwickler dem Format den Namen "WebFileItems".

Als Nächstes müssen die genauen Eigenschaften des Formats festgelegt werden. Der Entwickler entscheidet sich für Folgendes:

  • Das Format sollte aus einem IPropertyValue bestehen, der ein InspectableArray enthält, das für die URIs (Uniform Resource Identifiers) steht.
  • Das Format muss mindestens ein Element enthalten. Eine Obergrenze für die Anzahl der Elemente gibt es aber nicht.
  • Alle gültigen URIs sind zulässig.
  • URIs, die außerhalb der Grenzen der Quellanwendung nicht zugänglich sind (z. B. authentifizierte URIs) sollten nicht verwendet werden.

Diese Informationen reichen zur Erstellung und Verwendung eines benutzerdefinierten Formats aus.

Sollte ich für meine App benutzerdefinierte Formate verwenden?

Das Freigabefeature von Windows 8 unterstützt sechs Standarddatenformate:

  • Text
  • HTML
  • Bitmap
  • StorageItems
  • URI
  • RTF

Da diese Formate sehr vielseitig sind, kann Ihre App schnell und einfach das Freigeben unterstützen und freigegebene Inhalte empfangen. Es gibt jedoch einen Nachteil: Die Standardformate stellen der Empfänger-App nicht immer eine ausführliche Beschreibung der Daten zur Verfügung. Ein Beispiel hierfür ist die folgende Zeichenfolge, die für eine Anschrift steht:

1234 Main Street, New York, NY 98208

Eine App kann diese Zeichenfolge mit DataPackage.setText freigeben. Da die App auf der Empfängerseite aber nicht genau weiß, wofür die Zeichenfolge steht, kann sie die Daten nur begrenzt verarbeiten. Mithilfe eines benutzerdefinierten Datenformats kann die Quell-App die freigegebenen Daten als Ort im Format http://schema.org/Place definieren. So erhält die Empfänger-App zusätzliche Informationen und kann diese nutzen, um die Informationen wie vom Benutzer erwartet zu verarbeiten. Durch die Verwendung vorhandener Schema-Formate kann die App mit einer großen Datenbank mit definierten Formaten verbunden werden.

Benutzerdefinierte Datenformate können auch zum effizienteren Freigeben von Daten beitragen. Ein Benutzer hat z. B. eine Fotosammlung auf Microsoft OneDrive gespeichert und möchte einige der Fotos in einem sozialen Netzwerk teilen. Die Standardformate sind hierfür aus den folgenden Gründen nicht die beste Wahl:

  • Beim URI-Format kann immer nur ein Element auf einmal freigegeben werden.
  • OneDrive gibt Sammlungen als StorageItems mit Streamunterstützung frei. Wenn in diesem Szenario StorageItems verwendet würden, müsste die App jedes einzelne Foto erst herunterladen und dann freigeben.
  • Bei Text und HTML können Sie eine Liste mit Links angeben, aber da die Bedeutung der Links verloren geht, erfährt die Empfänger-App nicht, dass diese Links für die freizugebenden Fotos stehen.

Ein benutzerdefiniertes Schema-Format zum Freigeben der Fotos hat in diesem Szenario zwei wichtige Vorteile:

  • Die App kann die Fotos schneller freigeben, da Sie eine Auflistung von URIs erstellen können, statt alle Bilder auf den Computer herunterzuladen und lokal zu speichern.
  • Die Empfänger-App erkennt, dass die URIs für Fotos stehen, und kann sie entsprechend verarbeiten.

Empfohlene und nicht empfohlene Vorgehensweisen

Definieren eines benutzerdefinierten Formats

Wenn Sie zu dem Schluss kommen, dass sich ein benutzerdefiniertes Format für Ihre App anbietet, berücksichtigen Sie folgende Punkte:

  • Prüfen Sie, ob ein Standardformat denselben Zweck erfüllt, damit Sie nicht unnötigerweise ein benutzerdefiniertes Format erstellen. Überprüfen Sie, ob auf http://www.schema.org ein Format vorhanden ist, das Ihre Zwecke erfüllt. Es ist wahrscheinlicher, dass eine andere App anstelle Ihres benutzerdefinierten Formats ein Standardformat verwendet. Dann wären die von Ihnen gewünschten End-to-end-Szenarien einem breiteren Publikum zugänglich.
  • Überlegen Sie, welches Ziel Sie mit der App verfolgen. Welche Aktionen möchten die Benutzer ausführen, und welches Datenformat ist dafür am besten geeignet?
  • Machen Sie die Definition Ihres benutzerdefinierten Formats für andere App-Entwickler verfügbar.
  • Geben Sie dem benutzerdefinierten Format einen aussagekräftigen Namen, der zum Inhalt passt. Ein Name wie UriCollection weist beispielsweise darauf hin, dass alle URIs gültig sind. In einem Format mit dem Namen WebImageCollection sind hingegen nur URIs enthalten, die auf Onlinebilder verweisen.
  • Machen Sie sich Gedanken über die Bedeutung des Formats. Sie sollten genau wissen, wofür das Format steht und wie es zu verwenden ist.
  • Überprüfen Sie die Struktur des Formats. Kann es mehrere Elemente oder eine Serialisierung unterstützen? Welchen Einschränkungen unterliegt es?
  • Ändern Sie das benutzerdefinierte Format nach der Veröffentlichung nicht mehr. Die Situation ist ähnlich wie bei einer API: Auch wenn Elemente hinzugefügt werden oder überholt sind, müssen Abwärtskompatibilität und langfristige Unterstützung gegeben sein.
  • Vermeiden Sie Formatkombinationen. Sie können beispielsweise nicht davon ausgehen, dass eine App ein bestimmtes Format erkennt und sofort weiß, dass sie nach einem zweiten Format suchen muss. Aus diesem Grund müssen Formate eigenständig sein.

Hinzufügen benutzerdefinierter Formate zu Ihrer App

Beachten Sie folgende Empfehlungen, wenn Sie ein benutzerdefiniertes Format erstellt haben und es der App hinzufügen möchten:

  • Testen Sie das Format mit anderen Apps. Überprüfen Sie, ob die Daten bei der Übertragung von der Quell-App an die Ziel-App richtig verarbeitet werden.
  • Halten Sie sich an den vorgesehenen Zweck des Formats. Verwenden Sie es nicht für andere Zwecke.
  • Wenn Sie eine Quell-App schreiben, stellen Sie zusätzlich mindestens ein Standardformat bereit. So können Benutzer Daten auch mit Apps teilen, die das benutzerdefinierte Format nicht unterstützen. Die Benutzererfahrung ist dabei möglicherweise nicht optimal, aber immerhin können die Benutzer ihre Daten überhaupt mit den gewünschten Apps teilen. Dokumentieren Sie das Format auch online, sodass andere Anwendungen es kennen und verwenden können.
  • Wenn Sie eine Ziel-App schreiben, sollte diese nach Möglichkeit mindestens ein Standardformat unterstützen. So kann die App auch dann Daten von Quell-Apps empfangen, wenn diese nicht das bevorzugte benutzerdefinierte Format aufweisen.
  • Wenn Sie ein bestimmtes benutzerdefiniertes Format aus einer anderen App übernehmen möchten, insbesondere von einem anderen Unternehmen, sollten Sie sich vergewissern, dass es öffentlich online dokumentiert ist. Bei undokumentierten Formaten ist es wahrscheinlicher, dass diese sich ohne Ankündigung ändern, wodurch möglicherweise Inkonsistenzen entstehen oder die App nicht mehr funktioniert.

Weitere Hinweise zur Verwendung

Auswählen eines Datentyps

Eine der wichtigsten Entscheidungen beim Definieren eines benutzerdefinierten Formats betrifft die Auswahl des WinRT-Datentyps, der zur Übertragung des Formats zwischen der Quell- und Zielanwendung verwendet werden soll. Die DataPackage-Klasse unterstützt verschiedene Datentypen für benutzerdefinierte Formate:

Wenn Sie ein Format definieren, wählen Sie den jeweils zu den Daten passenden Typ aus. Alle Consumer und Empfänger des Formats müssen denselben Datentyp verwenden – auch wenn verschiedene Optionen zur Auswahl stehen –, da sonst in den Zielanwendungen Fehler wegen unerwarteter Datentypen auftreten können.

Wenn Sie für das Format den Datentyp "Zeichenfolge" auswählen, können Sie es auf der Zielseite mit der Form GetTextAsync(formatId) der Funktion GetTextAsync abrufen. Diese Funktion übernimmt die Überprüfung des Datentyps. Andernfalls müssen Sie GetDataAsync verwenden und einen Schutz vor möglichen Datentypkonflikten einrichten. Wenn beispielsweise eine Quellanwendung einen einzelnen URI bereitstellt und das Ziel versucht, diesen als URI-Auflistung abzurufen, entsteht ein Konflikt. Um Konflikte dieser Art zu vermeiden, können Sie Code hinzufügen, der ähnlich wie dieses Beispiel lautet:

Auffüllen des Datenpakets


var uris = new Array();
uris[0] = new Windows.Foundation.Uri("http://www.msn.com");
uris[1] = new Windows.Foundation.Uri("http://www.microsoft.com");
var dp = new Windows.ApplicationModel.DataTransfer.DataPackage();
dp.setData("UriCollection", uris);


Abrufen der Daten


if (dpView.contains("UriCollection")) {
    dpView.getDataAsync("UriCollection").done(function(uris) {
        // Array.isArray doesn’t work – uris is projected from InspectableArray
        if (uris.toString() === "[object ObjectArray]") {
            var validUriArray = true;
            for (var i = 0; (true === validUriArray) && (i < uris.length); i++) {
                validUriArray = (uris[i] instanceof Windows.Foundation.Uri);
            }
            if (validUriArray) {
                // Type validated data 
            }
        }
    }
}


Verwandte Themen

Für Entwickler (HTML)
Auswählen von Datenformaten für die Freigabe
Quickstart: Sharing content
Quickstart: Receiving shared content
Für Entwickler (XAML)
Auswählen von Datenformaten für die Freigabe
Quickstart: Sharing content
Empfangen von geteilten Inhalten
Beispiele
Beispiel zur Quell-App für die Inhaltsfreigabe
Beispiel zur Ziel-App für die Inhaltsfreigabe

 

 

Anzeigen:
© 2015 Microsoft