Shall we put the AppPreferencesRepositoryImpl into app or data module?

[lydiasama]

Issue

From this PR: #389, I decided to implement the AppPreferencesRepositoryImpl inside of data module.

Why?

If we consider a standard Android project, it is common to place SharedPreferences in the app module, as it is often closely tied to the application's lifecycle and functions as a convenient storage location for user preferences and settings. This approach is straightforward and simple, as the SharedPreferences can be accessed directly from the Context of the application.

However, in a more modular or architectural approach, such as MVVM or Clean Architecture, it may be preferable to place the SharedPreferences in the data layer of the application. This approach allows for a clearer separation of concerns, as the data layer is responsible for managing and persisting data, including user preferences. Additionally, this makes it easier to test the data layer and provides a clear API for accessing and modifying SharedPreferences from the rest of the application.

Problem

We need to add androidx.datastore:datastore-preferences dependency in both data and app modules.
👉🏻 data: Uses the dependency for implementing the Sharepreferences handling.
👉🏻 app: Uses the dependency for the di module.

Solution

We have 2 approaches here with some trade-offs:

1. Move this AppPreferencesRepositoryImpl into the app module. We will no longer consider it a resource like when we call the API. And this way, we can get rid of the androidx.datastore:datastore-preferences dependency in the data module. BTW, when considering the structure between AppPreferencesRepositoryImpl and ReposirotyImpl that we use for calling APIs, it can create another question for other developers about why we don't do the same structure between them.

2. Leave the AppPreferencesRepositoryImpl to be in the data module and use the same structure with ReposirotyImpl. But this way, we need to add the androidx.datastore:datastore-preferences dependency in the data module.

Who Benefits?

Android developers

What's Next?

Update the #389 after getting the conclusion.

[AVI5HEK]

From the Clean Architecture POV, :data module can have platform dependencies. So it's fine to add that library in the :data module. In terms of responsibility, AppPreferencesRepositoryImpl is a :data module component.

[luongvo]

@lydiasama With this option Leave the AppPreferencesRepositoryImpl to be in the data module and use the same structure with ReposirotyImpl, we need to know whether we can get rid of the DataStore dependency definition from the app module or not.

[ryan-conway]

@luongvo We can remove the DataStore dependency from the app module if we move PreferencesModule into data and let data handle dependency injection for it. But to do that we must add the kapt plugin, hilt plugin and hilt-compiler kapt dependency to data build.gradle 🙏🏻

[lydiasama]

And also, the structure for the di will not be the same place as others. 🤔

[toby-thanathip]

@ryan-conway @lydiasama Do I understand correctly that this discussion has been resolved, as we already merged #389? 🙏

[lydiasama]

@Tuubz Nah. This issue is for discussing about shall we refactor our code that merged by #389 raised from @luongvo . 🙏🏻

[lydiasama]

Can we close this discussion? @luongvo @ryan-conway What do you think?