Nodojido

A great deal has changed in the last five years.  Not that long ago,  it was just accepted that an app would have a gi-normous “God” activity or fragment, few if any tests of any description, and that detangling the code might be tricky — in other words, the app was “resistant to change.”
Recently things have been shifting in a positive direction.  There are now any number of mature, stable 3rd party libraries dealing with the more arcane and error-prone aspects of networking, databases, graphics, etc.  By building an app around these libraries, the burden of debugging may be shifted from the developer to the vendor — with careful attention to detail, the same app will contain less code and fewer bugs, be easier to modify and maintain, and permit shorter turnaround of new features.
Additionally, a very simple concept known as “Clean” (or “Uncle Bob’s”) architecture is gaining in name recognition.  The idea is that an app is built in layers, and inner layers know nothing about outer layers.  While at first this can make code seem very indirect or confusing as to where actual “stuff happens,” the goal isn’t about simplicity in that sense, but rather in making individual modules depend on as few outside influences as possible.  As the modules become self-contained and communicate via interfaces, both testing and replacement (e.g. swapping out sql for realm in the case of a database) are greatly facilitated; a few wrapper classes would need to be written, and most of the hard work is likely already done.
These days I won’t consider starting a new project without a few essentials:
RxJava/RxAndroid for reactive semantics — everything is a stream
Dagger2 for dependency injection
* Retrofit for networking
* glide or picasso for graphics
* leakcanary for (you guessed it) leak reporting
* crashlytics for crash and event reports
* and of course “clean” architecture
Also, a reduction in the proliferation of activities and fragments; specifically I try to achieve a single-activity app and avoid nesting fragments.  This is simply about avoiding some of the pitfalls that “clean” architecture and the above libraries are intended to help prevent — keep things as simple as possible and avoid getting trapped in weird lifecycle issues beyond the control of your own code.

An android developer both during the day, where I’m employed by a startup in the AR (Augmented Reality) sector, and in my spare time, where I’m busy readying personal apps for the Play Store.
Currently I’m concentrating on “Nodojido” (available on the Play Store here)  Intended mostly for enthusiasts of Japanese karaoke, this app converts data from the “Nodojiman” website into a browsable database.  Handy for seeing at a glance what songs are most popular with amateur singers from the land that gave the world karaoke!

Currently based in Tokyo (Japan).