react native code push
9.0.0
警告
React Native Codepushは新しいアーキテクチャをサポートしません。 0.76から始まるReactネイティブバージョンでこのプラグインを使用するには、新しいアーキテクチャからオプトアウトする必要があります。
注：このREADMEは、プラグインの最新バージョンにのみ関連しています。古いバージョンを使用している場合は、GitHubリポジトリの関連タグに切り替えて、その特定のバージョンのドキュメントを表示してください。
このプラグインは、CodePushサービスのクライアント側の統合を提供し、Reactネイティブアプリに動的な更新エクスペリエンスを簡単に追加できます。
Reactネイティブアプリは、JavaScriptファイルと付随する画像で構成されており、メトロバンドラーによってバンドルされ、プラットフォーム固有のバイナリ（つまり.ipaまたは.apkファイル）の一部として配布されます。アプリがリリースされたら、JavaScriptコード（例：バグ修正の作成、新機能の追加）または画像資産のいずれかを更新するには、バイナリ全体を再コンパイルして再配布する必要があります。あなたは公開しています。
CodePushプラグインは、JavaScriptと画像をCodePushサーバーにリリースする更新と同期し続けることにより、エンドユーザーの前で製品の改善を即座に取得するのに役立ちます。このようにして、アプリはオフラインのモバイルエクスペリエンスの利点と、利用可能になり次第、サイドロードアップデートの「Webのような」敏ility性を獲得します。 win-winです！
エンドユーザーが常にアプリの機能バージョンを持っていることを確認するために、CodePushプラグインは以前のアップデートのコピーを維持するため、クラッシュを含むアップデートを誤ってプッシュする場合、自動的にロールバックできます。このようにして、サーバーにロールバックする機会がある前に、新たなリリースの俊敏性がユーザーがブロックされるようになってしまうことがないので、安心できます。それはwin-win-winです！
注：ネイティブコードにタッチする製品の変更（ AppDelegate.m / MainActivity.javaファイルの変更、新しいプラグインを追加）をCodepushで配布することはできないため、適切なストアを介して更新する必要があります。
私たちは、プラグインの後方互換性を以前のバージョンのReactネイティブと維持するために最善を尽くしますが、プラットフォームの性質とリリース間の壊れた変化の存在により、CodePushの特定のバージョンを使用する必要がある可能性があります使用しているReactネイティブの正確なバージョンをサポートするためのプラグイン。次の表は、どのCodepushプラグインバージョンがそれぞれのReactネイティブバージョンを公式にサポートするかを概説しています。
| ネイティブバージョンを反応する | Codepushバージョンをサポートする |
|---|---|
| <0.14 | サポートされていません |
| v0.14 | v1.3 （導入されたAndroidサポート） |
| V0.15-V0.18 | v1.4-V1.6 （iOSアセットサポートの導入） |
| V0.19-V0.28 | V1.7-V1.17 （Android Assetサポート導入） |
| V0.29-V0.30 | V1.13-V1.17 （RNはネイティブホスティングコードをリファクタリングします） |
| V0.31-V0.33 | V1.14.6-V1.17 （RNはネイティブホスティングコードをリファクタリングします） |
| V0.34-V0.35 | V1.15-V1.17 （RNはネイティブホスティングコードをリファクタリングします） |
| V0.36-V0.39 | V1.16-V1.17 （RNリファクタリング履歴書ハンドラー） |
| V0.40-V0.42 | v1.17 （RNはiOSヘッダーファイルをリファクタリングしました） |
| V0.43-V0.44 | V2.0+ （RNはUimanager依存関係をリファクタリングしました） |
| V0.45 | v3.0+ （RNリファクタリングインスタンスマネージャーコード） |
| V0.46 | V4.0+ （RNはJSバンドルローダーコードをリファクタリングしました） |
| V0.46-V0.53 | v5.1+ （RNはJSモジュールの未使用の登録を削除しました） |
| V0.54-V0.55 | v5.3+ （Android Gradleプラグイン3.x統合） |
| V0.56-V0.58 | v5.4+ （Androidツール用のRNアップグレードバージョン） |
| V0.59 | v5.6+ （RNはJSバンドルローダーコードをリファクタリングしました） |
| V0.60-V0.61 | v6.0+ （RNは自動リンクに移動しました） |
| V0.62-V0.64 | v6.2+ （RN除去されたlivereload） |
| V0.65-V0.70 | v7.0+ （RNがiPhone-Target-versionを更新） |
| V0.71 | V8.0+ （RNはReact-Native-Gradle-Pluginに移動しました） |
注： V5.7.0より低いreact-native-code-pushバージョンは、近い将来に動作を停止します。詳細については、ドキュメントでご覧いただけます。
私たちは新しいRNリリースに対応するために一生懸命努力していますが、時々私たちを壊します。 RNリリースごとにこのチャートを更新して、ユーザーが「公式」サポートが何であるかを確認できるようにします。
React Native Assets System（つまり、 require("./foo.png") Syntaxを使用する）を使用する場合、次のリストは、参照された画像とビデオをCodepushで更新することをサポートするコアコンポーネント（および小道具）のセットを表します。
| 成分 | 小道具 |
|---|---|
Image | source |
MapView.Marker（React-Native-Maps >=O.3.2が必要です） | image |
ProgressViewIOS | progressImage 、 trackImage |
TabBarIOS.Item | icon 、 selectedIcon |
ToolbarAndroid（ネイティブ0.21.0+を反応する） | actions[].icon 、 logo 、 overflowIcon |
Video | source |
次のリストは、静的な画像とビデオ（つまり{ uri: "foo" }セットを表します。
| 成分 | 小道具 |
|---|---|
SliderIOS | maximumTrackImage 、 minimumTrackImage 、 thumbImage 、 trackImage |
Video | source |
資産の参照をサポートする新しいコアコンポーネントがリリースされると、このリストを更新して、ユーザーがCodePushを使用して更新することが期待できることを確認します。
注：codepushは、ソースプロップでrequire使用する場合にのみビデオコンポーネントで動作します。例えば：
< Video source = { require ( "./foo.mp4" ) } / > CodePushアカウントを設定するための汎用の「Getgent Getering」という手順に従えば、アプリのルートディレクトリ内から次のコマンドを実行してReactネイティブアプリのCodePushを開始できます。
npm install --save react-native-code-push他のすべてのReactネイティブプラグインと同様に、統合エクスペリエンスはiOSとAndroidで異なるため、ターゲットを絞っているプラットフォームに応じて、次のセットアップ手順を実行します。注意してください。両方のプラットフォームをターゲットにしている場合は、各プラットフォームに個別のCodePushアプリケーションを作成することをお勧めします。
他のプロジェクトがCodepushとどのように統合されているかを確認したい場合は、コミュニティが提供する優れたサンプルアプリをご覧ください。さらに、Codepush + React Nativeにすばやく慣れたい場合は、Bilal BudhaniやDeepak Sisodiyaが作成した素晴らしい開始ビデオをチェックできます。
注：このガイドは、 react-native init Commandを使用してReactネイティブプロジェクトを初期化したことを前提としています。 2017年3月の時点で、コマンドcreate-react-native-app使用して、Reactネイティブプロジェクトを初期化することもできます。このコマンドを使用している場合は、 npm run ejectプロジェクトのホームディレクトリで排出して、 react-native initが作成したものと非常によく似たプロジェクトを取得してください。
次に、ネイティブモジュールのインストールを続けます
CodePushプラグインがダウンロードされリンクされ、CodePushに適切なJSバンドルを入手する場所を尋ねるアプリを使用すると、残っている唯一のことは、次のポリシーを制御するために必要なコードをアプリに追加することです。
更新をチェックするのはいつですか？ （たとえば、APPの開始、設定ページのボタンをクリックすることに応じて、定期的に固定インターバルで定期的に）
更新が利用可能なとき、エンドユーザーにそれを提示する方法は？
これを行う最も簡単な方法は、アプリのルートコンポーネントを「Codepush-fify」することです。これを行うには、次の2つのオプションのいずれかを選択できます。
オプション1：ルートコンポーネントをcodePush高次コンポーネントで包みます。
クラスコンポーネント用
import codePush from "react-native-code-push" ;
class MyApp extends Component {
}
MyApp = codePush ( MyApp ) ;機能成分用
import codePush from "react-native-code-push" ;
let MyApp : ( ) => React$Node = ( ) => {
}
MyApp = codePush ( MyApp ) ;オプション2：ES7デコレーターの構文を使用します。
注：デコレーターは、提案の保留中のバベル6.xでまだサポートされていません。 Babel-PreSet-React-Native-Stage-0をインストールおよび使用することにより、有効にする必要がある場合があります。
クラスコンポーネント用
import codePush from "react-native-code-push" ;
@ codePush
class MyApp extends Component {
}機能成分用
import codePush from "react-native-code-push" ;
const MyApp : ( ) => React$Node = ( ) => {
}
export default codePush ( MyApp ) ;デフォルトでは、CodePushはすべてのアプリの開始の更新をチェックします。アップデートが利用可能な場合、それは静かにダウンロードされ、次にアプリが再起動されるときにインストールされます（エンドユーザーまたはOSによって明示的に）。これにより、エンドユーザーにとって最も侵襲的なエクスペリエンスが保証されます。利用可能な更新が必須である場合、すぐにインストールされ、エンドユーザーができるだけ早くそれを取得できるようにします。
アプリに更新をより迅速に見つけたい場合は、アプリがバックグラウンドから再開するたびにCodePushサーバーと同期することもできます。
クラスコンポーネント用
let codePushOptions = { checkFrequency : codePush . CheckFrequency . ON_APP_RESUME } ;
class MyApp extends Component {
}
MyApp = codePush ( codePushOptions ) ( MyApp ) ;機能成分用
let codePushOptions = { checkFrequency : codePush . CheckFrequency . ON_APP_RESUME } ;
let MyApp : ( ) => React$Node = ( ) => {
}
MyApp = codePush ( codePushOptions ) ( MyApp ) ;または、チェックがいつ発生したか（ボタンプレスやタイマー間隔など）を細かく制御したい場合は、希望のSyncOptionsを使用していつでもCodePush.sync()呼び出し、オプションでCodepushの自動チェックを指定してオフにすることができます。マニュアル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 ) ;更新確認ダイアログ（「アクティブインストール」）を表示する場合は、利用可能な更新がインストールされている場合（Forceの即時再起動など）、または更新エクスペリエンスを他の方法でカスタマイズする場合は、 codePush() APIリファレンスを参照してください。このデフォルトの動作を調整する方法については。
注：ReduxおよびRedux Sagaを使用している場合は、React-Native-Code-Push-Sagaモジュールを使用することもできます。これにより、 syncおそらくよりシンプル/よりイディオマティックな方法で呼び出されたときにカスタマイズできます。
Android Google PlayとiOS App Storeには、アプリケーション内にCodePushソリューションを統合する前に、注意する必要があるルールがある対応するガイドラインがあります。
デバイスとネットワーク乱用のトピックの3番目の段落は、Google Playの更新メカニズム以外の方法でソースコードを更新することが制限されていることを説明しています。しかし、この制限はJavaScriptバンドルの更新には適用されません。
この制限は、仮想マシンで実行され、Android APIへのアクセスが制限されているコードには適用されません（WebViewまたはブラウザのJavaScriptなど）。
JSバンドルだけを更新し、ネイティブコードパーツを更新できないため、CodePushが完全に可能になります。
パラグラフ3.3.2 、2015年のApple Developer Programライセンス契約は、JavaScriptとAssetsのオーバーザエアアップデートを完全に実行することを許可しました。
解釈されたコードはアプリケーションにダウンロードされる場合がありますが、そのようなコードのようにのみです。（a）アプリに提出されたアプリケーションの意図および宣伝されている目的と矛盾する機能または機能を提供することにより、アプリケーションの主要な目的を変更しません。ストア、（b）他のコードまたはアプリケーション用のストアまたはストアフロントを作成しないでください。（c）OSの署名、サンドボックス、またはその他のセキュリティ機能をバイパスしません。
CodePushを使用すると、プッシュする更新が元のApp Store承認の意図から製品を大幅に逸脱していない限り、これらのルールを完全にコンプライアンスして従うことができます。
Appleのガイドラインをさらに順守するために、App Storeレビューガイドラインでは次のように書かれているため、App Store-Sistributedアプリはsync呼び出すときにupdateDialogオプションを有効にしないことをお勧めします。
アプリは、アプリの機能、コンテンツ、または使用にアクセスするために、ユーザーにアプリの評価、アプリのレビュー、その他のアプリ、またはその他の同様のアクションをダウンロードするように強制してはなりません。
ユーザーが新しいバージョンをダウンロードすることは強制されないため、これは必ずしもupdateDialogの場合はそうではありませんが、少なくとも表示することにした場合は、その判決に注意する必要があります。
アプリがユーザーに設定されて配布され、JSまたはアセットの変更が行われたら、リリースする時が来ました。それらをリリースする推奨される方法は、App Center CLIでrelease-reactコマンドを使用することです。これにより、JavaScriptファイル、アセットファイルをバンドルし、CodePushサーバーに更新をリリースします。
注：更新のリリースを開始する前に、 appcenter loginコマンドを実行してアプリセンターにログインしてください。
最も基本的な形式では、このコマンドには1つのパラメーターのみが必要です。所有者名 + "/" +アプリ名。
appcenter codepush release-react -a < ownerName > / < appName >
appcenter codepush release-react -a < ownerName > /MyApp-iOS
appcenter codepush release-react -a < ownerName > /MyApp-Android release-reactコマンドは、iOSのアプリのエントリファイルがindex.ios.jsまたはindex.jsのいずれかであると仮定して、リリースバンドルを生成するなど、多くの賢明なデフォルトを提供するため、このような単純なワークフローを有効にします。ただし、これらのデフォルトはすべてカスタマイズして、必要に応じて増分柔軟性を可能にするため、ほとんどのシナリオに適しています。
# 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 "
CodePushクライアントは差分アップデートをサポートしているため、すべてのアップデートでJSバンドルとアセットをリリースしている場合でも、エンドユーザーは実際に必要なファイルのみをダウンロードします。このサービスはこれを自動的に処理して、素晴らしいアプリの作成に集中し、エンドユーザーのダウンロードを最適化することを心配することができます。
release-reactコマンドの仕組みの詳細と、それが公開するさまざまなパラメーターについては、CLIドキュメントを参照してください。さらに、 react-native bundleコマンドの実行を自分で実行したい場合、したがって、 release-reactよりもさらに柔軟なソリューションが必要な場合は、詳細についてはreleaseコマンドを参照してください。
問題に遭遇した場合、または質問/コメント/フィードバックがある場合は、ReactIFLUXの＃Code-Pushチャンネル内で私たちをping、電子メールで送信するか、以下のトラブルシューティングの詳細を確認できます。
注：CodePushの更新は、デバッグモード以外のモードでテストする必要があります。デバッグモードでは、Reactネイティブアプリは常にPackagerによって生成されたJSバンドルをダウンロードするため、CodePushによってダウンロードされたJSバンドルは適用されません。
Getting Docsでは、特定の展開キーを使用してCodePushプラグインを構成する方法を示しました。ただし、リリースを効果的にテストするためには、CodePushアプリ（または作成したカスタム展開）を最初に作成したときに自動生成されるStagingとProduction展開を活用することが重要です。このようにして、自分自身を検証できなかったという更新をエンドユーザーにリリースすることはありません。
注：クライアント側のロールバック機能は、クラッシュをもたらすリリースをインストールした後にユーザーのブロックを解除するのに役立ち、サーバー側のロールバック（つまり、 appcenter codepush rollback ）により、追加のユーザーが識別されると、追加のユーザーが悪いリリースをインストールできないようにします。ただし、誤った更新がそもそも広くリリースされるのを防ぐことができれば、明らかに優れています。
StagingとProduction展開を利用することで、次のようなワークフローを実現できます（カスタマイズしてください！）：
appcenter codepush release-reactコマンド（またはより詳細なコントロールが必要な場合はappcenter codepush release ）を使用して、 Staging展開にCodePushアップデートをリリースします）
アプリのステージング/ベータビルドを実行し、サーバーから更新を同期し、予想どおりに機能することを確認します
appcenter codepush promoteコマンドを使用して、 StagingからProductionまでのテストされたリリースを促進する
アプリの制作/リリースビルドを実行し、サーバーから更新を同期し、予想どおりに機能することを確認します
注：より慎重なアプローチを取りたい場合は、＃3の一部として「ステージロールアウト」を実行することもできます。可能なデバイス/条件？）ユーザーの割合で制作アップデートのみを使用できるようにすることにより（たとえば、 appcenter codepush promote -a <ownerName>/<appName> -s Staging -d Production -r 20 ）。次に、クラッシュレポートや顧客のフィードバックが入っているかどうかを確認するために合理的な時間を待った後、 appcenter codepush patch -a <ownerName>/<appName> Production -r 100実行することで、視聴者全体に拡張できます。
上記の手順は、アプリの「ステージングビルド」と「生産ビルド」を指していることに気付くでしょう。ビルドプロセスが既に「環境」ごとに異なるバイナリを生成している場合、CodePush展開キーを交換することは、アプリ（Facebookなど）の他のサービスの環境固有の構成を処理するようなものであるため、これ以上読む必要はありません。ただし、これに対応するためにビルドプロセスをセットアップする方法に関する例（デモプロジェクトを含む）を探している場合は、アプリがターゲットにしているプラットフォームに応じて、次のセクションを参照してください。
上記のセクションでは、複数のCodePush展開を活用して、アップデートを効果的にテストしてから、エンドユーザーに広くリリースする方法を示しました。ただし、そのワークフローは展開割り当てを実際のバイナリに静的に埋め込むため、ステージングまたは生産ビルドはその展開からの更新のみを同期するだけです。多くの場合、チーム、顧客、利害関係者などのみを望んでいるため、これは十分です。したがって、ステージングと同期する方法を知っているビルドが必要です。ただし、A/Bテストを実行したり、特定のユーザーにアプリを早期にアクセスできるようにしたい場合は、実行時に特定のユーザー（または視聴者）を特定の展開に動的に配置できることが非常に便利です。
この種のワークフローを達成するために、必要なのは、 codePushメソッドを呼び出すときに現在のユーザーに統合したい展開キーを指定することだけです。指定すると、このキーは、アプリのInfo.plist （iOS）またはMainActivity.java （android）ファイルで提供された「デフォルト」のキーをオーバーライドします。これにより、ステージングまたは制作用のビルドを作成できます。これは、必要に応じて動的に「リダイレクト」することもできます。
// 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 } ) ;その変更が整った状態で、現在のユーザーの適切な展開キーをアプリがどのように決定するかを選択するだけの問題です。実際には、通常、これには2つのソリューションがあります。
いつでも展開を変更するためのユーザー可視メカニズムを公開します。たとえば、設定ページには、「ベータ」アクセスを有効にするためのトグルがあります。このモデルは、プリプロダクションの更新のプライバシーに関心がない場合に適切に機能し、以前の（および潜在的にバグのある）更新を自分の意志でオプトインしたいパワーユーザーがいます（Chromeチャンネルのようなものです）。ただし、このソリューションは決定をユーザーの手に委ねるため、A/Bテストを透過的に実行するのに役立ちません。
ユーザーのサーバー側のプロファイルに、同期する展開を示す追加のメタデータをユーザーに注釈します。デフォルトでは、アプリはバイナリ埋め込まれたキーを使用するだけですが、ユーザーが認証された後、サーバーはそれらを別の展開に「リダイレクト」することを選択できます。 。サーバーの応答をローカルストレージに保存して、新しいデフォルトになるように選択することもできます。ユーザーのプロファイルと一緒にキーを保存する方法は、完全に認証ソリューション（Auth0、Firebase、Custom DB + REST APIなど）に完全に依存していますが、一般的にはかなり些細なことです。
注：必要に応じて、エンドユーザーが異なる展開を切り替えることができるハイブリッドソリューションを実装し、サーバーがその決定をオーバーライドできるようにすることもできます。このように、あなたはあなたのアプリがすぐにすぐに更新することができるようにする「展開解決」の階層を持っています、あなたのエンドユーザーはビットに早期にアクセスすることで報酬を感じることができますが、あなたは必要に応じてユーザーにA/Bテストを実行します。
前のセクションで説明したように、アップデートのプレリリーステストのためにStaging展開を使用することをお勧めしますが、早期に許可するのではなく、ユーザーにA/Bテストを実行するために使用することは必要ありません。アクセス（上記のオプション＃1で説明されているように）。したがって、ユーザーをセグメント化できるように、カスタムアプリの展開を最大限に活用することをお勧めします。ただし、ニーズには理にかなっています。たとえば、長期的または1回限りの展開を作成し、アプリのバリアントをリリースしてから、特定のユーザーがどのように関与するかを確認するために特定のユーザーを配置できます。
// #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注：展開の「インストールメトリック」で報告されているユーザー数の合計は、ある展開から別の展開に「切り替えた」ユーザーを考慮します。たとえば、 Production展開が現在1人のユーザーを持っていると報告しているが、そのユーザーをStagingに動的に切り替えると、 Production展開は合計ユーザーが0個を報告し、 Staging 1（切り替えたばかりのユーザー）を報告します。この動作により、ランタイムベースの展開リダイレクトソリューションを使用した場合でも、リリースの採用を正確に追跡できます。
React Native Communityは、開始している開発者の例として役立ついくつかの素晴らしいオープンソースアプリを丁寧に作成しました。以下は、Codepushを使用しているOSS Reactネイティブアプリのリストであるため、他の人がサービスを使用している方法を確認するために使用できます。
さらに、React Native + Codepushを始めたい場合は、素晴らしいスターターキットを探している場合は、以下をチェックしてください。
注：CodePushを使用してReactネイティブアプリを開発した場合は、オープンソースでもある場合は、お知らせください。このリストに追加したいと思います！
sync方法には、すぐに診断される診断ログが含まれているため、使用するときに問題に遭遇した場合、最初に試してみるのに最適なことは、アプリの出力ログを調べることです。これにより、アプリが正しく構成されているかどうか（プラグインが展開キーを見つけることができますか？）、アプリがサーバーに到達できる場合、利用可能な更新が発見されている場合、更新が正常にダウンロード/インストールされている場合、など。ロギングを可能な限り直感的/包括的に改善し続けたいので、混乱している、または何かが欠けていることがわかった場合はお知らせください。
これらのログを表示する最も簡単な方法は、各コマンドのフラグ--debugを追加することです。これにより、CodePushメッセージのみにフィルタリングされたログストリームが出力されます。これにより、プラットフォーム固有のツールを使用することなく、または潜在的に大量のログを介してWADEを使用することなく、問題を簡単に識別できます。
さらに、プラットフォーム固有のツールを使用して、CodePushログをより快適にする場合は、CodePushログを表示することもできます。 Chrome DevToolsコンソール、Xcodeコンソール（iOS）、OS Xコンソール（iOS）および/またはADB LogCat（Android）を簡単に起動し、 [CodePush]が付いたメッセージを探します。
デフォルトでは、リリースビルドのiOSでReactネイティブログが無効になっているため、リリースビルドでそれらを表示する場合は、 AppDelegate.mファイルに次の変更を行う必要があります。
#import <React/RCTLog.h>ステートメントを追加します。 rn <v0.40の使用： #import "RCTLog.h"
次のステートメントをapplication:didFinishLaunchingWithOptions
RCTSetLogThreshold (RCTLogLevelInfo);これで、iOSまたはAndroidの両方で、デバッグモードまたはリリースモードでCodePushログを表示できるようになりました。ログを調べることが問題を示していない場合は、追加の解決のアイデアについては、次の一般的な問題を参照してください。
| 問題 /症状 | 可能な解決策 |
|---|---|
| コンパイルエラー | React Nativeのバージョンが使用しているCodepushバージョンと互換性があることを再確認します。 |
ネットワークタイムアウト /呼び出したときにsyncを呼び出すとき、またはiOSシミュレーターのcheckForUpdate | Simulator -> Reset Content and Settings..を選択して、メニュー項目を選択して、シミュレーターをリセットしてから、アプリを再実行してください。 |
サーバーは、 syncまたはcheckForUpdate呼び出すときに404で応答します | Info.plist （ios）、 build.gradle （android）、またはsync / checkForUpdateに渡される展開キーが実際に正しいことを再確認します。 appcenter codepush deployment list <ownerName>/<appName> --displayKeys実行して、アプリの展開の正しいキーを表示できます。 |
| 発見されていない更新 | 実行中のアプリのバージョン（ 1.0.0など）が、CodePushの更新をリリースするときに指定したバージョンと一致することを再確認します。さらに、アプリが同期するように構成されているのと同じ展開にリリースされていることを確認してください。 |
| 再起動後に表示されない更新 | [ルートコンポーネントのcomponentDidMount内など）でsyncを呼び出していない場合は、App StartでnotifyApplicationReady明示的に呼び出す必要があります。 |
| iOSのアップデートをリリースしましたが、Androidアプリも更新を表示し、それが破損します | 更新を正しく受信するために、各プラットフォームに異なる展開キーがあることを確認してください |
| 新しい更新をリリースしましたが、変更は反映されていません | デバッグ以外のモードでアプリを実行していることを確認してください。デバッグモードでは、Reactネイティブアプリは常にPackagerによって生成されたJSバンドルをダウンロードするため、CodePushによってダウンロードされたJSバンドルは適用されません。 |
| iOSシミュレーターに対してアプリを実行するときにJSバンドルは見つかりません | デフォルトでは、React Nativeはシミュレーターに対して実行するときにJSバンドルを生成しません。したがって、 [CodePush bundleURL]使用し、iOSシミュレーターをターゲットにしている場合は、結果nil得ることができます。この問題は、RN 0.22.0で修正されますが、リリースビルドのみです。この変更をローカルにすることで、このシナリオのブロックを解除できます。 |
Codepush CLIを使用して更新を「手動で」リリースすることができることに加えて、アプリにアップデートを連続して配信するために、再現可能で持続可能なソリューションを作成することが重要であると考えています。そうすれば、あなたやあなたのチームがアジャイル展開を実行するリズムを作成して維持するのに十分簡単です。 CodepushベースのCDパイプラインのセットアップを支援するために、さまざまなCIサーバーとの次の統合を参照してください。
さらに、CodePushを含む完全なモバイルCI/CDワークフローがどのように見えるかについての詳細が必要な場合は、Zeemee Engineeringチームによるこの優れた記事をご覧ください。
このモジュールは、NPMパッケージの一部としてその*.d.tsファイルを出荷します。これにより、単純にimport 、サポートエディター（Visual Studio Codeなど）のIntelliSenseを受け取ることができます。 TypeScriptを使用します。ほとんどの場合、この動作は箱から出して作業する必要がありますが、 tsconfig.jsonファイルのtargetまたはmoduleコンパイラオプションの値としてes6指定した場合は、その場合は、設定してください。 nodeへのmoduleResolutionオプション。これにより、TypeScriptコンパイラは、インポートされたモジュールのタイプ定義のnode_modules内を見ることができます。それ以外の場合、 react-native-code-pushモジュールをインポートしようとすると、次のようなエラーが表示されます。 error TS2307: Cannot find module 'react-native-code-push' 。
このプロジェクトは、Microsoftのオープンソース行動規範を採用しています。詳細については、FAQのコードを参照するか、追加の質問やコメントについては[email protected]にお問い合わせください。
