Skip to main content

Migration

Migration Guide: 1.4.x / 1.5.x → 1.6.x​

This document describes the breaking changes and recommended migration steps when updating from versions 1.4.x / 1.5.x to 1.6.x of the SDK.

0. Migration Instructions for Plugin Files (Unity Project)​

Before applying code-level changes, you must correctly migrate plugin files inside the Unity project.

Step-by-step instructions:​

  1. Close the Unity Editor

    • Ensure that the editor is fully shut down before modifying files.

  2. Clean old plugin files

    • Delete all folders and files inside:
      Assets/Platform101XP
    • Except the following folders, which should be kept:
      • Assets/Platform101XP/Editor
      • Assets/Platform101XP/iOSConfig
      • Assets/Platform101XP/AndroidConfig

  3. Review Unity build configuration files

    • The plugin uses only its own custom AndroidManifest.xml located in:
      Assets/Plugins/Android/AndroidManifest.xml
    • The plugin does not currently use any other custom Unity Android build configuration files (Gradle templates, ProGuard files, etc.).
    • If your project uses custom Gradle templates or other build configuration overrides, verify that they do not contain old 101XP plugin content.
      If such leftover content exists, remove it manually.

  4. Optional cleanup

    • You may delete the entire folders:
      • Assets/Plugins/Android
      • Assets/Plugins/iOS
    • (Unity will recreate necessary folders or the plugin will reimport them.)

  5. Re-import the plugin

    • Reopen the Unity Editor.
    • Import the new version of the plugin (1.6.x).
    • After import, reapply plugin settings:
      Window → P101XP → Settings → Apply

1. Overview of Breaking Changes​

1.1. Data member naming convention changed​

  • Fields previously in snake_case are now camelCase.
  • Several fields were renamed entirely (not only case-converted).

1.2. Event payload structures changed​

AuthorizeResult and AccountResult were redesigned in 1.6.x.

1.3. New runtime access methods​

Authorization and account state is now accessed via:

public Token GetToken();
public Account GetAccount();

1.4. Namespaces Update (NEW in 1.6.x)​

In versions 1.4.x / 1.5.x, data classes had no namespace and lived in Unity’s default namespace.

Starting from 1.6.x, all data classes were moved into:

namespace Platform101XP.Entities

Migration requirement​

Add this line to all C# files where these SDK classes are used:

using Platform101XP.Entities;

This applies to:

  • AuthorizeResult
  • Token
  • AccountResult
  • Account
  • Other SDK data classes

If your project relied on implicit default namespace resolution, compilation errors will occur until this using directive is added.

2. Data Member Renaming​

2.1. General Naming Convention Change​

All (or most) data classes that previously used snake_case members now use camelCase.

For example (generic pattern):

  • access_token → accessToken
  • user_name → userName
  • user_photo_url → userPhotoUrl

When migrating, please update all your code that directly accesses these fields to use camelCase.

2.2. Specific Renamed Members​

In addition to the case change, some members were explicitly renamed:

Old nameNew name
error_messageerror
is_initializedinitialized
is_invitedinvited

Please update all references to these fields accordingly.

3. Authorization Result Changes​

3.1. Event Signature​

The authorization event keeps the same delegate type and event name:

public delegate void ResultOfAuthorize(AuthorizeResult authorizeResult);
public event ResultOfAuthorize AuthorizeResultEvent;

However, the AuthorizeResult structure has changed.

3.2. Old AuthorizeResult (≤1.5.x)​

public class AuthorizeResult
{
    public string access_token;
    public long   expires;
    public string type;
    public string provider;
    public bool   is_guest;
    public string error_message;
}

3.3. New AuthorizeResult (1.6.x)​

public class AuthorizeResult
{
    public Token  token;
    public string error;
}

Where Token is defined as:

public class Token
{
    public string accessToken;
    public long   expires;
    public string type;
    public string provider;
}

3.3.1. Key Changes​

  1. Token fields moved into a nested Token class

    • Previously: access_token, expires, type, provider directly on AuthorizeResult.
    • Now: wrapped inside AuthorizeResult.token of type Token.

  2. Error field renamed

    • error_message → error.

  3. Guest flag removed

    • is_guest was removed from AuthorizeResult.
    • Guest status is now determined via account information (see section 4).

3.4. Migration Example​

Before (≤1.5.x):

void OnAuthorize(AuthorizeResult result)
{
    if (!string.IsNullOrEmpty(result.error_message))
    {
        // handle error
        return;
    }

    if (result.is_guest)
    {
        // guest flow
    }
    else
    {
        // logged-in user flow
    }

    var token = result.access_token;
}

After (1.6.x):

void OnAuthorize(AuthorizeResult result)
{
    if (!string.IsNullOrEmpty(result.error))
    {
        // handle error
        return;
    }

    // Token object with camelCase members
    Token token = result.token;
    if (token == null)
    {
        // handle unexpected missing token
        return;
    }

    // Guest / login status is now handled via Account (see section 5)
}

4. Account Result & Event Changes​

4.1. Event Signature​

The account-related event keeps the same delegate type and name:

public delegate void ResultOfGettingAccount(AccountResult result);
public event ResultOfGettingAccount GetAccountEvent;

The payload type is now AccountResult with the following structure:

public class AccountResult
{
    public Account account;
    public string  error;
}

Where Account is:

public class Account
{
    public long   accountId;
    public long   portalId;
    public long   userGameId;
    public long   mobileId;
    public string userName;
    public string userPhotoUrl;
    public bool   isGuest;
}

4.2. Guest and Login Status​

The guest flag is now located in the Account object:

  • Use Account.isGuest to check whether the user is a guest.
  • Use Account presence (null vs non-null) to determine if account information is available.

Example:

void OnAccountReceived(AccountResult result)
{
    if (!string.IsNullOrEmpty(result.error))
    {
        // handle error
        return;
    }

    var account = result.account;
    if (account == null)
    {
        // account info not available yet or failed to load
        return;
    }

    bool isGuest = account.isGuest;
    // use account.accountId, account.userName, etc.
}

5. New Runtime Methods: GetToken() and GetAccount()​

To simplify checking the current authorization state, version 1.6.x introduces:

public Token   GetToken();
public Account GetAccount();

5.1. Return Values​

  • Both methods return null if the user is not authorized at all, including cases where:

    • The user is not logged in.
    • The user does not even have a guest session.

  • If the user is authorized as guest or a normal user:

    • GetToken() will eventually return a valid Token.
    • GetAccount() will eventually return a valid Account (with isGuest indicating guest vs regular user).

5.2. Timing & Synchronization​

Token and account information are fetched via two separate requests inside the SDK:

  • Token information usually appears earlier.
  • Account information may be available later.

This means:

  • If GetToken() returns a non-null value, it does not necessarily mean that GetAccount() will immediately return a non-null value.
  • Your code should handle the possibility that token is ready while account is still loading.
  1. Initial state check:
var token   = sdk.GetToken();
var account = sdk.GetAccount();

bool isAuthorized = token != null;
bool hasAccount   = account != null;
bool isGuest      = account != null && account.isGuest;
  1. Reacting to asynchronous updates:

Use the events to be notified when data becomes available:

  • AuthorizeResultEvent — triggered when token-related authorization completes.
  • GetAccountEvent — triggered when account information is obtained.

Example:

sdk.AuthorizeResultEvent += OnAuthorize;
sdk.GetAccountEvent      += OnAccountReceived;

This pattern lets you:

  • Use GetToken() / GetAccount() for polling / immediate checks.
  • Use events for synchronizing with the moment when the SDK actually receives the data.

6. Migration Checklist​

When upgrading from 1.4.x / 1.5.x to 1.6.x, make sure to:

  1. Update naming for all data members:

    • Change snake_case fields to camelCase where applicable.

    • Apply explicit renames:

      • error_message → error
      • is_initialized → initialized
      • is_invited → invited

  2. Update authorization handling:

    • Replace direct usage of AuthorizeResult.access_token, expires, type, provider with AuthorizeResult.token.accessToken, token.expires, etc.
    • Replace error_message with error.
    • Remove usage of is_guest on AuthorizeResult and migrate to Account.isGuest.

  3. Update account handling:

    • Adjust handlers for GetAccountEvent to accept the new AccountResult structure.
    • Use AccountResult.error instead of any previous error field.
    • Use Account.isGuest to distinguish guest vs logged-in users.

  4. Use new helper methods where appropriate:

    • Use GetToken() and GetAccount() to check current state instead of relying only on events or old APIs.
    • Handle the fact that GetToken() may become available earlier than GetAccount().

  5. Test guest and logged-in flows:

    • Verify behavior for:

      • Completely unauthorized user.
      • Guest user.
      • Fully logged-in user.

    • Confirm you correctly handle null returns from GetToken() / GetAccount() and error fields in results.

If you encounter any specific issues during migration (for example, ambiguous field mapping or event ordering problems), consider logging the raw structures in your environment to verify the actual data and adjust your migration accordingly.