Mai 2016
Band 31, Nummer 5
Universelle Windows-Plattform-Apps – Gehostete Webanwendungen für Unternehmen
Von Tim Kulp | Mail 2016
Entwickler, die in einer Unternehmensstruktur arbeiten, wissen, dass es nicht immer einfach ist, neue Technologien zu implementieren. Die Einführung von etwas Neuem im Unternehmen, wie z. B. ein UWP-App-Projekt (universelle Windows-Plattform), kann eine Herausforderung darstellen, wenn es keine Teams gibt, die befähigt sind (oder es sich zutrauen), diese Art von App bereitzustellen. Viele Unternehmen haben viel in Webanwendungen in ihrem Intranet und die Teams zu deren Unterstützung investiert. Gehostete Webanwendungen ebnen Web-Apps im Intranet von Unternehmen bei nur wenig Aufwand einen Weg in den Windows Store für Unternehmen.
In diesem Artikel wandle ich eine im Intranet vorhandene Webanwendung in eine UWP-Anwendung für den Windows Store um und ergänze die App mit nativer Windows-Funktionalität. Wie Abbildung 1 zeigt, ist die Webanwendung eine App für soziale Anerkennung namens „Gotcha“, die es Mitarbeitern des Unternehmens Contoso ermöglicht, ihren Kollegen für Gefälligkeiten Anerkennung zu zollen oder Wertschätzung zu bekunden. Aufgabe von Gotcha ist es, in einem gefestigten, zufriedenen Team für ein noch besseres Klima zu sorgen. Diese Webanwendung ist deshalb gut für den Windows Store geeignet, da sie eine einfache Integration mit Kontakten, das Teilen von Informationen und die Kamerafunktion ermöglicht.
.png "Die Webanwendung Gotcha")
Abbildung 1: Die Webanwendung Gotcha
Brücken und gehostete Webanwendungen für Unternehmen
Für Entwickler in Unternehmen sind UWP-Brücken und gehostete Web-Apps (Hosted Web Apps, HWAs) sinnvoll, da sie ihre vorhandenen Tools, Prozesse und Entwicklungssysteme für ihre Apps weiter nutzen können. Das Brückenkonzept soll Entwickler in die Lage versetzen, ihre vorhandenen iOS-, Android-, Win32- oder Webanwendungen auf die UWP und in den plattformübergreifenden Windows Store zu überführen. Ziel ist es, Entwicklern das Portieren ihrer vorhandenen Codebasis auf die UWP zu ermöglichen, damit sie die Benutzererfahrung mit Windows-spezifischen Features, wie z. B. besonderen Xbox-Funktionen, optimieren können.
Brücken erleichtern das Überführen von Code auf die UWP, doch Entwickler in Unternehmen sehen sich weiteren Herausforderungen gegenüber, die das Konvertieren ihres Codes erschweren. Entwickler in einem Unternehmen können Einschränkungen hinsichtlich der Code-Editoren, die ihnen zur Verfügung stehen, oder des Orts unterliegen, an dem Code basierend auf der Vertraulichkeit der Informationen innerhalb der Anwendung bereitgestellt werden kann. Der tatsächliche Nutzen von UWP-Brücken für Unternehmen ist nicht die Einfachheit beim Konvertieren von Apps, sondern die Weiternutzung vorhandener Tools für die Entwicklung von Unternehmenssoftware, Methoden und des Change Managements zur Bereitstellung von UWP-Apps über den Windows Store.
Als Beispiel hierfür ermöglichen gehostete Webanwendungen (auch bekannt als „Project Westminster“) Entwicklern das Einbetten von Webanwendungen in eine UWP-App. Sobald die UWP-App für das Verwenden des HWA-Inhalts entwickelt wurde, können Entwickler weiter ihre bisherigen Methoden zum Pflegen der Webanwendung befolgen, wodurch die Webanwendungserfahrung der UWP-App automatisch aktualisiert wird. Mithilfe der HWA-Brücke können sich Entwickler auf ihre Webanwendung konzentrieren und mithilfe der Featureerkennung für die UWP spezifische Features einbeziehen. Das Arbeiten mit einem vorhandenen Intranet ist ein besonders gut geeigneter Anwendungsfall für UWP-Brücken, doch auch unternehmensexterne Entwickler können gehostete Webanwendungen (HWAs) nutzen, um ihre Web-Apps in den Windows Store zu überführen. Jede Website kann zu einer gehosteten Webanwendung werden, solange die jeweilige Website den Zertifizierungsprozess für den Windows Store durchlaufen hat.
Die Grundlagen gehosteter Webanwendungen werden von Kiril Seksenov in seinem Blogbeitrag „Project Westminster in a Nutshell“ unter (bit.ly/1PTxxW4) ausführlich behandelt. Ich empfehle die Lektüre dieses Beitrags, um sich mit den Konzepten hinter gehosteten Webanwendungen eingehender vertraut zu machen.
Starten eines HWA-Projekts zur Umwandlung einer Webanwendung
Der erste Schritt beim Umwandeln der Webanwendung Gotcha in eine gehostete Webanwendung (HWA) ist das Erstellen einer neuen JavaScript-UWP-App in Visual Studio. Nach Erstellen der App öffne ich die Paketmanifestdatei und lege die Startseite auf die URL der Webanwendung fest (siehe Abbildung 2). In diesem Fall wird die Webanwendung unter „localhost:6107“ ausgeführt. Nach Festlegen dieser Startseite zeigt die App die Webseite an der angegebenen Adresse anstelle des lokalen Inhalts für die App an.
.png "Festlegen der Startseite in der Paketmanifestdatei")
Abbildung 2: Festlegen der Startseite in der Paketmanifestdatei
Legen Sie schließlich die Inhalts-URIs in der Paketmanifestdatei fest. Diese URIs informieren Ihre App, welche Seite auf WinRT-Bibliotheken (Windows Runtime) zugreifen und welchen Zugriffsgrad diese URIs haben können. Dieses Szenario wurde beschrieben als Festlegen der Grenze, an der die App aufhört und das Internet anfängt. Ich finde, dass dies gut die Vorstellung vermittelt, wie Inhalts-URIs verwendet werden sollten. In der vorhandenen Webanwendung Gotcha gibt es klare Unterscheidungen dazwischen, was die App leistet und was sie mithilfe des Internets leisten kann. Innerhalb von Gotcha können Benutzer beispielsweise Anerkennung in sozialen Netzwerken wie LinkedIn kundtun. Die LinkedIn-Website gehört nicht zur UWP-App Gotcha, sondern ist Teil des Internets. Ich empfehle, nur URIs einzuschließen, die direkt in der Anwendung verwendet werden, und auch nur diejenigen, die Zugriff auf UWP-APIs benötigen.
Durch den Einsatz von Inhalts-URIs kann der Entwickler die Benutzer der App schützen, indem der Zugriff auf WinRT-Bibliotheken für nicht registrierte URIs verhindert wird. Geben Sie für jeden URI an, welcher Zugriffsgrad auf WinRT-Bibliotheken erforderlich ist:
- All: In der Webanwendung (in diesem Fall Gotcha) ausgeführter JavaScript-Code kann auf sämtliche UWP-APIs zugreifen, die im Rahmen der App-Funktionalität definiert sind.
- Allow for Web Only: In der Webanwendung ausgeführter JavaScript-Code kann benutzerdefinierte WinRT-Komponenten ausführen, die im App-Paket enthalten sind, aber nicht auf alle UWP-APIs zugreifen.
- None: In der Webanwendung ausgeführter JavaScript-Code kann nicht auf lokale UWP-APIs zugreifen (Standardeinstellung).
Bedenken Sie beim Festlegen von Inhalts-URIs, dass diese ein wesentliches Element der Anwendungssicherheit für Benutzer der UWP-App darstellen. Vergewissern Sie sich, dass Sie für einen URI nur die Mindestberechtigungen für die notwendigen Funktionen der UWP-App erteilen (siehe Abbildung 3). Vermeiden Sie das Festlegen des WinRT-Zugriffs für den Stamm-URI auf „All“, sofern dies innerhalb der App nicht wirklich erforderlich ist.
.png "Festlegen von Inhalts-URIs mit der für die Ausführung der App erforderlichen Mindestberechtigung")
Abbildung 3: Festlegen von Inhalts-URIs mit der für die Ausführung der App erforderlichen Mindestberechtigung
Ich empfehle nicht das Entfernen vorhandener Inhalte, die die Folge des Projekterstellungsprozesses sind (wie z. B. CSS-, JS-Dateien und WinJS-Ordner). Diese vorhandenen Inhalte bieten Entwicklern ein ausgezeichnetes Framework, das zum Hinzufügen lokaler Inhalte zur Web-HWA dienen kann. Im weiteren Verlauf dieses Artikels nutze ich diese Ordner für lokale Inhalte zum Erstellen verschiedener Funktionen, die die Offline-Erfahrung der Web-HWA ergänzen.
Führen Sie nach Konfiguration der Paketmanifestdatei die UWP aus. Wie in Abbildung 4 gezeigt, wird die Webanwendung nun wie alle anderen UWP-Apps in einem App-Fenster angezeigt.
.png "Die für den Windows Store bereite App Gotcha")
Abbildung 4: Die für den Windows Store bereite App Gotcha
Debuggen einer gehosteten Webanwendung
Gehostete Webanwendungen haben im Vergleich mit rein nativen Apps eine geringfügig andere Debugumgebung. Drücken Sie bei geöffneter UWP-App F12. Die F12-Entwicklertools für die UWP-App werden angezeigt. Mit den F12-Entwicklertools kann ich die Webanwendung wie in einem Browser debuggen, profilieren und testen. Wenngleich alle Features der F12-Entwicklertools für Entwickler gehosteter Webanwendungen nützlich sind, fand ich am nützlichsten das Debuggen außerhalb von Visual Studio und Erstellen von Profilen der Netzwerkaktivität. Ich verwende diese Features zur detaillierten Untersuchung des Verhalten einer bestimmten App und Erfassung von Problemen (wie z. B. Zwischenspeichern im Cache), die für eine unerwartete Erfahrung in der App sorgen.
Vergleichbar mit dem Verwenden von F12 im Browser können Entwickler auch das DOM ändern und basierend auf Bildschirm- oder Fenstergröße verschiedene UI-Umgebungen ausprobieren. Dies dient zum Untersuchen von Änderungen am Layout einer Webanwendung basierend auf die Anforderungen der App an die Reaktionsfähigkeit. So sollte beispielsweise nach dem Andocken der UWP-App als Randleiste die App so dynamisch umgebrochen werden, dass ein überzeugende Oberfläche gezeigt wird. Wenn die App bei der Größenänderung nicht dynamisch umgebrochen wird, kann mit den F12-Entwicklertools der Grund bestimmt und mit dem DOM experimentiert werden, um herauszufinden, was für den gewünschten dynamischen Umbruch erforderlich ist.
Hinzufügen von Funktionalität zur UWP-App
Mit einer grundlegenden gehosteten Webanwendung zur Hand untersuche ich nun im Detail die Funktionsmöglichkeiten der Webanwendung, um einige UWP-APIs zu aktivieren und die Benutzerumgebung zu optimieren. Webanwendungen in Intranets können Einschränkungen aufweisen, die gehostete Webanwendungen nicht haben. Mithilfe der UWP-APIs kann eine gehostete Webanwendung Zugriff auf zahlreiche lokale Funktionen des UWP-Geräts erlangen (z. B. Kamera, Positionsbestimmungs- und andere Sensoren). Denken wir zunächst an die Anwendungsfälle, die die Implementierung der Webanwendung als gehostete Webanwendung vorantreiben. In der App Gotcha möchte ich, dass Benutzer in ihren Kontakten eine Wahl treffen können, wer eine Anerkennung erhalten soll, anstatt bloß den Namen der Person einzugeben und ein Bild an die Anerkennung anzufügen.
Zunächst erstelle ich die Remotecodedatei „GotchaNative.js“ für die Webanwendung (die Skriptdatei „GotchaNative.js“ wird sich auf dem Remoteserver mit der Webanwendung befinden), die die nativen API-Namespaces ermittelt und den entsprechenden Code ausführt, um unsere nativen Anwendungsfälle auszulösen. Fügen Sie der Datei „NativeGotcha.js code“ den folgenden Code hinzu:
var GotchaNative = (function () {
if (typeof Windows != 'undefined') {
// Add find contact here
// Add capture photo here
}});
Dieser Code dient zum Erstellen des „GotchaNative“-Objekts, das die gesamte Funktionalität der UWP-APIs enthält. Das Zentralisieren dieser APIs ermöglicht eine einzelne einzuschließende Datei auf Seiten mit hinzugefügter UWP-API-Funktionalität. Ich isoliere diese Datei, damit ich Inhalts-URIs explizit deklarieren kann, die diese spezifische Datei als URIs mit Zugriff auf die benötigten UWP-APIs einschließen. Auf diese Weise kann ich das Sicherheitskonzept der geringsten Rechte umsetzen und die Berechtigung nur URIs erteilen, die Zugriff auf die UWP-APIs brauchen.
Ein weiterer Vorteil der Isolierung dieser Datei ist die Vorbereitung auch für andere native Plattformen. Darauf werde ich in diesem Artikel noch weiter eingehen, doch betrachten Sie diese Datei für den Moment als den Ausgangspunkt sämtlicher nativer Funktionalität, die in die Webanwendung Gotcha einbezogen wird.
Erweitern bestehender Funktionalität
Nachdem ich das „GotchaNative“-Objekt erstellt habe, kann ich die spezifische Funktionalität hinzufügen, um eine Verbindung der gehosteten Webanwendung mit den UWP-APIs herzustellen. Beim ersten Anwendungsfall ermöglicht die Web-App Gotcha Benutzern die Eingabe einer Person, der Anerkennung gezollt werden soll. Auf der UWP haben Benutzer die App „Personen“, die zum Speichern von Kontakten dient. Es wäre wesentlich einfacher für den Benutzer, den Namen der Person auszuwählen statt ihn einzugeben. Ersetzen Sie den Kommentar „Add find contact here“ in der Codedatei „GotchaNative.js“ durch Folgendes:
this.FindContact = function () {
var picker = new Windows.ApplicationModel.Contacts.ContactPicker();
picker.desiredFieldsWithContactFieldType.append(
Windows.ApplicationModel.Contacts.ContactFieldType.email);
return picker.pickContactAsync();
}
Dieser Code dient als Basisverbindung mit der „ContactPicker“-API, um in der Liste der Kontakte einen Kontakt auszuwählen. Eine Liste von UWP-APIs zum Andocken an Web-HWAs finden Sie auf „rjs.azureWebsites.net“. Diese Website enthält einige beliebte APIs mit kopier- und einfügefähigem Code zur Unterstützung des Erstellens eines Web-HWA-Projekts.
Die Funktionalität zum Hinzufügen einer Person finden Sie im Person View Model für die Gotcha-Website. Fügen Sie den Code in Abbildung 5 zum Person View Model hinzu.
Abbildung 5: Dem Person View Model hinzuzufügender Code
if (Windows != undefined) {
var nativeGotcha = new NativeGotcha();
nativeGotcha.FindContact().done(function (contact) {
if (contact !== null) {
$("#txtWho").val(contact.displayName);
} else {
// Write out no contact selected
}
});
}
else {
$('#add-person').on('shown.bs.modal', function () {
$("#txtWho").focus();
}
Der Code in Abbildung 5 verwendet die „FindContact“-Methode, wenn das „Windows“-Objekt mithilfe eines Skripts definiert wird, das als HWA ausgeführt wird. Wenn das „Windows“-Objekt nicht definiert ist, nutzt die Webanwendung weiter das vorhandene modale „Bootstrap“-Fenster zum Erfassen von Informationen der Person, der Anerkennung zuteilwerden soll. Dieser Code ermöglicht der Webanwendung das Befolgen eines Ansatzes zum Eingeben einer Person, der Anerkennung zuteilwerden soll, während die UWP-App einen anderen, angepassteren Ansatz für den Benutzer nutzen kann.
Hinzufügen neuer Funktionalität
Mitunter erlaubt das Aktivieren der UWP-APIs neue Funktionalität, die es normalerweise in der Webanwendung nicht gibt. In der gehosteten Webanwendung Gotcha möchte ich den Benutzern ermöglichen, Fotos zu machen und diese Fotos zwecks Ausdrücken von Anerkennung an andere Gotcha-Benutzer zu senden. Diese Funktionalität wäre neu für die Anwendung und ist in der Webanwendung nicht gegeben. Prüfen Sie beim Erstellen einer gehosteten Webanwendung die Chancen, die sich dank der UWP-APIs für die App eröffnen.
Zum Implementieren dieser neuen Funktionalität ersetze ich zuerst in der Codedatei „GotchaNative.js“ den Kommentar „Add capture photo“ durch Folgendes:
this.CapturePicture = function () {
var captureUI = new Windows.Media.Capture.CameraCaptureUI();
captureUI.photoSettings.format =
Windows.Media.Capture.CameraCaptureUIPhotoFormat.png;
return captureUI.captureFileAsync(
Windows.Media.Capture.CameraCaptureUIMode.photo);
}
In diesem Code öffne ich die Oberfläche zum Schießen des Fotos, erlaube dem Benutzer, ein Foto zu machen, und gebe das Foto anschließend an den Aufrufer zurück. Dieses neue Feature muss für die Webanwendung aktiviert werden, wenn das „Windows“-Objekt definiert ist. Unter Verwendung derselben Ermittlung von Features wie beim Person View Model füge ich den Code in Abbildung 6 dem Home View Model hinzu, in dem sich der Code zum Hinzufügen der Anerkennung befindet.
Abbildung 6: Code zur Ermittlung von Features, der dem Home View Model hinzugefügt werden soll
$('#give-modal').on('shown.bs.modal', function () {
if (typeof Windows != 'undefined') {
var gotchaNative = new NativeGotcha();
$("#btnCamera").click(function () {
gotchaNative.CapturePicture().then(function (capturedItem) {
// Do something with capturedItem;
});
}).show();
}
else {
$("#btnCamera").hide();
}
})
Im Code in Abbildung 6 blende ich „btnCamera“ aus, wenn das „Windows“-Objekt nicht definiert ist. Wenn das „Windows“-Objekt nicht definiert ist, konfiguriere ich das „click“-Ereignis so, dass die „CapturePicture“-Funktion ausgelöst wird. Der Kürze halber habe ich einen Kommentar dazu belassen, was mit dem Foto zu tun ist. Beim Aktivieren der Kamera muss ich im Hinterkopf behalten, dass diese gehostete Webanwendung immer noch eine UWP-App ist und dass die Webcamfunktion für die App aktiviert werden muss, was in der Paketmanifestdatei erfolgen kann.
Webanwendungen für Unternehmen können in gehostete Webanwendungen umgewandelt werden und die UWP-APIs aus dem Windows Store nutzen. Das Verwenden vorhandener Webanwendungen erleichtert das Erstellen von UWP-Apps im Windows Store, doch für gehostete Webanwendungen wird eine Internetverbindung vorausgesetzt. Als Nächste zeige ich Ihnen, wie Sie eine App erstellen, die auch ohne Internetzugriff funktioniert.
Offline verbinden
Die UWP-App kann über lokale Dateien verfügen, die eine Offline- oder lokale Umgebung bieten. Mithilfe lokaler Inhalte können Sie einige der UWP-API-Aufrufe von der gehosteten Webanwendung trennen. Wie die Ermittlung von Features, die bereits erfolgt ist, kann das Verbinden mit lokalen Inhalten über das Aktivieren von Links erfolgen. Für Gotcha füge ich ein Zuordnungsfeature hinzu, das die Steuerelemente der lokalen Zuordnung verwendet.
In der gehosteten Webanwendung kann ich dieselbe Ermittlung von Features nutzen, die zuvor beim Home View Model verwendet wurde. Das Verwenden des richtigen URI-Schemas ermöglicht der gehosteten Webanwendung das Springen zwischen dem Webinhalt und lokalen Inhalt. Auf der Startseite kann ich den folgenden Link hinzufügen:
<a href="ms-appx:///default.html" id="lnkMap">
<span class="glyphicon glyphicon-map-marker"> </span> Show Map
</a>
Der Link stellt eine Verbindung mit dem Schema „ms-appx:///“ her, das der Anwendung das Verbinden mit lokalem Inhalt innerhalb des Anwendungspaket ermöglicht. Beim Arbeiten im Schema „ms-appx“ kann die App sich mit den benötigten UWP-APIs verbinden. Dies ist vergleichbar mit dem Verwenden der Inhalts-URIs zum Deklarieren, welchen Zugriffsgrad eine Seite für den Zugriff auf APIs hat. Das Verwenden von „ms-appx“ entspricht dem Markieren des URI als „All“. In diesem Fall hat die Seite „default.html“ Zugriff auf die UWP-APIs. Wenn der Link in der gehosteten Webanwendung angezeigt wird, können Benutzer darauf klicken, damit dieser im App-Paket verarbeitet wird.
Entwicklern in Unternehmen ermöglicht dieses Feature die Isolierung von Anwendungsfällen, die spezifisch für die UWP und nicht unbedingt mit der Webanwendung verbunden sind. Das Verbinden mit Paketinhalten kann Ihnen auch ermöglichen, das Bereitstellen von Zugriff auf die UWP-APIs für die Webanwendung zu vermeiden und diesen gesamten Zugriff im Paket zu belassen.
Was spricht für mehr als einen Store?
Je nach Unternehmen liegt eine BYOD-Umgebung (Bring Your Own Device) vor. Dies bedeutet, dass ein Unternehmen ggf. in vorhandenen Apps iOS- und Android-Geräte als Ziele definiert hat. Android- und iOS-Apps bietet mit gehosteten Webanwendungen vergleichbare Konzepte in Form des Steuerelements „WebView“. WebView ermöglicht Entwicklern das Bereitstellen eines Fensters innerhalb ihrer App für eine vorhandene Webanwendung und die anschließende Interaktion mit dieser Web-App, als wäre sie Teil der nativen App (klingt das vertraut?). Gehostete Webanwendungen können für ein Zusammenspiel mit anderen entwickelt werden, wobei die Funktionalität einer vorhandenen Web-App an die Plattform angepasst wird, die die Web-App bereitstellt. Als Nächstes ändere ich „GotchaNative.js“ so, dass Android unterstützt wird, und zeige, wie HWA-Code parallel mit JavaScript-Code existieren kann, der andere Zielplattformen hat.
Zuvor habe ich die Datei „GotchaNative.js“ eingerichtet, die sämtlichen nativen Code in der App enthält. Die „ViewModels“ verarbeiten die Ausgabe dieser nativen Methoden. Das Verwenden von APIs auf einer beliebigen Plattform ist ähnlich wie bei gehosteten Webanwendungen: Zunächst muss die App bestimmen, ob die nativen APIs verfügbar sind, und dann die entsprechende API aufrufen. Zunächst füge ich „GotchaNative.js“ eine Eigenschaft hinzu, die mich informiert, welche native Plattform (sofern vorhanden) erkannt wird. In den folgenden Beispiele nehme ich an, dass die Android-App eine „WebView“ verwendet, die „Android“ als lokalen Skriptnamespace deklariert:
this.Platform = function () {
if (Windows != 'undefined')
return "Windows";
else if (Android != 'undefined')
return "Android";
else
return "Web";
}
Diese Funktion ermöglicht meinem Code das Bestimmen, mit welcher Plattform er zusammenarbeiten wird, sodass ich den Code und die Antwort an die Plattform anpassen kann. Von hier aus kann jede Methode in „GotchaNative.js“ die Plattform überprüfen, um zu bestimmen, wie fortgefahren werden soll (siehe Abbildung 7).
Abbildung 7: GotchaNative.js – Methoden, die die Plattform überprüfen
this.CapturePicture = function () {
switch (this.Platform()) {
case "Windows":
var captureUI = new Windows.Media.Capture.CameraCaptureUI();
captureUI.photoSettings.format =
Windows.Media.Capture.CameraCaptureUIPhotoFormat.png;
return captureUI.captureFileAsync(
Windows.Media.Capture.CameraCaptureUIMode.photo);
break;
case "Android":
Android.CaptureFile(); // Calls Android code in Native app
break;
default:
return null;
break;
}
In den „ViewModels“ wird dieser Code anschließend so aktualisiert, dass die Plattformerkennung verwendet wird, um zu ermitteln, was mit der Ausgabe der „GotchaNative“-Methoden passieren soll. Es folgt eine Änderung des Ereignisses der Kameraschaltfläche im HomeViewModel:
$("#btnCamera").click(function () {
switch (gotchaNative.Platform()) {
case "Windows":
gotchaNative.CapturePicture().then(function (capturedItem) {
// Do something with capturedItem;
});
break;
case "Android":
// Handle Android output
break;
}
}).show();
Nun da die App mehrere Plattformen unterstützt, verfüge ich über eine zentrale Stelle in meinem Code, von der aus ich die Funktionen für alle Plattformen erweitern kann. Sollte morgen ein neues angesagtes Betriebssystem herauskommen, ist das Entwicklungsteam in der Lage, den Code an die neue Plattform anzupassen.
Zusammenfassung
Entwickler in Unternehmen sehen sich bei ihrer Arbeit zahlreichen Herausforderungen gegenüber. Standardisierte Prozesse und Tools können als Hindernisse für die Implementierung neuer Technologien wie UWP-Apps wahrgenommen werden. Mithilfe von UWP-Brücken können Entwickler in Unternehmen ihre vorhandenen Intranet- oder externen Web-Apps in den Windows Store überführen (entweder in den öffentlichen oder den Windows Store für Unternehmen). Brücken für gehostete Webanwendungen (HWAs) dienen zum Umwandeln einer Web-App in eine plattformübergreifende UWP-App, wobei UWP-APIs zum Optimieren der Benutzererfahrung zum Einsatz kommen.
In diesem Artikel habe ich untersucht, wie eine vorhandene Webanwendung ausgewählt und in eine HWA umgewandelt wird, während UWP-App-spezifische Features wie der Zugriff auf die Kamera und Kontakte hinzugefügt werden. Mithilfe des „ms-appx“-Schemas habe ich gezeigt, wie Sie innerhalb des App-Pakets von Ihrer gehosteten Webanwendung zu lokalen Inhalten springen. Schließlich habe ich erläutert, wie HWAs (mit etwas Planung) unter Berücksichtigung vieler verschiedener Plattformen erstellt werden können, sodass das Unternehmen mit der stetig größer werden Welt von Mobilgeräten Schritt halten kann. Unter Verwendung dieser Techniken können HWAs von den bereits in Webanwendungen erfolgten Investitionen profitieren und Unternehmen helfen, Teil des Windows Store-Ökosystems zu werden.
Tim Kulpist ein erfahrener IT-Architekt aus Baltimore, USA. Er entwickelt Web-, mobile und UWP-Anwendungen, ist Autor, Maler, Vater und wäre gern ein verrückter Professor. Folgen Sie ihm auf Twitter: @seccode oder LinkedIn: linkedin.com/in/timkulp.
Unser Dank gilt dem folgenden technischen Experten bei Microsoft für die Durchsicht dieses Artikels: John-David Dalton und Kiril Seksenov