Make Unity sdk async/await

General
,
1

Using callbacks is very tiresome and a big waste of time. I recommend sdk to be upgraded to use async/await.

There are issues with C# Tasks as they are multithreaded and don’t work on WebGL. That’s why Unity is adding Awaitable in 2023 but there’s much better solution called UniTask GitHub - Cysharp/UniTask: Provides an efficient allocation free async/await integration for Unity. widely used in many project with Unity 2018+ support.

Async/await makes handling errors very simple with single try/catch, error dialog and retry logic. I can provide an example if you aren’t familiar with it.

As a bonus there’s performance improvement as UniTask doesn’t allocate memory compared to IEnumerator coroutines.

2

Hello @kamyker

Thanks a lot for your feedback.

Could you please provide a code snipet with an example?

Also, is UniTask an official Unity Solution? Or is it a public 3rd party API? In case it’s public, do you know who is mantaining it?

Thanks!

3

Hi @Ivan_Martinez

Here’s an example Async vs Callback example · GitHub
In this case async would be pretty much 30% less code, additionally it handles all exceptions (as opposed to callbacks).

UniTask isn’t Unity Solution but it’s made by one of the biggest open source contributor in Unity/C# space, Japanese developer Neuecc https://neuecc.medium.com/

4

Thanks a lot for this information @kamyker.

The Async looks indeed cleaner and more maintainable. It probably comes with a few downsides (not big fan of big Try-Catch statements where many things can go wrong, does the exception give enough information for easy debugging?).

The problem with this is, we cannot use 3rd party SDK unless they are official, as it implies many risks. Something similar happened with NGUI, where Unity hired the developer and integrated it officially inside Unity (although it did not end well as far as I can remember).

I will mention this to the internal team, although I’m afraid it would be a huge change in our SDK structure. So in case we see future in implementing this, don’t expect it to be any time soon :grin:

5

does the exception give enough information for easy debugging?

I skipped that part in the example but SDK should throw AccelByteException that would basically be the current Error. Then code would be:

try
{

} 
catch (AccelByteException e)
{
  //handle AccelByte errors, e.Error for more info etc
}
//optional
catch (Exception e)
{
  //handle other exceptions
}

we cannot use 3rd party SDK unless they are official, as it implies many risks

In my opinion, using a 3rd party SDK from an experienced developer implies less risks than using anything official from Unity, especially since Unity’s code is closed source. Additionally, official solution from Unity (Awaitable) could be used in the future in case UniTask stops being maintained.

would be a huge change in our SDK

I forgot to mention that UniTask can also await IEnumerators so it wouldn’t be that huge. If I decide to use Accelbyte more then I’ll write simple code generator that adds async methods but for now I’m only using matchmaking. ~Few hours of work, already did something similar for Epic’s sdk.

6

Thanks again @kamyker

I have forwarded all this information to the SDK Team to take a look at it, and at least be aware of this :+1:

7

Good news @kamyker , the team is actually in the process of replacing Coroutines with Async Await. It’ll take some time to do it for each domain area but it’s already in progress :slightly_smiling_face:

2 Likes