some feedback for the android app

[Matthijs Tijink]

Hi Kurt,

Thanks for the feedback! Here's my personal reaction (I can't speak for 
everyone, of course):

> * 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.
Does it matter a lot if this is unchanged? On the other hand, if we get less 
warnings that's good too, but indeed only after outstanding stuff is merged.

> * 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?
Yes, we like supporting old versions as long as possible, especially if 
there's no good reason to drop them. Also, KDE Connect doesn't have a typical 
user base, so these usage numbers are somewhat different for us. Later this 
year we'll have to raise this minimum because of the new Google rules though, 
so we'll go to API 14.

> * JavaVersion is set to 1.7. This is probably because nobody upgraded
> it, when 1.8 became available for android.
Actually, there's currently a review request to change this!

> * 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?
We know of some crashes on 8.1, but the most active developers don't have 8.1 
yet, so we can't fix it (some help here would be greatly appreciated!). We 
can't include such stuff, since KDE Connect is GPL-licensed. The patchset 
would be okay (since we won't distribute it ourselves that way), but how many 
people will use that? I think we get some exceptions via the Google play 
console though.

> * 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.
Good points, we should fix that indeed. Most of the developers aren't really 
used to Android/Java development, so we make mistakes :-( But if you're 
willing to help, that would be great!
About Kotlin: I guess it depends on how different it is from Java/C++, and how 
well it integrates into the existing Java code. Learning two languages just to 
dive into the KDE Connect app might be a bit much. What can you tell us about 
that?

In general: if there's stuff we can do better: patches are always welcome! 
Reviewing review requests also helps, as that also improves the abilities of 
the other developers.

Kind regards, Matthijs Tijink