react native code push
9.0.0
Aviso
O React Native Codepush não suportará uma nova arquitetura. Para usar este plug -in em versões nativas do React a partir de 0,76, você precisará optar por não participar da nova arquitetura.
NOTA: Este ReadMe é relevante apenas para a versão mais recente do nosso plug -in. Se você estiver usando uma versão mais antiga, mude para a tag relevante em nosso repositório do GitHub para visualizar os documentos para essa versão específica.
Este plug-in fornece a integração do lado do cliente para o serviço CodePush, permitindo que você adicione facilmente uma experiência de atualização dinâmica ao seu (s) aplicativo (s) nativo (s) react.
Um aplicativo nativo do React é composto por arquivos JavaScript e quaisquer imagens que acompanham, que são agrupadas pelo Metro Bundler e distribuídas como parte de um binário específico da plataforma (ou seja, um arquivo .ipa ou .apk ). Depois que o aplicativo é lançado, atualizando o código JavaScript (por exemplo, criando correções de bugs, adicionando novos recursos) ou ativos de imagem, exige que você recompile e redistribua todo o binário, o que obviamente inclui qualquer tempo de revisão associado ao (s) loja (s) você está publicando.
O plug -in CodePush ajuda a obter melhorias no produto na frente dos usuários finais instantaneamente, mantendo o JavaScript e as imagens sincronizadas com as atualizações que você lançará no servidor CodePush. Dessa forma, seu aplicativo obtém os benefícios de uma experiência móvel offline, bem como a agilidade "semelhante à Web" de atualizações de carregamento lateral assim que estiverem disponíveis. É um ganha-ganha!
Para garantir que seus usuários finais sempre tenham uma versão em funcionamento do seu aplicativo, o plug -in CodePush mantém uma cópia da atualização anterior, para que, no caso de você pressionar acidentalmente uma atualização que inclua uma falha, ele possa recuar automaticamente. Dessa forma, você pode ter certeza de que sua nova agilidade de liberação não resultará na bloqueio dos usuários antes de ter a chance de reverter o servidor. É um ganha-ganha-ganha!
Nota: Quaisquer alterações no produto que tocam o código nativo (por exemplo, modificando seu arquivo AppDelegate.m / MainActivity.java , adicionando um novo plug -in) não podem ser distribuídas via codepush e, portanto, devem ser atualizadas por meio do (s) armazen (s) (s) apropriado (s).
Tentamos o nosso melhor para manter a compatibilidade com versões anteriores do nosso plug -in com versões anteriores do React Native, mas devido à natureza da plataforma e à existência de intervalos de mudanças entre as liberações, é possível que você precise usar uma versão específica do codepush Plug -in para suportar a versão exata do React Native que você está usando. A tabela a seguir descreve quais versões do CodePush suportam oficialmente as respectivas versões nativas do React:
| Reaja versão nativa (s) | Suportando versão (s) CodePush |
|---|---|
| <0,14 | Não suportado |
| v0.14 | v1.3 (suporte Android introduzido) |
| v0.15-v0.18 | v1.4-v1.6 (suporte de ativos introduzido) |
| v0.19-v0.28 | V1.7-V1.17 (suporte de ativos Android introduzido) |
| v0.29-V0.30 | v1.13-v1.17 (RN refatorou o código de hospedagem nativa) |
| v0.31-V0.33 | v1.14.6-v1.17 (RN refatorou o código de hospedagem nativa) |
| v0.34-v0.35 | v1.15-v1.17 (RN refatorou o código de hospedagem nativa) |
| v0.36-v0.39 | V1.16-V1.17 (RN Refatored Retum Handler) |
| v0.40-v0.42 | v1.17 (RN refatorou os arquivos de cabeçalho iOS) |
| v0.43-v0.44 | v2.0+ (RN refatorou as dependências uimanager) |
| v0.45 | v3.0+ (código do gerente de instância refatorado) |
| v0.46 | v4.0+ (RN Refatorou JS Bundle Loader Code) |
| v0.46-v0.53 | v5.1+ (RN removido o registro não utilizado dos módulos JS) |
| v0.54-V0.55 | v5.3+ (Android Gradle Plugin 3.x integração) |
| v0.56-V0.58 | v5.4+ (versões atualizadas do RN para ferramentas Android) |
| v0.59 | v5.6+ (RN Refatorou JS Bundle Loader Code) |
| v0.60-v0.61 | v6.0+ (RN migrou para a automobilismo) |
| v0.62-v0.64 | V6.2+ (RN removido Livereload) |
| v0.65-v0.70 | V7.0+ (RN atualizado para iPhone-Target-Version) |
| v0.71 | V8.0+ (RN mudou-se para react-nativo-plugin) |
NOTA: As versões react-native-code-push inferiores ao V5.7.0 pararão de trabalhar em um futuro próximo. Você pode encontrar mais informações em nossa documentação.
Trabalhamos duro para responder a novos lançamentos do RN, mas eles ocasionalmente nos quebram. Atualizaremos este gráfico com cada versão do RN, para que os usuários possam verificar qual é o nosso suporte "oficial".
Ao usar o sistema de ativos nativos do React (ou seja, usando o require("./foo.png") sintaxe), a lista a seguir representa o conjunto de componentes principais (e adereços) que suportam suas imagens e vídeos referenciados atualizados via codepush:
| Componente | Adereços) |
|---|---|
Image | source |
MapView.Marker(Requer mapas react-nativos >=O.3.2 ) | image |
ProgressViewIOS | progressImage , trackImage |
TabBarIOS.Item | icon , selectedIcon |
ToolbarAndroid(React Native 0.21.0+) | actions[].icon , logo , overflowIcon |
Video | source |
A lista a seguir representa o conjunto de componentes (e adereços) que atualmente não suportam seus ativos sendo atualizados via codepush, devido à sua dependência de imagens e vídeos estáticos (ou seja, usando a sintaxe { uri: "foo" } ):
| Componente | Adereços) |
|---|---|
SliderIOS | maximumTrackImage , minimumTrackImage , thumbImage , trackImage |
Video | source |
À medida que novos componentes principais são lançados, que suportam ativos de referência, atualizaremos esta lista para garantir que os usuários saibam o que exatamente eles podem esperar atualizar usando o CodePush.
NOTA: O CodePush funciona apenas com componentes de vídeo ao usar require no suporte de origem. Por exemplo:
< Video source = { require ( "./foo.mp4" ) } / > Depois de acompanhar as instruções de "começar" para configurar sua conta CodePush, você pode iniciar o CodePush-Ipping Your React Native App, executando o seguinte comando no diretório raiz do seu aplicativo:
npm install --save react-native-code-pushComo em todos os outros plug -ins nativos do React, a experiência de integração é diferente para iOS e Android; portanto, execute as seguintes etapas de configuração, dependendo da (s) plataforma (s) que você está segmentando. Observe que, se você estiver segmentando as duas plataformas, é recomendável criar aplicativos CodePush separados para cada plataforma.
Se você quiser ver como outros projetos se integraram ao CodePush, pode conferir os excelentes aplicativos de exemplo fornecidos pela comunidade. Além disso, se você quiser se familiarizar rapidamente com o CodePush + React Native, pode conferir os vídeos incríveis de início produzidos por Bilal Budhani e/ou Deepak Sisodiya.
Nota: Este guia pressupõe que você tenha usado o comando react-native init para inicializar seu projeto nativo do React. Em março de 2017, o comando create-react-native-app também pode ser usado para inicializar um projeto nativo do React. Se estiver usando este comando, execute npm run eject no diretório inicial do seu projeto para obter um projeto muito semelhante ao que react-native init teria criado.
Em seguida, continue com a instalação do módulo nativo
Com o plug -in CodePush baixado e vinculado, e seu aplicativo pedindo ao CodePush onde obter o pacote JS certo, a única coisa que resta é adicionar o código necessário ao seu aplicativo para controlar as seguintes políticas:
Quando (e com que frequência) verificar uma atualização? (Por exemplo, iniciar o aplicativo, em resposta ao clique em um botão em uma página de configurações, periodicamente em algum intervalo fixo)
Quando uma atualização está disponível, como apresentá -lo ao usuário final?
A maneira mais simples de fazer isso é "CodePush-Iff" o componente raiz do seu aplicativo. Para fazer isso, você pode escolher uma das duas opções a seguir:
Opção 1: Enrole seu componente raiz com o componente codePush de ordem superior:
Para componente de classe
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 ) ;Opção 2: Use a sintaxe do decorador ES7:
NOTA: Os decoradores ainda não são suportados no Babel 6.x Atualização de proposta pendente. Pode ser necessário habilitá-lo instalando e usando Babel-Preset-React-native-stage-0.
Para componente de classe
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 ) ;Por padrão, o CodePush verificará se há atualizações em todos os aplicativos. Se uma atualização estiver disponível, ela será baixada silenciosamente e instalada na próxima vez que o aplicativo for reiniciado (explicitamente pelo usuário final ou pelo sistema operacional), o que garante a experiência menos invasiva para seus usuários finais. Se uma atualização disponível for obrigatória, será instalada imediatamente, garantindo que o usuário final o obtenha o mais rápido possível.
Se você deseja que o seu aplicativo descubra as atualizações mais rapidamente, também poderá optar por sincronizar com o servidor CodePush sempre que o aplicativo retoma do plano de fundo.
Para componente de classe
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 ) ; Como alternativa, se você deseja controle de grão fino sobre quando o cheque ocorre (como um botão pressionar ou intervalo do timer), você pode chamar CodePush.sync() a qualquer momento com as SyncOptions desejadas e, opcionalmente, desativar a verificação automática do CodePush especificando um checkFrequency manual:
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 ) ; Se você deseja exibir uma caixa de diálogo de confirmação de atualização (uma "instalação ativa"), configure quando uma atualização disponível estiver instalada (como forçar uma reinicialização imediata) ou personalizar a experiência de atualização de qualquer outra maneira, consulte a referência da API codePush() Para obter informações sobre como ajustar esse comportamento padrão.
Nota: Se você estiver usando o Redux e o Redux Saga, poderá usar o módulo React-native-Code-Push-Saga, que permite personalizar quando sync é chamada de uma maneira talvez mais simples/mais idiomática.
O Android Google Play e a iOS App Store possuem diretrizes correspondentes com regras que você deve estar ciente antes de integrar a solução CodePush em seu aplicativo.
O terceiro parágrafo do tópico de abuso de dispositivo e rede descreve que a atualização do código -fonte por qualquer método que não seja o mecanismo de atualização do Google Play seja restrito. Mas essa restrição não se aplica à atualização dos pacotes JavaScript.
Essa restrição não se aplica ao código que é executado em uma máquina virtual e possui acesso limitado às APIs do Android (como JavaScript em um WebView ou navegador).
Isso permite totalmente o CodePush, pois atualiza apenas os pacotes JS e não pode atualizar a parte do código nativo.
O parágrafo 3.3.2 , desde o contrato de licença do Programa de Desenvolvedores da Apple em 2015, permitiu a execução de atualizações ao ar livre de JavaScript e ativos-e em sua versão mais recente (20170605) Download aqui Esta decisão é ainda mais ampla:
O código interpretado pode ser baixado para um aplicativo, mas apenas enquanto esse código: (a) não altera o objetivo principal do aplicativo, fornecendo recursos ou funcionalidade que são inconsistentes com o objetivo pretendido e anunciado do aplicativo, conforme enviado ao aplicativo A loja, (b) não cria uma loja ou loja para outros código ou aplicativos e (c) não ignora a assinatura, a caixa de areia ou outros recursos de segurança do sistema operacional.
O CodePush permite que você siga essas regras em plena conformidade, desde que a atualização que você pressione não desvie significativamente seu produto da intenção original da App Store.
Para permanecer ainda em conformidade com as diretrizes da Apple, sugerimos que os aplicativos distribuídos da App Store não possam ativar a opção updateDialog ao chamar sync , pois nas diretrizes da App Store Review, está escrito que:
Os aplicativos não devem forçar os usuários a classificar o aplicativo, revisar o aplicativo, baixar outros aplicativos ou outras ações semelhantes para acessar a funcionalidade, conteúdo ou uso do aplicativo.
Este não é necessariamente o caso do updateDialog , pois não forçará o usuário a fazer o download da nova versão, mas pelo menos você deve estar ciente dessa decisão se decidir mostrá -la.
Depois que seu aplicativo estiver configurado e distribuído aos seus usuários e você fez algumas alterações de JS ou ativos, é hora de liberá -los. A maneira recomendada de lançá-los é usar o comando release-react na CLI do App Center, que agrupará seus arquivos JavaScript, arquivos de ativos e lançará a atualização para o servidor CodePush.
Nota: Antes de começar a lançar atualizações, faça login no App Center executando o comando appcenter login .
Em sua forma mais básica, este comando requer apenas um parâmetro: nome do seu proprietário + "/" + nome do aplicativo.
appcenter codepush release-react -a < ownerName > / < appName >
appcenter codepush release-react -a < ownerName > /MyApp-iOS
appcenter codepush release-react -a < ownerName > /MyApp-Android O comando release-react permite um fluxo de trabalho tão simples, pois fornece muitos padrões sensíveis (como gerar um pacote de liberação, assumindo que o arquivo de entrada do seu aplicativo no iOS seja index.ios.js ou index.js ). No entanto, todos esses padrões podem ser personalizados para permitir a flexibilidade incremental, conforme necessário, o que a torna uma boa opção para a maioria dos cenários.
# 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 "
O cliente CodePush suporta atualizações diferenciais; portanto, mesmo que você esteja lançando seu pacote e ativos JS em todas as atualizações, seus usuários finais apenas baixam os arquivos de que precisam. O serviço lida com isso automaticamente, para que você possa se concentrar na criação de aplicativos incríveis e podemos nos preocupar em otimizar downloads do usuário final.
Para obter mais detalhes sobre como funciona o comando release-react , bem como os vários parâmetros que expõe, consulte os documentos da CLI. Além disso, se você preferir lidar com a execução do comando react-native bundle e, portanto, deseja uma solução ainda mais flexível do que release-react , consulte o comando release para obter mais detalhes.
Se você tiver algum problema ou tiver alguma dúvida/comentário/feedback, poderá pingar-nos no canal #Code-Push no Reactiflux, envie-nos e-mails e/ou confira os detalhes de solução de problemas abaixo.
Nota: as atualizações do CodePush devem ser testadas em modos que não sejam o modo de depuração. No modo de depuração, o React Native App sempre faz o download do pacote JS gerado pelo Packager, para que o JS Bundle baixado por CodePush não se aplique.
Ao iniciar os documentos, ilustramos como configurar o plug -in CodePush usando uma chave de implantação específica. No entanto, para testar efetivamente seus lançamentos, é fundamental que você aproveite as implantações Staging e Production que são geradas automaticamente quando você criou seu aplicativo CodePush (ou quaisquer implantações personalizadas que você possa ter criado). Dessa forma, você nunca lançará uma atualização para seus usuários finais de que não conseguiu validar a si mesmo.
NOTA: Nosso recurso de reversão do lado do cliente pode ajudar a desbloquear os usuários após a instalação de uma versão que resultou em uma falha e reversão do lado do servidor (ou seja, appcenter codepush rollback ) permite que você impeça que os usuários adicionais instalem uma versão ruim depois de identificada. No entanto, é obviamente melhor se você pode impedir que uma atualização errônea seja amplamente lançada em primeiro lugar.
Aproveitar as implantações Staging e Production permite obter um fluxo de trabalho como o seguinte (sinta -se à vontade para personalizar!):
Libere uma atualização CodePush para sua implantação Staging usando o comando appcenter codepush release-react (ou appcenter codepush release se precisar de mais controle)
Execute sua criação de estadiamento/beta do seu aplicativo, sincronize a atualização do servidor e verifique se ele funciona como esperado
Promova a liberação testada de Staging à Production usando o comando appcenter codepush promote
Execute sua criação de produção/liberação do seu aplicativo, sincronize a atualização do servidor e verifique se ele funciona como esperado
NOTA: Se você deseja adotar uma abordagem mais cautelosa, pode até optar por executar um "lançamento encenado" como parte do número 3, que permite mitigar riscos potenciais adicionais com a atualização (como seus testes em #2 toquem todos dispositivos/condições possíveis?) Ao disponibilizar apenas a atualização de produção para uma porcentagem de seus usuários (por exemplo appcenter codepush promote -a <ownerName>/<appName> -s Staging -d Production -r 20 ). Então, depois de aguardar um tempo razoável para ver se algum relatório de falha ou feedback do cliente entra, você pode expandi -lo para todo o seu público executando appcenter codepush patch -a <ownerName>/<appName> Production -r 100 .
Você notará que as etapas acima se referem a uma "construção de estadiamento" e "construção de produção" do seu aplicativo. Se o seu processo de compilação já gerar binários distintos por "ambiente", você não precisará ler mais, pois trocar as chaves de implantação CodePush é como lidar com a configuração específica do ambiente para qualquer outro serviço que seu aplicativo use (como o Facebook). No entanto, se você está procurando exemplos ( incluindo projetos de demonstração ) sobre como configurar seu processo de construção para acomodar isso, consulte as seções a seguir, dependendo da (s) plataforma (s), seu aplicativo está segmentando:
A seção acima ilustrou como você pode aproveitar várias implantações CodePush para testar efetivamente suas atualizações antes de liberá -las amplamente para seus usuários finais. No entanto, como o fluxo de trabalho incorpora estaticamente a atribuição de implantação no binário real, uma criação de estadiamento ou produção só será de sincronização de atualizações dessa implantação. Em muitos casos, isso é suficiente, pois você deseja apenas sua equipe, clientes, partes interessadas etc. para sincronizar com seus lançamentos de pré-produção e, portanto, apenas eles precisam de uma construção que saiba sincronizar com a encenação. No entanto, se você deseja executar testes A/B ou fornecer acesso precoce ao seu aplicativo a determinados usuários, pode ser muito útil poder colocar dinamicamente usuários específicos (ou público) em implantações específicas em tempo de execução.
Para alcançar esse tipo de fluxo de trabalho, tudo o que você precisa fazer é especificar a chave de implantação com a qual você deseja que o usuário atual sincronize ao chamar o método codePush . Quando especificado, essa chave substituirá a "padrão" que foi fornecida nos arquivos Info.plist (iOS) ou MainActivity.java (Android) do seu aplicativo. Isso permite que você produz uma construção para estadiamento ou produção, que também é capaz de ser dinamicamente "redirecionado", conforme necessário.
// 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 } ) ;Com essa mudança no lugar, agora é apenas uma questão de escolher como seu aplicativo determina a chave de implantação correta para o usuário atual. Na prática, normalmente existem duas soluções para isso:
Exponha um mecanismo visível ao usuário para alterar as implantações a qualquer momento. Por exemplo, sua página de configurações pode ter uma alternância para ativar o acesso "beta". Esse modelo funciona bem se você não estiver preocupado com a privacidade de suas atualizações de pré-produção e você tem usuários de energia que podem querer optar por atualizações anteriores (e potencialmente de buggy) por sua própria vontade (como canais cromados ). No entanto, esta solução coloca a decisão nas mãos de seus usuários, o que não ajuda você a executar testes A/B transparentemente.
Anote o perfil do lado do servidor de seus usuários com uma peça adicional de metadados que indica a implantação com a qual devem sincronizar. Por padrão, seu aplicativo pode usar apenas a chave incorporada binária, mas depois que um usuário autenticado, seu servidor pode optar por "redirecioná-los" para uma implantação diferente, o que permite que você coloque gradualmente determinados usuários ou grupos em diferentes implantações, conforme necessário . Você pode até optar por armazenar a resposta do servidor no armazenamento local para que ele se torne o novo padrão. Como você armazena a chave ao lado dos perfis do seu usuário, depende inteiramente da sua solução de autenticação (por exemplo, Auth0, Firebase, API de REST DB + personalizada), mas geralmente é bastante trivial.
NOTA: Se necessário, você também pode implementar uma solução híbrida que permitisse que seus usuários finais alterassem entre diferentes implantações, além de permitir que seu servidor substituísse essa decisão. Dessa forma, você tem uma hierarquia de "resolução de implantação" que garante que seu aplicativo tenha a capacidade de se atualizar para fora da caixa, seus usuários finais podem se sentir recompensados ao obter acesso precoce a bits, mas você também tem a capacidade de Execute os testes A/B em seus usuários, conforme necessário.
Como recomendamos o uso da implantação Staging para testes de pré-lançamento de suas atualizações (conforme explicado na seção anterior), não faz sentido usá-lo para executar testes A/B em seus usuários, em vez de permitir que acesso (conforme explicado na opção 1 acima). Portanto, recomendamos fazer pleno uso de implantações de aplicativos personalizadas, para que você possa segmentar seus usuários, no entanto, faça sentido para suas necessidades. Por exemplo, você pode criar implantações de longo prazo ou até pontuais, liberar uma variante do seu aplicativo e colocar certos usuários nela para ver como eles se envolvem.
// #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: A contagem total de usuários relatada nas "métricas de instalação" da sua implantação levará em consideração os usuários que "trocaram" de uma implantação para outra. Por exemplo, se a sua implantação Production atualmente relatar um usuário total, mas você muda dinamicamente esse usuário para Staging , a implantação Production relatará 0 usuários totais, enquanto Staging relataria 1 (o usuário que acabou de mudar). Esse comportamento permite rastrear com precisão sua adoção de lançamento, mesmo no caso de usar uma solução de redirecionamento de implantação baseada em tempo de execução.
A comunidade nativa do React criou graciosamente alguns aplicativos de código aberto impressionantes que podem servir como exemplos para os desenvolvedores que estão começando. A seguir, é apresentada uma lista de aplicativos nativos do OSS React que também estão usando o CodePush e, portanto, podem ser usados para ver como os outros estão usando o serviço:
Além disso, se você deseja começar com o React Native + CodePush e está procurando um kit inicial incrível, verifique o seguinte:
Nota: Se você desenvolveu um aplicativo nativo do React usando o CodePush, isso também é de código aberto, informe-nos. Gostaríamos muito de adicioná -lo a esta lista!
O método sync inclui muitos registros de diagnóstico, por isso, se você estiver encontrando um problema ao usá-lo, a melhor coisa a tentar primeiro é examinar os logs de saída do seu aplicativo. Isso lhe dirá se o aplicativo está configurado corretamente (como o plug -in pode encontrar sua chave de implantação?), Se o aplicativo puder alcançar o servidor, se uma atualização disponível estiver sendo descoberta, se a atualização estiver sendo baixada/instalada com sucesso, etc. queremos continuar melhorando o registro para ser o mais intuitivo/abrangente possível; portanto, informe -nos se você achar que está confuso ou perdendo qualquer coisa.
A maneira mais simples de visualizar esses logs é adicionar o sinalizador --debug para cada comando. Isso produzirá um fluxo de log que é filtrado apenas para mensagens CodePush. Isso facilita a identificação de problemas, sem precisar usar uma ferramenta específica da plataforma ou percorrer um volume potencialmente alto de logs.
Além disso, você também pode usar qualquer uma das ferramentas específicas da plataforma para visualizar os logs CodePush, se estiver mais confortável com elas. Iniciar simples o console do Chrome DevTools, o Xcode Console (iOS), o OS X Console (iOS) e/ou o ADB Logcat (Android) e procure mensagens prefixadas com [CodePush] .
Observe que, por padrão, os logs nativos do React estão desativados no iOS nas compilações de liberação; portanto, se você quiser vê -las em uma compilação de liberação, precisará fazer as seguintes alterações no seu arquivo AppDelegate.m :
Adicione uma instrução #import <React/RCTLog.h> . Para RN <v0.40 Use: #import "RCTLog.h"
Adicione a seguinte declaração ao topo do seu application:didFinishLaunchingWithOptions Method:
RCTSetLogThreshold (RCTLogLevelInfo);Agora você poderá ver os logs CodePush no modo de depuração ou liberação, no iOS ou no Android. Se o exame dos logs não fornecer uma indicação do problema, consulte os seguintes problemas comuns para idéias adicionais de resolução:
| Questão / sintoma | Solução possível |
|---|---|
| Erro de compilação | Verifique duas vezes se sua versão do React Native é compatível com a versão CodePush que você está usando. |
Tempo limite da rede / pendure ao ligar para sync ou checkForUpdate no simulador iOS | Tente redefinir o simulador selecionando o Simulator -> Reset Content and Settings.. Item do menu e, em seguida, execute novamente seu aplicativo. |
O servidor responde com um 404 ao ligar para sync ou checkForUpdate | Verifique se a chave de implantação que você adicionou ao seu Info.plist (iOS), build.gradle (Android) ou que você está passando para sync / checkForUpdate está de fato correto. Você pode executar appcenter codepush deployment list <ownerName>/<appName> --displayKeys para visualizar as chaves corretas para as implantações de aplicativos. |
| Atualização não sendo descoberta | Verifique se a versão do seu aplicativo em execução (como 1.0.0 ) corresponde à versão especificada ao lançar a atualização para o CodePush. Além disso, verifique se você está lançando para a mesma implantação com a qual seu aplicativo está configurado para sincronizar. |
| Atualização não sendo exibida após reiniciar | Se você não está ligando para sync no aplicativo Iniciar (como no componentDidMount do seu componente raiz), precisará ligar explicitamente notifyApplicationReady no aplicativo Iniciar; caso contrário, o plug -in pensará que sua atualização falhou e o rolará de volta. |
| Lançei uma atualização para iOS, mas meu aplicativo Android também mostra uma atualização e o quebra | Certifique -se de ter diferentes chaves de implantação para cada plataforma para receber atualizações corretamente |
| Languei uma nova atualização, mas as alterações não são refletidas | Certifique -se de que você esteja executando o aplicativo em outros modos que não a depuração. No modo de depuração, o React Native App sempre faz o download do pacote JS gerado pelo Packager, para que o JS Bundle baixado por CodePush não se aplique. |
| Nenhum pacote JS está sendo encontrado ao executar seu aplicativo contra o simulador iOS | Por padrão, o React Native não gera seu pacote JS ao correr contra o simulador. Portanto, se você estiver usando [CodePush bundleURL] e direcionando o simulador iOS, poderá estar obtendo um resultado nil . Este problema será corrigido no RN 0,22.0, mas apenas para construções de liberação. Você pode desbloquear esse cenário agora, fazendo essa alteração localmente. |
Além de poder usar a CLI CodePush para lançar atualizações "manualmente", acreditamos que é importante criar uma solução repetível e sustentável para fornecer atualizações contloveriamente ao seu aplicativo. Dessa forma, é simples o suficiente para você e/ou sua equipe criar e manter o ritmo de realizar implantações ágeis. Para ajudar na configuração de um pipeline de CD baseado em CodePush, consulte as seguintes integrações com vários servidores de IC:
Além disso, se você quiser mais detalhes sobre como pode parecer um fluxo de trabalho de CI/CD móvel completo, que inclui o CodePush, confira este excelente artigo da equipe de engenharia Zeemee.
Este módulo envia seu arquivo *.d.ts como parte de seu pacote NPM, que permite simplesmente import -lo e receber o IntelliSense em apoiar editores (como o Código do Visual Studio), bem como a verificação do tipo de tempo de compilação se você estiver usando o TypeScript. Na maioria das vezes, esse comportamento deve apenas funcionar fora da caixa, no entanto, se você especificou es6 como o valor para a opção de compilador target ou module no seu arquivo tsconfig.json , apenas certifique -se de definir também o Opção moduleResolution para node . Isso garante que o compilador do TypeScript pareça dentro dos node_modules para as definições de tipo de módulos importados. Caso contrário, você receberá um erro como o seguinte ao tentar importar o módulo react-native-code-push : error TS2307: Cannot find module 'react-native-code-push' .
Este projeto adotou o Código de Conduta Open Microsoft. Para obter mais informações, consulte o Código de Conduta Perguntas frequentes ou entre em contato com [email protected] com quaisquer perguntas ou comentários adicionais.
