Skip to content

Instantly share code, notes, and snippets.

@jmfayard

jmfayard/Mercari-Jmfayard.adoc

Last active November 21, 2018 11:37
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jmfayard/baec25a74adadf9f3a0e0fcf27bf9881 to your computer and use it in GitHub Desktop.
Save jmfayard/baec25a74adadf9f3a0e0fcf27bf9881 to your computer and use it in GitHub Desktop.
Download ZIP
Mercari-Jmfayard
Raw
Mercari-Jmfayard.adoc

Mercari-Jmfayard

Table of Contents

Up and running

Clone the project, run the unit tests and install the app

$ git clone https://github.com/m-rec/c325017f9e66db9320f99fdced6ac3d66abc9212.git mercari-jmfayard
$ cd mercari-jmfayard
$ ./gradlew testDebugUnitTest installDebug

You can also open the project in Android Studio

Screencast

TODOs

As can be seen in the screencast, the layouts are as simple as possible and thus do not respect yet all the UX requirements

This is because I choose Scenario B : A base for an app that will be developed and maintained for a long time

The easiest place to on-board a new developer is to ask them to polish the UX according to the detailed requirements that we have thanks to the mockups etc…​ What that require is to decouple the View from the logic of the app as cleanly as possible and I did took care of that.

Specifically the new developer should have to modify only

KISS and YAGNI

A big reason why Android developpment seems so hard is that we follow blindly all the good practices, especially all the recommandations from the Android team.

Actually, a third of those "good practices" are actually always good, a second third is good in some projects but not yours, and a third is just bad.

So I believe in ruthlessly eliminating complexity by applying those two principles

KISS

Keep It Simple And Stupid

YAGNI

You Ain’t Gonna Need It

Specifically here:

  • I use Coroutines that are beautifully simple for network stuff instead of RxJava or worse (AsyncTask, Service, …​)

  • I have no need for Fragments, Bundles, Multiple Activities, Intents, Navigation Component, Service, ViewPager, …​

  • I use a Single Activity architecture with the MVP pattern. For that, I use Magellan and in practice this project is based on my own sample https://github.com/jmfayard/android-kotlin-magellan

  • In the MVP pattern, my presenter is MercariScreen.kt. This presenter is persistent in memory which makes lot of usual Android problems disappear. It is a normal Kotlin class, not tied to the Android Framework but who knows how to recreate its View/MercaryDisplay whenever the android lifecycle needs it

Long-term investments

Since I am choosing scenario B, I put some things in place that will avoid my team to waste lots of time in the future:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment