Closed blyscuit closed 4 months ago
@blyscuit
NetworkJSONAPIClient
class, you can check the publishData() function, its default queue is the main queue, but in this class I also have to use the Japx library to decode JSONAPI, so I set the queue for publishData( ) to .global(qos: .userInteractive), this will ensure all subsequent map functions are executed in the global queue and do not block the main thread. Finally, I switch the thread back to main to return the data in the main thread as a default utility like the default queue of publishData().SurveyRepositoryWithCachingImpl
class. As I said above, NetworkJSONAPIClient
returns data to the main queue by default. However, in SurveyRepositoryWithCachingImpl
class I still have to do some additional work such as reading and writing cache data to the file. I didn't want these to block the main thread so I decided to move them back to the background thread and then back to the main thread to return the final data.If a repository or a use case calls two network request with Publishers.merge, so it depend on which thread the each Publisher on Publishers.merge run on.
For example:
1st one emit values 1-3-5 and run on main thread, 2nd one emit 2-4-6 and run on background thread so in Publishers.merge the observation code will run on main thread when it receive values 1-3-5 and on background thread when receive values 2-4-6. Therefore, to unify the observation thread for Publishers.merge, we need to use the receive(on:)
for Publishers.merge.
No, I believe API calls will not block the main thread.
Issue
receive(on:)
in multiple places. What are the thought behind adding thesereceive(on:)
?Publishers.merge
, what thread are the calls being made on?