You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Social SDK: Update UFL Guide with new helper functions (#7689)
* Social SDK: Update UFL Guide with new helper functions
Update documentation to show how to use
`Client::GetRelationshipsByGroup` and
`Client::SetRelationshipGroupsUpdatedCallback`.
* Apply suggestion from @anthonydiscord
Review upadate
Co-authored-by: Anthony <anthony.tesija@discordapp.com>
---------
Co-authored-by: Anthony <anthony.tesija@discordapp.com>
@@ -25,13 +25,18 @@ Before you begin, make sure you have:
25
25
26
26
### Implementing a Unified Friends List
27
27
28
-
The Discord friend list is ultimately constructed from two entities: Relationships, and Users. You can query Relationships API to find everyone a user is a friend with, and the Users API to find the necessary extra information for rendering the list, such as whether they are online or not.
28
+
The Discord friend list is ultimately constructed from two entities: Relationships, and Users. You can query
29
+
Relationships API to find everyone a user is a friend with, and the Users API to find the necessary extra information
30
+
for rendering the list, such as whether they are online or not.
29
31
30
32
### Relationships
31
33
32
-
[Relationships](/docs/discord-social-sdk/development-guides/managing-relationships) are how Discord models friends, friend requests, and more. All relationships for the current user are loaded when the Client connects. Each relationship has a target user id, and a type, such as `Friend`, `PendingOutgoing`, or `Blocked`. The set of all relationships can be queried with [`Client::GetRelationships`].
34
+
[Relationships](/docs/discord-social-sdk/development-guides/managing-relationships) are how Discord models friends,
35
+
friend requests, and more. All relationships for the current user are loaded when the Client connects. Each
36
+
relationship has a target user id, and a type, such as `Friend`, `PendingOutgoing`, or `Blocked`.
33
37
34
-
To allow users to manage their relationships in your game, you should provide a way to accept or reject friend requests, block users, and manage pending requests. See [Development Guide: Managing Relationships in Your Game](/docs/discord-social-sdk/development-guides/managing-relationships) for implementation details.
38
+
To allow users to manage their relationships in your game, you should provide a way to accept or reject friend
39
+
requests, block users, and manage pending requests. See [Development Guide: Managing Relationships in Your Game](/docs/discord-social-sdk/development-guides/managing-relationships) for implementation details.
35
40
36
41
### Users
37
42
@@ -50,13 +55,144 @@ The SDK will only display activities associated with the current game, meaning y
50
55
51
56
See our [Design Guidelines: Status & Rich Presence](/docs/discord-social-sdk/design-guidelines/status-rich-presence) for best practices on displaying presence information.
52
57
53
-
Let's combine to create a unified friends list.
58
+
There are two ways in which you can create a unified friends list in your game:
59
+
60
+
1. Using the SDK Unified Friends List helper functions, which automatically group and sort
61
+
relationships and users for you.
62
+
2. Directly retrieving relationships and users from the SDK, and sorting manually.
63
+
64
+
## Approach 1: Using SDK Unified Friends List Helper Functions
65
+
66
+
:::info
67
+
This approach is recommended as it significantly reduces the amount of code you need to write and maintain compared to
68
+
manually fetching and organizing relationships, while ensuring your friends list follows Discord's best practices.
69
+
:::
70
+
71
+
The Discord Social SDK provides built-in helper functions that automatically group and sort your friends list according
72
+
to Discord's [recommended design guidelines](/docs/discord-social-sdk/design-guidelines/unified-friends-list).
73
+
This approach is generally simpler and more maintainable than manually fetching and organizing relationships.
74
+
75
+
The SDK automatically organizes friends into the three groups we find via [`RelationshipGroupType`]:
76
+
-`OnlinePlayingGame`: Friends who are online and currently playing your game
77
+
-`OnlineElsewhere`: Friends who are online but not playing your game
78
+
-`Offline`: Friends who are offline
79
+
80
+
### Step 1: Display the Unified Friends List
81
+
82
+
The [`Client::GetRelationshipsByGroup`] method returns a pre-sorted list of relationships for a specific group type.
83
+
This eliminates the need to manually filter, categorize, and sort friends yourself. The SDK handles all the logic
84
+
for determining which group each friend belongs to based on their online status and game activity, and
85
+
automatically sorts users within each group (for example, users who have played your game are moved to the top of
86
+
the OnlineElsewhere group).
87
+
88
+
Let's create a function that uses the SDK helper functions to display a properly organized friends list:
@@ -122,7 +258,7 @@ This will output the raw relationship data to the console. You can use this info
122
258
123
259
---
124
260
125
-
## Step 2: Organize Relationships
261
+
### Step 2: Organize Relationships
126
262
127
263
Based on our design guidelines for a [Unified Friends List](/docs/discord-social-sdk/design-guidelines/unified-friends-list), you should separate the player's friends list into three sections: `Online - GameTitle`, `Online - Elsewhere`, and `Offline`.
If we build and run our application, we should now see a list of friends separated into three categories: `Online - GameTitle`, `Online - Elsewhere`, and `Offline`.
221
357
222
-
## Step 3: Monitor Changes to Users
358
+
###Step 3: Monitor Changes to Users
223
359
224
360
To monitor for user changes, we're going using the [`Client::SetUserUpdatedCallback`] function.
225
361
@@ -242,7 +378,7 @@ user list, or similar operations.
242
378
:::
243
379
---
244
380
245
-
## Step 4: Monitor Changes in Relationships
381
+
### Step 4: Monitor Changes in Relationships
246
382
247
383
Let us setup two callbacks to handle relationship updates.
248
384
@@ -251,7 +387,7 @@ These examples rebuild the friends list from scratch every time a relationship c
251
387
recommend maintaining a collection of [`UserHandle`] objects and adding and removing them appropriately.
252
388
:::
253
389
254
-
### Relationship Created Callback
390
+
#### Relationship Created Callback
255
391
256
392
This can happen when a user sends or accepts a friend invite, or blocks a user.
0 commit comments