react native code push
9.0.0
Warnung
React Native Codepush unterstützt keine neue Architektur. Um dieses Plugin für native React -Versionen ab 0,76 zu verwenden, müssen Sie sich von der neuen Architektur abmelden.
Hinweis: Diese Readme ist nur für die neueste Version unseres Plugins relevant. Wenn Sie eine ältere Version verwenden, wechseln Sie bitte zum entsprechenden Tag in unserem Github -Repo, um die Dokumente für diese bestimmte Version anzuzeigen.
Dieses Plugin bietet eine clientseitige Integration für den Codepush-Dienst, mit dem Sie Ihren nativen React-App (en) problemlos ein dynamisches Update-Erlebnis hinzufügen können.
Eine reag-native App besteht aus JavaScript-Dateien und allen begleitenden Bildern, die vom Metro-Bundler zusammengefasst und als Teil einer plattformspezifischen Binärdatei (dh an .ipa oder .apk Datei) verteilt werden. Sobald die App veröffentlicht wurde, müssen Sie entweder den JavaScript -Code (z. B. Making -Fehler -Fixes, Hinzufügen neuer Funktionen) oder Bildvermögen benötigen, und müssen Sie die gesamte Binärdatei neu kompilieren und neu verteilt, was natürlich alle Überprüfungszeiten enthält, die mit dem Geschäft verbunden sind (en). Sie veröffentlichen zu.
Das Codepush -Plugin hilft sofort, Produktverbesserungen vor Ihren Endbenutzern zu erhalten, indem Ihr JavaScript und die Bilder mit den Aktualisierungen synchronisiert werden, die Sie auf dem Codepush -Server veröffentlichen. Auf diese Weise erhält Ihre App die Vorteile eines mobilen Offline-Erlebnisses sowie die "webartige" Agilität von Nebenladungs-Updates, sobald sie verfügbar sind. Es ist eine Win-Win-Situation!
Um sicherzustellen, dass Ihre Endbenutzer immer über eine funktionierende Version Ihrer App verfügen, verwaltet das Codepush -Plugin eine Kopie des vorherigen Updates, sodass Sie versehentlich ein Update beschreiben, das einen Absturz enthält, automatisch zurückrollen kann. Auf diese Weise können Sie sicher sein, dass Ihre neu entdeckte Release -Agilität nicht dazu führt, dass Benutzer blockiert werden, bevor Sie die Möglichkeit haben, auf dem Server zurückzurollen. Es ist eine Win-Win-Situation!
Hinweis: Alle Produktänderungen, die nativen Code berühren (z. B. Änderungen Ihrer AppDelegate.m / MainActivity.java -Datei, ein neues Plugin hinzuzufügen) kann nicht über Codepush verteilt werden und müssen daher über die entsprechenden Speicher aktualisiert werden.
Wir versuchen unser Bestes, um die Kompatibilität unseres Plugins mit früheren Versionen von React Native rückwärts zu halten. Aufgrund der Art der Plattform und der Existenz von Veränderungen zwischen den Freisetzungen ist jedoch möglich, dass Sie eine bestimmte Version des Codepush verwenden müssen Plugin Um die genaue Version von React Native zu unterstützen, die Sie verwenden. Die folgende Tabelle beschreibt, welche Codepush -Plugin -Versionen offiziell die jeweiligen React Native -Versionen unterstützen:
| Reagieren Sie native Version (en) | Unterstützende Codepush -Version (en) |
|---|---|
| <0,14 | Nicht unterstützt |
| v0.14 | v1.3 (eingeführte Android -Unterstützung) |
| V0.15-V0.18 | V1.4-V1.6 (Einführung von iOS-Asset-Unterstützung) |
| V0.19-V0.28 | V1.7-V1.17 (Einführung von Android Asset Support) |
| V0.29-V0.30 | V1.13-V1.17 (RN Refactored Native Hosting-Code) |
| V0.31-V0.33 | V1.14.6-V1.17 (RN Refactored Native Hosting-Code) |
| V0.34-V0.35 | V1.15-V1.17 (RN Refactored Native Hosting-Code) |
| V0.36-V0.39 | V1.16-V1.17 (RN Refactored Lebenslauf-Handler) |
| V0.40-V0.42 | v1.17 (RN refactored iOS -Header -Dateien) |
| V0.43-V0.44 | v2.0+ (RN refactored Uimanager -Abhängigkeiten) |
| v0.45 | v3.0+ (RN refactored Instance Manager Code) |
| v0.46 | v4.0+ (RN refactored JS Bundle Loader Code) |
| V0.46-V0.53 | v5.1+ (RN hat die nicht verwendete Registrierung von JS -Modulen entfernt) |
| V0.54-V0.55 | v5.3+ (Android Gradle Plugin 3.x Integration) |
| V0.56-V0.58 | v5.4+ (RN verbesserte Versionen für Android -Tools) |
| v0.59 | v5.6+ (RN refactored JS Bundle Loader Code) |
| V0.60-V0.61 | v6.0+ (RN migrierte auf Autolinking) |
| V0.62-V0.64 | V6.2+ (RN entfernte Leberoad) |
| V0.65-V0.70 | v7.0+ (RN aktualisiert iPhone-Target-Version) |
| v0.71 | V8.0+ (RN bewegte sich auf React-nativ-Gradle-Plugin) |
Hinweis: react-native-code-push -Versionen, die niedriger als V5.7.0, wird in naher Zukunft aufhören zu arbeiten. Weitere Informationen finden Sie in unserer Dokumentation.
Wir arbeiten hart daran, auf neue RN -Veröffentlichungen zu reagieren, aber sie brechen uns gelegentlich. Wir werden dieses Diagramm mit jeder RN -Version aktualisieren, damit Benutzer überprüfen können, was unsere "offizielle" Unterstützung ist.
Bei der Verwendung des reag nativen Assets -Systems (dh der Verwendung der Syntax require("./foo.png") ) repräsentiert die folgende Liste den Satz von Kernkomponenten (und Requisiten), die die referenzierten Bilder und Videos über Codepush aktualisieren:
| Komponente | Requisiten) |
|---|---|
Image | source |
MapView.Marker(Erfordert React-Native-Maps >=O.3.2 ) | image |
ProgressViewIOS | progressImage , trackImage |
TabBarIOS.Item | icon , selectedIcon |
ToolbarAndroid(React Native 0,21.0+) | actions[].icon , logo , overflowIcon |
Video | source |
Die folgende Liste stellt den Satz von Komponenten (und Requisiten) dar, die aufgrund ihrer Abhängigkeit von statischen Bildern und Videos (dh unter Verwendung der { uri: "foo" } -Syntax), die derzeit nicht über Codepush aktualisiert werden, nicht unterstützen.
| Komponente | Requisiten) |
|---|---|
SliderIOS | maximumTrackImage , minimumTrackImage , thumbImage , trackImage |
Video | source |
Wenn neue Kernkomponenten veröffentlicht werden, die die Referenzierung von Assets unterstützen, aktualisieren wir diese Liste, um sicherzustellen, dass Benutzer wissen, was genau sie mit Codepush erwarten können.
HINWEIS: Codepush funktioniert nur mit Videokomponenten, wenn sie in der Quellpropie require . Zum Beispiel:
< Video source = { require ( "./foo.mp4" ) } / > Sobald Sie die Anweisungen "Erste Schritte" für die Einrichtung Ihres Codepush-Kontos "Erste Schritte" befolgt haben, können Sie die Codepush-Identifizierung Ihrer nativen React-App starten, indem Sie den folgenden Befehl aus dem Root-Verzeichnis Ihrer App ausführen:
npm install --save react-native-code-pushWie bei allen anderen React -Plugins unterscheidet sich die Integrationserfahrung für iOS und Android. Führen Sie daher die folgenden Setup -Schritte aus, je nachdem, welche Plattform (en) Sie abzielen. Beachten Sie, dass bei beiden Plattformen empfohlen wird, separate Codepush -Anwendungen für jede Plattform zu erstellen.
Wenn Sie sehen möchten, wie andere Projekte in Codepush integriert sind, können Sie sich die hervorragenden Beispiel -Apps der Community ansehen. Wenn Sie sich schnell mit Codepush + React Native vertraut machen möchten, können Sie sich die fantastischen Erste -Start -Videos ansehen, die von Bilal Budhani und/oder Deepak Sisodiya produziert werden.
HINWEIS: In dieser Anleitung wird davon ausgegangen, dass Sie den Befehl react-native init verwendet haben, um Ihr React Native-Projekt zu initialisieren. Bis März 2017 kann der Befehl create-react-native-app auch verwendet werden, um ein React Native-Projekt zu initialisieren. Wenn Sie diesen Befehl verwenden, führen Sie bitte npm run eject im Heimverzeichnis Ihres Projekts aus, um ein Projekt zu erhalten, das dem react-native init sehr ähnlich ist.
Fahren Sie dann mit der Installation des nativen Moduls fort
Wenn das Codepush -Plugin heruntergeladen und verknüpft ist und Ihre App Codepush, wohin Sie das richtige JS -Bundle erhalten können, ist das einzige, was übrig ist, das erforderliche Code zu Ihrer App hinzuzufügen, um die folgenden Richtlinien zu steuern:
Wann (und wie oft) nach einem Update zu überprüfen? (Zum Beispiel die App Starten Sie als Antwort auf das Klicken auf eine Schaltfläche auf einer Einstellungsseite, regelmäßig in einem festen Intervall)
Wie können Sie es dem Endbenutzer vorstellen, wenn ein Update verfügbar ist?
Der einfachste Weg, dies zu tun, besteht darin, die Root-Komponente Ihrer App "Codepush zu iifieren". Dazu können Sie eine der folgenden zwei Optionen auswählen:
Option 1: Wickeln Sie Ihre Root-Komponente mit der codePush Komponente höherer Ordnung ein:
Für Klassenkomponente
import codePush from "react-native-code-push" ;
class MyApp extends Component {
}
MyApp = codePush ( MyApp ) ;Für funktionale Komponente
import codePush from "react-native-code-push" ;
let MyApp : ( ) => React$Node = ( ) => {
}
MyApp = codePush ( MyApp ) ;Option 2: Verwenden Sie die ES7 -Dekorationssyntax:
Hinweis: Dekorateure werden in Babel 6.x noch nicht unterstützt. Möglicherweise müssen Sie es aktivieren, indem Sie Babel-Preset-React-Native-Stufe-0 installieren und verwenden.
Für Klassenkomponente
import codePush from "react-native-code-push" ;
@ codePush
class MyApp extends Component {
}Für funktionale Komponente
import codePush from "react-native-code-push" ;
const MyApp : ( ) => React$Node = ( ) => {
}
export default codePush ( MyApp ) ;Standardmäßig prüft Codepush nach Updates für jeden App -Start. Wenn ein Update verfügbar ist, wird es stillschweigend heruntergeladen und beim nächsten Neustart der App (entweder explizit vom Endbenutzer oder vom Betriebssystem) installiert, was die am wenigsten invasive Erfahrung für Ihre Endbenutzer gewährleistet. Wenn ein verfügbares Update obligatorisch ist, wird es sofort installiert, um sicherzustellen, dass der Endbenutzer es so schnell wie möglich erhält.
Wenn Sie möchten, dass Ihre App Updates schneller entdeckt, können Sie sich bei jedem Wiederaufleben der App auch mit dem Codepush -Server aus dem Hintergrund synchronisieren.
Für Klassenkomponente
let codePushOptions = { checkFrequency : codePush . CheckFrequency . ON_APP_RESUME } ;
class MyApp extends Component {
}
MyApp = codePush ( codePushOptions ) ( MyApp ) ;Für funktionale Komponente
let codePushOptions = { checkFrequency : codePush . CheckFrequency . ON_APP_RESUME } ;
let MyApp : ( ) => React$Node = ( ) => {
}
MyApp = codePush ( codePushOptions ) ( MyApp ) ; Alternativ können Sie mit Ihren gewünschten SyncOptions die feinkörnige Kontrolle über die Überprüfung (wie ein Taste Drücken Sie oder ein Timerintervall) aufrufen und die automatische Überprüfung von CodePush.sync() optional deaktivieren. Handbuch checkFrequency :
let codePushOptions = { checkFrequency : codePush . CheckFrequency . MANUAL } ;
class MyApp extends Component {
onButtonPress ( ) {
codePush . sync ( {
updateDialog : true ,
installMode : codePush . InstallMode . IMMEDIATE
} ) ;
}
render ( ) {
return (
< View >
< TouchableOpacity onPress = { this . onButtonPress } >
< Text > Check for updates < / Text >
< / TouchableOpacity >
< / View >
)
}
}
MyApp = codePush ( codePushOptions ) ( MyApp ) ; Wenn Sie ein Dialogfeld zur Aktualisierungsbestätigung (eine "aktive Installation") anzeigen möchten, konfigurieren Sie, wann ein verfügbares Update installiert ist (wie ein sofortiger Neustart) oder die Update -Erfahrung auf andere Weise anpassen, unter codePush() API -Referenz Informationen zum Optimieren dieses Standardverhaltens.
HINWEIS: Wenn Sie Redux- und Redux-Saga verwenden, können Sie das React-nativ-Code-Push-Saga-Modul alternativ verwenden, mit dem Sie anpassen können, wenn sync möglicherweise einfacher/idiomatischer ist.
Android Google Play und iOS App Store verfügen über entsprechende Richtlinien, die Regeln haben, die Sie vor der Integration der Codepush -Lösung in Ihre Anwendung integrieren sollten.
Der dritte Absatz von Geräte- und Netzwerkmissbrauchsthema Beschreiben Sie, dass das Aktualisieren von Quellcode mit einer anderen Methode als dem Aktualisierungsmechanismus von Google Play eingeschränkt ist. Diese Einschränkung gilt jedoch nicht für die Aktualisierung von JavaScript -Bündeln.
Diese Einschränkung gilt nicht für Code, der in einer virtuellen Maschine ausgeführt wird und nur einen begrenzten Zugriff auf Android -APIs hat (z. B. JavaScript in einem Webview oder Browser).
Dadurch können Sie Codepush, da es nur JS -Bundles aktualisiert, vollständig und kann den nativen Code -Teil nicht aktualisieren.
Absatz 3.3.2 , seitdem die Apple Developer-Programmlizenzvereinbarung von 2015 die Durchführung von JavaScript- und Vermögenswerten im Auge die Durchführung von Over-Air-Updates-und in seiner neuesten Version (20170605) hier ist diese Entscheidung noch breiter:
Interpretierter Code kann in eine Anwendung heruntergeladen werden, jedoch nur so lange, wie Code: (a) nicht den Hauptzweck der Anwendung ändert, indem Funktionen oder Funktionen bereitgestellt werden, die mit dem beabsichtigten und beworbenen Zweck der Anwendung nicht übereinstimmen, wie sie der App übermittelt wurde Store, (b) erstellt kein Geschäft oder Storefront für andere Code oder Anwendungen, und (c) umgeht weder die Unterzeichnung, Sandbox oder andere Sicherheitsfunktionen des Betriebssystems.
Mit Codepush können Sie diese Regeln in vollem Umfang befolgen, solange das von Ihnen Push -Update Ihr Produkt nicht wesentlich von der ursprünglichen App Store genehmigten Absicht wesentlich abweist.
Um weiter zu bleiben, werden die Richtlinien von Apple weiterhin vorgeschlagen, dass Apps mit App Store-verteilten Apps die Option updateDialog beim Aufrufen sync nicht aktivieren, da in den App-Store-Überprüfungsrichtlinien geschrieben wurde, dass:
Apps dürfen Benutzer nicht zwingen, die App zu bewerten, die App zu überprüfen, andere Apps oder andere ähnliche Aktionen herunterzuladen, um auf Funktionen, Inhalte oder die Verwendung der App zuzugreifen.
Dies ist nicht unbedingt der Fall für updateDialog , da er den Benutzer nicht zum Herunterladen der neuen Version zwingt. Zumindest sollten Sie sich dieses Urteils bewusst sein, wenn Sie sich entscheiden, sie anzuzeigen.
Sobald Ihre App konfiguriert und an Ihre Benutzer verteilt ist und Sie einige JS- oder Asset -Änderungen vorgenommen haben, ist es an der Zeit, sie zu veröffentlichen. Die empfohlene Möglichkeit, sie zu veröffentlichen, besteht darin, den Befehl release-react in der App Center CLI zu verwenden, mit dem Ihre JavaScript-Dateien, Asset-Dateien und die Aktualisierung des Codepush-Servers das Update veröffentlicht werden.
Hinweis: Bevor Sie mit der Veröffentlichung von Updates beginnen, melden Sie sich bitte in das App Center an, indem Sie den Befehl appcenter login ausführen.
In seiner grundlegendsten Form erfordert dieser Befehl nur einen Parameter: Ihr Besitzername + "/" + App -Name.
appcenter codepush release-react -a < ownerName > / < appName >
appcenter codepush release-react -a < ownerName > /MyApp-iOS
appcenter codepush release-react -a < ownerName > /MyApp-Android Der Befehl release-react ermöglicht einen so einfachen Workflow, da er viele vernünftige Standardeinstellungen bietet (z. B. das Generieren eines Release-Bundle, vorausgesetzt, die Eintragsdatei Ihrer App auf iOS ist entweder index.ios.js oder index.js ). Alle diese Standardeinstellungen können jedoch angepasst werden, um bei Bedarf eine inkrementelle Flexibilität zu ermöglichen, was es für die meisten Szenarien gut geeignet ist.
# Release a mandatory update with a changelog
appcenter codepush release-react -a < ownerName > /MyApp-iOS -m --description " Modified the header color "
# Release an update for an app that uses a non-standard entry file name, and also capture
# the sourcemap file generated by react-native bundle
appcenter codepush release-react -a < ownerName > /MyApp-iOS --entry-file MyApp.js --sourcemap-output ../maps/MyApp.map
# Release a dev Android build to just 1/4 of your end users
appcenter codepush release-react -a < ownerName > /MyApp-Android --rollout 25 --development true
# Release an update that targets users running any 1.1.* binary, as opposed to
# limiting the update to exact version name in the build.gradle file
appcenter codepush release-react -a < ownerName > /MyApp-Android --target-binary-version " ~1.1.0 "
Der Codepush -Client unterstützt unterschiedliche Updates. Auch wenn Sie Ihr JS -Bundle und Ihre Assets für jedes Update veröffentlichen, laden Ihre Endbenutzer nur die benötigten Dateien herunter. Der Service übernimmt dies automatisch, damit Sie sich darauf konzentrieren können, fantastische Apps zu erstellen, und wir können uns Sorgen um die Optimierung des Endbenutzers machen.
Weitere Informationen darüber, wie der Befehl release-react funktioniert, sowie die verschiedenen Parameter, die er enthüllt, finden Sie in den Cli-Dokumenten. Wenn Sie es vorziehen möchten, den Befehl react-native bundle selbst auszuführen und daher eine noch flexiblere Lösung als release-react zu wünschen, finden Sie im Befehl release für weitere Details.
Wenn Sie auf Probleme stoßen oder Fragen/Kommentare/Feedback haben, können Sie uns im #Code-Push-Kanal auf Reactiflux, E-Mail an uns und/oder die folgenden Fehlerbehebungsdaten an.
Hinweis: Codepush -Updates sollten in anderen Modi als dem Debug -Modus getestet werden. Im Debug -Modus lädt die von Packager generierte React Native App immer das von Packager generierte JS -Bundle herunter, sodass JS -Bundle von Codepush heruntergeladen wird.
In unseren Erste -Start -Dokumenten haben wir veranschaulicht, wie das Codepush -Plugin mithilfe eines bestimmten Bereitstellungsschlüssels konfiguriert wird. Um Ihre Veröffentlichungen effektiv zu testen, ist es jedoch wichtig, dass Sie die Staging und Production nutzen, die automatisch generiert werden, wenn Sie Ihre Codepush-App (oder alle benutzerdefinierten Bereitstellungen, die Sie möglicherweise erstellt haben) erstellt haben. Auf diese Weise veröffentlichen Sie nie ein Update für Ihre Endbenutzer, das Sie nicht selbst validieren konnten.
HINWEIS: Unsere clientseitige Rollback-Funktion kann die Benutzer nach der Installation einer Version, die zu einem Absturz führte, und serverseitige Rollbacks (IE appcenter codepush rollback ) dabei helfen, zu verhindern, dass zusätzliche Benutzer eine schlechte Version installieren, sobald sie identifiziert wurde. Es ist jedoch offensichtlich besser, wenn Sie verhindern können, dass ein fehlerhaftes Update in erster Linie weitgehend freigegeben wird.
Durch die Nutzung der Staging und Production können Sie einen Workflow wie das Folgende erreichen (können Sie gerne anpassen!):
Veröffentlichen Sie ein Codepush-Update für Ihre Staging Bereitstellung mit dem Befehl appcenter codepush release-react (oder appcenter codepush release wenn Sie mehr Steuerung benötigen).
Führen Sie Ihren Staging/Beta -Build Ihrer App aus, synchronisieren Sie das Update vom Server und überprüfen Sie, ob sie wie erwartet funktioniert
Werben Sie die getestete Version von Staging bis zur Production mit dem Befehl appcenter codepush promote
Führen Sie Ihren Produktions-/Release -Build Ihrer App aus, synchronisieren Sie das Update vom Server und überprüfen Sie, ob es wie erwartet funktioniert
Hinweis: Wenn Sie einen vorsichtigen Ansatz verfolgen möchten, können Sie sogar einen "inszenierten Rollout" als Teil von 3 durchführen, mit dem Sie das zusätzliche potenzielle Risiko mit dem Update mindern können (wie Ihre Tests in #2 Touch All durch Mögliche Geräte/Bedingungen?), indem Sie das Produktions -Update nur einem Prozentsatz Ihrer Benutzer zur Verfügung stellen (z appcenter codepush promote -a <ownerName>/<appName> -s Staging -d Production -r 20 Nachdem Sie auf eine angemessene Zeit gewartet haben, um festzustellen, ob Crash -Berichte oder Kundenfeedback eingehen, können Sie es auf Ihr gesamtes Publikum erweitern, indem Sie appcenter codepush patch -a <ownerName>/<appName> Production -r 100 ausführen.
Sie werden feststellen, dass sich die obigen Schritte auf einen "Staging -Build" und "Produktion Build" Ihrer App beziehen. Wenn Ihr Build-Prozess bereits unterschiedliche Binärdateien pro "Umgebung" generiert, müssen Sie keine weiter lesen, da das Austausch von Codepush-Bereitstellungsschlüssel genau wie die Umgebungskonfiguration für die Umgebung für jeden anderen Dienst ist, den Ihre App verwendet (wie Facebook). Wenn Sie jedoch nach Beispielen ( einschließlich Demo -Projekten ) suchen, wie Sie Ihren Build -Prozess einrichten, um dies zu berücksichtigen, verweisen Sie je nach Plattform (n) die folgenden Abschnitte, abhängig von der Plattform (n) Ihre App zielt darauf ab:
Der obige Abschnitt hat gezeigt, wie Sie mehrere Codepush -Bereitstellungen nutzen können, um Ihre Updates effektiv zu testen, bevor Sie sie breit an Ihre Endbenutzer weitergeben. Da dieser Workflow jedoch die Bereitstellungszuweisung in die tatsächliche Binärdatum einbettet, wird ein Staging oder eine Produktionsaufstellung immer nur Aktualisierungen dieser Bereitstellung synchronisieren. In vielen Fällen ist dies ausreichend, da Sie nur möchten, dass Ihr Team, Kunden, Stakeholder usw. mit Ihren Vorproduktionsveröffentlichungen synchronisiert wird, und daher benötigen sie nur einen Build, der weiß, wie man mit der Inszenierung synchronisiert. Wenn Sie jedoch in der Lage sein möchten, A/B -Tests durchzuführen oder bestimmte Benutzer einen frühen Zugriff auf Ihre App zu gewähren, kann es sich als sehr nützlich erweisen, bestimmte Benutzer (oder Publikum) dynamisch zur Laufzeit in bestimmte Bereitstellungen einzubeziehen.
Um diese Art von Workflow zu erreichen, müssen Sie lediglich den Bereitstellungsschlüssel angeben, mit dem der aktuelle Benutzer beim Aufrufen der codePush -Methode synchronisiert wird. Bei der Angabe wird dieser Schlüssel das "Standard" -Dateien der Info.plist (iOS) oder MainActivity.java (Android) überschreiben. Auf diese Weise können Sie einen Build für Staging oder Produktion herstellen, der bei Bedarf dynamisch "umgeleitet" werden kann.
// Imagine that "userProfile" is a prop that this component received
// which includes the deployment key that the current user should use.
codePush . sync ( { deploymentKey : userProfile . CODEPUSH_KEY } ) ;Mit dieser Änderung ist es jetzt nur noch eine Frage der Auswahl, wie Ihre App den richtigen Bereitstellungsschlüssel für den aktuellen Benutzer bestimmt. In der Praxis gibt es hier in der Regel zwei Lösungen:
Stellen Sie einen benutzerfreundlichen Mechanismus für die Änderung der Bereitstellungen jederzeit auf. Beispielsweise kann Ihre Einstellungsseite einen Umschalter für die Aktivierung von "Beta" -Access haben. Dieses Modell funktioniert gut, wenn Sie sich nicht mit der Privatsphäre Ihrer Vorproduktions-Updates befassen, und Sie haben Power-Benutzer, die sich möglicherweise für frühere (und potenziell fehlerhafte) Aktualisierungen anmelden möchten (ähnlich wie Chrome-Kanäle wie Chrome-Kanäle ). Diese Lösung stellt jedoch die Entscheidung in die Hände Ihrer Benutzer ein, die Ihnen nicht hilft, A/B -Tests transparent durchzuführen.
Annotieren Sie das serverseitige Profil Ihrer Benutzer mit einem zusätzlichen Stück Metadaten, das die Bereitstellung angibt, mit der sie synchronisieren sollten. Standardmäßig könnte Ihre App nur den Binärbetten-Schlüssel verwenden, aber nachdem ein Benutzer authentifiziert wurde, kann Ihr Server sie zu einer anderen Bereitstellung "umleiten", sodass Sie bestimmte Benutzer oder Gruppen nach Bedarf in schrittweisen Einrichtungen in verschiedene Bereitstellungen platzieren können . Sie können sogar die Serverantwort im lokalen Speicher speichern, damit sie zur neuen Standardeinstellung wird. Wie Sie den Schlüssel neben den Profilen Ihres Benutzers speichern, entspricht ganz Ihrer Authentifizierungslösung (z. B. Auth0, Firebase, benutzerdefinierte DB + REST -API), ist jedoch im Allgemeinen ziemlich trivial.
Hinweis: Bei Bedarf können Sie auch eine hybride Lösung implementieren, mit der Ihre Endbenutzer zwischen verschiedenen Bereitstellungen umschalten und gleichzeitig es Ihrem Server ermöglichten, diese Entscheidung zu überschreiben. Auf diese Weise haben Sie eine Hierarchie der "Bereitstellungsauflösung", die sicherstellt Führen Sie nach Bedarf A/B -Tests für Ihre Benutzer aus.
Da wir empfehlen, die Staging Bereitstellung für die Vorabentests Ihrer Updates zu verwenden (wie im vorherigen Abschnitt erläutert), ist es nicht sinnvoll, sie für die Durchführung von A/B-Tests Ihrer Benutzer zu verwenden, anstatt frühzeitig zuzulassen. Zugriff (wie in Option 1 oben erläutert). Daher empfehlen wir, benutzerdefinierte App -Bereitstellungen vollständig zu nutzen, damit Sie Ihre Benutzer segmentieren können, ist jedoch sinnvoll für Ihre Anforderungen. Sie können beispielsweise langfristige oder sogar einmalige Bereitstellungen erstellen, eine Variante Ihrer App veröffentlichen und dann bestimmte Benutzer in sie einfügen, um zu sehen, wie sie sich engagieren.
// #1) Create your new deployment to hold releases of a specific app variant
appcenter codepush deployment add - a < ownerName > / <appName> test-variant-one
// #2) Target any new releases at that custom deployment
appcenter codepush release - react - a < ownerName > / <appName> -d test-variant-one Hinweis: Die gesamte Benutzerzahl, die in den "Installationsmetriken" Ihrer Bereitstellung gemeldet wird, berücksichtigt Benutzer, die von einer Bereitstellung auf einen anderen "umgeschaltet" sind. Wenn beispielsweise Ihre Production derzeit mit einem Gesamtbenutzer berichtet, diesen Benutzer jedoch dynamisch auf Staging wechseln, würde die Production 0 Gesamtbenutzer melden, während Staging 1 melden würde (der gerade umgeschaltete Benutzer). Mit diesem Verhalten können Sie Ihre Release-Adoption genau verfolgen, selbst wenn Sie eine runtzeitbasierte Umleitungslösung für Bereitstellungen verwenden.
Die React Native Community hat freundlicherweise einige großartige Open -Source -Apps erstellt, die als Beispiele für Entwickler dienen können, die anfangen. Das Folgende ist eine Liste der nativen OSS -Reaktoren, die auch Codepush verwenden und daher verwendet werden können, um zu sehen, wie andere den Dienst verwenden:
Wenn Sie mit React Native + Codepush beginnen und nach einem fantastischen Starter -Kit suchen, sollten Sie sich Folgendes ansehen:
Hinweis: Wenn Sie eine reag-native App mit Codepush entwickelt haben, die auch Open-Source ist, teilen Sie uns dies bitte mit. Wir würden es gerne zu dieser Liste hinzufügen!
Die sync enthält eine Menge diagnostischer Protokollierung außerhalb des Boxs. Wenn Sie also bei der Verwendung auf ein Problem stoßen, ist es das Beste, zuerst die Ausgabeprotokolle Ihrer App zu untersuchen. Auf diese Weise werden Sie angegeben, ob die App korrekt konfiguriert ist (wie kann das Plugin Ihren Bereitstellungsschlüssel finden?). usw. Wir möchten die Protokollierung weiter verbessern, um so intuitiv/umfassend wie möglich zu sein. Bitte teilen Sie uns bitte mit, ob Sie es verwirrend oder verpassen.
Die einfachste Möglichkeit, diese Protokolle anzuzeigen, besteht darin, das Flag --debug für jeden Befehl hinzuzufügen. Dadurch wird ein Protokollstrom ausgegeben, der nur auf Codepush -Nachrichten gefiltert wird. Dies erleichtert es einfach, Probleme zu identifizieren, ohne ein plattformspezifisches Tool zu verwenden oder durch ein potenziell hohes Volumen an Protokollen zu waten.
Darüber hinaus können Sie auch eines der plattformspezifischen Tools verwenden, um die Codepush-Protokolle anzuzeigen, wenn Sie sich mit ihnen wohler fühlen. Einfaches Start der Chrome Devtools -Konsole, der Xcode Console (iOS), der OS X -Konsole (iOS) und/oder ADB -Logcat (Android) und nach Nachrichten suchen, die mit [CodePush] vorangestellt sind.
Beachten Sie, dass die nativen reag nativen Protokolle standardmäßig in iOS in Release -Builds deaktiviert sind. Wenn Sie sie also in einem Release -Build anzeigen möchten, müssen Sie die folgenden Änderungen an Ihrer AppDelegate.m -Datei vornehmen:
Fügen Sie eine #import <React/RCTLog.h> ordnungsgemäß hinzu. Für RN <v0.40 Verwendung: #import "RCTLog.h"
Fügen Sie die folgende Erklärung an die Spitze Ihrer application:didFinishLaunchingWithOptions -Methode:
RCTSetLogThreshold (RCTLogLevelInfo);Jetzt können Sie Codepush -Protokolle entweder im Debug- oder im Release -Modus sowohl im iOS als auch im Android sehen. Wenn die Prüfung der Protokolle keinen Hinweis auf das Problem liefert, finden Sie in den folgenden gängigen Themen für zusätzliche Lösungsideen:
| Problem / Symptom | Mögliche Lösung |
|---|---|
| Kompilierungsfehler | Überprüfen Sie, ob Ihre Version von React Native mit der von Ihnen verwendeten Codepush-Version kompatibel ist. |
Timeout / Hängen von Netzwerk beim Aufrufen sync oder checkForUpdate im iOS -Simulator | Versuchen Sie, den Simulator zurückzusetzen, indem Sie den Simulator -> Reset Content and Settings.. Menüelement .. Menüelement, und dann Ihre App erneut zu veranlassen. |
Der Server antwortet mit einem 404 beim Aufrufen von sync oder checkForUpdate | Überprüfen Sie checkForUpdate ob der sync , build.gradle Sie zu Ihrer Info.plist hinzugefügt haben. Sie können appcenter codepush deployment list <ownerName>/<appName> --displayKeys ausführen, um die richtigen Schlüssel für Ihre App -Bereitstellungen anzuzeigen. |
| Update nicht entdeckt werden | Überprüfen Sie, ob die Version Ihrer laufenden App (wie 1.0.0 ) mit der Version übereinstimmt, die Sie bei der Veröffentlichung des Updates mit Codepush angegeben haben. Stellen Sie außerdem sicher, dass Sie die gleiche Bereitstellung veröffentlichen, mit der Ihre App konfiguriert ist, mit der Sie synchronisiert sind. |
| Update, das nach dem Neustart nicht angezeigt wird | Wenn Sie sync bei App Start nicht aufrufen (wie in componentDidMount Ihrer Stammkomponente), müssen Sie notifyApplicationReady auf dem App -Start explizit aufrufen. Andernfalls wird das Plugin der Meinung, dass Ihr Update fehlgeschlagen ist und es zurückrollt. |
| Ich habe ein Update für iOS veröffentlicht, aber meine Android -App zeigt auch ein Update und es bricht es | Stellen Sie sicher, dass Sie für jede Plattform unterschiedliche Bereitstellungsschlüssel haben, um Aktualisierungen korrekt zu erhalten |
| Ich habe ein neues Update veröffentlicht, aber Änderungen werden nicht reflektiert | Stellen Sie sicher, dass Sie App in anderen Modi als Debugg ausführen. Im Debug -Modus lädt die von Packager generierte React Native App immer das von Packager generierte JS -Bundle herunter, sodass JS -Bundle von Codepush heruntergeladen wird. |
| Beim Ausführen Ihrer App gegen den iOS -Simulator wird kein JS -Bundle gefunden | Standardmäßig erzeugt React Native Ihr JS -Bundle nicht, wenn Sie gegen den Simulator ausgeführt werden. Wenn Sie also [CodePush bundleURL] verwenden und auf den iOS -Simulator abzielen, erhalten Sie möglicherweise ein nil -Ergebnis. Dieses Problem wird in RN 0,22.0 behoben, jedoch nur für Veröffentlichungsbaus. Sie können dieses Szenario jetzt entsperren, indem Sie diese Änderung lokal vornehmen. |
Wir können nicht nur die Codepush -CLI zu "manuell" Release -Updates verwenden, sondern auch für die Erstellung einer wiederholbaren und nachhaltigen Lösung für die Bereitstellung von Updates an Ihre App. Auf diese Weise ist es für Sie und/oder Ihr Team einfach genug, den Rhythmus der Durchführung agiler Bereitstellungen zu erstellen und aufrechtzuerhalten. Um die Einrichtung einer Codepush-basierten CD-Pipeline zu unterstützen, finden Sie die folgenden Integrationen mit verschiedenen CI-Servern:
Wenn Sie mehr Details darüber wünschen, wie ein vollständiger mobiler CI/CD -Workflow aussehen kann, der Codepush enthält, lesen Sie diesen hervorragenden Artikel des Zeemee Engineering -Teams.
Dieses Modul versendet seine *.d.ts Datei als Teil import NPM Verwenden von TypeScript. Dieses Verhalten sollte größtenteils einfach außerhalb des Box funktionieren. Wenn Sie es6 jedoch als Wert für die Option target oder module in Ihrer Datei tsconfig.json angegeben haben, stellen Sie einfach sicher, dass Sie auch die festlegen, dass Sie auch die festlegen moduleResolution zum node . Dadurch wird sichergestellt, dass der Typscript -Compiler in den node_modules nach den Typdefinitionen von importierten Modulen sucht. Andernfalls erhalten Sie einen Fehler wie das folgende, wenn Sie versuchen, das react-native-code-push Modul zu importieren: error TS2307: Cannot find module 'react-native-code-push' .
Dieses Projekt hat den Microsoft Open Source -Verhaltenscode übernommen. Weitere Informationen finden Sie im FAQ oder wenden Sie sich an [email protected] mit zusätzlichen Fragen oder Kommentaren.
