react native code push
9.0.0
Advertencia
React Native Codepush no admitirá una nueva arquitectura. Para usar este complemento en las versiones nativas de React a partir de 0.76, deberá optar por no participar en una nueva arquitectura.
Nota: Este ReadMe solo es relevante para la última versión de nuestro complemento. Si está utilizando una versión anterior, cambie a la etiqueta relevante en nuestro repositorio de GitHub para ver los documentos para esa versión en particular.
Este complemento proporciona integración del lado del cliente para el servicio CodePush, lo que le permite agregar fácilmente una experiencia de actualización dinámica a sus aplicaciones React Native.
Una aplicación Native React está compuesta de archivos JavaScript y cualquier imagen acompañante, que el Metro Bundler agrupa y se distribuye como parte de un binario específico de la plataforma (es decir, un archivo .ipa o .apk ). Una vez que se lanza la aplicación, actualizar el código JavaScript (por ejemplo, hacer correcciones de errores, agregar nuevas características) o activos de imagen, requiere que vuelva a compilar y redistribuir todo el binario, que, por supuesto, incluye cualquier tiempo de revisión asociado con las tiendas (s). Estás publicando.
El complemento CodePush ayuda a obtener mejoras de productos frente a sus usuarios finales al instante, manteniendo su JavaScript y las imágenes sincronizadas con las actualizaciones que libera al servidor Codepush. De esta manera, su aplicación obtiene los beneficios de una experiencia móvil fuera de línea, así como la agilidad "similar a la web" de las actualizaciones de carga lateral tan pronto como estén disponibles. ¡Es un beneficio mutuo!
Para garantizar que sus usuarios finales siempre tengan una versión en funcionamiento de su aplicación, el complemento Codepush mantiene una copia de la actualización anterior, de modo que en caso de que accidentalmente presione una actualización que incluya un bloqueo, puede volver automáticamente. De esta manera, puede estar seguro de que su nueva agilidad de lanzamiento no dará como resultado que los usuarios se bloqueen antes de tener la oportunidad de volver al servidor. ¡Es un beneficio de ganar-ganar!
Nota: Cualquier cambio de producto que toque el código nativo (por ejemplo, modificar su archivo AppDelegate.m / MainActivity.java , agregando un nuevo complemento) no se puede distribuir a través de Codepush y, por lo tanto, debe actualizarse a través de las tiendas apropiadas.
Hacemos todo lo posible para mantener la compatibilidad hacia atrás de nuestro complemento con versiones anteriores de React Native, pero debido a la naturaleza de la plataforma, y la existencia de cambios de ruptura entre las versiones, es posible que necesite usar una versión específica de Codepush complemento para admitir la versión exacta de React Native que está utilizando. La siguiente tabla describe que las versiones de complemento de Codepush admiten oficialmente las respectivas versiones nativas de React:
| React Versiones nativas | Soporte de versión (s) de Codepush (s) |
|---|---|
| <0.14 | Sin apoyo |
| V0.14 | V1.3 (soporte de Android introducido) |
| V0.15-V0.18 | V1.4-V1.6 (introducido soporte de activos de iOS) |
| V0.19-V0.28 | V1.7-V1.17 (introducido soporte de activos de Android) |
| V0.29-V0.30 | V1.13-V1.17 (código de alojamiento nativo de RN refactorizado) |
| V0.31-V0.33 | V1.14.6-V1.17 (código de alojamiento nativo RN refactorizado) |
| V0.34-V0.35 | V1.15-V1.17 (código de alojamiento nativo RN refactorizado) |
| V0.36-V0.39 | V1.16-V1.17 (controlador de currículums refactorizado RN) |
| V0.40-V0.42 | V1.17 (RN refactorizados de archivos de encabezado iOS) |
| V0.43-V0.44 | V2.0+ (dependencias de UIManager refactorizadas RN) |
| V0.45 | V3.0+ (código de administrador de instancias de RN refactorizado) |
| V0.46 | V4.0+ (código de cargador de paquete JS RN refactorizado) |
| V0.46-V0.53 | v5.1+ (RN eliminado el registro no utilizado de los módulos JS) |
| V0.54-V0.55 | V5.3+ (Android Gradle Plugin 3.x Integración) |
| V0.56-V0.58 | v5.4+ (versiones actualizadas de RN para herramientas de Android) |
| V0.59 | V5.6+ (código de cargador de paquete JS RN refactorizado) |
| V0.60-V0.61 | V6.0+ (RN migró a la autoleta) |
| V0.62-V0.64 | V6.2+ (RN eliminado de hurgeload) |
| V0.65-V0.70 | V7.0+ (RN actualizado para iPhone-Target-Versión) |
| V0.71 | V8.0+ (RN se movió para reaccionar-Native-Gradle-Plugin) |
Nota: Las versiones react-native-code-push inferiores a V5.7.0 dejarán de trabajar en el futuro cercano. Puede encontrar más información en nuestra documentación.
Trabajamos duro para responder a los nuevos lanzamientos de RN, pero ocasionalmente nos rompen. Actualizaremos este gráfico con cada versión RN, para que los usuarios puedan verificar cuál es nuestro soporte "oficial".
Al usar la sintaxis del sistema React Native Assets (es decir, el require("./foo.png") ), la siguiente lista representa el conjunto de componentes centrales (y accesorios) que admiten sus imágenes y videos referenciados actualizados a través de Codepush:
| Componente | Accesorios) |
|---|---|
Image | source |
MapView.Marker(Requiere react-nativo-maps >=O.3.2 ) | image |
ProgressViewIOS | progressImage , trackImage |
TabBarIOS.Item | icon , selectedIcon |
ToolbarAndroid(React Native 0.21.0+) | actions[].icon , logo , overflowIcon |
Video | source |
La siguiente lista representa el conjunto de componentes (y accesorios) que actualmente no admiten sus activos actualizados a través de Codepush, debido a su dependencia de imágenes y videos estáticos (es decir, usando la sintaxis { uri: "foo" } )::
| Componente | Accesorios) |
|---|---|
SliderIOS | maximumTrackImage , minimumTrackImage , thumbImage , trackImage |
Video | source |
A medida que se lanzan nuevos componentes básicos, que admiten los activos de referencia, actualizaremos esta lista para garantizar que los usuarios sepan exactamente qué pueden esperar actualizar usando CodePush.
Nota: Codepush solo funciona con componentes de video cuando se require en el accesorio de origen. Por ejemplo:
< Video source = { require ( "./foo.mp4" ) } / > Una vez que haya seguido las instrucciones de uso general de "comenzar" para configurar su cuenta de Codepush, puede iniciar Codepush-iguando su aplicación React Native ejecutando el siguiente comando desde el directorio raíz de su aplicación:
npm install --save react-native-code-pushAl igual que con todos los demás complementos de React Native, la experiencia de integración es diferente para iOS y Android, así que realice los siguientes pasos de configuración dependiendo de qué plataforma (s) se dirige. Tenga en cuenta que si se dirige a ambas plataformas, se recomienda crear aplicaciones de Codepush separadas para cada plataforma.
Si desea ver cómo otros proyectos se han integrado con Codepush, puede consultar las excelentes aplicaciones de ejemplo proporcionadas por la comunidad. Además, si desea familiarizarse rápidamente con Codepush + React Native, puede ver los increíbles videos de inicio producidos por Bilal Budhani y/o Deepak Sisodiya.
Nota: Esta guía supone que ha utilizado el comando react-native init para inicializar su proyecto Native React. A partir de marzo de 2017, el comando create-react-native-app también se puede utilizar para inicializar un proyecto nativo React. Si usa este comando, ejecute npm run eject en el directorio de inicio de su proyecto para obtener un proyecto muy similar a lo que react-native init .
Luego continúe instalando el módulo nativo
Con el complemento CodePush descargado y vinculado, y su aplicación pide a Codepush de dónde obtener el paquete JS correcto, lo único que queda es agregar el código necesario a su aplicación para controlar las siguientes políticas:
¿Cuándo (y con qué frecuencia) verificar una actualización? (Por ejemplo, el inicio de la aplicación, en respuesta a hacer clic en un botón en una página de configuración, periódicamente a algún intervalo fijo)
Cuando hay una actualización disponible, ¿cómo presentarla al usuario final?
La forma más sencilla de hacerlo es "Codepush-Eify" el componente raíz de su aplicación. Para hacerlo, puede elegir una de las dos siguientes opciones:
Opción 1: envuelva su componente raíz con el componente de orden superior codePush :
Para componente de clase
import codePush from "react-native-code-push" ;
class MyApp extends Component {
}
MyApp = codePush ( MyApp ) ;Para componente funcional
import codePush from "react-native-code-push" ;
let MyApp : ( ) => React$Node = ( ) => {
}
MyApp = codePush ( MyApp ) ;Opción 2: use la sintaxis del decorador de ES7:
Nota: Los decoradores aún no son compatibles con la actualización de la propuesta pendiente de Babel 6.x. Es posible que deba habilitarlo instalando y utilizando Babel-Preset-React-Native Stage-0.
Para componente de clase
import codePush from "react-native-code-push" ;
@ codePush
class MyApp extends Component {
}Para componente funcional
import codePush from "react-native-code-push" ;
const MyApp : ( ) => React$Node = ( ) => {
}
export default codePush ( MyApp ) ;De manera predeterminada, Codepush verificará las actualizaciones de cada inicio de la aplicación. Si hay una actualización disponible, se descargará en silencio e instalará la próxima vez que se reinicie la aplicación (ya sea explícitamente por el usuario final o por el sistema operativo), lo que garantiza la experiencia menos invasiva para sus usuarios finales. Si una actualización disponible es obligatoria, se instalará de inmediato, asegurando que el usuario final la obtenga lo antes posible.
Si desea que su aplicación descubra actualizaciones más rápidamente, también puede optar por sincronizar con el servidor Codepush cada vez que la aplicación se reanuda desde el fondo.
Para componente de clase
let codePushOptions = { checkFrequency : codePush . CheckFrequency . ON_APP_RESUME } ;
class MyApp extends Component {
}
MyApp = codePush ( codePushOptions ) ( MyApp ) ;Para componente funcional
let codePushOptions = { checkFrequency : codePush . CheckFrequency . ON_APP_RESUME } ;
let MyApp : ( ) => React$Node = ( ) => {
}
MyApp = codePush ( codePushOptions ) ( MyApp ) ; Alternativamente, si desea un control de grano fino sobre cuándo ocurre el cheque (como un botón de presionar o intervalo de temporizador), puede llamar CodePush.sync() en cualquier momento con SyncOptions deseadas, y opcionalmente apagar la verificación automática de Codepush especificando un Manual 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 ) ; Si desea mostrar un cuadro de diálogo de confirmación de actualización (una "instalación activa"), configure cuando se instale una actualización disponible (como forzar un reinicio inmediato) o personalice la experiencia de actualización de cualquier otra manera, consulte la referencia de API codePush() Para obtener información sobre cómo modificar este comportamiento predeterminado.
Nota: Si está utilizando Redux y Redux SAGA, puede usar alternativamente el módulo react-nativo-código-saga, que le permite personalizar cuándo se llama sync de una manera quizás más simple/más idiomática.
Android Google Play y iOS App Store tienen las pautas correspondientes que tienen reglas de las que debe tener en cuenta antes de integrar la solución Codepush dentro de su aplicación.
El tercer párrafo del tema del dispositivo y el abuso de red describe que la actualización del código fuente por cualquier método que no sea el mecanismo de actualización de Google Play está restringido. Pero esta restricción no se aplica a la actualización de los paquetes de JavaScript.
Esta restricción no se aplica al código que se ejecuta en una máquina virtual y tiene acceso limitado a las API de Android (como JavaScript en una visión web o navegador).
Que permiten completamente Codepush, ya que se actualiza solo los paquetes JS y no puede actualizar la parte del código nativo.
El párrafo 3.3.2 , desde el acuerdo de licencia del programa de desarrollador de Apple de 2015, el acuerdo de licencia de Apple se permitió realizar actualizaciones de JavaScript y activos por completo, y en su última versión (20170605) descargable aquí esta decisión es aún más amplia:
El código interpretado se puede descargar a una aplicación, pero solo siempre que dicho código: (a) no cambia el propósito principal de la aplicación al proporcionar características o funcionalidades que son inconsistentes con el propósito previsto y anunciado de la aplicación que se envía a la aplicación Almacene, (b) no crea una tienda o tienda para otros códigos o aplicaciones, y (c) no omite la firma, Sandbox u otras características de seguridad del sistema operativo.
CodePush le permite seguir estas reglas en su totalidad, siempre que la actualización que presione no desvíe significativamente su producto de su intención original aprobada por la tienda de aplicaciones.
Para permanecer más en el cumplimiento de las pautas de Apple, sugerimos que las aplicaciones distribuidas en App Store no habiliten la opción updateDialog al llamar sync , ya que en las pautas de revisión de la tienda de aplicaciones está escrita que está escrita que:
Las aplicaciones no deben obligar a los usuarios a calificar la aplicación, revisar la aplicación, descargar otras aplicaciones u otras acciones similares para acceder a la funcionalidad, el contenido o el uso de la aplicación.
Este no es necesariamente el caso de updateDialog , ya que no obligará al usuario a descargar la nueva versión, pero al menos debe conocer esa decisión si decide mostrarla.
Una vez que su aplicación está configurada y distribuida a sus usuarios, y ha realizado algunos cambios JS o activos, es hora de liberarlos. La forma recomendada de liberarlos es usar el comando de release-react en la CLI del centro de aplicaciones, que agrupará sus archivos JavaScript, archivos de activos y liberará la actualización al servidor CodePush.
Nota: Antes de que pueda comenzar a publicar actualizaciones, inicie sesión en el centro de aplicaciones ejecutando el comando appcenter login .
En su forma más básica, este comando solo requiere un parámetro: el nombre de su propietario + "/" + Nombre de la aplicación.
appcenter codepush release-react -a < ownerName > / < appName >
appcenter codepush release-react -a < ownerName > /MyApp-iOS
appcenter codepush release-react -a < ownerName > /MyApp-Android El comando release-react permite un flujo de trabajo tan simple porque proporciona muchos valores predeterminados sensibles (como generar un paquete de liberación, suponiendo que el archivo de entrada de su aplicación en iOS sea index.ios.js o index.js ). Sin embargo, todos estos valores predeterminados se pueden personalizar para permitir la flexibilidad incremental según sea necesario, lo que lo hace un buen ajuste para la mayoría de los escenarios.
# 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 "
El cliente Codepush admite actualizaciones diferenciales, por lo que aunque está lanzando su paquete JS y activos en cada actualización, sus usuarios finales solo descargarán los archivos que necesitan. El servicio maneja esto automáticamente para que pueda concentrarse en crear aplicaciones increíbles y podamos preocuparnos por optimizar las descargas de usuarios finales.
Para obtener más detalles sobre cómo funciona el comando release-react , así como los diversos parámetros que expone, consulte los documentos CLI. Además, si prefiere manejar la ejecución del comando react-native bundle usted mismo y, por lo tanto, desea una solución aún más flexible que release-react , consulte el comando release para obtener más detalles.
Si se encuentra con algún problema o tiene alguna pregunta/comentario/comentarios, puede hacernos ping dentro del canal #Code-Push en Reactiflux, enviarnos un correo electrónico a nosotros y/o consultar los detalles de solución de problemas a continuación.
Nota: Las actualizaciones de Codepush deben probarse en modos distintos al modo de depuración. En modo de depuración, React Native App siempre descarga el paquete JS generado por Packager, por lo que JS Bundle descargado por Codepush no se aplica.
En nuestros documentos de inicio, ilustramos cómo configurar el complemento Codepush utilizando una tecla de implementación específica. Sin embargo, para probar de manera efectiva sus lanzamientos, es fundamental que aproveche las implementaciones Staging y Production que se generan automáticamente cuando creó su aplicación Codepush (o cualquier implementación personalizada que pueda haber creado). De esta manera, nunca publica una actualización a sus usuarios finales que no haya podido validarse.
Nota: Nuestra función de reversión del lado del cliente puede ayudar a los usuarios de desbloqueo después de instalar una versión que resultó en un bloqueo, y las reversiones del lado del servidor (es decir, appcenter codepush rollback ) le permite evitar que los usuarios adicionales instalen una liberación incorrecta una vez que se ha identificado. Sin embargo, obviamente es mejor si puede evitar que una actualización errónea se publique ampliamente en primer lugar.
Aprovechar las implementaciones Staging y Production le permite lograr un flujo de trabajo como el siguiente (¡no dude en personalizar!):
Relase una actualización de Codepush a su implementación Staging utilizando el comando appcenter codepush release-react (o appcenter codepush release si necesita más control)
Ejecute su preparación de puesta en escena/beta de su aplicación, sincronice la actualización del servidor y verifique que funcione como se esperaba.
Promover la versión probada de Staging a Production utilizando el comando appcenter codepush promote
Ejecute su compilación de producción/versión de su aplicación, sincronice la actualización del servidor y verifique que funciona como se esperaba
Nota: Si desea adoptar un enfoque más cauteloso, incluso puede optar por realizar un "despliegue por etapas" como parte del #3, que le permite mitigar el riesgo potencial adicional con la actualización (como lo hicieron sus pruebas en #2 Touch All ¿Posibles dispositivos/condiciones?) Al poner la actualización de producción a disposición de un porcentaje de sus usuarios (por ejemplo appcenter codepush promote -a <ownerName>/<appName> -s Staging -d Production -r 20 ). Luego, después de esperar una cantidad de tiempo razonable para ver si llega algún informes de bloqueo o comentarios de los clientes, puede expandirlo a toda su audiencia ejecutando appcenter codepush patch -a <ownerName>/<appName> Production -r 100 .
Notará que los pasos anteriores se refieren a una "compilación de puesta en escena" y "compilación de producción" de su aplicación. Si su proceso de compilación ya genera distintos binarios por "entorno", entonces no necesita leer más, ya que cambiar las claves de implementación de Codepush es como manejar la configuración específica del entorno para cualquier otro servicio que su aplicación use (como Facebook). Sin embargo, si está buscando ejemplos ( incluidos proyectos de demostración ) sobre cómo configurar su proceso de compilación para acomodar esto, consulte las siguientes secciones, dependiendo de la (s) plataforma (s) de que su aplicación está dirigida:
La sección anterior ilustra cómo puede aprovechar múltiples implementaciones de codepush para probar de manera efectiva sus actualizaciones antes de liberarlas ampliamente a sus usuarios finales. Sin embargo, dado que ese flujo de trabajo incorpora estáticamente la asignación de implementación en el binario real, una construcción de puesta en escena o producción solo sincronizará actualizaciones de esa implementación. En muchos casos, esto es suficiente, ya que solo desea que su equipo, clientes, partes interesadas, etc. se sincronicen con sus lanzamientos de preproducción y, por lo tanto, solo ellos necesitan una construcción que sepa cómo sincronizar con la puesta en escena. Sin embargo, si desea poder realizar pruebas A/B, o proporcionar acceso temprano de su aplicación a ciertos usuarios, puede resultar muy útil poder colocar dinámicamente usuarios específicos (o audiencias) en implementaciones específicas en tiempo de ejecución.
Para lograr este tipo de flujo de trabajo, todo lo que necesita hacer es especificar la clave de implementación con la que desea que el usuario actual sincronice al llamar al método codePush . Cuando se especifica, esta clave anulará la "predeterminada" que se proporcionó en los archivos Info.plist (iOS) o MainActivity.java (Android) de su aplicación. Esto le permite producir una construcción para la estadificación o la producción, que también es capaz de ser dinámicamente "redirigido" según sea necesario.
// 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 } ) ;Con ese cambio en su lugar, ahora es solo cuestión de elegir cómo su aplicación determina la clave de implementación correcta para el usuario actual. En la práctica, generalmente hay dos soluciones para esto:
Exponga un mecanismo visible para el usuario para cambiar las implementaciones en cualquier momento. Por ejemplo, su página de configuración podría tener una palanca para habilitar el acceso "beta". Este modelo funciona bien si no le preocupa la privacidad de sus actualizaciones de preproducción, y tiene usuarios eléctricos que pueden optar por las actualizaciones anteriores (y potencialmente errores) a su cuenta (algo así como canales de Chrome ). Sin embargo, esta solución pone la decisión en manos de sus usuarios, lo que no le ayuda a realizar pruebas A/B de manera transparente.
Anotar el perfil del lado del servidor de sus usuarios con una pieza adicional de metadatos que indican la implementación con la que deben sincronizarse. De forma predeterminada, su aplicación podría usar la clave binaria incrustada, pero después de que un usuario se haya autenticado, su servidor puede optar por "redirigirlos" a una implementación diferente, lo que le permite colocar incrementalmente ciertos usuarios o grupos en diferentes implementaciones según sea necesario . Incluso puede optar por almacenar la respuesta del servidor en el almacenamiento local para que se convierta en el nuevo valor predeterminado. La forma en que almacena la llave junto con los perfiles de su usuario depende completamente de su solución de autenticación (por ejemplo, Auth0, Firebase, API Custom DB + REST), pero generalmente es bastante trivial.
Nota: Si es necesario, también puede implementar una solución híbrida que permitiera a sus usuarios finales alternar entre diferentes implementaciones, al tiempo que permite que su servidor anule esa decisión. De esta manera, tiene una jerarquía de "resolución de implementación" que garantiza Ejecute pruebas A/B en sus usuarios según sea necesario.
Dado que recomendamos utilizar la implementación Staging para las pruebas previas a la liberación de sus actualizaciones (como se explica en la sección anterior), no es necesario usarlo para realizar pruebas A/B en sus usuarios, en lugar de permitir temprano. Acceso (como se explica en la opción #1 anterior). Por lo tanto, recomendamos hacer un uso completo de las implementaciones de aplicaciones personalizadas, para que pueda segmentar a sus usuarios, sin embargo, tiene sentido para sus necesidades. Por ejemplo, puede crear implementaciones únicas a largo plazo o incluso, lanzar una variante de su aplicación y luego colocar a ciertos usuarios en ella para ver cómo se involucran.
// #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 Nota: El recuento total de usuarios que se informa en las "métricas de instalación" de su implementación tendrá en cuenta a los usuarios que han "cambiado" de una implementación a otra. Por ejemplo, si su implementación Production informa actualmente con 1 usuario total, pero cambia dinámicamente a ese usuario a Staging , entonces la implementación Production informaría 0 usuarios totales, mientras que Staging informaría 1 (el usuario que acaba de cambiar). Este comportamiento le permite rastrear con precisión su adopción de liberación, incluso en el caso de utilizar una solución de redirección de implementación basada en tiempo de ejecución.
La comunidad nativa React ha creado gentilmente algunas increíbles aplicaciones de código abierto que pueden servir como ejemplos para los desarrolladores que están comenzando. La siguiente es una lista de aplicaciones nativas de OSS React que también están usando Codepush y, por lo tanto, se pueden usar para ver cómo otros están utilizando el servicio:
Además, si está buscando comenzar con React Native + Codepush, y está buscando un increíble kit de inicio, debe consultar lo siguiente:
Nota: Si ha desarrollado una aplicación Native React usando Codepush, que también es de código abierto, háganoslo saber. ¡Nos encantaría agregarlo a esta lista!
El método sync incluye una gran cantidad de registro de diagnóstico fuera de la caja, por lo que si se encuentra con un problema al usarlo, lo mejor para probar primero es examinar los registros de salida de su aplicación. Esto le dirá si la aplicación está configurada correctamente (como ¿puede el complemento encontrar su clave de implementación?), Si la aplicación puede llegar al servidor, si se descubre una actualización disponible, si la actualización se descarga/instalando correctamente, etc. Queremos seguir mejorando el registro para que sea lo más intuitivo/integral posible, así que háganos saber si parece que es confuso o falta algo.
La forma más sencilla de ver estos registros es agregar el indicador --debug para cada comando. Esto emitirá una secuencia de registro que se filtra a los mensajes de Codepush. Esto facilita la identificación de problemas, sin necesidad de usar una herramienta específica de la plataforma, o vadear a través de un volumen potencialmente alto de registros.
Además, también puede usar cualquiera de las herramientas específicas de la plataforma para ver los registros de codepush, si se siente más cómodo con ellos. Simple Inicio de la consola Chrome DevTools, la consola XCode (iOS), la consola OS X (iOS) y/o ADB logCat (Android), y busque mensajes que se prefijan con [CodePush] .
Tenga en cuenta que, de forma predeterminada, los registros nativos de React están deshabilitados en iOS en compilaciones de versión, por lo que si desea verlos en una versión de versión, debe realizar los siguientes cambios en su archivo AppDelegate.m :
Agregue una instrucción #import <React/RCTLog.h> . Para RN <v0.40 use: #import "RCTLog.h"
Agregue la siguiente declaración a la parte superior de su application:didFinishLaunchingWithOptions Método:
RCTSetLogThreshold (RCTLogLevelInfo);Ahora podrá ver los registros de Codepush en modo de depuración o liberación, tanto en iOS como en Android. Si examinar los registros no proporciona una indicación del problema, consulte los siguientes problemas comunes para obtener ideas de resolución adicionales:
| Problema / síntoma | Solución posible |
|---|---|
| Error de compilación | Vuelva a verificar que su versión de React Native sea compatible con la versión Codepush que está utilizando. |
Tiempo de espera de red / colgar al llamar sync o checkForUpdate en el simulador iOS | Intente restablecer el simulador seleccionando el Simulator -> Reset Content and Settings.. Elemento de menú y luego volver a ejecutar su aplicación. |
El servidor responde con un 404 al llamar sync o checkForUpdate | Compruebe dos veces que la checkForUpdate de implementación build.gradle agregó a su Info.plist sync Puede ejecutar appcenter codepush deployment list <ownerName>/<appName> --displayKeys para ver las claves correctas para las implementaciones de su aplicación. |
| Actualizar no ser descubierto | Verifique que la versión de su aplicación en ejecución (como 1.0.0 ) coincida con la versión que especificó al lanzar la actualización a Codepush. Además, asegúrese de estar liberando a la misma implementación con la que su aplicación está configurada para sincronizar. |
| Actualizar que no se muestra después de reiniciar | Si no está llamando sync en la aplicación Start (como dentro de componentDidMount de su componente raíz), entonces debe llamar explícitamente notifyApplicationReady al inicio de la aplicación, de lo contrario, el complemento pensará que su actualización falló y la volverá a rodar. |
| He lanzado una actualización para iOS, pero mi aplicación Android también muestra una actualización y la rompe | Asegúrese de tener diferentes claves de implementación para cada plataforma para recibir actualizaciones correctamente |
| He lanzado una nueva actualización, pero los cambios no se reflejan | Asegúrese de ejecutar la aplicación en modos distintos de la depuración. En modo de depuración, React Native App siempre descarga el paquete JS generado por Packager, por lo que JS Bundle descargado por Codepush no se aplica. |
| No se encuentra ningún paquete JS al ejecutar su aplicación contra el simulador de iOS | Por defecto, React Native no genera su paquete JS cuando se ejecuta contra el simulador. Por lo tanto, si está utilizando [CodePush bundleURL] y el simulador de iOS, puede obtener un resultado nil . Este problema se solucionará en RN 0.22.0, pero solo para compilaciones de liberación. Puede desbloquear este escenario en este momento haciendo este cambio localmente. |
Además de poder usar la CLI de Codepush para las actualizaciones de lanzamiento "manualmente", creemos que es importante crear una solución repetible y sostenible para entregar actualizaciones de su aplicación. De esa manera, es bastante simple para que usted y/o su equipo creen y mantengan el ritmo de realizar implementaciones ágiles. Para ayudar a configurar una tubería de CD basada en Codepush, consulte las siguientes integraciones con varios servidores CI:
Además, si desea más detalles de cómo puede ser un flujo de trabajo completo de CI/CD móvil, que incluye Codepush, consulte este excelente artículo del equipo de Ingeniería de Zeemee.
Este módulo envía su archivo *.d.ts como parte de su paquete NPM, que le permite simplemente import y recibir IntelliSense en los editores de apoyo (como Visual Studio Code), así como compilación de tiempo de compilación si está Uso de mecanografiado. Sin embargo, en su mayor parte, este comportamiento debería funcionar fuera de la caja, sin embargo, si ha especificado es6 como el valor para la opción de compilador target o module en su archivo tsconfig.json , solo asegúrese de establecer también la configuración de establecer el Opción moduleResolution al node . Esto asegura que el compilador TypeScript se verá dentro de node_modules para las definiciones de tipo de módulos importados. De lo contrario, obtendrá un error como el siguiente al intentar importar el módulo react-native-code-push : error TS2307: Cannot find module 'react-native-code-push' .
Este proyecto ha adoptado el Código de Conducta Open Open Microsoft. Para obtener más información, consulte el Código de Conducta Preguntas frecuentes o comuníquese con [email protected] con cualquier pregunta o comentario adicional.
