Skip to content

rsetkus/cars-map

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

90 Commits
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Cars

Build Status

Downloads

Download app from here

Design & Dependencies

I ❤️ Kotlin. Java is great too but due to certain reasons it has limitations. Let me put it this way, when I am writing Kotlin code most of the time I don't need to think "how", I just need to know "what" I have to code.

High-order functions, Sequences, data types you name it. All those language features helps to maintain and scale applications much easier then before. Also and most important thing, Kotlin is first-class language for Android by Google.

Because nobody wants to read random 💩 code style. In industry like this we have to have widely agreed standards. I take coding style very seriously because I seek to write code where everybody would feel comfortable reading it and I expect the same from the others. Ktlint is lightweight static code analysis tool. To some extent it obeys official Android Kotlin style guide. It necessarily means that you have blindly follow it. If there is something you don't like or you want customise, you can easily do it.

Detekt is another great tool but it's main purpose is not for code style. You can plug in Ktlin but I didn't want to over-engineer the application.

Then it comes question what you should choose when you design application architecture, I think it doesn't really much matter. MVP, MVVM, MVI or any other pattern, they all are very similar and they all do the same thing - separate application concerns.

MVP was the top choice for many years because of strong Android developer community but today I prefer MVVM. It is my first choice because it is created and maintained by Google (they had to step in long time ago!:rage:) and most importantly you don't need to maintain application life cycle which was pain in a neck. Certainly, there are tricks there you can fail, start observing data in wrong place of retained fragment for instance. Anyway, it is great asset for any Android developer.

I was keen to try Kotlin Coroutines because it is native Kotlin way do the complicated threading work. I've tried it before and really enjoyed. However, I feel comfortably with RxJava. Although, I don't consider myself as an expert but I spent great time learning it.

No doubt easiest way to setup RESTful services 👌. Supports many adapters for various libraries. 💪

Just because easy to setup. There are many JSON serialization/deserialization libraries and which one you should use depends on case. Interesting Reddit thread to read about Moshi vs Gson.

Dagger2 is for Java projects. Period. I hate when I have to expose inner implementation of Kotlin classes and make them nullable or use lateinit just because Dagger cannot inject dependencies. Also, configuration is utterly clumsy. Always, have to go to documentation when I need to change Dagger setup. One of those things which you setup once and don't touch for long time but when you need to change it is hard to understand how it is working. There is one good thing about Dagger, application won't compile if configuration is invalid (code is generated on compile time).

For Kotlin projects I prefer something which is friendly with Kotlin concepts and implemented with Kotlin. I know Kodein and Koin and my preference of choice is Koin due to simple reasons. Easy to setup, readable (arguably 😐), lightweight and simply can inject into private val. However, comparing to Dagger it has one drawback - you would get run time exception if Koin setup is invalid. Which means you won't know if your setup is correct until when you explicitly run a code in exact place.

Functional Programming is a big trend now. Even strictly OOP languages like Java (lambda function implementation) are getting influenced by FP. I am extremely interested into it.

At first, I didn't plan to use it but I came to the point when I couldn't figure out what is the best way to deal with multiple data types which represents the state (like view state loading, error, empy etc.). I had few options here:

This one looks fairly simple and should serve for all possible execution states. It compiles fine but it is quite obvious that there will be some problems. The thing is, on run time you cannot know the type of T because it is deleted on compile time. You would need to cast! 😨

sealed class State<out T : Any> {
    object Loading : State<Nothing>()
    class Success<out T : Any>(val data: T) : State<T>()
    class Error<out T : Throwable>(val error: T) : State<T>()
}

Again another simple solution but not great too. Here we have concrete types and wouldn't need to cast on run time. Problem is that you would need to duplicate it for all data types. So, it is not scalable.

sealed class State {
    object Loading : State()
    class Success(val data: String) : State()
    class Error(val error: Throwable) : State()
}

Also, was considering this implementation. Frankly speaking, it is quite good but I wanted something simpler and at the same time neat.

At the end, I came with an idea that any code execution has only two states/branches - successful and error. It doesn't have loading, empty or something else. Arrow data types seemed to be a way to go. Also, always wanted to try it 😎. Arrow library is modular which means you don't need to include everything. Arrow Core module is a good start for programming FP!

No particular reason. Just another great library from Square family which easy to pick up and use.

I am a huge fan of TDD. Mockito for Kotlin projects just feels a bit too Java-ish when you have this elegant Kotlin code (have to escape when because in Kotlin when is keyword). MockK’s main philosophy is offering first-class support for Kotlin features and being able to write idiomatic Kotlin code when using it.

Being a responsible for the code I write I take testing very seriously. I never felt good about hard coding test data and write tests based on explicit data input. Great library when it comes a matter of question how populate test data. Moreover, inspired of this library and influenced by my colleagues/friends, my next focus will be on Property Based Testing.

About

Cars on the map

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages