Currently if user calls Session.send(request) without setting the callback queue, it will use main thread for processing the callback.
But APIKit, in layered architecture designing, should be in the infrastructure layer or persistence layer; And on the other side, main queue in iOS, since it mainly handles UI process, is usually considered in the UI layer.
Therefore, it's probably not a good idea to let APIKit know about the main queue. it's a UI world thing, which an infrastructure world thing probably should not know.
And by using main queue, which may also be used by any object in the program, as the default queue, it's very easy to cause a deadlock if a user tries to use a semaphore to stop current thread until the response received.
So my opinion is that in Session's initializer, maybe it's better to set the default value of callbackQueue to DispatchQueue.global() or DispatchQueue(label: someLabel)
Currently if user calls
Session.send(request)without setting the callback queue, it will use main thread for processing the callback.But APIKit, in layered architecture designing, should be in the infrastructure layer or persistence layer; And on the other side, main queue in iOS, since it mainly handles UI process, is usually considered in the UI layer.
Therefore, it's probably not a good idea to let APIKit know about the main queue. it's a UI world thing, which an infrastructure world thing probably should not know.
And by using main queue, which may also be used by any object in the program, as the default queue, it's very easy to cause a deadlock if a user tries to use a semaphore to stop current thread until the response received.
So my opinion is that in
Session's initializer, maybe it's better to set the default value ofcallbackQueuetoDispatchQueue.global()orDispatchQueue(label: someLabel)Thanks for considering this issue.