1. How does the network request interact with the UI thread?
My current practice is to create a thread pool to manage the network request thread, adding a task to add a new network request. All network operations are implemented through a unified request, and the network returns results are processed using callbacks onerror and onsuccess, which involve UI updates with Runonuithread or handler in the UI, both of which are available on the project. Mainly see you like, but with handler please pay attention to memory leak problem ... )
The advantage of this approach is that the thread pool avoids the constant opening of threads leading to wasted resources while managing threads and customizing the order in which tasks are executed. The reason for unifying the request and callback is that you do not need to instantiate each request and do custom processing directly in the callback.
Of course, to be generalized, it is best to use the manager to wrap these up and then use them, so that the division of labor is clear.
2, Activity1 open Activity2, then Activity2 how to notify Activity1 update data? (Cannot use intent)
Personally feel that the most ox-breaking writing is broadcast, or watcher. The reason for the bull break is that no matter how many activity updates you want to notify, you can do so as long as you register the message.
Broadcast is the registration of monitoring events, and then the sender sends a message, interested people register to listen to the message can be received when the broadcaster sends a message.
The Watcher Observer pattern is similar in that it informs the notifier that I am interested in a message.
How do network requests interact with the UI thread? Activity2 how to notify Activity1 update data
