Adobe Edge Inspect CC & Co.

Ratgeber: Remote-Debugging mit Smartphones und Mobile-Plattformen
Kommentare

Bei plattformspezifischen Layouts ist es unverzichtbar, direkt mit Hardware zu entwickeln. Unterschiede zwischen Browserversionen sowie bei mobilen Endgeräten – wie Smartphones, Tablets und bei Desktopbrowsern – sollten nicht immer als vernachlässigbar eingestuft werden. Erkennen lassen sich diese meist erst durch genaues Hinsehen.

Werden mit HTML5 und CSS3 vollwertige Anwendungen erstellt, kommen dabei neben den verschiedenen Displays viele Browsereigenschaften zum Tragen – einschließlich der im Browsersystem verborgenen Shadow-DOM, Browser-Cache oder WebStorage. Sie alle müssen funktionieren, wenn Polifills nur Fallbacklösungen darstellen sollen. Daher sollten entsprechende Debugging-Optionen genutzt werden.

Die Systemeigenschaften eines Browsers können mit der Entwicklerkonsole erfragt werden. Browser auf mobilen Endgeräten stellen jedoch keine eigene Konsole bereit. Via Remote-Debugging ist es dennoch möglich, Systemeigenschaften über die Entwicklerkonsole auszugeben.

Die Nutzung mobiler Browser nimmt in den letzten Jahren stetig zu. Vorreiter sind vor allem Android und iOS, deren Entwickler Browser im Desktop- und im mobilen Bereich bereitstellen. Um die Mobilversion von der Desktopvariante sicher unterscheiden zu können, muss man schon genau unter den jeweiligen Einstellungen nachsehen. Letztlich ist es der User Agent, der vorgibt, was mit einem Browser möglich ist und wie etwas dargestellt wird. Emulatoren und auch Simulatoren können dabei keine hundertprozentige Entsprechung liefern. Ebenso ist es mit bloßem Umstellen des User Agents nicht getan, Eigenschaften eines anderen Browsers zu emulieren. Am Sichersten ist es daher, direkt mit mobilen Hardwaregeräten zu debuggen und zu testen.

Mit den folgenden Tools soll gezeigt werden, dass ein Remote-Debugging mit der Hardware von mobilen Devices problemlos möglich ist.

Adobe Edge Inspect CC

Der Edge Inspect ist im Downloadcenter von Adobe frei downloadbar. Er ist für Webseiten als Standalone-Remote-Debugger nutzbar und wurde zudem von Adobe in die beiden Entwicklertools „Edge Reflow“ und „Edge Code“ integriert. Letzteres ist unter anderem dem Integrieren von Drittanbietern, wie etwa „Weinre“ für die Remote-Datenverbindung, zu verdanken. Das große Gesamtpaket in Form der proprietären Lösungen lässt sich so wesentlich einfacher handhaben als Extensions von unterschiedlichen Anbietern.

Drei, bzw. zur eigentlichen Installation zwei, zusätzliche Entwicklertools sind nötig, um Edge Inspect zum Debuggen zu bringen:

  • Edge Inspect selbst, das auf dem PC zu installieren ist
  • Die Chrome-Extension
  • Ein Mobile-Client, der auf dem zu debuggenden Hardwaregerät benötigt wird

Die Links zu den Tools bekommt man bequem über das Adobe-Downloadcenter.

Sind diese Tools installiert, kann die Verbindung zwischen PC und Mobile Device hergestellt werden. Zuerst wird Edge Inspect auf dem PC gestartet. Für den Verbindungsaufbau wird verlangt, dass sich beide Geräte im gleichen Netzwerk befinden. Befinden sich die Geräte außerdem noch im gemeinsamen Sub-Netz, kann die Verbindung automatisch gefunden werden. Wenn nicht, muss mit dem Mobile Device der PC anhand der IP-Adresse des PCs gefunden werden, was ebenfalls problemlos durchführbar ist. Der Verbindungsaufbau wird vom Mobile Device aus mit einem erzeugten Passwort angestoßen, das dann in der Chrome-Extension auf dem PC eingegeben werden muss. Nun kann die zu debuggende Seite mit Chrome geöffnet werden. Von der Chrome-Extension aus wird nun die Seite im Mobile Device durch einen abschließenden Klick auf den Button START DEBUGGING („< >“) geöffnet. Gleichzeitig öffnet sich ein neues Browserfenster mit der Entwicklerkonsole des Chrome-Browsers, das die Inhalte des Mobile Devices – wie HTML-Code, Caches, Netzwerkaktivitäten etc. – ausgibt (Abb. 1).

Abb. 1: Mit der Chrome-Extension lässt sich die Ausgabe im Adobe-Browser auf dem Mobile Device fernsteuern

Auffällig ist, dass auf dem Mobile Device nicht Chrome, Firefox oder ein anderer bestehender Browser, sondern ein eigener Browser verwendet wird. Probleme bereitet der Client-Browser jedoch nicht. Er zeigt CSS3-Eigenschaften oder beispielsweise mit @Font-Face, Cufón oder mit Adobe Typekit eingebundene Schriftarten sauber an.

Unterstützt wird das Remote-Debugging für iOS, Android und Kindle Fire. Was aber auch heißt, dass ältere oder abweichende Geräte, für die keine Extension existiert, nicht verwendet werden können.

Für Fragen zur Verwendung von Edge Inspect ist das Edge-Inspect-Team-Blog zu empfehlen. Das Blog gibt eine gute Übersicht, was mit dem Tool alles möglich ist. Außerdem werden dort neue Funktionalitäten sowie Tipps und Tricks announced und kurz beschrieben.

Remote-Debugging via USB und Android

Für den Chrome-Browser stellt Google zur Entwicklung mit Android-Geräten die ADB-Extension (Android Debug Bridge) bereit. Damit lässt sich via USB ein Android-Gerät debuggen. Voraussetzung ist auf dem Mobile Device die Chrome-Version 28 oder höher. Im Gegensatz zum Android-Emulator muss das Android-SDK nicht installiert sein.

Auf dem Mobile Device sind jedoch einige Einstellungen vorzunehmen. Gehen Sie zu EINSTELLUNGEN | ENTWICKLEROPTIONEN und setzen Sie die „Entwickleroptionen“ auf „AN“. Schalten Sie außerdem die Option „USB-Debugging“ ein (Abb. 2).

Abb. 2: Für das Remote-Debugging via USB muss die Einstellung am Gerät aktiviert sein

Was nicht vergessen werden darf, ist die Einstellung der USB-Verbindung zum PC. Zudem darf unter EINSTELLUNGEN |8 SPEICHER | USB-VERBINDUNG (PC) (der Konfigurations-Button mit den drei aufgetürmten Rechtecken oben rechts) „Mediengerät (MTP)“ nicht aktiviert sein (Abb. 3). Bei Android-Geräten ist die Einstellung zur Konfiguration der USB-Verbindung nötig, ob die Verbindung zum Debuggen oder für Filesystemtransaktionen genutzt werden soll. Sollten Sie nach dem Debuggen wieder Mediendaten vom oder zum Gerät senden wollen, müssen Sie daran denken, diese Option vorher wieder einzuschalten.

Sind die Einstellungen gemacht und das USB-Kabel angeschlossen, zeigt das Android-Gerät das mit dem Pop-up-Dialog „USB-Debugging zulassen?“ an, der bestätigt werden muss. Ebenso muss im Chrome-Browser unter EINSTELLUNGEN | ENTWICKLER-TOOLS ein Haken bei „Web-Debugging via USB aktivieren“ gesetzt werden (Abb. 4).

Abb. 3: Für das Debugging muss die Option „Mediengerät (MTP)“ deaktiviert werden

Abb. 4: Im Desktop-Browser wird die Einstellung „Web-Debugging via USB“ aktiviert

Mit der Chrome-Extension auf dem PC wird die ADB gestartet. Das Android-Männchen „Andy“ ist jetzt grün und zeigt die Anzahl der angeschlossenen Geräte an (Abb. 5). Wählt man nun die Option „View Inspection Targets“, können angeschlossene Geräte mit „inspect“ ausgewählt werden.

Abb. 5: Mit der Browser-Extension wird die ADB gestartet und angeschlossene Geräte für das Debuggen ausgewählt

Automatisch wird ein Fenster mit den Entwicklertools geöffnet. Die entsprechende Internetseite öffnet sich auf dem Mobile Device aber nicht automatisch, sondern muss manuell geöffnet werden. PC-Browser und Mobile Device sind jetzt für das Debuggen bereit. Es können allerdings nur Geräte verwendet werden, auf denen Android installiert ist.

Aufmacherbild: Code bug. Software bug hidden inside a binary code von Shutterstock / Urheberrecht: Mircea Maties [ header = Seite 2: Weinre – die browser- und betriebssystemunabhängige Alternative ]

Weinre – die browser- und betriebssystemunabhängige Alternative

Bei den zwei oben genannten Remote-Debugging-Lösungen sind Konfigurationsschritte vor dem Debuggen und zu installierende Komponenten weniger aufwändig und relativ überschaubar. Der Nachteil ist jedoch, dass nicht alle Betriebssystem- und Browserhersteller abgedeckt werden. Sollen Betriebssysteme wie Windows Phone oder Tizen (Linux) oder doch recht weit verbreitete Browser wie Firefox, Internet Explorer, BlackBerry oder Opera Mini eingesetzt werden, muss man sich noch etwas tiefer in die Welt der freien Software wagen und eine betriebssystemunabhängige Installation wie Weinre (WEb INspector REmote) verwenden. Weinre ist ein Remote-Debugger, der über das interne Sub-Netz oder über das Internet mit dem Mobile Device kommuniziert.

Zur Installation des Weinre-Packages wird Node.js sowie die Weinre-JavaScript-Datei target-script-min.js benötigt, die vom FTP-Server als -bin.zip heruntergeladen werden kann. Außerdem ist eine lokale Serverinstallation, z. B. der Apache-Server, der mit XAMPP installiert wird, notwendig. Allerdings ist ein lokaler Server nur unter Mac OS X zu empfehlen – unter Windows gibt es lokal Konflikte bei der Vergabe von Ports. Hier sollte man stattdessen einen Root-Server einsetzen.

Die Kommunikation zwischen Mobile Device und Weinre funktioniert mittels HTTP-Protokoll und XHR (XMLHttpRequest) relativ schnell. Zuerst muss Node.js heruntergeladen und installiert werden. Überprüfen lässt sich die korrekte Installation mit dem Terminal (Mac) bzw. mit der Kommandozeile cmd.exe (Windows):

node --version
npm --version

Die aktuelle Node.js-Installation beinhaltet ebenfalls npm (Node Packaged Modules), was zur Installation von Weinre benötigt wird. Dazu gibt man im Terminal folgenden Befehl ein:

$ sudo npm install -g weinre

bzw. in der Windows-Kommandozeile wäre dies:

npm install weinre

Damit ist Weinre installiert und muss konfiguriert werden, und zwar der „boundHost“. Das geschieht mit dem Aufruf weinre –boundHost -all-.

Nun benötigt man die IP-Adresse des Weinre-Hosts. Bei einer lokalen Installation ist das die IP-Adresse des PCs. Der Weinre-Debug-Client sollte unter dieser IP-Adresse mit der Angabe des Ports 8080 erreichbar sein, z. B. ht tp://192.168.0.10:8080. Öffnet sich daraufhin die Weinre-Seite, ist der Weinre-Debug-Server erreichbar (Abb. 6).

Abb. 6: Der Weinre-Debug-Client zeigt an, dass der Weinre-Server läuft

Von dort bekommt man den Link zum Debug Access Point und zum Target Script angezeigt. Zusätzlich werden Links zur Dokumentation und zu Einstellungen wie der Multi-Target-Anbindung aufgeführt. Das Target Script muss von dort kopiert und auf der zu debuggenden Internetseite eingebunden werden:

<script src="ht tp://192.168.0.10:8080/target/target-script-min.js#anonymous"></script>

Gleichzeitig starten wir unsere Serverinstallation, auf der die zu debuggende Seite abgelegt ist. Wie oben bereits erwähnt, benötigen wir außerdem die JavaScript-Datei selbst, damit der Aufruf der externen Dateireferenz nicht in einem 404-Request endet. Laden Sie dazu das Zip-File mit der Endung -bin.zip vom FTP-Server herunter. Das Script-File liegt im Verzeichnis unter webtargettarget-script-min.js. Um gefunden werden zu können, muss das File im Serververzeichnis an der angegebenen Stelle abgelegt werden, wie es die oben genannte JavaScript-Einbindung vorgibt.

Jetzt können wir auf dem Debug-Host-PC dem Link zum Access Point (in unserem Beispiel ht tp://192.168.0.10:8080/client/#anonymous) folgen und mit dem Mobile Device unsere zu debuggende Seite auf dem Server aufrufen. Der Browser des Access Points zeigt sofort nach dem Aufruf der Seite die IP-Adresse des Mobile Devices (Target) an. Das Fenster des Access Points ist identisch mit dem des oben vorgestellten Adobe Edge Inspect CC. Mit den Menü-Tabs vom Access Point kann die aufgerufene Seite im Mobile Device debugged werden. Unter „Elements“ lassen sich HTML-Code, Style Sheets etc. debuggen, unter „Resources“ der Browser-Cache und unter „Network“ die Netzaktivitäten etc. Was Sie beachten sollten:

  • Zu empfehlen ist Mac OS X als lokale Debugging-Plattform. Lokal unter Windows gibt es Probleme bei der Zuweisung des Weinre-boundHost durch gegenseitiges Blockieren von Ports.
  • Auf jeder Seite, die zum Debug Target übertragen werden soll, muss das JavaScript eingebunden werden. Im Produktiv-Code sollte in jedem Fall das JavaScript wieder entfernt werden.
  • CSS-Quelltexte, die in @Media-Queries stehen, werden nicht mit zum Mobile Device übertragen. @Media-Queries werden beispielsweise in aktuellen WordPress-Themes („Twenty Twelve“, „Twenty Thirteen“) eingesetzt.
  • Mit @Font-Face eingebundene Schriften und Font-Icons sind für Weinre kein Problem.

Fazit

Aktuell ist es möglich, mit allen erdenklichen Browsern und verschiedenen mobilen Betriebssystemen eine Internetseite direkt auf dem Mobile Device zu debuggen. Förderlich ist dabei, dass mehrere verschiedene Entwicklungen nebeneinander bestehen, dass Tools, Browser, Betriebssystem etc. kombiniert werden können und dass trotzdem immer ein geeignetes Debug-Set-up gefunden werden kann.

Beim Remote-Debugging ist zwar gegenüber dem Debuggen einer Desktopseite ein überschaubarer Mehraufwand notwendig, das Ergebnis für mobile Webseiten wird aber besser in seiner Aussagekraft. Das macht sich beispielsweise beim Einsatz von Media-Queries, wie device-pixel-ratio, device-width, High-Resolution, Fluid-Grids, flexiblen Bildern und RESS (Responsive Design plus Server-side Components) bemerkbar. Schließlich soll sich eine mobile Webseite den Gegebenheiten anpassen können, die von Mobile Devices bereitstellt werden.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -