react native code push
9.0.0
Предупреждение
React Native CodePush не будет поддерживать новую архитектуру. Чтобы использовать этот плагин для нативных версий React, начиная с 0,76, вам нужно будет отказаться от новой архитектуры.
Примечание. Этот README имеет отношение только к последней версии нашего плагина. Если вы используете более старую версию, переключитесь на соответствующий тег в нашем репо Github, чтобы просмотреть документы для этой конкретной версии.
Этот плагин обеспечивает интеграцию на стороне клиента для службы CodePush, что позволяет легко добавить опыт динамического обновления в ваше нативное приложение React.
Нативное приложение React состоит из файлов JavaScript и любых сопровождающих изображений, которые объединены в бондлер Metro и распространяются как часть бинарного файла, специфичной для платформы (то есть файл .ipa или .apk ). Как только приложение будет выпущено, обновление либо кода JavaScript (например, исправление ошибок, добавление новых функций) или активы изображений, требует от переработки и перераспределения всего двоичного файла, которое, конечно, включает в себя любое время обзора, связанное с магазином (ы) Вы публикуете.
Плагин CodePush помогает мгновенно получить улучшения продукта перед вашими конечными пользователями, сохраняя ваш JavaScript и изображения, синхронизированные с обновлениями, которые вы выпускаете на сервере CodePush. Таким образом, ваше приложение получает преимущества автономного мобильного опыта, а также «веб-подобную» ловкость обновлений побочной загрузки, как только они будут доступны. Это беспроигрышный вариант!
Чтобы убедиться, что ваши конечные пользователи всегда имеют функционирующую версию вашего приложения, плагин CodePush сохраняет копию предыдущего обновления, так что в случае, если вы случайно нажимаете обновление, которое включает в себя сбой, он может автоматически откатиться. Таким образом, вы можете быть уверены, что ваша новая гибкость выпуска не приведет к тому, что пользователи будут заблокированы, прежде чем у вас появится шанс вернуться на сервер. Это беспроигрышная победа!
ПРИМЕЧАНИЕ. Любые изменения продукта, которые касаются собственного кода (например, изменяя ваш файл AppDelegate.m / MainActivity.java , добавление нового плагина) не может быть распределен через CodePush, и, следовательно, должен быть обновлен через соответствующий магазин (ы).
Мы изо всех сил стараемся поддерживать обратную совместимость нашего плагина с предыдущими версиями React Nation плагин для поддержки точной версии RACE Native, которую вы используете. В следующей таблице рассказывается, какие версии плагина 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 Refactored Code нативного хостинга) |
| V0.31-V0.33 | v1.14.6-v1.17 (RN Refactored Code Hosting) |
| V0.34-V0.35 | v1.15-v1.17 (RN Refactored Code Hosting) |
| V0.36-V0.39 | v1.16-v1.17 (обработчик RN Refactored Resume) |
| v0.40-v0.42 | v1.17 (RN Refactored Files Files) |
| V0.43-V0.44 | v2.0+ (RN Refactored uimanager -зависимости) |
| v0.45 | v3.0+ (код менеджера по рефакторированию экземпляров RN) |
| v0.46 | v4.0+ (RN Refactoreded JS -код загрузчика) |
| v0.46-v0.53 | v5.1+ (RN удалена неиспользованная регистрация модулей JS) |
| V0.54-V0.55 | v5.3+ (интеграция Android Gradle Plugin 3.x) |
| v0.56-v0.58 | v5.4+ (RN обновленные версии для инструментов Android) |
| v0.59 | v5.6+ (RN Refactoreded JS -код загрузчика) |
| v0.60-v0.61 | v6.0+ (RN мигрировал на автолизование) |
| V0.62-V0.64 | v6.2+ (RN удален Livereleload) |
| v0.65-v0.70 | v7.0+ (RN обновленная iPhone-Target-версия) |
| v0.71 | v8.0+ (RN перенесен в реагирование-родной фрадл-плугин) |
ПРИМЕЧАНИЕ. Версии react-native-code-push ниже, чем v5.7.0, перестанут работать в ближайшем будущем. Вы можете найти больше информации в нашей документации.
Мы усердно работаем, чтобы ответить на новые релизы RN, но они иногда ломают нас. Мы обновим этот график с каждым выпуском RN, чтобы пользователи могли проверить, что такое наша «официальная» поддержка.
При использовании системы Native Assets React (то есть с использованием синтаксиса require("./foo.png") ), в следующем списке представлен набор основных компонентов (и реквизитов), которые поддерживают их ссылочные изображения и видео, обновленные через CodePush:
| Компонент | Реквизит) |
|---|---|
Image | source |
MapView.Marker(Требуется реагировать-коренные карты >=O.3.2 ) | image |
ProgressViewIOS | progressImage , trackImage |
TabBarIOS.Item | icon , selectedIcon |
ToolbarAndroid(Реагировать натив 0,21,0+) | actions[].icon , logo , overflowIcon |
Video | source |
Следующий список представляет набор компонентов (и реквизитов), которые в настоящее время не поддерживают их активы, обновляемые через CodePush, из -за их зависимости от статических изображений и видео (то есть используя { uri: "foo" } синтаксис):
| Компонент | Реквизит) |
|---|---|
SliderIOS | maximumTrackImage , minimumTrackImage , thumbImage , trackImage |
Video | source |
По мере того, как выпущены новые основные компоненты, которые поддерживают ссылки на активы, мы обновим этот список, чтобы пользователи знали, что именно они могут ожидать обновления с помощью CodePush.
ПРИМЕЧАНИЕ. CodePush работает только с видео компонентами при использовании require in Source Prop. Например:
< Video source = { require ( "./foo.mp4" ) } / > После того, как вы следовали инструкциям «Начало начала» общего назначения для настройки учетной записи CodePush, вы можете запустить CodePush, подчиняя свое приложение React Native, выполнив следующую команду из корневого каталога вашего приложения:
npm install --save react-native-code-pushКак и во всех других нативных плагинах React, опыт интеграции отличается для iOS и Android, поэтому выполните следующие шаги настройки в зависимости от того, на какую платформу вы нацелены. Обратите внимание, что если вы нацелены на обе платформы, рекомендуется создавать отдельные приложения CodePush для каждой платформы.
Если вы хотите увидеть, как другие проекты интегрировались с CodePush, вы можете проверить отличные приложения приложения, предоставленные сообществом. Кроме того, если вы хотите быстро познакомиться с CodePush + React Native, вы можете посмотреть потрясающие видео для начала работы, созданные Билал Будхани и/или Дипак Сизодия.
Примечание. В этом руководстве предполагается, что вы использовали команду react-native init для инициализации вашего нативного проекта React. По состоянию на март 2017 года, команда create-react-native-app также может использоваться для инициализации нативного проекта React. Если использовать эту команду, пожалуйста, запустите npm run eject в домашнем каталоге вашего проекта, чтобы получить проект, очень похожий на то, что создал бы react-native init .
Затем продолжить с установкой нативного модуля
С загруженным и связанным плагином CodePush, и вашим приложением спрашивает CodePush, откуда получить правильный пакет JS, единственное, что осталось, - добавить необходимый код в ваше приложение для управления следующими политиками:
Когда (и как часто) проверить на обновление? (Например, приложение запускается, в ответ на нажатие кнопки на странице настроек, периодически с каким -то фиксированным интервалом)
Когда доступно обновление, как представить его конечному пользователю?
Самый простой способ сделать это-«CodePush-ifi-ifive» корневого компонента вашего приложения. Для этого вы можете выбрать один из следующих двух вариантов:
Вариант 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: Используйте синтаксис Decorator ES7:
ПРИМЕЧАНИЕ. Декораторы еще не поддерживаются в Babel 6.x, ожидающем обновления предложения. Возможно, вам понадобится включить его, установив и используя Babel-Preset-React-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 проверит на наличие обновлений каждого запуска приложения. Если обновление доступно, оно будет молча загружено и установлено в следующий раз, когда приложение будет перезагружено (либо явно у конечного пользователя, либо ОС), что обеспечивает наименьший инвазивный опыт для ваших конечных пользователей. Если доступное обновление является обязательным, то оно будет установлено немедленно, гарантируя, что конечный пользователь получит его как можно скорее.
Если вы хотите, чтобы ваше приложение обнаружило обновления быстрее, вы также можете синхронизировать с сервером 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 ) ; В качестве альтернативы, если вы хотите мелкозернистый контроль над тем, когда произойдет проверка (например, нажатие кнопки или интервал таймера), вы можете вызвать CodePush.sync() в любое время с желаемыми SyncOptions и, необязательно отключить автоматическую проверку 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 ) ; Если вы хотите отобразить диалоговое окно подтверждения обновления («активная установка»), настройте, когда установлено доступное обновление (например, принудительно перезагрузка) или настраивать опыт обновления любым другим способом, см codePush() Для получения информации о том, как настроить это поведение по умолчанию.
ПРИМЕЧАНИЕ. Если вы используете Saga Redux и Redux, вы можете альтернативно использовать модуль React-Code-Push-Saga, который позволяет вам настраивать, когда sync , возможно, проще/идиоматическим образом.
Android Google Play и iOS App Store имеют соответствующие руководящие принципы, которые имеют правила, которые вы должны знать, прежде чем интегрировать решение CodePush в вашем приложении.
Третий параграф по вопросам злоупотребления устройствами и сети описывает, что обновление исходного кода любым методом, кроме механизма обновления Google Play, ограничено. Но это ограничение не применяется к обновлению связков JavaScript.
Это ограничение не применяется к коду, который работает в виртуальной машине и имеет ограниченный доступ к API -интерфейсам Android (например, JavaScript в WebView или браузере).
Это полностью разрешает CodePush, когда он обновляется только в пакетах JS и не может обновить собственную кодовую часть.
Пункт 3.3.2 , так как лицензионный соглашение о программе Apple Developer 2015 года полностью разрешено выполнять обновления в эфире JavaScript и активов-и в своей последней версии (20170605).
Интерпретированный код может быть загружен в приложение, но только до такого кода: (a) не меняет основную цель приложения, предоставляя функции или функциональность, которые несовместимы с предполагаемой и рекламируемой целью приложения, как представлено в приложение Хранить, (b) не создает магазин или магазин для других кодов или приложений, и (c) не обходит подписание, песочницу или другие функции безопасности ОС.
CodePush позволяет вам следовать этим правилам в полном соответствии, пока обновление, которое вы нажимаете, не отклоняет ваш продукт от своего первоначального одобренного App Store.
Чтобы дополнительно оставаться в соответствии с руководящими принципами Apple, мы предлагаем, чтобы приложения, распределенные в магазине, не позволяют опции updateDialog при вызове sync , поскольку в Руководстве по обзору App Store это написано, что:
Приложения не должны заставлять пользователей оценивать приложение, просмотреть приложение, загружать другие приложения или другие подобные действия, чтобы получить доступ к функциональности, контенту или использования приложения.
Это не обязательно относится к updateDialog , поскольку он не заставит пользователя загружать новую версию, но, по крайней мере, вы должны знать об этом решении, если решите показать ее.
Как только ваше приложение настроено и распространяется с вашими пользователями, и вы внесли некоторые изменения JS или активы, пришло время их выпустить. Рекомендуемый способ выпустить их-это использование команды release-react в CLI центра приложений, которая будет объединять ваши файлы JavaScript, файлы активов и выпустить обновление на сервер CodePush.
Примечание. Прежде чем вы сможете начать выпускать обновления, войдите в центр приложений, запустив команду appcenter login .
В своей основной форме эта команда требует только одного параметра: имя вашего владельца + "/" + имя приложения.
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 для получения дополнительной информации.
Если вы столкнетесь с любыми проблемами или у вас есть какие-либо вопросы/комментарии/отзывы, вы можете пропитывать нас в канале #-push на Reactiflux, напишите нам и/или проверить приведенные ниже подробности по устранению неполадок.
Примечание. Обновления CodePush должны быть протестированы в режимах, отличных от режима отладки. В режиме отладки React Native App всегда загружает пакет JS, созданный Packager, поэтому JS Bundle, загруженный CodePush, не применяется.
В наших документах по началу работы мы проиллюстрировали, как настроить плагин CodePush, используя конкретный ключ развертывания. Однако для эффективного тестирования ваших выпусков крайне важно, чтобы вы использовали развертывания Staging и Production , которые автоматически генерируются, когда вы впервые создали свое приложение CodePush (или любые пользовательские развертывания, которые вы могли создать). Таким образом, вы никогда не выпускаете обновление своим конечным пользователям, которое вы не смогли проверить себя.
ПРИМЕЧАНИЕ. Наша функция отката на стороне клиента может помочь Unblock пользователей после установки релиза, которое привело к сбою, а откаты на стороне сервера (то есть appcenter codepush rollback ) позволяют вам не дать дополнительным пользователям установить плохой релиз после его идентификации. Однако, очевидно, лучше, если вы сможете предотвратить ошибочное обновление в первую очередь.
Использование преимущества Staging и развертывания Production позволяет вам добиться рабочего процесса, подобного следующему (не стесняйтесь настроить!):
Выпустите обновление CodePush для развертывания Staging , используя команду appcenter codepush release-react (или appcenter codepush release если вам нужно больше управления)
Запустите свою постановку/бета -сборку вашего приложения, синхронизируйте обновление с сервера и убедитесь, что оно работает, как и ожидалось
Продвигайте протестированный выпуск от Staging до Production , используя команду appcenter codepush promote
Запустите свое производственное/выпускное сборку вашего приложения, синхронизируйте обновление с сервера и подтвердите, что оно работает, как и ожидалось
ПРИМЕЧАНИЕ. Если вы хотите использовать более осторожный подход, вы даже можете выполнить «поэтапный развертывание» как часть № 3, что позволяет смягчить дополнительный потенциальный риск с помощью обновления (например, ваше тестирование в #2 касается всех Возможные устройства/условия?) Только сделав обновление производства доступным для процента ваших пользователей (например 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 ) или 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 } ) ;С этим изменением, теперь это просто вопрос выбора того, как ваше приложение определяет правильный ключ развертывания для текущего пользователя. На практике, как правило, есть два решения для этого:
Разместите пользовательский визитный механизм для изменения развертывания в любое время. Например, ваша страница настроек может иметь переключение для обеспечения «бета -бета». Эта модель работает хорошо, если вы не обеспокоены конфиденциальностью ваших предварительных обновлений, и у вас есть энергопотребления, которые могут захотеть выбрать более ранние (и потенциально глючные) обновления в своей собственной воле (вроде хромированных каналов ) Тем не менее, это решение приводит решение в руках ваших пользователей, что не помогает вам прозрачно выполнять A/B -тесты.
Аннотируйте профиль на стороне сервера ваших пользователей дополнительной частью метаданных, что указывает на развертывание, с которым они должны синхронизироваться. По умолчанию ваше приложение может просто использовать клавишу с двойной, но после того, как пользователь провел аутентификацию, ваш сервер может выбрать «перенаправить» их в другое развертывание, что позволяет постепенно размещать определенных пользователей или групп в разные развертывания по мере необходимости Полем Вы даже можете сохранить сервер-ответ в локальном хранилище, чтобы оно стало новым по умолчанию. То, как вы храните ключ вместе с профилями вашего пользователя, полностью зависит от вашего решения для аутентификации (например, Auth0, Firebase, Custom DB + REST API), но, как правило, довольно тривиально.
Примечание. При необходимости вы также можете реализовать гибридное решение, которое позволило вашим конечным пользователям переключаться между различными развертываниями, а также позволяет вашему серверу переопределить это решение. Таким образом, у вас есть иерархия «разрешения развертывания», которая гарантирует, что ваше приложение имеет возможность обновлять себя вне коробки, ваши конечные пользователи могут чувствовать себя вознагражденными, получая ранний доступ к битам, но у вас также есть возможность Запустите A/B -тесты на ваших пользователях по мере необходимости.
Поскольку мы рекомендуем использовать Staging для тестирования ваших обновлений перед выпуском (как объяснено в предыдущем разделе), не обязательно имеет смысл использовать его для выполнения A/B-тестов на ваших пользователях, в отличие от разрешения раннего доступ (как объяснено в варианте № 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 любезно создало несколько потрясающих приложений с открытым исходным кодом, которые могут служить примерами для разработчиков, которые начинаются. Ниже приведен список нативных приложений OSS React, которые также используют CodePush, и поэтому могут использоваться, чтобы увидеть, как другие используют сервис:
Кроме того, если вы хотите начать с React Native + CodePush и ищете потрясающий стартовый комплект, вы должны проверить следующее:
ПРИМЕЧАНИЕ. Если вы разработали нативное приложение React с помощью CodePush, это также открытый исход, пожалуйста, сообщите нам об этом. Мы хотели бы добавить его в этот список!
Метод sync включает в себя множество диагностических журналов из коробки, поэтому, если вы сталкиваетесь с проблемой при использовании, лучше всего попробовать-это изучить выходные журналы вашего приложения. Это скажет вам, правильно ли настроено приложение (например, может ли плагин найти ваш ключ развертывания?), Если приложение может достичь сервера, если обнаружено доступное обновление, если обновление успешно загружается/установлено,, и т. д. Мы хотим продолжать улучшать журналы, чтобы быть максимально понятным/всеобъемлющим, поэтому, пожалуйста, сообщите нам, если вы обнаружите, что это сбивает с толку или что -либо упускает.
Самый простой способ просмотреть эти журналы -добавить флаг --debug для каждой команды. Это выведет поток журнала, который отфильтровано в только сообщения CodePush. Это позволяет легко определить проблемы, без необходимости использовать инструмент для конкретной платформы или проходить через потенциально большой объем журналов.
Кроме того, вы также можете использовать любой из инструментов для конкретной платформы для просмотра журналов CodePush, если вам удобнее с ними. Простой запуск консоли Chrome Devtools, консоли Xcode (iOS), консоли OS X (iOS) и/или LogCat ADB (Android) и ищите сообщения, которые префикс [CodePush] .
Обратите внимание, что по умолчанию нативные журналы React отключены на iOS в сборках выпуска, поэтому, если вы хотите просмотреть их в сборке релиза, вам необходимо внести следующие изменения в свой файл AppDelegate.m :
Добавьте оператор #import <React/RCTLog.h> . Для RN <v0.40 Использование: #import "RCTLog.h"
Добавьте следующее утверждение в верхнюю часть вашего application:didFinishLaunchingWithOptions Метод:
RCTSetLogThreshold (RCTLogLevelInfo);Теперь вы сможете увидеть журналы CodePush в режиме отладки или режима выпуска, как на iOS, так и на Android. Если изучение журналов не дает указания на вопрос, пожалуйста, обратитесь к следующим общим вопросам для дополнительных идей разрешения:
| Проблема / симптом | Возможное решение |
|---|---|
| Ошибка компиляции | Дважды проверьте, что ваша версия React Native совместима с версией CodePush, которую вы используете. |
Тайм -аут сети / подвеска при вызове sync или checkForUpdate в симуляторе iOS | Попробуйте сбросить симулятор, выбрав Simulator -> Reset Content and Settings.. |
Сервер отвечает 404 при вызове sync или checkForUpdate | Дважды проверьте, что ключ развертывания, который вы добавили в свой Info.plist (iOS), build.gradle (android) или что вы передаете в sync / checkForUpdate , на самом деле правильно. Вы можете запустить appcenter codepush deployment list <ownerName>/<appName> --displayKeys чтобы просмотреть правильные ключи для развертывания вашего приложения. |
| Обновление не обнаружено | Дважды проверяйте, что версия вашего приложения запуска (например, 1.0.0 ) соответствует указанной вами версии при выпуске обновления в CodePush. Кроме того, убедитесь, что вы выпускаете до того же развертывания, что ваше приложение настроено для синхронизации. |
| Обновление не отображается после перезапуска | Если вы не вызываете sync при запуске приложения (например, в componentDidMount вашего корневого компонента), вам необходимо явно вызовать notifyApplicationReady готовые к запуску приложения, в противном случае плагин будет думать, что ваше обновление не удалось и отменить его обратно. |
| Я выпустил обновление для iOS, но мое приложение для Android также показывает обновление, и оно ломает его | Убедитесь, что у вас есть разные ключи развертывания для каждой платформы, чтобы правильно получать обновления |
| Я выпустил новое обновление, но изменения не отражаются | Убедитесь, что вы запускаете приложение в режимах, кроме отладки. В режиме отладки React Native App всегда загружает пакет JS, созданный Packager, поэтому JS Bundle, загруженный CodePush, не применяется. |
| При запуске вашего приложения против симулятора iOS не обнаружен пакет JS. | По умолчанию React Native не генерирует ваш пакет JS при работе с симулятором. Поэтому, если вы используете [CodePush bundleURL] и нацелены на симулятор iOS, вы можете получить результат nil . Эта проблема будет исправлена в RN 0,22,0, но только для выпуска. Вы можете разблокировать этот сценарий прямо сейчас, сделав это изменение локально. |
В дополнение к возможности использовать CLI CODEPUSH для обновлений «вручную», мы считаем, что важно создать повторяемое и устойчивое решение для благоприятного предоставления обновлений в ваше приложение. Таким образом, вам и/или вашей команде достаточно просто создать и поддерживать ритм выполнения гибких развертываний. Чтобы помочь с настройкой конвейера CD на основе CodePush, см. Следующие интеграции с различными серверами CI:
Кроме того, если вам нужна более подробная информация о том, как может выглядеть полный мобильный рабочий процесс CI/CD, который включает в себя CodePush, ознакомьтесь с этой отличной статьей команды Zeemee Engineering.
Этот модуль отправляет свой файл *.d.ts как часть своего пакета NPM, который позволяет вам просто import его и получать Intellisense в вспомогательных редакторах (например, код Visual Studio), а также проверку типа компиляции, если вы Использование TypeScript. По большей части, это поведение должно просто работать из коробки, однако, если вы указали es6 в качестве значения для target или module компилятора в вашем файле tsconfig.json , просто убедитесь, что вы также установили Опция moduleResolution на node . Это гарантирует, что компилятор TypeScript будет смотреть в node_modules для определений типов импортированных модулей. В противном случае вы получите ошибку, подобную следующей, при попытке импортировать модуль react-native-code-push : error TS2307: Cannot find module 'react-native-code-push' .
Этот проект принял код поведения с открытым исходным кодом Microsoft. Для получения дополнительной информации см. Кодекс поведения FAQ или свяжитесь с [email protected] с любыми дополнительными вопросами или комментариями.
