Introduction to GetSocial User Management

GetSocial SDKs provide User Management facilities which let you make user interactions more personal and engaging.

User Management in the Web SDK

The rest of this page applies only to our mobile SDKs. Due to platform differences, the Web SDK has a more minimal approach to user management - see the guide for details.

Features

• Guest access: allow anonymous users to interact with GetSocial.
• Authentication with social or custom identities: we support user authentication via Facebook or your custom authentication system. Authentication happens transparently for the user, without any extra login screens.
• Profile customizations: set user display name and avatar to match the in-game or social profile.
• Custom user properties: attach any key-value pairs to the user profile, like the current level in a game or join date.

Key Advantages

• Single point of authentication between GetSocial and your app: provides seamless access to your users for all GetSocial features, so your users do not have to authenticate twice.
• Cross-platform and cross-device support: allows you to identify and authenticate users across platforms and multiple devices.
• User profiles: create user profiles using user identities and custom user properties.

How Does It Work

As soon as you initialize GetSocial SDK, an anonymous user will be created, ready to interact with all SDK features.

GetSocial SDK allows you to identify your users by adding User Identities from Facebook or your own identity provider.

This user is persisted between app restarts and may be bound to multiple user’s physical devices (e.g., a phone and a tablet).

User’s identity is a combination of Provider Id and a User Id that allows you to identify users easily inside SDK without the need to create or store IDs of users other than the ones you already use in your app.

The GetSocial user is persistent across sessions, that means that anything you set up for this user, will be available the next time the user opens your app, and our SDK gets initialized. There is no need to add identities each time.

Getting User Object

GetSocial SDK defines few types of user objects: current (authenticated), public user profiles, conflict user and user reference.

Current user object represents the authenticated entity and is available as soon as the SDK is initialized. Current user can be anonymous. It is not possible to obtain the instance of current user object, but SDK provides methods to read and update user properties.

Public user profiles represent any user in GetSocial. Read-only instances on public users are returned from various SDK methods.

Conflict user appears when you’re trying to add the identity that already belongs to another user.

User reference is a lightweight representation of the public user profile and it contains basic information like id, name and avatar URL. It is used when queried a large list of users.

Check how to obtain user objects.

Anonymous Users and Users with Identities

After the SDK gets initialized, it always has a user entity operating with all the features. The user can be either anonymous or bound to some identity (e.g., facebook, email login, your custom provider, etc.).

The first time SDK gets initialized on the user’s device, it receives an anonymous user. Anonymous user has no identity attached and is bound only to the device it was created on.

By default, anonymous users can interact with all the features on the GetSocial SDK without any limitations. Random display name (i.e., “User 1234567890”) and empty avatar will be set for this user. You can change those later if you want.

The user will remain anonymous until you add the first identity. For instance, after people log in with facebook into your app.

You have to add identities to transfer user between devices.

Read more about managing identities.

Handling Multiple User’s Devices

A quite common scenario is that your users change devices or want to use your app on several devices at the same time, and of course, they might want to keep using the same user on all devices.

You can easily recover a user by adding, to the current GetSocial user, the same identity that you already added to the user on the first device.

Let’s look into the particular use case.

You identify users in the app with Facebook. Linda, a new user, has just authenticated with Facebook and you have added the Facebook identity to the GetSocial user.

After some time, Linda gets a new device and wants to continue using your app there.

She will open the app and will authenticate again with Facebook to get back her user. At this moment, you will need to add the Facebook identity to the current anonymous GetSocial user on this new device.

When you add FB identity, SDK will detect that the identity already belongs to an existing GetSocial user and raise an identity conflict callback that you can easily resolve with either:

• Current User - the GetSocial user currently on the device
• Remote User - the user Linda had on the first device.

The user you choose to resolve the conflict with will be the one available as GetSocial current user.

If you are using a custom provider to identify your users, the flow is the same.

Read more about managing user’s identities.

Reading and Updating User Properties

By default, anonymous users get random display name (i.e., “User 1234567890”) and empty avatar, custom user properties maps are empty. You can change those values at any time.

Custom properties

In addition to user display name and avatar URL, we allow you to set any custom property for each user. Custom properties are split up into two categories: Private and Public.

Private user properties are visible only for current user. You can use it to keep some private data about the user, that should not be visible for other users: current level progress, bonuses, user profile data(phone number, birth, etc.) or anything other information you need to have about the user.

Main advantages of this approach:

• You do not need to store any data about the user on his phone;
• You do not need to develop your backend side with user-related data - keep everything in one place;
• Properties are shared across all user devices.

Public properties, in opposite to Private ones, are visible to other users in PublicUser entity. So, if you are logged in as User1, you can get Public properties of User2, but can not get Private. Also, you can only change properties(private or public) of the current authenticated user.

Public properties can be used for information you want to share with other users. For example, you have a user profile screen, where you can look at your friend profile. In addition to avatar and name, you may want to show something else:

• Social part(user mood, relatives, joining date, etc.)
• In-game part(user location in your world, pet, main artifact, etc.)
• SDK part - if our SDK doesn’t provide you with some functionality you’d like to keep about the user, you can ask us to add this feature, and you will see it in few days in our new release, but if you don’t want to wait for that, you still can keep it in custom properties.

Read more about reading and updating user’s properties.

Next Steps

• Learn the User Management best practices.
• Learn how to authenticate users within GetSocial.

Give us your feedback! Was this article helpful?

😀 🙁