text: Entwicklung browserübergreifender Erweiterungen / Likeastore Blog / Sudo Null IT News
  alexbeletsky 27. Juni 2014 um 15.03 Uhr
  Entwicklung browserübergreifender Erweiterungen
  In meinem letzten Artikel habe ich die Veröffentlichung einer Browser-Erweiterung für Google Chrome erwähnt, mit der die Sucheffizienz gesteigert werden kann, indem relevante Informationen aus Artikeln in sozialen Netzwerken bereitgestellt werden, die Ihnen gefallen.
  Heute unterstützen wir 3 Hauptbrowser: Chrome, Firefox und Safari. Trotz der unterschiedlichen Plattformen werden alle aus einer Codebasis zusammengesetzt. Ich werde Ihnen erzählen, wie dies geschehen ist und wie ich mein Leben durch die Entwicklung von Browser-Erweiterungen vereinfachen kann.
  Alles begann damit, dass ich eine einfache Erweiterung für Chrome erstellt habe. Ich stelle übrigens fest, dass sich die Entwicklung für Chrome als die angenehmste und bequemste erwiesen hat. Insbesondere nach dem lokalen Debuggen habe ich den Inhalt der Erweiterung in .zipden Web Store gepackt und in diesen hochgeladen , ohne mich um die Automatisierung zu kümmern.
  Die Erweiterung wurde von unserer Zielgruppe gut angepasst. Laut Kennzahlen und Nutzerbewertungen ist dies genau das, was wir brauchen. Und da 15% unseres Traffics von Firefox kommt, sollte es der nächste sein.
  Das Wesentliche aller Browsererweiterungen ist dasselbe - dies sind HTML / CSS / JS-Anwendungen mit einer eigenen Manifestdatei, die die Eigenschaften und den Inhalt sowie den Quellcode selbst beschreibt. Daher lautete meine Hauptidee wie folgt: Ich kopiere das Erweiterungs-Repository für Chrome und passe es für Firefox an.
  Während der Arbeit verspürte ich jedoch ein Gefühl der "Schuld" für das Kopieren und Einfügen, das vielen Programmierern vertraut war. Es war offensichtlich, dass 99% des Codes zwischen den Erweiterungen wiederverwendet wurden und die Aussicht auf eine erweiterte Funktionalität, die verschiedene Zweige unterstützt, zu einem Problem werden könnte.
  Es kam vor, dass ich eine ausgezeichnete Octotree- Erweiterung bemerkte (ich empfehle sie allen, die GitHub aktiv nutzen), ich bemerkte einen Fehler darin und beschloss, ihn zu beheben. Als ich das Repository geklont habe und anfing, mich mit dem Inhalt zu befassen, fand ich eine interessante Funktion - alle 3 Octotree-Erweiterungen werden von einem Repository gesammelt. Wie Likeastore ist Octotree eine einfache Inhaltsinjektion und deshalb war ihr Modell auch für mich großartig.
  Ich habe den Erstellungsprozess in Octotree für mein Projekt angepasst und verbessert (der Fehler wurde übrigens auch behoben ) , um zu sehen, was passiert ist.
  Ich werde eine Antragsstruktur vorschlagen, die meiner Meinung nach für Erweiterungen geeignet ist.
  build , dist - automatisch generierte Ordner, in die der Quellcode der Erweiterungen bzw. die verteilungsfertige Anwendung passen.
  css , img , js - Quellcode der Erweiterung.
  Hersteller - plattformspezifischer Code, für jeden Browser ein eigener Ordner.
  Werkzeuge - Werkzeuge, die für die Montage benötigt werden.
  Alles wird von gulp gesammelt, dem "umgedachten" Sammlerprojekt für node.js. Und selbst wenn Sie den Knoten nicht in der Produktion verwenden, empfehle ich dringend, ihn auf Ihrem Computer zu installieren. In der npm-Galaxie werden jetzt viele nützliche Dinge angezeigt.
  Plattformabhängiger Code
  Beginnen wir mit dem Wichtigsten: Wenn Sie ein neues Projekt starten oder ein vorhandenes anpassen möchten, müssen Sie klar verstehen, welche plattformspezifischen Aufrufe erforderlich sind, und das separate Modul hervorheben.
  In meinem Fall gab es nur einen solchen Aufruf - das Abrufen der URL zu der Ressource in der Erweiterung (in meinem Fall zu den Bildern). Daher wurde eine separate Datei, browser.js, hervorgehoben.
  Relevante Versionen für Firefox und Safari .
  In komplexeren Fällen wird browser.js erweitert, um alle erforderlichen Aufrufe zu erfüllen und eine Fassade zwischen Ihrem Code und dem Browser zu bilden.
  Neben der Fassade enthält der plattformspezifische Code Manifeste und Erweiterungseinstellungen. Für Chome ist dies manifest.jsonFirefox main.js+ package.jsonund schließlich Safari, das in der alten Art und Weise .plist-Dateien verwendet - Info.plist, Settings.plist, Update.plist.
  Automatisieren Sie das Bauen mit Schluck
  Die Aufgabe der Assembly besteht darin, die Quellcodedateien des Erweiterungs- und plattformspezifischen Codes in Ordner zu kopieren, deren Struktur vom Browser selbst vorgegeben wird.
  Dazu erstellen Sie 3 Schluckaufgabe,
  Die Standardaufgabe, die alle drei Erweiterungen sammelt,
  Außerdem ist es für die Entwicklung sehr praktisch, wenn sich der Code ändert und gleichzeitig die Montage automatisch durchgeführt wird.
  Die Erweiterung für die Verteilung vorbereiten
  Aber die Assembly selbst ist nicht alles, ich möchte in der Lage sein, die Anwendung in ein Format zu packen, das für die Platzierung im entsprechenden App Store bereit ist )
  Bei Chrome müssen Sie lediglich ein .zipArchiv erstellen, das bereits auf der Seite des Chrome Web Store signiert und überprüft wurde.
  Für Firefox ist es etwas komplizierter: Sie benötigen ein SDK mit dem Tool cfx, mit dem Sie die Erweiterung in eine xpiDatei "umschließen" können .
  Aber mit Safari ist es im Allgemeinen ein "Mist". Sie können die Anwendung nur im .safariextz-Paket in Safari selbst erstellen. Ich habe mehr als eine Stunde gebraucht, um die Anweisung zum Arbeiten zu bringen, aber alles umsonst. Leider ist es jetzt nicht möglich, Ihr Entwicklungszertifikat in ein .p12Format zu exportieren. Daher ist es nicht möglich, die erforderlichen Schlüssel zum Signieren eines Pakets zu erstellen. Safari muss noch manuell gepackt werden, die Verteilungstask wird vereinfacht, um die Update.plist-Datei zu kopieren.
  Der Entwicklungsprozess von einem Repository aus ist einfach und unterhaltsam. Wie bereits erwähnt, ist Chrome für mich die bequemste Entwicklungsumgebung. Alle Änderungen werden dort hinzugefügt und getestet.
  Nachdem alles in Chrome funktioniert, überprüfen Sie Firefox
  Und auch im "manuellen" Modus in Safari.
  Wir beschließen, eine neue Version zu veröffentlichen, die entsprechenden Manifestdateien mit der neuen Version zu aktualisieren und auszuführen
  Als Ergebnis im Ordner / dist, welche Dateien verteilt werden. Es wäre ideal, wenn der App Store eine API hätte, über die Sie die neue Version hochladen können, aber vorerst müssen Sie dies von Hand tun. Alle Details bitte hier .