Open dsilhavy opened 2 years ago
Proposal from @haudiobe and @dsilhavy on Friday, 14th October is to model the Media Session Handler as an Android service. https://developer.android.com/guide/components/services
The Media Session Handler definitely fits the description of a background service rather than a foreground service because it lacks any user interface of its own.
In the orthogonal axis, it sounds like the Media Session Handler is most elegantly realised as a bound service (with an automatically reference-counted lifespan) rather than a started service (whose lifespan is explicitly managed). This will allow multiple applications to share the Media Session Handler service and the system will stop the service when no applications want it anymore. Interprocess communication can probably use the Messenger
class without resorting to hand-crafting Android Interface Definition Language.
https://developer.android.com/guide/components/bound-services#Messenger
An alternative approach would be to instantiate the Media Session Handler service separately in each "player" application process. Less elegant, but it might simplify the implementation if there is no Media Session Handler state shared between different application contexts. Each concurrently running 5GMS-Aware Application would end up with its own separate M5 connection to the 5GMS AF and there would be no opportunity to multiplex traffic over a shared HTTP session.
I know you've been reading up on this as well, @davidjwbbc. Any additional thoughts?
Our current considerations:
Platform that the MSH should run on: Android
DEV Environment : Android Studio
Programming language do we want to use to implement the MSH: Java or Kotlin, most likely Java
Thanks, @shilinding. Thinking about this in connection with @dsilhavy's diagrams on 5G-MAG/rt-5gms-media-stream-handler#2, I had some additional thoughts about the Media Session Handler realisation.
To recap, we would like to be able to use the Media Session Handler in two different runtime configurations:
The above may require two different build targets for the Media Session Handler in order to achieve the desired flexibility.
In terms of high-level class structure, I envisage something along the following lines:
Any additional thoughts, @davidjwbbc?
This issue is supposed to be used to discuss and answer the following questions