Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
SDK C++ Google Play Jeux
Résumé
Organisation
Le principal point d'entrée pour les fonctionnalités des services de jeux Play est la classe GameServices. Les instances GameServices sont créées avec GameServices::Builder. Voir GameServices
Les méthodes qui accèdent à l'état de l'ensemble de la session GameServices ou qui modifient celles-ci sont actives dans la classe GameServices elle-même.
D'autres fonctionnalités sont transmises par le biais d'un ensemble de gestionnaires par fonctionnalité. Ces gestionnaires regroupent les fonctionnalités apparentées ; ils ne contiennent pas eux-mêmes d'état visible par l'utilisateur. Les gestionnaires sont renvoyés par référence et sont contrôlés à vie par l'instance GameServices associée. Par conséquent, le code client ne doit jamais conserver la référence d'un gestionnaire, mais conserver plutôt l'instance GameServices. Consultez la page Administrateurs.
Les données sont renvoyées via des objets de type valeur immuable. Ces valeurs reflètent une vue cohérente des données sous-jacentes au moment où la requête a été effectuée. Consultez Types de valeurs.
Modèle d'exécution de threads
Sauf indication contraire, toutes les méthodes GameServices et Manager sont threadsafe et asynchrones. Elles peuvent être appelées sur n'importe quel thread sans verrouillage externe, et s'exécutent dans l'ordre dans lequel elles sont appelées. En général, les méthodes de mutateur (celles qui changent d'état) utilisent un modèle "fire-and-get". Les méthodes d'accesseur (celles qui lisent l'état) présentent deux variantes majeures. La première variante (avec des noms tels que "GetProperty") fournit ses résultats de manière asynchrone à un rappel fourni. La deuxième variante (avec des noms tels que "GetPropertyBlocking) renvoie les résultats de manière synchrone au thread appelant. Les accesseurs voient les résultats de tous les mutateurs appelés précédemment. Toutefois, le mutateur peut ou non avoir modifié l'état distant des services de jeux à un moment donné.
Tous les rappels utilisateur (rappels uniques fournis en tant qu'arguments aux méthodes d'accesseur ou rappels multi-usages configurés au moment de la compilation de GameServices) sont appelés sur un thread de rappel dédié. Ce thread est potentiellement différent de tout concept de plate-forme de "thread principal" ou de "thread UI". Les rappels utilisateur doivent s'exécuter rapidement, car un thread de rappel bloqué peut entraîner des problèmes visibles par l'utilisateur (par exemple, le traitement retardé d'une requête de déconnexion).
Les propriétés des types de valeurs immuables sont disponibles de manière synchrone et sans blocage.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/07/27 (UTC)."],[],[],null,["# Google Play Games C++ SDK\n=========================\n\nSummary\n-------\n\nOrganization\n\nThe main entry point for Play Game Services functionality is the GameServices class. GameServices instances are created with GameServices::Builder. See [GameServices](/games/services/cpp/api/other/classgpg_1_1GameServices)\n\nMethods that access or mutate the state of the entire GameServices session live in the GameServices class itself.\n\nOther functionality is indirected through a set of per-feature managers. These managers group related functionality together; they contain no user-visible state themselves. Managers are returned by reference, and have lifetime controlled by the containing GameServices instance. As such, client code should never hold onto a manager reference, but instead hold on to the GameServices instance. See [Managers](/games/services/cpp/api/other/group__Managers).\n\nData is returned via immutable value type objects. These values reflect a consistent view of the underlying data at the point in time the query was made. See [Value Types](/games/services/cpp/api/other/group__ValueType).\n\nThreading Model\n\nUnless otherwise noted, all GameServices methods and Manager methods are threadsafe and asynchronous. They can be called on any thread without external locking, and will execute in an order consistent with their invocation order. In general, mutator methods (those that change state) use a fire-and-forget model. Accessor methods (those that read state) come in two major variants. The first variant (with names like GetProperty) asynchronously supply their results to a provided callback; the second variant (with names like GetPropertyBlocking) synchronously return their results to the calling thread. Accessors see the results of all mutators that have been called prior; however, the mutator may or may not have modified the remote Game Services state at any given time.\n\nAll user callbacks (whether one-shot callbacks supplied as arguments to accessor methods, or multi-use callbacks configured at GameServices build time) are invoked on a dedicated callback thread. This thread is potentially distinct from any platform concept of a \"main thread\" or \"UI thread\". User callbacks should execute quickly, as a stalled callback thread can cause user-visible issues (for example, delayed completion of a sign-out request).\n\nProperties on immutable value types are available synchronously and without blocking."]]
