Tam Hanna Freelancer

Konservative Naturen verbinden ihr Log-in-Konto nur ungern mit dem Microsoft-Account und bekommen bei der erstmaligen Einrichtung der Beziehung für Project Rome dementsprechend Schwierigkeiten mit dem System. In der Praxis funktioniert Rome allerdings bestens – das Anwerfen von Programmen erfolgt problemlos.

Microsofts Stärke liegt traditionell im Desktopbereich: Das halbwegs erfolgreiche Windows Mobile ging spätestens mit dem Aufkommen des iPhone den Weg über den Jordan. Um in der heutigen, verbundenen Zeit relevant zu bleiben, muss man im Hause Microsoft die Desktop- und sonstige Infrastruktur so effizient wie möglich mit anderen Diensten verbinden.

Mit Project Rome möchte man in Redmond die Stärke der Xbox und die enorme Verbreitung von Windows am Laptop bzw. am Desktop ausnutzen. Die dahinterstehende Idee ist einfach: Ein Nutzer soll einen Task auf einem Gerät beginnen können, um ihn danach mit „minimalem Aufwand“ auf einem anderen Gerät fertigzustellen.

Die in Vorstellungen gerne besprochene Übergabe eines Films von Handy auf Xbox mag nett aussehen, dürfte in der Praxis aber wenig Relevanz haben. Bessere Anwendungsfälle wären beispielsweise ein Aktienverwaltungsprogramm, das Charts bei Bedarf unter Nutzung einer Xbox oder einer Workstation an einen Beamer sendet.

Artikelserie

Teil 1: Project Rome: Apps auf Wanderschaft

Teil 2: Project Rome auf Abwegen

Teil 3: Komplexe Remote-Interaktionen mit App Services

Im Interesse maximaler Flexibilität beschränkt sich Microsoft nicht auf die hauseigene Cloud: Project Rome funktioniert auch unter Nutzung von Bluetooth oder WLAN. Das Remote-Systems-API sucht automatisch nach dem idealen Kommunikationsmedium: Entwickler können die Endgeräte als „einfach vorhanden“ annehmen. Als Bindeglied zwischen den verschiedenen Geräten eines Nutzers dient ein Microsoft-Account. Dass man sich in Redmond naturgemäß darüber freut, wenn möglichst viele Nutzer die hauseigenen Dienste nutzen, folgt aus der Logik.

Windows Developer wird Ihnen in den kommenden Ausgaben detailliert die Möglichkeiten des Project-Rome-Service vorstellen. Dieser erste Teil wird Grundlagen der Universal Windows Platform vorstellen; im darauffolgenden Artikel werfen wir einen Blick auf Project Rome für Android, und der dritte und letzte Artikel geht sodann auf App-Services ein, die die Realisierung fortgeschrittener Kommunikationsszenarien ermöglichen.

Eine Frage der Arbeitsumgebung

Da Microsoft mittlerweile diverse Betriebssysteme – darunter auch die einstigen Todfeinde Android und iOS – unterstützt, ist für eine vollständige Betrachtung von Project Rome einiges an Hardware erforderlich. Der Autor nutzt in den folgenden Schritten ein unter Windows 10 Version 1703 laufendes Lenovo ThinkPad T430, ein unter Windows 10 Version 10.0.14393.1066 laufendes TecLast X98-Pro und auf Seiten von Android ein Vernee Apollo Lite mit Android 6.0.

Aktiv und passiv

Bei der Betrachtung des Remote Systems-API ist es empfehlenswert, Geräte in aktive und passive Teilnehmer zu unterteilen. Ein aktiver Teilnehmer kann hierbei Kommandos senden, während ein passives Device Kommandos entgegennimmt. Universal-Windows-Platform-basierte Systeme können beide Rollen ausfüllen, während Android und iOS nur zum Absetzen von Befehlen fähig sind.

Microsoft zeigt sich im Bereich der Windows-Version übrigens relativ kulant: Project Rome läuft auf allen Versionen von Windows 10 ab Version v10.0.14393.0. Zudem ist zum Test natürlich ein Microsoft-Account erforderlich, der mit den lokalen Benutzerkonten des ThinkPads und des Tablets verbunden sein muss.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Windows Developer 10.17 - "Datenarbeit mit Durchblick"

Alle Infos zum Heft
579811144Microsoft verknüpft alle Geräte und Dienste miteinander
X
- Gib Deinen Standort ein -
- or -