Document which thread is whole SDK or callbacks using

[qsdigor]

As we all know there are different threads in java, they usually differentiate into one main thread and many background threads.

It looks like SDK is using background threads to do network work and returns results on background threads. This is good as it won't block apps and can run async. Network stuff is done on WebSocketConnectReadThread thread.

The issue is usually on android apps as they tend to change UI after receiving presence updates or get messages. Our background thread does not support UI updates like changing some texts or updating recycler view adapters.

We have multiple options:

• Change the thread to main when returning the results. This will increase complexity and introduce bugs.
• Implement an option to allow users to select a thread of their choice.
• Document usage of background threads and point out that all work is done on background tread, for UI changes please use the main thread.

I would recommend the third option as a simpler and better option. This won't break any apps or cause implementation issues as the code won't change.

┆Issue is synchronized with this Jira Story by Unito

[qsdigor]

@QuintinWillison @KacperKluka I would value your opinion on this. Thank you

[KacperKluka]

I think we should at least document it 👍 I had an issue some time ago and it turned out to be related to background threads and they seem to be poorly documented in the SDK.

[QuintinWillison]

In the short term, under this issue, I think we should go with your third option and document better the threading behaviours exhibited.

Longer term, marshalling to the main thread - at least on Android - is probably the simplest option for customers to understand. As you point out, this could cause all kinds of new issues for customer apps. And, of course, we need to work out how this would fit into the brave (new) world of Kotlin coroutines. 🤔

[ikbalkaya]

I would prefer callbacks/listeners are invoked in the same thread as the thread that methods are called on. In my experience of using some good SDKs (Retrofit / Google SDks) , async results are provided on the same thread. I also remember using some other SDKs (including Ably) that callbacks are happening on background thread. I think this might be confusing for developers and not a great developer experience as a result for the reasons below:

• Callback/listener methods aren't intended to be blocking, they are just there to notify about a result from an async operation. So I do not think there is a strong reason for background threads.
• SDK users might have the wrong assumptions about the behaviour as commonly used SDKs do not use them.
• In Android, developers will mostly want to execute the listener on main thread. Not providing this in main thread forces them to add additional code that is not really needed. I think the rare case would be that they would want to switch to a different thread than they called which they can still control.