What would playing music files look like in Clean Architecture?

[connexion2000]

Hi, It is not actual issue, just question. I am very interested in clean architecture, and my application is about playing audio files. I am about to rewrite my app for the third time (none even complete in 20%), this time using Clean Architecture.

How would playing music files fit in CA? Where should music playing service reside (which layer)?

[Trikke]

Dependent on your scope of the application, this could happen in a few layers. An easy solution is to place it in the Data Layer. But myself, i'm more a fan of creating an Infrastructure layer, and having the "music playing service" reside there. This is because the actual implementation of what plays the music is external to your app. The layer starts making sense when you have a lot of these "system services" in the app, like a service for communication with Google Cloud Messaging and so on.

[alexwhb]

First off I want to say think you for making this project!!! you seriouly made my app 100 times more maintainable. I'm still getting the hang of this structure though. I have a few questions regarding this:

1. assuming we have an infrastructure layer, would each action on the audio player be represented by a use case? Example: a use case for play and one for skip track... etc?

2. can something in the infrastructure layer talk directly to the data access layer? or is data passed between the domain layer for the infrastructure layer to get data?

3. assuming my second question is false ie. We do have to use the domain layer to mediate data... is it a bad practice for the domain layer to request data from the data access layer using a Use Case of course, and return that to the audio player in the infrastructure layer, so we don't have to go all the way out to the presentation layer for this data?

let me illustrate 3 a little bit: let's say we have a simple interface for our audio player, for the sake of this example:

public interface player {
  boolean loadTrack(String uri); 
  void play();
}

in this example it would be ideal to have my use case get the track URI from the data access layer rather than storing that in the presenter layer. Would It be a bad idea to call a data access use case from this play use case to request the track URI from the data layer?

any help on this would be greatly appreciated.

[leninZ]

hi @alexwhb , I am facing the same problem and I am very curious about how did you finally resolve this issue. Can you share your knowledge?

[ikidou]

Hello @alexwhb, did you find out the solution? I have same problem now

[alexwhb]

Somehow I never got notified of the @leninZ or @ikidou 's question. It's been a long time since I wrote, but I think my advice with the player connecting to the app using UseCases... I would use a MediaSession instead which allows you to easily interface with your player without having to hack a media service together. Then I would only expose a very small part of the interface to your use cases if you absolutely need to control from your Use Cases... I would do all the player logic in the player.

I'd also highly recommend anyone interested look at this project for reference

I would let the player pull data that it needs from the data access layer rather than get data pushed to it from the central domain layer mostly because these two systems live in different lifecycles. I would also not use Use Cases for player actions (though I did in my implementation). It just became really messy. I would probably dependency inject a service connector into whatever presenter / view model needs access to the player controls and talk directly to the player that way.

Take all of this with a grain of salt. Do whatever works for you.. don't be too dogmatic about structure. If it gets in your way too much it's not worth it IMO.