קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
SDK של Google Play Games C++
סיכום
ארגון
נקודת הכניסה הראשית לפונקציונליות של שירותי המשחקים של Play היא המחלקה GameServices. מכונות GameServices נוצרים באמצעות GameServices::Builder. למידע נוסף, אפשר לעיין ב-GameServices
שיטות שנכנסות או משנות את המצב של כל סשן GameServices זמינות במחלקה עצמה של GameServices.
פונקציונליות נוספת נקבעת על ידי קבוצה של מנהלי תכונה לכל תכונה. המנהלים מקבצים יחד פונקציונליות שקשורה לנושאים. הם לא מכילים בעצמם מצבים שגלויים למשתמש. המנהלים מוחזרים באמצעות הפניה, וכל משך החיים שלהם מנוהל על ידי מכונת GameServices שמכילה. לכן, קוד הלקוח אף פעם לא אמור לכלול הפניה של חשבון ניהול, אלא לשמור על מכונת GameServices. הצגת מנהלים
הנתונים מוחזרים דרך אובייקטים מסוג ערך לא משתנים. הערכים האלה משקפים תצוגה עקבית של נתוני הבסיס בזמן ביצוע השאילתה. מידע נוסף זמין במאמר סוגי ערכים.
דגם הברגה
אלא אם צוין אחרת, כל השיטות של GameServices ושיטות הניהול של GameServices יהיו בטוחות בשרשור ואסינכרוניות. אפשר להפעיל אותן בכל שרשור ללא נעילה חיצונית, והן יופעלו לפי סדר ההפעלה (לפי סדר ההפעלה). באופן כללי, שיטות מוטנט (השיטות המשנות את המצב) משתמשות במודל 'אש ושכח'. שיטות הגישה (שנקראות מצב קריאה) קיימות בשתי גרסאות עיקריות. הווריאנט הראשון (עם שמות כמו GetProperty) מספק באופן אסינכרוני את התוצאות שלו לקריאה חוזרת (callback) שסופקה. הווריאציה השנייה (עם שמות כמו GetPropertyBlock) מחזירה באופן סינכרוני את התוצאות לשרשור המתקשר. בעלי הגישה רואים את התוצאות של כל המוטטורים שהופעלו בעבר. עם זאת, המוטטור יכול לשנות בכל זמן נתון את המצב של שירותי המשחקים המרוחקים, או לא.
כל הקריאות החוזרות (callback) של המשתמש (callbacks חד-פעמיים) שמסופקים כארגומנטים לשיטות גישה, או קריאות חוזרות (callbacks) רב-שימושיות שהוגדרו בזמן ה-build של GameServices) מופעלות בשרשור ייעודי של התקשרות חזרה. ה-thread הזה עשוי להיות שונה מכל קונספט פלטפורמה של 'thread ראשי' או 'thread UI'. הקריאות החוזרות של המשתמשים אמורות להתבצע במהירות, כי שרשור של התקשרות חזרה שנתקע עלול לגרום לבעיות גלויות למשתמשים (לדוגמה, עיכוב בהשלמה של בקשת יציאה).
מאפיינים בסוגי ערכים שאינם משתנים זמינים באופן סינכרוני וללא חסימה.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-07-27 (שעון UTC).
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 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."]]
