android10
Android device specific module
Hello,
This is intended to be more of an open discussion, than an actual issue. I want to add some Android specific components in the project, like the Bluetooth and I want to keep the clean architecture. Currently I have 4 modules:
-
common- utility stuff that can be used by all the modules (even other projects) - pure Java -
data- everything related to data -
domain- entities, use cases, repositories -
presentation- everything related to the UI
I was thinking to add these to the data module, but this could be out of scope for that module as it will handle other things beside data.
On a presentation made by Tomislav Homan, I've read that a new module could be added which can include Android stuff such as sensors, alarms, notifications, players, all kinds of Managers, and so on.
Something like a device module which should have the actual implementation of the Android specific stuff and expose it via Observables or interfaces.
What do you think it is the best approach for this in order to keep the clean architecture and to respect the dependency rule. If you know/have examples with source code that will be even greater.
IMO the data layer is probably the best place to add those specific functionalities you want.
Have into account that actually you will collect data from the Sensors or certain information from the Bluetooth system. After all, this is what the data layer is doing, it uses external resources to load data (Http request and/or database), so it shouldn't matter which one you use.
You might have a kind of a SystemService class instead of Repository that handles that information, which would be used by your UseCase in a hidden (encapsulated) way, and just deliver the data you need.
Anyway, all depends on how are you managing your layered architecture, since you can create another new layer for that specific purpose, but honestly the result would be the same.
Hope it helps.
It's been long discussed in here and many other issues in this board: https://github.com/android10/Android-CleanArchitecture/issues/151 In summary, someone proposed an infrastructure layer in charge of platform specific stuff.
Personally, I use this to handle socket connections and android permissions in my project. This infrastructure layer coexists simultaneously with the data layer -both at the same level- and is accessed through interfaces defined in the domain layer, pretty much the same as the data layer.
Thank you @Zireck,
That is a very good example and it is very close to what Tomislav Homan described. The only difference there is that everything is in one module. I prefer using modules for each layer as it is easy to decouple from the platform easier. For example, the domain layer is made in pure java, thus enforcing the development to not rely on Android specific components.
After some thinking, I will go with an separate module which will be an Android library module and I will try to keep it as much as possible on the same layer as the data layer. I will break this down into specific packages and I will make an minimal implementation to expose it's functionality (via Observables or Interfaces).
If you guys think there are better approaches or do you have more examples, presentations, ideas, please share them here and maybe we can make a new PR to include it into this demo project.
Thank you all.
@IonutNegru87 this text was originally published at Five Agency series about Clean Architecture.
Presentation
This module is already created for you by the Android studio when you create a project.
Domain
Entities, use cases, repositories interfaces, and device interfaces go into the domain module. Ideally, entities and business logic should be platform agnostic. To feel safe, and to prevent us from placing some android stuff in here, we will make it a pure java module
Data
The data module should hold everything related to data persistence and manipulation. Here we will find DAOs, ORMs, SharedPreferences, network related stuff like Retrofit services and similar.
Device
The device module should have everything related to Android that’s not data persistence and UI. In example, wrapper classes for ConnectivityManager, NotificationManager and misc sensors.
Thank you for the information @jpventura. That is exactly what I had done in the end :)
@IonutNegru87 hello, I've got a project set up very similar to how you and @jpventura have described and I'm working on adding some bluetooth stuff to the project. I have different types of bt devices I want to connect to, and I need to use sdk's for some of the devices(some sdk's handle the actual bt connections), so my original idea was to create a core android bt module (has android fg service that handles communication between app and bt layer), and individual modules for each bt device. the individual bt modules would have the core as a dependency and was thinking of using dagger to inject domain implementations (bt repo/service) from the various bt modules into the core bt module. One problem I'm facing is how do I specify which bt device to connect to via the domain? I was trying to keep any kind of reference to a specific type of bt device out of the domain, but after some thought I think I might need to define an enum or sealed class to list the type of devices and then use that as a param in a usecase to pick the device. However, each bt device module implements an interface and to inject a specific one, I need to use the Named annotation, which means if I want to use the repo or service implementation in the usecase to connect to the device, I need to know which one before hand, so that means I need usecases to connect to each specific device, which I don't like. Maybe I pass in the repo or service to the usecase instead of injecting it...?
Anyways, hopefully that's not too incoherent. If anyone has any ideas on how I could structure things, I'm looking for ideas.
