SlimeKT
SlimeKT copied to clipboard
List of problems!
-
I would suggest avoid using the name of project on classes.
-
Singleton
CoroutineScope
is a wrong pattern because every async operation needs to have a scope to define when they will be canceled. Check here -
As we chatted, the interfaces in the
data
module should moved out to a new module, let's name itdata-api
, so other modules that needs it could inject the interfaces. Also as I noticed the interfaces of implementation indata
module actually are on wrong modules! For instance, the implementation ofArticleDao
interface will be generated in thedata
module so this interface must be beside otherDao
interfaces in the so calleddata-api
module. -
It's hard to understand why you have
core
module and alsocommon-ui
andfeatures/authentication/common-ui
modules!
Hope it helps.
Hey @hadilq thanks for reviewing the code. I was just following this guide available here for singleton coroutine scope: https://manuelvivo.dev/coroutinescope-hilt
So the common-ui
that is on the project level contains UI components that is required to the whole app. The Composables in it might be required in ui-home
as well as in ui-explore
.
The other common-ui
module which is located inside features/authentication/common-ui
contains UI components that is needed by the specific feature only. Here as this common-ui is inside of authentication feature, the components will be required only by ui-auth
(login and register screen)
As I mentioned, because Google has a document for something doesn't mean it's correct! It just means it has a demand to be documented/standardized.
Regarding common-ui
in a specific feature directory, It just means nothing! common
means there's a code that is shared among other models, which is not the case here.
core
module has codes that are needed by almost all modules. The other module is just not common
, it's common-ui
. Do you mean that I should remove all the common-ui
modules in feature directories and merge them with the root common-ui
?
@kasem-sm I also don't understand why a UI module like ui-auth
is outside feature
directory?
The thing is UI modules are the ones using the features. Some screen such as the ui-home
or ui-explore
are using multiple features. As of now, only ui-auth
uses a single feature, that is the authentication
feature. If I added the ui-auth
module inside of features\authentication
package, it may cause confusion to some people.