Using Uncle Bob's clean architecture with Kotlin language and the latest Android technologies(Rx, Dagger2 etc.).

License: Apache License 2.0

Kotlin 100.00%

clean-architecture-android-kotlin's Introduction

Android Clean Architecture - Kotlin

This is an Android Clean Architecture base project using 100% Kotlin including Unit tests!

You could use it as the base project when you create a new Android project. This architecture optimized the Clean Architecture and MVP for the Android Kotlin project. When using this architecture, you could isolate the UI, business logic and data sources, and also making the unit test easier. It uses latest and most popular technologies e.g. Dagger2, RxJava etc.

Benefit

Makes your new project clean
Isolates UI, business logic and data sources' responsibilities
Testable
Avoids multi-threading problems

Approach of Clean Architecture for Android

There are 3 layers in the project: Data, Domain and Presentation(UI), and the UI layer contains view and presenters.

Multi-threading

Base UseCase class handles the thread of Rx chains, it puts whole chain on IO thread, and then changes back to Android main thread(UI thread) for the steps after use case execution. That means when you write the project based on this project, then you don't have to worry about any multi-threading issue.

Requirements & configurations

Requirements

JDK 8
Android SDK API 26
Kotlin Gradle plugin 1.2.30 (it will be installed automatically when this project is synced)

Configurations

minSdkVersion=21
targetSdkVersion=26

Language

Kotlin

Libraries

More about The Clean Architecture

The Clean Architecture

S.O.L.I.D Principle

More articles available on my blog: https://medium.com/@pyin001

TODO

Bugs and Feedback

For bugs, feature requests, and discussion please use GitHub Issues. For general usage questions please use the StackOverflow.

License

Copyright 2017 Patrick Yin

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

clean-architecture-android-kotlin's People

Stargazers

Watchers

clean-architecture-android-kotlin's Issues

domain module has dependency on data module.

Does it violate dependency rule of clean architecture?

Memory leak

Because your modules didn't support custom scopes so memory leak is existing
Example:
class GetArticlesListUseCase @Inject constructor(private val articlesRepository: ArticlesRepository,
subscribeScheduler: Scheduler,
postExecutionScheduler: Scheduler) : UseCase<List

, Unit>(subscribeScheduler, postExecutionScheduler) {

override fun buildUseCaseSingle(params: Unit?): Single<List

> = articlesRepository.articles()
.map {
it.map { Article(it.title, it.pubDate, it.link) }
}
//I added some code at here to check memory leak by Profiler of Android Studio
var test: ByteArray? = null
init {
test = ByteArray(1024102450)
}

fun test() {
    if (test != null) {

    }
}

}

//Java memory in MEMORY tab from Profiler increases 50KB->100KB->150KB... whenever the app opens the activity which is using GetArticlesListUseCase

Singleton UseCase?

    @Provides
    @Singleton
    internal fun provideGetArticlesListUseCase(articlesRepository: ArticlesRepository, @Named("ioScheduler") ioScheduler: Scheduler, @Named("mainThreadScheduler") mainThreadScheduler: Scheduler): GetArticlesListUseCase =
            GetArticlesListUseCase(articlesRepository, ioScheduler, mainThreadScheduler)

I think the @Singleton annotation is superfluous, because onDestroy we do a dispose of CompositeDisposable, therefore we can not perform the request again.

The build was falling after the build engine has been upgraded D8

Gradle log:

AGPBI: {"kind":"error","text":"Static interface methods are only supported starting with Android N (--min-api 24): okhttp3.Request okhttp3.Authenticator.lambda$static$0(okhttp3.Route, okhttp3.Response)","sources":[{}],"tool":"D8"}
AGPBI: {"kind":"error","text":"Static interface methods are only supported starting with Android N (--min-api 24): okhttp3.Request okhttp3.Authenticator.lambda$static$0(okhttp3.Route, okhttp3.Response)","sources":[{}],"tool":"D8"}

> Task :ui:mergeExtDexDevelopmentDebug FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Could not resolve all files for configuration ':ui:developmentDebugRuntimeClasspath'.
> Failed to transform file 'jetified-okhttp-3.14.0.jar' to match attributes {artifactType=android-dex, dexing-is-debuggable=true, dexing-min-sdk=21} using transform DexingTransform
   > Error while dexing.
> Failed to transform file 'jetified-okhttp-3.14.0.jar' to match attributes {artifactType=android-dex, dexing-is-debuggable=true, dexing-min-sdk=21} using transform DexingTransform
   > Error while dexing

Fragments

Would be nice to have fragment implementation

Suggest a new structure

Hi Patrickyin,

With current structure, when the app has a new activity or a new fragment, it takes more time of developer for creating classes, modules and creating references between them.

Usecases in domain layer don't have many useful. It cannot do business logic, because data from apis are sent to Observers, all code logic is being implemented in Observers or Presenters.

So, I'm suggesting that we should restructure the project, move Presenter and Observer to domain layer, remove Usecase from domain layer. Presenter will not call UseCase, it will call directly Services in data layer, data will return to Observer.

The new structure will reduce 2 classes and references relate to "Usecase" and "UseCaseModule".

Thanks,
Duy

patrickyin / clean-architecture-android-kotlin Goto Github PK