I canali

Come Capgo sceglie un canale (precedenza)

Quando un dispositivo chiede a Capgo un aggiornamento, il canale che verrà utilizzato viene deciso in questo ordine (priorità più alta per prima):

1. Mappatura forzata del dispositivo: Se l'ID dispositivo viene esplicitamente impostato su un canale (vedi la Lista dei dispositivi forzati all'interno delle impostazioni del canale), quel canale vince sempre.
2. Cloud override (creato da setChannel() o azione Webapp): Chiamando setChannel (o modificando il canale di un dispositivo nella dashboard) si scrive un sovrapposizione persistente nel cloud legata a quell'ID dispositivo. Quella sovrapposizione viene consultata dopo la mappatura forzata ma prima di qualsiasi impostazione predefinita. Ri‑installando l'app non la rimuove; eliminando l'entry del dispositivo non.
3. Capacitor config defaultChannel (impostazione predefinita per build di test): Per i build interni / beta / di test puoi impostare defaultChannel (chiave legacy channel) in capacitor.config.* così i dispositivi di test iniziano su un canale di pre-rilascio (ad esempio beta, pr-123). Se assente, il dispositivo procederà al cloud default. I build di produzione lasciano spesso questo non impostato.
4. Canale Cloud Predefinito (strategia principale per ~99% degli utenti): La principale canale di produzione in cui quasi tutti gli utenti reali atterrano. Qualsiasi nuovo dispositivo senza una forza, senza un sovraccarico, e senza una configurazione defaultChannel utilizza questo. Cambiandolo si distribuisce (o si annulla) per tutti in secondi—nessun nuovo binario.

Perché il cloud default è la strada principale:

• Rollout o rollback istantaneo senza ricostruire o ririlasciare i binari nativi.
• Un posto per gestire il comportamento di iOS, Android e Electron.
• Maggiore sicurezza: puoi confermare che i pacchetti esistono e le impostazioni sono corrette prima di passare a impostazioni predefinite.
• Modifiche tracciabili (i membri del team possono vedere chi ha modificato cosa nella UI / log). Principio di progettazione: Layer sopra (forza / sovrascrivi / config) sono eccezioni

(debug utente singolo, QA switching, test build defaults). Flusso degli utenti normali verso il cloud predefinito. Cambiare il canale cloud predefinito influisce nuovi

• dispositivi normali che:
• Non sono stati obbligati
• Non hanno già un sovrascrittura cloud presente defaultChannel definito

Se un test build viene spedito con defaultChannel: 'beta' e successivamente cambi il cloud default a production, dispositivi che sono partiti su beta attraverso la configurazione rimangono lì fino a quando non: (a) li sovrascrivete con setChannel(), (b) force them, or (c) delete the device entry.

, (b) li forzate, o (c) cancellate l'entry del dispositivo.

• I dispositivi rimangono sul loro canale corrente a meno che non:
• Forzate su un altro canale. setChannel() Chiamate
• (creando/sovrascrivendo l'override cloud) o lo cambiate manualmente nel dashboard.

Rimuovete / archiviate il canale su cui si trovano (poi cadrebbero nuovamente attraverso la precedenza di nuovo alla prossima verifica).

Nota: Impostare defaultChannel significa cambiarlo richiede un nuovo binario; utilizzalo intenzionalmente per test/QA, non per il controllo generale di produzione.

Capacitor esempio di configurazione

capacitor.config.ts

// Example: a TestFlight or internal QA build defaults to the beta channel.
const config = {
  plugins: {
    Capgo: {
      defaultChannel: 'beta', // Test build default. Omit in production so users attach to cloud default.
      // legacy key: channel
    },
  },
};
export default config;

Se in seguito cambi il default dashboard a production, devices already on another channel (via config, override, or force) will NOT move automatically; only fresh devices (or those whose override/force you clear) pick it up.

---

, i dispositivi già su un altro canale (tramite configurazione, sovrascrittura o forza) NON si sposteranno automaticamente; solo i dispositivi freschi (o quelli di cui hai cancellato la sovrascrittura/forza) li assumeranno.

Sezione intitolata “Gestione dei canali” In primo luogo, prendiamo in considerazione la pagina dei canali. Puoi accedervi cliccando sul tuo app Ecco il passo successivo Cliccando sul pulsante dei canali.

Creazione di un canale

Ecco che cosa vedete: esiste un pulsante '+' nell'angolo in basso a destra. (1 nell'immagine) Cliccandolo si aprirà una finestra modale dove potrete creare un nuovo canale.

Poi dopo aver cliccato su Add un nuovo canale dovrebbe apparire nell'elenco.

Cosa significa 'non configurato correttamente'?

A volte la configurazione di un canale non è valida. In quel caso, riceverai un grande avviso e il Misconfigured colonna dirà Yes per uno o più dei canali. Puoi imparare di più su di esso qui

Cancellazione di un canale

Cancellare un canale è piuttosto semplice. Basta cliccare sull'icona della spazzatura e confermare la cancellazione. (2 nell'immagine)

Gestione di un canale

Cliccando sul nome del canale si aprirà una finestra modale dove potrai gestire le impostazioni del canale. (3 in l'immagine)

La pagina delle impostazioni del canale contiene tutte le opzioni di configurazione per il tuo canale. Andremo a esaminare ogni impostazione.

---

In primo luogo il Default channel toggle. Quando abilitato, questo canale diventa il predefinito per i nuovi dispositivi. Per una spiegazione completa di come funzionano i canali predefiniti, compresa la configurazione dei predefiniti specifici per piattaforma (uno per iOS, uno per Android e uno per Electron), vedi la sezione Configurazione del Canale Predefinito . In secondo luogo l'

---

impostazione. Questo è relativamente semplice. Se questo è falso, i dispositivi iOS non saranno autorizzati a scaricare aggiornamenti da questo canale. IOS In terzo luogo l'

impostazione. Questo è simile a Android . Se questo è falso, i dispositivi Android non saranno autorizzati a scaricare aggiornamenti da questo canale. IOS__CAPGO_KEEP_0__

Quarto è il Electron impostazione. Questo è simile a IOS e Android. Se questo è falso, gli app di Electron non saranno autorizzati a scaricare gli aggiornamenti da questo canale.

Quinto è il Disable auto downgrade under native impostazione. Se questo è vero, sarà impossibile scendere di versione da una versione nativa. Ciò significa che se hai caricato una 1.2.0 versione sull'app store o play store e cerchi di impostare la versione del canale su 1.1.0 allora l'aggiornamento (abbassamento) fallirà.

Sesto è il Disable auto update. Questa impostazione è piuttosto complessa, e puoi imparare di più su di essa qui

Per quanto riguarda Allow development build. Se è vero, i build di sviluppo saranno autorizzati a scaricare aggiornamenti da questo canale. Se non è vero, allora ogni richiesta di aggiornamento che ha il prod set to false

verrà rifiutata. Questo è utile soprattutto per scopi di testing. Allow Emulators. If this is false then Capgo will disallow any update request that comes from an emulator. This is mostly useful for testing purposes.

. Se è falso, __CAPGO_KEEP_0__ disporrà di rifiutare qualsiasi richiesta di aggiornamento che proviene da un emulatore. Questo è utile soprattutto per scopi di testing. Allow devices to self associateOttavo è il . Se è vero, il setChannel metodo sarà disponibile. Se è impostato su falso e si prova a chiamare il setChannel

metodo con questo canale, allora la chiamata fallirà.

Se stai utilizzando Canali per pianificare la routing dei canali e la distribuzione in fase di staging, 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 unico per il contesto pratico in Capgo Pratiche di ambiente di produzione: Staging con un ID di App Mobile.