Xenos Client
A XenosClient represents the interface to Xenos, through which user and profile data regarding specific accounts may be retrieved. This client may be used to interact with a specific Xenos instance and its datastore. No internal caching is performed, as the latency to Xenos should already be pretty low and caching twice could introduce more stale data into the lookups.
All lookups are executed asynchronously (through coroutines) and return their results after the response from the Client has been recorded. Endpoints that work with streams of data are also executed asynchronously and are wrapped into flows to be compatible with the coroutines. Errors will always be returned immediately if they are discovered and the operation will only be automatically retried, if the returned condition can be recovered from.
The signatures of the protobuf RPCs have been slightly adjusted to unify their naming scheme and to better fit into the Kotlin/Java ecosystem. Generally speaking, no hidden logic is embedded into the calls and the values are therefore relayed to Xenos without further changes. The Client is always kept compatible with the official recommendations and should be used directly whenever possible, as the individual steps are atomic.
See also
Inheritors
Functions
Closes all open resources that are associated with the Xenos Client. After this operation, this instance of the Xenos Client may no longer be used, as all connections are no longer usable. This method is idempotent and can therefore be called any number of times without changing its behaviour. It is guaranteed, that after this call all open connections and allocated resources will be closed or released. Although not all implementations have such resources, the method should still always be called (for example, within a Try-With-Resources block or a use method) to cleanly terminate resource usage.
Retrieves the current cape of the supplied userId from Xenos. The result includes the moment when the data was fetched from the Mojang API, to that stale data can be identified. If the player cannot be found or has no cape, null
will be returned. The texture is guaranteed to be present within the memory and therefore easily accessible.
Retrieves the current head of the supplied userId from Xenos. The result includes the moment when the data was fetched from the Mojang API, to that stale data can be identified. The overlay skin layer may be included. If the player cannot be found, null
will be returned. The texture is guaranteed to be present within the memory and therefore easily accessible.
Retrieves the current skin of the supplied userId from Xenos. The result includes the moment when the data was fetched from the Mojang API, to that stale data can be identified. If the player cannot be found, null
will be returned. The texture is guaranteed to be present within the memory and therefore easily accessible.
Retrieves the UUID for the supplied name from Xenos. The result includes the moment when the data was fetched from the Mojang API, so that stale data can be identified. If the player cannot be found, null
will be returned. The username does not have to be in the correct case and the canonical name will be returned within the result.
Retrieves the UUIDs of the supplied names from Xenos. Duplicates are filtered from the result and names that could not be found are discarded from the result. Each result includes the moment when the data was fetched from the Mojang API, so that stale data can be identified. The usernames do not have to be in the correct case and the canonical names will also be returned within the result.