Code clean-ups

[hiqua]

After the next release (which will come some time soon I'm sure 😃), I'd like to suggest some code health improvements, some of which could easily be taken by other contributors, and most of which I think I could do myself if there's no other volunteer. My ideas:

• split numerical and yes/no habits into two proper classes, inheriting from an abstract one (there might be better patterns, but that should already be an improvement over the current class containing both)
• enum for yes / no and other values (but no DB migration)
• fix all warnings when running ./gradlew build

Anything against these @iSoron?

If you're fine with that I'll create the corresponding issues to see if somebody else would be interested in carrying them out, and I'll do them myself eventually if not. In any case after the next release to avoid delaying it further.

There's also #1075 which I can spend some time on as well.

[iSoron]

@hiqua I think all of these would be nice to have. My concern with the first and second suggestions, though, is that any modification to Habit and Entry currently propagate through the entire codebase: from the core model classes, all the way to the UI classes. I don't really see how could we do this refactoring a few files at a time with our current architecture, which risks introducing subtle bugs everywhere.

Something I started a while ago was ensuring that UI classes depend only on primitives, not on our core classes, so that changes to the core classes stop at the core/UI boundary. For example, everything required to render TargetCardView is contained in TargetCardState, which contains only lists of numbers (not Habit or Entry) so it would not be affected by these kinds of refactoring. The changes would stop at TargetCardPresenter, which builds the state from the data in the core classes. The entire ShowHabitActivity is already using this architecture, but the remaining activities are still tightly coupled with model classes. I was doing this mostly for the multiplatform aspect of it (we can easily reuse State and Presenter in all platforms, and just rewrite the view itself), but it would also help with this refactoring issue.

I suggest completing this refactoring before moving onto more ambitious changes to the core classes. If you do think this refactoring can be done cleanly even in the current state, please feel free to go ahead and submit a PR. I might be wrong.