
Showcases clean architecture principles in an Android app, offering guidelines and best practices with layered project structure and integration with Open Weather API for demonstration.
Kotlin Android application that serves as showcase of a clean architecture. Among other things, provides a set of a guidelines, and demonstrates best practices.
This is a result of an iteration over different approaches we've been using in Ahead iTec apps.
The Clean Architecture (highly recommended to read)
The app uses Open Weather API as it's remote endpoint.
The project structure of the App module is splitted by layer
data
└───weather-feature
│ mapper
│ remote
│ WeatherRepositoryImpl // Implementation of the contract [WeatherRepository interface] from the domain layer.
│ ...
└───foo-feature
│ ...
│
domain
└───weather-feature
│ model
│ GetCurrentWeatherByLocation
│ WeatherRepository // Domain contains the interfaces to the data, on how we store and access data.
│ ...
└───location-feature
│ ...
│
infrastructure
└───location-feature
│ mapper
│ LocationRepositoryImpl
│ ...
presentation
└───navigation // Classes used to navigate through the application.
│ Navigator
└───presenter
│ ...
│
└───view
│ ...
│
Basically, there are two approaches to combining use cases:
In the CA all of the business logic goes into an use case and presenters are "dumb". Therefore I personally prefer the second approach.
See GetCurrentWeatherByLocation
implementation "com.aheaditec.architecture:architecture:$libVersions.architecture"implementation "com.aheaditec.functional:functional:$libVersions.functional"Copyright 2020 AHEAD iTec, s.r.o
Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.
There is NO WARRANTY for this software. See LICENSE for details.
Kotlin Android application that serves as showcase of a clean architecture. Among other things, provides a set of a guidelines, and demonstrates best practices.
This is a result of an iteration over different approaches we've been using in Ahead iTec apps.
The Clean Architecture (highly recommended to read)
The app uses Open Weather API as it's remote endpoint.
The project structure of the App module is splitted by layer
data
└───weather-feature
│ mapper
│ remote
│ WeatherRepositoryImpl // Implementation of the contract [WeatherRepository interface] from the domain layer.
│ ...
└───foo-feature
│ ...
│
domain
└───weather-feature
│ model
│ GetCurrentWeatherByLocation
│ WeatherRepository // Domain contains the interfaces to the data, on how we store and access data.
│ ...
└───location-feature
│ ...
│
infrastructure
└───location-feature
│ mapper
│ LocationRepositoryImpl
│ ...
presentation
└───navigation // Classes used to navigate through the application.
│ Navigator
└───presenter
│ ...
│
└───view
│ ...
│
Basically, there are two approaches to combining use cases:
In the CA all of the business logic goes into an use case and presenters are "dumb". Therefore I personally prefer the second approach.
See GetCurrentWeatherByLocation
implementation "com.aheaditec.architecture:architecture:$libVersions.architecture"implementation "com.aheaditec.functional:functional:$libVersions.functional"Copyright 2020 AHEAD iTec, s.r.o
Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.
There is NO WARRANTY for this software. See LICENSE for details.