I have a project with separate Android (Java) and iOS (Swift) clients. One of the key features is that we have third party APIs that offer listeners for various events (e.g., third party chat service, etc.). These various third-party API are all non-blocking, employing a listener pattern.
On the iOS side, we routinely put these sorts of API into non-UIKit service/manager/controller objects. That way the functionality is available to any view controller that may eventually need it, and we abstract the vendor’s particular API out of our view controllers and view models.
This sort of decoupling of the UI from the service seems natural to me, but I had a surprisingly hard time describing the concept to our Android developers. I’m not sure if the issue was a language barrier, a platform terminology, or whether Android solves this problem using a different pattern.
So, what is the correct Android pattern/terminology for a custom object that is constantly alive while the app runs, listening for events/messages and/or allow allow activities to receive and send messages, independent from any particular activity/fragment? Android Service seems like the logical implementation, but perhaps there is some other pattern common in Android for decoupling some listener/publisher API from particular activity. How can I best describe this to an Android developer in terms that he or she will immediately understand?
Services, as you already indicated. There are several tutorials available, easily found searching the net.