Session

When a game client starts, makes some requests towards Unisave and then exits. This series of requests is said to belong to a single session. So a session is the action of someone playing your game. The word session is however also used to describe a short-term storage that belongs, well, to a session. This documentation page describes how you can use Unisave session storage.

What is a client session

When you make a facet call, the call also contains a piece of data called session ID. It is a short string, generated by the server during the first request. The client then remembers the session ID and sends it back to the server with every following request. This way when the server receives a request, it looks at the session ID and knows "oh, it's this guy!".

When you start your game (or Unity Editor), the session ID is not known. Therefore the first request sent will not contain it and that will trigger the start of a new session. Then, when your game exists, or is inactive for more than 60 minutes, the session ID is automatically forgotten.

The session storage is a small key-value storage (like PlayerPrefs) that is bound to a session ID and stored on the server (in the database). It is used to remember information about the session. The Auth facade uses session storage to remember who is logged in within the session. That's why you send your email and password only once and then the server remembers. The session ID acts as a temporary password that identifies you for the duration of a session.

Using session storage

When code executes in a facet, it already executes in the context of a session. Even the first request. Therefore you always have access to the session storage via the Session facade.

You can store a value under a key in the session:

Session.Set("some-key", someValue);

The value can be anything serializable. You can then retrieve the value from the session at some later time:

TValue value = Session.Get<TValue>("some-key");

The value type should match the type that has been stored otherwise the deserialization fails. You can also specify the default value to be returned in case the key is not present in the storage:

bool boolValue = Session.Get<bool>("some-key", false);

You can also check whether a key is present:

bool isKeyKnown = Session.Exists("some-key");

This will however return true even if the value is null. If you want to check that it exists and is non-null, use .Has:

bool isKeyKnownAndNonNull = Session.Has("some-key");

You can forget a key from the session (does nothing if the key isn't present):

Session.Forget("some-key");

And lastly you can clear the entire storage:

Session.Clear();

Unity Editor and Play Mode

When you exit your game, the session ID is forgotten which also acts as a logout. This is undesirable when you develop your game so this does not happen when you exit play mode. If you enter play mode, login, exit play mode and then enter play mode in a scene that expects you to be logged in, you will be logged in. This way you can debug a logged-in-only scene without having to log-in over and over again. Neat.