vasticles / CurrencyConverter

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

CurrencyConverter

This app uses a flavour of Clean architecture. It is split up into 3 modules (app, data, domain), as is customary for Android's version of Clean. The UI layer is set up with MVVM. Data layer uses Realm as the app's local database, and Dagger 2 for dependency injection. RxJava is used in every layer.

Things to note:

  1. MVVM is the prevalent architecture in Android, with the architectural components released to encourage this direction. However, MVVM can be achieved in various other ways. In this approach, I created view model objects from Databinding's library BaseObservable. Personally, I don't think there is much to gain from architectural components' ViewModel if you're not using LiveData. With Dagger 2, I can maintain my own scoped instances of the view models. Seeing how this is a single screen app, there is not even a need for such an approach.
  2. The reason why I don't use LiveData is because I have RxJava. It's not really difficult to manage Rx subscriptions and lifecycle events. Also, the number of transformations provided by the LiveData lib pales in comparison to what Rx offers.
  3. Using Realm over Room was determined by the amount of boilerplate you have to write to create relations between entities in Room. While Realm is far from being flawless, it was pretty simple to persist an entity that contained a list of other entities. For such a simple app, Realm is sufficient.
  4. My decision to use Currency and CurrencyAmount objects in the app has mostly backfired. It was my first time working with them, and I thought I would gain something more than just currency names and codes (e.g. actual symbols would be nice). What I didn't realize until later is that this decision would confine me to needing an instrumentation for most of my tests. That means using the dreaded Robolectric library (or running test on the device, which is even slower). My biggest complaint about this predicament is not being able to use JUnit5, as it is not supported by Robolectric or integration tests. Much of my favoured BDD style (using Nested classes with DisplayName annotations) went out the window. It would've been better to make my own Currency and CurrencyAmount objects that do not rely on Locale. Lesson learned.

About


Languages

Language:Kotlin 100.0%