It’s been a month since people (actually, my classmates) started using my Diary app. There are some things I want to share.
Build MVP first
If you don’t want the development to last forever, you should start with a minimal, simple version of the app that does just the absolutely necessary things.
A minimum viable product is a product with just enough features to satisfy early customers, and to provide feedback for future product development.
Do not use static
Use interfaces instead. Static references (I mean, variables and class methods that are used outside of the parent class) are mostly not trivial to test. Moreover, they are tough to remove from the codebase later. I made a wide use of a static network client class methods and I can not get rid of it so easily now — several classes depend on its functionality.
Even if you don’t have an ability to use unit tests, create some Espresso tests for the UI. They will save your time sooner than you expect.
Do not update Android Studio early
You should wait for the first bug fix release at least. I have wasted so much time with Data Binding compilation errors, just believe me. Unstable Data Binding implementation and tooling was one of the reasons why I switched to MVP (Model-View-Presenter) pattern from MVVM (Model-View-ViewModel).
Use ProGuard and LeakCanary
The first will shrink your APKs’ size, the second will notify should you miss any memory leak.
Use JodaTime for managing dates
This is the only true way to handle dates on Android (note Android-specific dependencyon GitHub) —
java.util.Date is mutable and does not handle time zones well.
Use RxJava for background work
RxJava is a life-saver in case you don’t want to struggle with
AsyncTask. It makes thread management simple and convenient.
Target lowest SDK possible
Who wouldn’t want to drop old versions support and forget about compatibility hacks? Well, everyone wants to target latest Android, but users often can’t — their hardware is the issue. Many vendors leave their devices with an old Android, making the new ones the priority. So, if you drop support for old versions, you will have to bring it back again, because (chances are) you will be asked to by one of your users.
Make version info easy to reach
You will need to know the version number when somebody tells you the app does not work as expected. Adding version number or a git commit hash to the About screen would be enough to make your life easier.
Add automatic updating
Imagine a user asking you why the app behaves unexpectedly, provided you fixed that bug two versions earlier — that’s not unreal. Almost no one actually install those APKs you publish unless they are on Google Play. There should be a way to install new versions on consumer devices automatically.