Canaux

Comment Capgo choisit un canal (préférence)

Lorsqu'un appareil demande à Capgo une mise à jour, le canal qu'il utilisera est décidé dans l'ordre suivant (priorité la plus élevée en premier):

1. Mappage de l'appareil forcé: Si l'ID de l'appareil est explicitement forcé à un canal (voir la liste à l'intérieur des paramètres du canal), ce canal gagne toujours. Surcharge de Cloud (créé par
2. ou l'action Webapp) setChannel() : AppelerAppareils forçés setChannel (ou en modifiant le canal d'un appareil dans l'interface de dashboard) écrit une mise à jour persistante dans le cloud liée à cet ID d'appareil. Cette mise à jour est consultée après la mise en correspondance forcée mais avant toute valeur par défaut. La réinstallation de l'application ne la supprime pas ; la suppression de l'entrée d'appareil ne le fait pas. __CAPGO_KEEP_0__ config : Pour les builds de test par défaut, vous pouvez définir
3. Capacitor config defaultChannel ) dansafin que les appareils de test commencent sur un canal de pré-version (par exemple, defaultChannel . Si absent, l'appareil se dirigera vers la valeur par défaut du cloud. Les builds de production laissent généralement cela non défini. channelCanal par défaut du Cloud (stratégie principale pour environ 99 % des utilisateurs) capacitor.config.* : Le principal canal de production sur lequel atterrissent presque tous les utilisateurs réels. N'importe quel nouveau dispositif sans force, sans mise à jour, et sans configuration. beta, pr-123Forced Channel (override strategy for ~1% of users)
4. : Le canal forcé (stratégie de mise à jour pour environ 1 % des utilisateurs).Legacy Channel (override strategy for ~0% of users) defaultChannel utilisez cela. La modification de ce paramètre déclenche un déploiement (ou un retrait) pour tous en quelques secondes – sans nouvelle version binaire.

Pourquoi le par défaut du cloud est la voie principale :

• Déploiement instantané ou retrait sans recompiler ou républier les binaires natifs.
• Un seul endroit pour gérer le comportement d'iOS, Android et Electron.
• Plus sûr : vous pouvez confirmer que les bundles existent et que les paramètres sont corrects avant de passer à la configuration par défaut.
• Les modifications auditable (les membres de l'équipe peuvent voir qui a modifié quoi dans l'interface utilisateur / les journaux). Principe de conception : Les couches au-dessus (forcer / ignorer / configurer) sont des exceptions

(debugger pour un utilisateur unique, QA, build de test par défaut). Les utilisateurs normaux suivent la voie par défaut du cloud. La modification de la le canal affecte nouveau les appareils normaux qui :

• Ne sont pas contraints
• Ne disposent pas déjà d'une surcharge cloud
• Ne disposent pas d'un niveau d'application defaultChannel défini

Si une version de test est expédiée avec defaultChannel: 'beta' et que vous modifiez ultérieurement la valeur par défaut cloud en productionles appareils qui ont démarré sur beta via la configuration restent là jusqu'à ce que vous : (a) les surprenez avec setChannel()b) les forcez, ou (c) supprimiez l'entrée de l'appareil.

Les appareils restent sur leur canal actuel à moins que vous ne fassiez :

• Forcez-les à rejoindre un autre canal.
• Appeler setChannel() (création/remplacement de la mise en surbrillance cloud) ou le modifier manuellement dans le tableau de bord.
• Supprimer/ archiver le canal sur lequel ils se trouvent (ils retomberont ensuite par la priorité à la prochaine vérification).

Si un canal est désactivé pour une plateforme (voir les commutateurs iOS / Android / Electron) et aurait autrement été sélectionné, la sélection le passe et retombe sur la règle suivante.

Remarque : Définir defaultChannel signifie que la modification nécessite un nouveau fichier binaire ; utilisez-le intentionnellement pour les tests/QA, pas pour le contrôle de production général.

Exemple de configuration Capacitor

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;

Si vous changez plus tard le panneau de bord par défaut en productionles appareils déjà sur un autre canal (via config, surcharge ou force) NE seront PAS automatiquement déplacés ; seuls les appareils frais (ou ceux dont vous annulez la surcharge/force) les récupèrent.

---

Gestion des canaux

Tout d’abord, passons par la page des canaux. Vous pouvez y accéder en cliquant sur votre application et puis cliquant sur l’onglet des canaux.

Créer un canal

Comme vous pouvez le voir, il existe un bouton plus en coin inférieur droit.1 Dans l'image) En cliquant dessus, cela ouvrira une boîte de dialogue où vous pourrez créer un nouveau canal.

Ensuite, après avoir cliqué sur Add un nouveau canal devrait apparaitre dans la liste.

Qu'est-ce que cela signifie ?

column dira Misconfigured pour un ou plusieurs de ces canaux. Vous pouvez en savoir plus sur cela Yes ici Supprimer un canal

What does misconfigured mean?

Supprimer un canal est tout à fait simple. Cliquez simplement sur l'icône de la poubelle et confirmez la suppression. (2 dans l'image)

Gestion d'un canal

En cliquant sur le nom du canal, une boîte de dialogue s'ouvrira où vous pourrez gérer les paramètres du canal. (3 dans l'image)

La page des paramètres du canal contient toutes les options de configuration pour votre canal. Allons-y, passons en revue chaque paramètre.

---

Premièrement, le Default channel commutateur. Lorsqu'il est activé, ce canal devient le canal par défaut pour les nouveaux appareils. Pour une explication complète de la façon dont les canaux par défaut fonctionnent, y compris la mise en place de paramètres spécifiques aux plateformes (un pour iOS, un pour Android, et un pour Electron), consultez la Configuration du canal par défaut section.

---

Deuxièmement, le IOS __CAPGO_KEEP_0__.

Si ce paramètre est faux, les appareils iOS ne seront pas autorisés à télécharger des mises à jour à partir de ce canal. Android Troisièmement, le IOSce paramètre est similaire à

. Si ce paramètre est faux, les appareils Android ne seront pas autorisés à télécharger des mises à jour à partir de ce canal. Electron Quatrièmement, le IOS ce paramètre est similaire à Androidet

. Si ce paramètre est faux, les applications Electron ne seront pas autorisées à télécharger des mises à jour à partir de ce canal. Disable auto downgrade under native Cinquièmement, le 1.2.0 version à envoyer sur l'App Store ou Google Play et essayez de définir la version du canal à 1.1.0 alors que l'update (dégradation) échouera.

Sixième est le Disable auto update. Cette configuration est assez complexe, et vous pouvez en savoir plus sur elle ici

Quant à Allow development build. Si c'est vrai, alors les builds de développement seront autorisés à télécharger des mises à jour à partir de ce canal. Si ce n'est pas le cas, alors toute demande de mise à jour qui a prod défini à faux sera rejetée. C'est surtout utile pour des fins de test.

Septième est le Allow Emulators. Si c'est faux, alors Capgo refusera toute demande de mise à jour qui provient d'un émulateur. C'est surtout utile pour des fins de test.

Huitième est le Allow devices to self associate. Si c'est vrai, alors le configurer le canal Cette méthode sera disponible. Si cette valeur est définie sur false et que vous essayez d'appeler la méthode "setChannel" avec ce canal, alors l'appel échouera. configurer le canal Cette méthode sera disponible. Si cette valeur est définie sur false et que vous essayez d'appeler la méthode "setChannel" avec ce canal, alors l'appel échouera.