Do you have pain while using old-style async API in third-party plugins?

How often do you have experience with asynchronous plugins API, which provide methods with callbacks like "void DoSomething(Callback onFinished)" and so on?
Do you like such workflow or prefer using coroutines or async methods instead?

I know that state of async in Unity is not so stable and has some caveats, but sometimes it looks better and leads lo lower callback hell.
What do you think about extension methods which convert such methods to less verbose async variant like "async Task<Result> DoSomething()"?

I think about writing a code generator to convert method signatures (as open source project) and would like to know about how it will help you with your projects. Samples of such API also will be helpful.

For example you can look at Facebook API: https://developers.facebook.com/docs/unity/reference/current/FB.ShareLink
Here you can see last argument as a "delegate", which called lately and it can be converted to Task using extension method.

What do you think about it?

 

Async is perfectly stable and is how you handle most third party libraries, network traffic, multiplayer, etc.

What is NOT stable is doing anything with the Unity API on anything but the main thread. This is well-documented by Unity3D, so don't do it.

The Unity "new async stuff" that they're working on is work in progress so I cannot speak to where it stands now. Ultimately I believe their goal is to allow a broader portion of their API to work from other threads, but don't quote me on that.

 

It's nice! I didn't have much experience with async in Unity yet (only in non-production code) and it looks like non main thread related stuff is a first thing that leads devs stay with old-style solutions like callbacks, coroutines and promises.
I agreed that it's easy to avoid with proper understanding what you can and can't do with async in Unity, but many devs didn't have such skill especially at the first time of using it.
One more thing - platform-dependent limitations, only related to WebGL, where threading is not supported (and some async features based on it implicitly), but it also can be avoided and it's required to keep that limits in mind.

 

Here you can see a short comparison of both variants related to BrainCloud API (cloud backend-as-as-service) - https://gist.github.com/KonH/f56dc99d1613a7f9a5193878399c5f23 and https://gist.github.com/KonH/8968cd1b89fb54c5b2e0d165f115d504.

It contains some simplifications (task-based variant behave slightly different) but should illustrate my idea.

The use-case is simple: perform login and allow to increment global and player variables.

What is better in the second variant, IMO:

• Code looks more compact and step-by-step, intentions cleaner
• Fewer lines of code
• Fever method count & repeats in signatures
• Shorten and less noisy method calls (no callbacks)
• Exception control: in case of callbacks you should repeat try-catch blocks inside callback code, because you don't control how your callback will execute, in the second variant you can try-catch async methods as usual