some feedback for the android app

[Kurt Seebauer]

Hi all,

I pulled the latest code of the android app and had a closer look. Here 
comes a round of feedback:

* the standard java/maven/gradle source layout says the sources are in 
src/main/java, resources in src/main/res, tests and androidTests in 
src/test and src/androidTest. Changing that would be as easy as to run a 
view git mv commands and removing the sourceSets-block in the 
build.gradle. Probably the script for the translations would have to be 
adjusted too. Would you agree to change that (after the active feature 
branches are merged)? Additionaly, package names start with a lower case 
and android studio warns about that, because it "thinks" we reference 
inner classes in the AndroidManifest.xml. Running Analyze/Inspect Code 
reveales a lot more warnings about that and style issues.

* minSdkVersion is set to 9. Active android versions below 19 
(KITKAT/4.4) are very rare and hard to provide test coverage for. Are 
there specific reasons to provide support for such old versions?

* JavaVersion is set to 1.7. This is probably because nobody upgraded 
it, when 1.8 became available for android.

* The app crashes a lot on my phone (Android 8.1), but seems to run fine 
most of the time when attached to the debugger. In a commercial app 
you'd include google Crashlytics to report crashes and exceptions. I'm 
not sure this is the right thing in an open source project. Maybe with 
an opt-in? A short feedback loop for crash reports seems important to me 
for an app with several thousands of installations. An option for 
developers would be to create a "crashlytics-patchset" and use that in a 
personal fork. Have there been discussions about such things?

* running work in the background is typically done in an AsyncTask in 
Android. We use a lot of new Thread(){}.start()s in our code. The 
MousePad-plugin starts 100s of threads within a few seconds causing the 
garbace collector to run wild. As a rule of thumb, creating a new thread 
costs about 1MB of memory and causes significant CPU overhead. 
AsyncTasks and other mechanisms reuse threads from a threadpool. If 
you're using Kotlin (which I'd recommend for the future), even better 
and less verbose options exist. I can try and come up with some patches, 
but I'd like to hear your opinion on Kotlin first. Using it would 
require a few lines in the build.gradle files and then you can start 
migrating one Java class after another. Readability should be no problem 
for someone who knows Java.

That's it for the first round!

Regards,
Kurt