Neulich nach dem Yoga erzählt eine Teilnehmerin lautstark davon, dass ihr Sohn jetzt tatsächlich Informatik studieren würde.

Ich brauchte erst eine ganze Zeit, bis mir klar war, dass ihre Lautstärke nicht daher kam, dass sie darauf super stolz sei, sondern dass sie es ganz furchtbar finde, dass ihr Sohn jetzt Informatiker werden möchte.

Wir sind in dieser Yogaklasse eine sehr kleine Gruppe (maximal 6 Personen), und die meisten wissen, dass ich ITlerin bin. Diese Teilnehmerin hatte das aber anscheinend verdrängt. Natürlich schauten mich jetzt alle anderen an. Erst mal drückte ich meine Begeisterung aus: "Das ist ja super, wir brauchen eh mehr ITler." Dann fragte ich nach, was denn so furchtbar wäre. Sie antwortete zunächst mit einem Beispiel, das nicht auf meine Frage einging, sondern ihren Unglauben auf eine für mich lustige Art untermauerte:

"Dann waren wir in der Stadt, und mein Sohn wollte unbedingt noch ein Mathematikbuch für das Studium kaufen. Als ich das Buch gesehen habe – ein richtig richtig dickes Buch –, hatte ich schon meine Zweifel. Das schaut der sich ja im Leben nicht an. Zu Hause dann, das Buch war noch eingeschweißt, habe ich mir genau gemerkt, wo er das Buch hingelegt hat. Ich war mir sicher, dass es auch in zwei Monaten exakt an der Stelle (und eingeschweißt) liegen wird. Aber nicht zu fassen, bereits am Abend war das Buch ausgepackt, und er schaute tatsächlich ausgiebig in das Buch. Das ist doch schrecklich!"

Ich kam wieder auf meine Frage zurück, was denn so schrecklich wäre? Die Hauptantwort war, dass er wohl gerne Computerspiele spielt und jetzt mit dem Studium dann ja nur noch in den Monitor starren und sich nicht mehr mit anderen Menschen auseinandersetzen würde. Mein Einwand, dass er seinem Hobby Computerspiele vermutlich auch bei einer anderen Studienwahl weiter frönen würde. Dass auch bei vielen anderen Studiengängen die Arbeit am Rechner unvermeidbar wäre, ließ sie nicht gelten.

Allerdings hörte sie mir staunend zu, als ich meinte, dass ITler üblicherweise im Team und nicht alleine arbeiten würden. Womit sie dann zu ihrer eigentlichen Sorge kam – ob er denn mit diesem Studiengang eine Chance auf einen Job hätte? ...

Dieses Gespräch hat mich wieder einmal darin bestätigt, wie schlecht "wir" im Vermarkten und damit im Aufbau einer guten (!) Reputation [1] sind. Und obwohl sich besagter Sohn für die IT entschieden hat, ist es ja nicht so, dass die Studienzahlen für IT durch die Decke gehen und dieses Missverständnis ein Generationenproblem ist. Aus diesem Grund sind Aktionen wie die Münchner Erklärung [2] (auch die Initiative dazu auf der letzten OOP [3]) wichtig, aber lange nicht ausreichend. Das heißt, "dieser Weg wird kein leichter sein".

Bislang gibt es für das Teilen von Inhalten zwischen mobilen Webanwendungen keinen einheitlichen Ansatz. Doch dies könnte sich bald ändern, denn bei der Web Incubator Community Group [1] macht man sich bereits Gedanken über entsprechende Web APIs: Über die Web Share API [2] soll das Teilen von Inhalten möglich sein, über die Web Share Target API [3] das Empfangen von Inhalten.

Beide genannten APIs befinden sich derzeit in einem noch frühen Stadium und werden noch in keiner offiziellen Version der großen Browser unterstützt. Allerdings lässt sich zumindest die Web Share API über den sogenannten Origin Trial von Google testen (der im Allgemeinen dem Chrome-Entwicklerteam dazu dient, Entwickler-Feedback bei der Implementierung neuer APIs zu bekommen). Registriert man sich dort, erhält man ein spezielles Token, nach dessen Einbau in die eigene Webanwendung die API auf Android-Geräten über Chrome Beta [4] geprüft werden kann:

Offiziell soll die Web Share API dann mit Version 55 Einzug in Chrome erhalten.

Die Web Share API

Wie bereits gesagt ist das Ziel der Web Share API [5], einen einheitlichen Weg zu schaffen, über den Inhalte (im folgenden "Ressourcen" genannt) zwischen mobilen Anwendungen geteilt werden können. Die API ist in seiner aktuellen Form relativ übersichtlich, zumal nur die beiden Interfaces Navigator und WorkerNavigator um eine Methode share() erweitert werden sollen. Feature Detection könnte daher beispielsweise wie folgt aussehen:

if(navigator.share === undefined) {
  console.error('Web Share API wird nicht unterstützt.');
} else {
  console.log('Web Share API wird unterstützt.');
}

Als Parameter erwartet die Methode share() ein Objekt vom Typ ShareData, das wiederum drei Eigenschaften haben kann:

• title: Titel der Ressource, die geteilt wird
• text: Text, über den sich eine zusätzliche Beschreibung der Ressource angeben lässt
• url: URL zu der Ressource, die geteilt wird
  

Außerdem ist geplant, auch die Angabe von Bilddaten beziehungsweise Blobs zu ermöglichen. Alle Eigenschaften sind optional, allerdings muss mindestens eine im Objekt enthalten sein.

let shareData =
{
  title: document.title,
  text: 'Die erste mit der Web Share API geteilte Ressource.',
  url: window.location.href
}

Als Rückgabewert erhält man von der Methode share() ein Promise-Objekt, auf dem sich wie gewohnt Callback-Funktionen definieren lassen:

navigator
  .share(shareData)
  .then(() => {
    console.log('Erfolgreich geteilt');
  })
  .catch(error => {
    console.log('Fehler beim Teilen: ', error)
  });

Die über then() angegebene Callback-Funktion wird aufgerufen, wenn der Nutzer eine Anwendung (bzw. "Share Target") ausgewählt hat, zu der die Ressource geteilt werden soll und die Ressource von dieser Anwendung ohne Fehler akzeptiert wurde. Im Fehlerfall wird entsprechend die über catch() definierte Callback-Funktion aufgerufen, wobei Fehler beispielsweise dann auftreten, wenn

1. die geteilte Ressource beziehungsweise im ShareData-Objekt übermittelte Daten fehlerhaft sind,
   
2. keine passende Anwendung gefunden wurde, die die Ressource entgegennimmt,
   
3. der Nutzer keine Anwendung auswählt beziehungsweise die Auswahl abbricht oder
   
4. die Ressource nicht erfolgreich zu der ausgewählten Anwendung übermittelt werden konnte.

"Share Targets" können zum einen vorhandene Dienste wie die Zwischenablage sein, zum anderen native Anwendungen wie Facebook oder Twitter, aber auch andere Webanwendungen, und zwar solche, die sich über die Web Share Target API für das Empfangen geteilter Inhalte registriert haben.

Die Web Share Target API

Während die Web Share API es ermöglichen soll, Inhalte zu teilen, soll es über die Web Share Target API [15] möglich sein, (von anderen Anwendungen) geteilte Inhalte entgegenzunehmen. Als Voraussetzung muss der jeweilige Browser dabei sowohl die Service Worker API [16] als auch die Web App Manifest API [17] unterstützen.

Eine Anwendung, die geteilte Inhalte entgegennehmen soll (wie gesagt auch "Share Target" genannt), registriert sich entweder über die Methode addEventListener() oder über den Event-Handler onshare für das share-Event:

navigator.actions.addEventListener('share', handler);

Empfangene Events sind vom Type ShareEvent und ermöglichen wiederum den Zugriff auf das jeweilige ShareData-Objekt:

const handler = event => {
  let shareData = event.data;
  console.log(shareData.title);
  console.log(shareData.text);
  console.log(shareData.url);
}

Die Daten innerhalb des SharedData-Objekts können je nach Zielanwendung unterschiedliche Verwendung finden, beispielsweise ließe sich bei einem E-Mail-Client als "Share Target" der Inhalt der Eigenschaft title als Betreff der E-Mail und die Kombination aus text und url als Inhalt der E-Mail verwenden, während bei einem Text Messenger der Inhalt von title ignoriert und dagegen nur eine Kombination aus text und url verwendet werden könnte:

const emailHandler = event => {
  let data = event.data;
  let subject = data.title;
  let content = `${data.text} ${data.url}`;
  composeEmail(subject, content);
}
const textMessengerHandler = event => {
  let content = `${data.text} ${data.url}`;
  composeMessage(content);
}

Fazit

Die Web Share API und die Web Share Target API definieren Schnittstellen zum Teilen von Inhalten zwischen mobilen Anwendungen. Derzeit werden beide APIs noch von keinem Browser unterstützt, die Web Share API lässt sich aber wie geschildert in Chrome Beta unter Android testen.