Comprendre les paramètres de compatibilité de votre application

Activé par défaut pour les applications existantes afin de garantir la compatibilité

Désactivé par défaut pour les nouvelles applications , afin qu'elles ne soient pas soumises aux limitations du système hérité.

brainCloud 5.8 permet désormais de fournir un contexte supplémentaire lors d'un achat sur les App Stores de Google ou d'Apple. Pour ce faire, il faut appeler CachePurchasePayloadContext() juste avant d'appeler les API d'achat de la plateforme.

Laisser cette option activée permet aux achats Apple et Google Play de fonctionner (avec une meilleure adaptation du prix au contexte du produit), même si les données de charge utile mises en cache sont absentes. Remarque : si la charge utile du contexte mis en cache est présente, elle sera utilisée.

Les développeurs ne doivent désactiver cet indicateur que s'ils ont ajouté les appels CachePurchasePayloadContext() appropriés à leur application.

Avant la version 5.5, les scores des utilisateurs et des groupes étaient enregistrés dans la même collection pour une application, ce qui n'est pas optimal, en particulier lorsqu'il s'agit de classements [fragmentés] plus grands.

Laisser cet indicateur activé préserve l'ancien comportement de stockage des scores ensemble.

Remarque : la désactivation de cet indicateur pour une application existante (avec des scores de groupe déjà stockés dans la collection) entraînera la perte des scores de groupe existants.

Dans la version 5.4, brainCloud a ajouté de nouveaux événements de progression qui sont diffusés à tous les membres du lobby lorsque les serveurs de salle et de relais hébergés sont lancés.

Les applications clientes existantes peuvent être perturbées par ces événements. Elles sont donc supprimées par défaut (pour les applications existantes uniquement).

Laisser cet indicateur activé supprime ces nouveaux événements

Avant la version 5.3 , brainCloud n'appliquait pas les valeurs de code de pays qui seraient acceptées par le serveur

À partir de la version 5.3 , le nouveau comportement consiste à rejeter les mises à jour qui ne respectent pas la liste acceptée des codes de pays.

Laisser cet indicateur activé continue de permettre la définition de n'importe quelle valeur

Dans la version 5.3, si l'argument data est nul lors de la mise à jour d'un score, la valeur data existante est conservée. Avant la version 5.3, la valeur data était réinitialisée à zéro.

Laisser le drapeau activé a préservé le comportement hérité

Avant la version 5.2 , brainCloud ne garantissait pas correctement que seul le joueur actuel pouvait appeler SubmitTurn() lors d'une partie asynchrone. Ce problème a été corrigé.

Notez que cet indicateur n'affecte aucune des autres méthodes AsyncMatch - ce qui garantit également que seul le joueur actuel peut mettre à jour le match.

Les applications qui doivent mettre à jour une correspondance via le joueur non actuel (par exemple, dans les scénarios de délai d'attente) sont encouragées à se faire passer pour l'autre joueur à l'aide d'un script de code cloud via cette technique ( https://help.getbraincloud.com/fr/articles/3631086-comment-usurper-l-identite-d-un-utilisateur-a-l-aide-de-l-api-braincloud ) plutôt que d'activer cet indicateur de compatibilité.

Laisser cet indicateur activé compromet la sécurité des correspondances.

Avant la version 5.2, brainCloud effectuait des recherches sensibles à la casse pour les codes de promotion. Le système a été modifié pour stocker les codes en MAJUSCULES et effectuer des recherches insensibles à la casse. Cet indicateur de compatibilité concerne les applications plus anciennes avec des codes de promotion existants, afin de garantir que ces derniers soient toujours trouvés par l'API.

Laisser cet indicateur activé ralentit les recherches de codes de promotion.

Avant la version 5.1, brainCloud autorisait par erreur l'appel de AwardUserItem() depuis le client. Nous l'avons même ajouté par erreur aux librairies ! Cet appel est désormais limité au serveur, sauf si cet indicateur de compatibilité est activé.

Laisser cet indicateur activé compromet la sécurité des éléments de votre application.

Avant la version 5.0, le paramètre eventType de SendEvent() était fortement recommandé, mais non requis. Ce paramètre est désormais requis par défaut.

Laisser cet indicateur activé autorise les types d'événements nuls, mais ralentira le traitement des événements de votre application.

Dans la version 4.15, brainCloud a ajouté une en-tête accept par défaut à tous les appels HTTPClient afin d'améliorer la compatibilité avec les systèmes externes. Cette modification pouvait entraîner des problèmes si un système tiers n'attendait pas l'en-tête pour une raison quelconque.

Laisser cet indicateur activé supprime l'en-tête, sauf s'il est spécifiquement ajouté par le développeur aux appels HTTPClient.

Le comportement par défaut de GetEntityPage() a été modifié dans un correctif spécial dans 4.10 suite à de graves problèmes de performances rencontrés par plusieurs clients avec cet appel. Ce problème était lié à la manière dont l'appel gérait la vérification des autorisations ACL (par défaut).

L'appel a été modifié pour exclure la recherche d'objets partagés (c'est-à-dire des entités possédées avec ACL définis comme accessible par d'autres utilisateurs) au profit d'une recherche plus stricte et plus rapide des objets appartenant à l'utilisateur actuel.

Plus d'informations ici

Les applications ne doivent pas activer cet indicateur . Si une application doit effectuer une recherche parmi des entités partagées, elle doit inclure spécifiquement ownedOnly: false dans le contexte de la requête options

La version 4.10 a corrigé certains problèmes de comportement des listes de contrôle d'accès (ACL) des groupes et des entités de groupe. En particulier, certaines opérations GroupEntity étaient gérées via l'ACL des groupes plutôt que via l'ACL des entités de groupe.

La version 4.9 a mis à jour la gestion des chemins de brainCloud pour la méthode bridge.callScript() afin de la rendre plus cohérente avec les normes de l'industrie (et notre propre méthode bridge.include()).

Dans la version 4.8, les structures de données et les identifiants couramment utilisés entre les services de lobby et les services de relais ont été modifiés pour plus de cohérence. L'impact principal a été le remplacement du champ owner des données de lobby par le champ ownerCxId approprié.

L'activation de cet indicateur ajoute à nouveau le champ hérité owner dans les messages de données du lobby.

Dans la version 4.7, le service Catalogue d'éléments a été refactorisé pour permettre une meilleure gestion des fichiers image.

Dans le cadre de ces améliorations, le service (par défaut) ne permet plus de définir des chemins d'image personnalisés (c'est-à-dire des chemins non ancrés dans brainCloud) dans le champ d'image.

Les applications souhaitant utiliser des URL d'image personnalisées peuvent utiliser la section JSON personnalisée ou les sections de données de ressources pour ces informations.

Plusieurs méthodes API, y compris les appels UserService SysGetPage/Offset(), ont été corrigées pour renvoyer correctement "profileId" au lieu de "playerId".

Le comportement de GetMultiSocialLeaderboard() a été modifié dans la version 4.4 afin qu'il ne renvoie plus les amis qui n'ont joué sur aucun des classements demandés

Le schéma des tâches intégrées dans une quête a changé dans la version 4.3.5.

Activez cet indicateur pour conserver l'ancien comportement.

Le stockage des transactions d'achat a été considérablement modifié dans la version 3.9

L'activation de cette option stocke les transactions dans le nouveau et l'ancien format (hérité).

Cette option est obsolète et ne doit jamais être activée.

La version 3.5 a nettoyé la réponse JSON pour certains appels d'API.

La version 3.3 a corrigé le json généré lors de la gestion des récompenses pour les augmentations de niveau XP ; le json renvoyé n'inclut plus la section "récompense" redondante.

Dans la version 4.13, le traitement des produits IAP non consommables a été modifié - de sorte que les récompenses soient traitées même si la transaction avait été précédemment traitée par l'utilisateur.

L'activation de cette option désactive ce comportement. Consultez les notes de version 4.13 pour plus d'informations.

Une optimisation significative des performances de l'API UpdateSingleton() a été réalisée dans la version 3.2.5.

Dans le cadre de cette optimisation, les champs entityId, acl, createdAt et updatedAt ne sont plus renvoyés dans la réponse à l'appel.

L'activation de cette option annule la modification, mais supprime également l'optimisation, ce qui entraîne des appels d'API UpdateSingleton() considérablement plus lents.

Avant la version 3.2, le système d'événements brainCloud utilisait des identifiants d'événements numériques : eventId. Ces identifiants présentaient des limitations importantes, notamment une lenteur à générer. Le système a été remanié pour utiliser un nouvel identifiant amélioré basé sur les GUID : evId.

L'activation de cet indicateur de compatibilité indique au système de continuer à créer (avec une certaine baisse de performances) les anciens événements eventId. Ceci est nécessaire si votre application utilise encore les anciennes méthodes d'API. Il est recommandé à toutes les applications de migrer vers les nouvelles API et la nouvelle version evId dès que possible.

Laisser cet indicateur activé ralentit le traitement des événements.

Activez cette option pour vérifier et obtenir les informations sur les récompenses de paiement incluses dans la réponse d'authentification lorsque le joueur se connecte.

Lorsque cette option est activée, 5 comptes d'API groupés sont cumulés à chaque connexion. 5 comptes d'API groupés équivalent à la moitié d'un compte d'API. [Le nombre d'API groupés s'accumule selon un ratio de 10:1].

Cette option est désactivée par défaut, car la plupart des applications souhaitent récupérer manuellement les informations de récompense et présenter les gains directement au joueur.

Dans brainCloud 3.2, par mesure de sécurité et de lutte contre la fraude, nous avons supprimé [par défaut] la possibilité pour les applications clientes de gérer directement les soldes de monnaie virtuelle. Les méthodes concernées, AwardCurrency(), ConsumeCurrency() et ResetCurrency() sont toujours exécutables depuis le Cloud Code côté serveur, ce qui est beaucoup plus sécurisé.

L'activation de cet indicateur de compatibilité remplace cette nouvelle restriction et permet à ces appels de continuer à être appelés à partir des librairies clientes.

L'activation de ce paramètre désactive les optimisations du réseau de distribution de contenu (CDN) introduites dans brainCloud 2.25. Cela peut être dû au fait que votre client ne gère pas correctement les redirections HTTP intégrées au traitement CDN. [Votre application nous demande un fichier spécifique, et nous redirigeons la requête vers le serveur CDN approprié. Les anciennes versions d'Unity, en particulier, ne prennent pas en charge les redirections ; cette option doit donc être activée pour les applications existantes basées sur Unity.]

Solution de contournement : les applications sans prise en charge de la redirection doivent utiliser la méthode GetCDNUrl() permettant de récupérer la version CDN de l'URL d'un fichier pour des téléchargements plus rapides (au lieu d'activer ce paramètre).

Pour de meilleurs résultats, l'indicateur de compatibilité de récupération de fichiers doit être laissé décoché.

Avant la version 2.25, brainCloud renvoyait toujours le contenu complet d'un objet entité après les opérations Create() et Update(). Cela semblait logique à l'époque, mais lorsque certains clients ont commencé à écrire des objets de 100 Ko ou plus, il est devenu évident que cela constituait un gaspillage de bande passante.

L'activation de cet indicateur de compatibilité ralentira inutilement les réponses des clients et augmentera l'utilisation des données de votre application (affectant vos clients).

Dans brainCloud 2.25, nous avons corrigé un défaut qui empêchait le serveur d'appliquer correctement les soldes de devises dans tous les scénarios de consommation de devises. Ce problème a depuis été résolu, mais l'indicateur de compatibilité est toujours présent au cas où certaines applications dépendaient du comportement précédent.

brainCloud a ajouté la prise en charge des amis gérés manuellement dans la version 2.22, ce qui a entraîné des modifications des données JSON renvoyées par les API de classement social. Cette option ne doit être activée que si votre application est antérieure à la version 2.22 et dépend des détails de l'ancien format.

Avant la version 2.22, brainCloud était utilisé pour renvoyer toutes les entités utilisateur d'un utilisateur en réponse aux méthodes Authenticate() et ReadPlayerState(). C'était très pratique pour lancer et se connecter rapidement aux applications, mais cela n'a pas fonctionné lorsque certaines applications ont commencé à stocker des milliers d'entités par utilisateur !

brainCloud ne le fait plus par défaut.

brainCloud inclut un système d'événements permettant d'envoyer des messages (événements) à des utilisateurs individuels. Ceci est utile pour envoyer des messages de chat, des récompenses, des cadeaux, des défis, etc. Les versions précédentes de brainCloud vérifiaient automatiquement les événements entrants pour un utilisateur lors du traitement de chaque appel d'API. Ce traitement a un impact négatif sur le serveur et, comme la plupart des applications n'utilisent pas d'événements, le traitement des applications courantes est inutilement ralenti. Les applications peuvent utiliser la méthode GetEvents() pour interroger les nouveaux événements.

La mise à jour brainCloud RTT offre une notification en temps réel supérieure pour la plupart des types d'événements. Les applications nécessitant une notification en temps réel doivent utiliser le RTT plutôt que d'activer cette option.

L'activation de l'indicateur ralentira tout le traitement de l'API pour l'application.

Dans brainCloud 2.10, nous avons ajusté les retours JSON des scripts Cloud Code afin de mieux les aligner sur ceux des appels API classiques. Ce paramètre permet aux scripts plus anciens de continuer à s'exécuter.