Saltare alla navigazione
Capgo - Aggiornamenti in Tempo Reale per Applicazioni Capacitor Capgo

Canali

A un canale di Aggiornamento in Tempo Reale viene indicato un bundle di build JS specifico dell'applicazione che verrà condiviso con qualsiasi dispositivo configurato per ascoltare quel canale per gli aggiornamenti. Quando installi il __CAPGO_KEEP_0__ Aggiornamento in Tempo Reale __CAPGO_KEEP_1__ nell'applicazione, qualsiasi binario nativo configurato per quel canale controlla le eventuali aggiornamenti ogni volta che l'applicazione viene avviata. Puoi modificare il build a cui punta un canale in qualsiasi momento e puoi anche tornare a precedenti build se necessario. install the Capgo Live Updates SDK Il canale non fornisce confidenzialità

Quando un dispositivo controlla un aggiornamento, __CAPGO_KEEP_0__ decide quale canale utilizzare in questo ordine rigoroso (priorità più alta per prima):

L'assegnazione forzata del dispositivo (Dashboard)

When a device checks for an update, Capgo decides which channel to use in this strict order (highest priority first):

  1. installare il __CAPGO_KEEP_0__ Live Updates __CAPGO_KEEP_1__ nell'applicazione, qualsiasi binario nativo configurato per quel canale controlla le eventuali aggiornamenti ogni volta che l'applicazione viene avviata. – Pinare manualmente un ID dispositivo specifico a un canale. Utilizzare per debug urgenti o test controllati con un singolo utente reale. Questo sempre vince.
  2. Sovrascrittura Cloud (per dispositivo) via Dashboard o API – Creato quando cambiate il canale del dispositivo nel dashboard o via API. Utilizzare per gli utenti QA che passano tra i canali di feature / PR o per riprodurre un problema di utente. La reinstallazione del binario non lo cancella; eliminando l'ingresso dispositivo.
  3. Plugin setChannel() canale locale – Creato quando l'app chiama setChannel() e il backend verifica che il canale di destinazione consente l'assegnazione auto. Il canale selezionato viene memorizzato localmente su quel dispositivo, ha effetto immediatamente e non viene visualizzato nell'interfaccia di sovrascrittura dei dispositivi.
  1. Capacitor config defaultChannel (costruzione di test predefinita) – Se presente in capacitor.config.* e non esiste un canale di forza/override/locale, l'app inizia su questo canale (ad esempio, beta, qa, pr-123Inteso per le costruzioni di TestFlight / interne affinché i tester atterrino su un canale pre‑rilascio automaticamente. Le costruzioni di produzione lasciano spesso questo non impostato.
  2. Canale predefinito di Cloud (percorso principale ~99% degli utenti) – Se segnala un canale predefinito nella dashboard, tutti gli utenti normali (nessun forzamento, nessuna sovrapposizione del dashboard/API, nessun canale locale del plugin, nessuna configurazione predefinita del canale) si collegano qui. Cambiarlo per distribuire o ritirare immediatamente—nessun nuovo binario. Se hai impostazioni predefinite specifiche per piattaforma (ad esempio, uno solo per iOS, uno solo per Android, uno solo per Electron), ogni dispositivo si collega al predefinito che corrisponde alla sua piattaforma. Lasciare il predefinito cloud non impostato è consentito; in tal caso il dispositivo deve corrispondere ai passaggi 1–4 per ricevere aggiornamenti.

Pratica consigliata:

  • Trattare 1–4 come layer di eccezione / testing; quando si imposta un predefinito cloud, gli utenti reali dovrebbero flusso in esso. Se si sceglie di non impostarlo, essere deliberati su come gli utenti si collegano (tipicamente tramite defaultChannel la configurazione o le sovrapposizioni per dispositivo).
  • Configura solo defaultChannel nei binari che si esplicitamente spediscono ai tester. Lasciarlo non impostato mantiene la logica di produzione centralizzata nella dashboard.
  • Usa setChannel() con parsimonia in produzione—principalmente per le QA o i diagnostici mirati.

Se un canale è disabilitato per la piattaforma (iOS/Android/Electron toggle) quando altrimenti sarebbe stato scelto, il processo di selezione lo ignora e continua nella lista.

Riepilogo: Forza > Sovrapposizione del dashboard/API > Canale locale del plugin > Config setChannel() > Predefinito cloud. defaultChannel Best practice: treat 1–4 as exception / testing layers; when you set a cloud default, real users should flow into it. If you choose not to set one, be deliberate about how users attach (typically via config or per-device overrides). Only configure in binaries you explicitly ship to testers. Leaving it unset keeps production logic centralized in the dashboard. Use sparingly in production—mainly for QA or targeted diagnostics. If a channel is disabled for the platform (iOS/Android/Electron toggles) when it would otherwise be chosen, the selection process skips it and continues down the list. Summary: Force > Dashboard/__CAPGO_KEEP_0__ Override > Plugin local channel > Config > Cloud Default.

Comportamento del canale predefinito

Sottosezione intitolata “Comportamento del canale predefinito”

Impostare un cloud predefinito è facoltativo, ma di solito serve come percorso di default per i nuovi dispositivi. Senza uno, solo i dispositivi che corrispondono alle mappature forzate, agli override o a defaultChannel nel Capacitor config riceveranno aggiornamenti. Quando scegli di segnalare i default, tieni presente queste pattern:

  • Default unico (più comune) – Se un canale ha iOS, Android e Electron abilitati, diventa il solo default; qualsiasi dispositivo senza override si attaccherà qui.
  • Default specifici per piattaforma – Se si suddivide i canali per piattaforma (ad esempio, ios-production con solo iOS abilitato, android-production con solo Android abilitato, e electron-production con solo Electron abilitato), segnala ogni canale come default per la sua piattaforma. Gli iOS vanno al default iOS, gli Android vanno al default Android e gli app Electron vanno al default Electron.

Ricorda che il cloud default e defaultChannel In entrambi occupano lo stesso livello di decisione. Se imposti un cloud predefinito, non hai bisogno di duplicare il valore nella tua __CAPGO_KEEP_0__ configurazione—lascia vuoto capacitor.config.* both occupy the same decision layer. If you set a cloud default, you don’t need to duplicate the value in your Capacitor config—leave defaultChannel per i binari che intendi spedire ai tester o QA quando desideri che inizino su un canale non di produzione anche se il cloud predefinito è diverso. defaultChannel Puoi modificare i valori predefiniti in qualsiasi momento nel pannello di controllo. Quando sostituisci un valore predefinito, i dispositivi nuovi rispettano le nuove impostazioni di routing immediatamente e i dispositivi esistenti seguono le regole di precedenza normali la prossima volta che si connettono.

Configurazione di un Canale

Sottosezione intitolata “Configurazione di un Canale”

Durante l'acquisizione dei dati tu crei il primo canale (la maggior parte delle squadre lo chiama “Produzione”), ma nulla è bloccato—puoi rinominare o cancellare qualsiasi canale in qualsiasi momento. Per aggiungere ulteriori canali in seguito:

Vai alla sezione “Canali” del pannello di controllo __CAPGO_KEEP_0__

  1. Go to the “Channels” section of the Capgo dashboard
  2. Inserisci un nome per il canale e clicca su “Crea”
  3. Il nome del canale può essere qualsiasi cosa tu desideri. Una strategia comune è di sincronizzare i canali con le tue fasi di sviluppo, ad esempio:

Cloudflare

  • Development - per testare gli aggiornamenti in tempo reale su dispositivi locali o emulatori
  • QA - per il team QA di verificare gli aggiornamenti prima della loro rilascio più ampio
  • Staging - per il testing finale in un ambiente simile a produzione
  • Production - per la versione dell'app che gli utenti finali ricevono dai negozi di app

Configurazione del Canale nell'App

Sezione intitolata “Configurazione del Canale nell'App”

Con i canali creati, hai bisogno di configurare l'app per ascoltare il canale appropriato. In questo esempio, useremo il Development canale.

Apri il tuo capacitor.config.ts (o capacitor.config.json) file. Sotto la plugins sezione, imposta optionalmente defaultChannel per edizioni di test (interno / QA). Per le edizioni di produzione, preferire l'omissione affinché i dispositivi utilizzino il Cloud Default a meno che non sia stato esplicitamente sovrascritto.

import { CapacitorConfig } from '@capacitor/cli';


const config: CapacitorConfig = {
  plugins: {
    CapacitorUpdater: {
      // For a QA/TestFlight build – testers start on the Development channel automatically.
      defaultChannel: 'Development',
      // Production builds usually omit this so users attach to the Cloud Default channel.
    },
  },
};

Successivamente, costruisci il tuo'app web e esegui npx cap sync per copiare il file di configurazione aggiornato nei tuoi progetti iOS, Android e Electron. Se salti questo passaggio di sincronizzazione, i tuoi progetti nativi continueranno ad utilizzare il canale su cui erano precedentemente configurati.

Opzioni e strategie del canale

Sottosezione intitolata “Opzioni e strategie del canale”

Il canale ha diverse opzioni che controllano chi può ricevere aggiornamenti e come gli aggiornamenti sono consegnati. Le più importanti sono quelle elencate di seguito. Potete configurarle dall'app web, dal CLI, o dal Public API.

  • Canale predefinito: Opzionalmente segnalate i canali o le configurazioni specifiche per piattaforma che i nuovi dispositivi si collegano a. Vedere “Comportamento del canale predefinito” per gli scenari di routing.
  • Filtro per piattaforma: Abilitare o disabilitare la consegna a iOS, Androido dispositivi per canale. Electron Disabilita l'auto downgrade sotto nativo: Impedisce di inviare un aggiornamento quando la versione dell'app nativa del dispositivo è più recente della bundle del canale (ad esempio, dispositivo su 1.2.3 mentre il canale ha 1.2.2).
  • Consenti gli aggiornamenti per build di sviluppo: Consentite gli aggiornamenti per i build di sviluppo (utile per i test).
  • Abilita o disabilita la consegna a dispositivi per canale.
  • Consenti dispositivi emulator: Consenti aggiornamenti ai dispositivi emulator/simulatore (utile per le prove).
  • Consenti l'assegnazione di dispositivo a se stesso: Consente all'app di passare a questo canale in esecuzione in tempo reale utilizzando setChannelSe disabilitato, setChannel fallirà per questo canale.

Disabilita strategie di aggiornamento automatico

Sezione intitolata “Disabilita strategie di aggiornamento automatico”

Utilizza questo per limitare quali tipi di aggiornamenti il canale consegnerà automaticamente. Opzioni:

  • maggiore: Blocca un pacchetto di destinazione la cui versione maggiore è superiore alla baseline nativa del dispositivo (version_buildEsempio: 1.2.3 -> 2.0.0 è bloccato; 1.2.3 -> 1.9.0 è consentito.
  • minore: Blocca un pacchetto di destinazione la cui versione maggiore o minore differisce dalla baseline nativa del dispositivo ( version_build. Esempio: 1.2.3 -> 1.3.0 è bloccato; 1.2.3 -> 1.2.4 è consentito.
  • patch: Modalità più rigorosa. Blocca qualsiasi modifica al numero di versione maggiore, minore o di patch. Sono consentite solo le modifiche ai suffissi mentre MAJOR.MINOR.PATCH rimane identico. Esempi: 1.0.0-beta.1 -> 1.0.0-beta.2 è consentito, 1.0.0+build.1 -> 1.0.0+build.2 è consentito, 1.0.0 -> 1.0.1 è bloccato.
  • metadata: Richiedi una versione di aggiornamento minima di metadati su ogni bundle. Configura tramite CLI usando --min-update-version o --auto-min-update-version. Se mancante, il canale viene segnalato come non configurato e gli aggiornamenti saranno rifiutati fino a quando non viene impostato.
  • nessuno: Consentire tutti gli aggiornamenti secondo compatibilità semver.

Queste strategie confrontano la bundle di destinazione del canale con la baseline nativa inviata come version_build, non la bundle scaricata attualmente inviata come version_name.

Scopri ulteriori dettagli e esempi nella strategia di disabilitazione degli aggiornamenti alla sezione /docs/cli/commands/#disable-updates-strategy.

Esempio (CLI):

Finestra del terminale
# Block major updates on the Production channel
npx @capgo/cli@latest channel set production com.example.app \
  --disable-auto-update major


# Allow devices to self-assign to the Beta channel
npx @capgo/cli@latest channel set beta com.example.app --self-assign

Utilizzando setChannel() dal tuo App

Sezione intitolata “Utilizzando setChannel() dal tuo App”

Il setChannel() metodo consente al tuo app di cambiare canali in modo programmatico durante l'esecuzione. Ciò è particolarmente utile per:

  • Menu QA/debug dove i tester possono cambiare tra canali
  • Flussi di opt-in per il programma beta
  • Implementazioni delle bandiere di feature
  • Scenari di testing A/B
import { CapacitorUpdater } from '@capgo/capacitor-updater';


// Switch to the beta channel
await CapacitorUpdater.setChannel({ channel: 'beta' });


// Optionally trigger an immediate update check after switching
await CapacitorUpdater.setChannel({
  channel: 'beta',
  triggerAutoUpdate: true
});

Assegnare un Bundle a un Canale

Sottosezione intitolata “Assegnare un Bundle a un Canale”

Per distribuire un aggiornamento in tempo reale, è necessario caricare un nuovo build del bundle JS e assegnarlo a un canale. Ciò può essere fatto in un solo passo con il Capgo CLI:

Fermata di sistema
npx @capgo/cli@latest bundle upload --channel=Development

Caricherà i tuoi asset web costruiti e stabilirà il nuovo bundle come build attiva per il Development canale. Gli app configurati per ascoltare quel canale riceveranno l'aggiornamento la prossima volta che ne faranno richiesta.

È anche possibile assegnare i build ai canali dalla sezione “Bundles” del Capgo dashboard. Cliccare sull'icona del menu accanto a un build e selezionare “Assegna a Canale” per scegliere il canale per quel build.

Versionamento dei Bundle e Canali

Sottosezione intitolata “Versionamento dei Bundle e Canali”

It’s importante notare che i pacchetti in Capgo sono globali per la tua app, non specifici per singoli canali. Lo stesso pacchetto può essere assegnato a più canali.

Quando versioni i pacchetti, consigliamo di utilizzare la versioning semantico con Capgo’s Tester Semver e identificatori di pre-uscita per costruzioni specifiche del canale. Ad esempio, una versione beta potrebbe essere versionata come 1.2.3-beta.1.

Questa approccio ha diversi benefici:

  • Chiaramente comunica la relazione tra le costruzioni. 1.2.3-beta.1 è ovvio che è una pre-uscita di 1.2.3.
  • Consente di riutilizzare i numeri di versione across canali, riducendo la confusione.
  • Abilita percorsi di rollback chiari. Se hai bisogno di tornare indietro da 1.2.3, sai che 1.2.2 è la versione stabile precedente.

Ecco un esempio di come potresti allineare le versioni dei pacchetti con un setup di canale tipico:

  • Development canale: 1.2.3-dev.1, 1.2.3-dev.2, ecc.
  • QA canale: 1.2.3-qa.1, 1.2.3-qa.2, ecc.
  • Staging canale: 1.2.3-rc.1, 1.2.3-rc.2, ecc.
  • Production canale: 1.2.3, 1.2.4, ecc.

Utilizzo l'uso di semver con identificatori di versione pre-rilascio è un approccio raccomandato, ma non strettamente richiesto. La chiave è trovare uno schema di versioning che comunichi chiaramente le relazioni tra le tue build e si allinei con il processo di sviluppo del tuo team.

Ritornare a un aggiornamento in tempo reale

Sezione intitolata “Ritornare indietro una Aggiornamento in Tempo Reale”

Se si distribuisce un aggiornamento in tempo reale che introduce un bug o che necessita di essere annullato, si può facilmente tornare a una versione precedente. Dalla sezione “Canali” della dashboard:

  1. Cliccare il nome del canale da cui si desidera tornare indietro
  2. Trovare la versione da cui si desidera tornare indietro e cliccare l'icona della corona Ritornare all'ultima versione
  3. Confermare l'azione

La versione selezionata diventerà immediatamente la versione attiva per quel canale. Le app riceveranno la versione ritornata la prossima volta che controllano per un aggiornamento.

Automazione degli Aggiornamenti

Sezione intitolata “Automazione degli Aggiornamenti”

Per flussi di lavoro più avanzati, si può automatizzare le distribuzioni degli aggiornamenti in tempo reale come parte del proprio pipeline CI/CD. Integrando Capgo nel proprio processo di build, si può caricare automaticamente nuovi bundle e assegnarli ai canali ogni volta che si pubblica su determinate branch o si crea nuove release.

Scopri di più sul Integrazione CI/CD documenti per imparare di più sull'automazione degli aggiornamenti Capgo in tempo reale.

Distribuire su un Dispositivo

Sezione intitolata “Distribuire su un Dispositivo”

Ora che hai capito i canali, sei pronto a iniziare a distribuire gli aggiornamenti in tempo reale su dispositivi reali. Il processo base è:

  1. Installa il Capgo SDK nel tuo'app
  2. Configura l'app per ascoltare il tuo canale desiderato
  3. Carica un build e assegna il canale a quel build
  4. Lancia l'app e attendi l'aggiornamento!

Per un walkthrough dettagliato, vedi il Distribuzione Aggiornamenti in Tempo Reale guida. Buon aggiornamento!

Utilizzo avanzato dei canali: segmentazione degli utenti

Sezione intitolata “Utilizzo avanzato dei canali: segmentazione degli utenti”

I canali possono essere utilizzati per più di solo le fasi di sviluppo. Sono uno strumento potente per la segmentazione degli utenti, che consente di attivare funzionalità come:

  • Bandiere di feature per diversi livelli di utenti
  • Test A/B
  • Rilascio graduale di nuove funzionalità
  • Programmi di testing beta

Scopri come implementare questi casi d'uso avanzati nella nostra guida: Come segmentare gli utenti per piano e canali per le bandiere di feature e i test A/B.

Continua da qui: canali

Se stai utilizzando

Canali Continua da qui per pianificare la routing dei canali e la distribuzione in fasi, connettilo con Canali per i dettagli di implementazione in Canali, Canali per i dettagli di implementazione in Canali, Soluzione di Test Beta per il flusso di lavoro del prodotto in Soluzione di Test Beta, Soluzione di Targeting della Versione per il flusso di lavoro del prodotto in Soluzione di Targeting della Versione, e Capgo Pratiche di Miglioramento dell'ambiente: Staging con un ID di App Mobile per il contesto pratico in Capgo Pratiche di Miglioramento dell'ambiente: Staging con un ID di App Mobile.