<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Hello,</div>
<div> </div>
<div>I only looked recently into the sources of kde connect, nevertheless I thought to add my 5ct to your comments.</div>
<div> </div>
<div>1) whatever is not standard I believe should be as much standard as possible. Some of the points you mentioned I can confirm, some others I don't see at the moment.</div>
<div> </div>
<div>2) minSdkVersion should indeed be 19, stumble across that as well lately. Maybe it should be considered to go for API level 21. The reason why I propose this is the problem I try to solve about access to the SD card and changes in there with that API level. About 10% of Android devices are on KitKat (level 19) so we would loose these users. Below level 19 we hardly have any user. https://developer.android.com/about/dashboards/index.html </div>
<div> </div>
<div>3) yes, please.</div>
<div> </div>
<div>4) crashes: Not sure what you mean with crashes, really app closes? I don't have that issue (Android 8), though I have lots of times issues where I don't know why something is not working correctly. I believe users should get much better informed.</div>
<div> </div>
<div>5) Not sure if at this point in time I would switch to Kotlin. I don't know how much people use it today, this might scare other people away.</div>
<div>
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b> Montag, 16. April 2018 um 19:11 Uhr<br/>
<b>Von:</b> "Kurt Seebauer" <kurt.seebauer.oss@gmail.com><br/>
<b>An:</b> "kde connect list" <kdeconnect@kde.org><br/>
<b>Betreff:</b> some feedback for the android app</div>
<div name="quoted-content">Hi all,<br/>
<br/>
I pulled the latest code of the android app and had a closer look. Here<br/>
comes a round of feedback:<br/>
<br/>
* the standard java/maven/gradle source layout says the sources are in<br/>
src/main/java, resources in src/main/res, tests and androidTests in<br/>
src/test and src/androidTest. Changing that would be as easy as to run a<br/>
view git mv commands and removing the sourceSets-block in the<br/>
build.gradle. Probably the script for the translations would have to be<br/>
adjusted too. Would you agree to change that (after the active feature<br/>
branches are merged)? Additionaly, package names start with a lower case<br/>
and android studio warns about that, because it "thinks" we reference<br/>
inner classes in the AndroidManifest.xml. Running Analyze/Inspect Code<br/>
reveales a lot more warnings about that and style issues.<br/>
<br/>
* minSdkVersion is set to 9. Active android versions below 19<br/>
(KITKAT/4.4) are very rare and hard to provide test coverage for. Are<br/>
there specific reasons to provide support for such old versions?<br/>
<br/>
* JavaVersion is set to 1.7. This is probably because nobody upgraded<br/>
it, when 1.8 became available for android.<br/>
<br/>
* The app crashes a lot on my phone (Android 8.1), but seems to run fine<br/>
most of the time when attached to the debugger. In a commercial app<br/>
you'd include google Crashlytics to report crashes and exceptions. I'm<br/>
not sure this is the right thing in an open source project. Maybe with<br/>
an opt-in? A short feedback loop for crash reports seems important to me<br/>
for an app with several thousands of installations. An option for<br/>
developers would be to create a "crashlytics-patchset" and use that in a<br/>
personal fork. Have there been discussions about such things?<br/>
<br/>
* running work in the background is typically done in an AsyncTask in<br/>
Android. We use a lot of new Thread(){}.start()s in our code. The<br/>
MousePad-plugin starts 100s of threads within a few seconds causing the<br/>
garbace collector to run wild. As a rule of thumb, creating a new thread<br/>
costs about 1MB of memory and causes significant CPU overhead.<br/>
AsyncTasks and other mechanisms reuse threads from a threadpool. If<br/>
you're using Kotlin (which I'd recommend for the future), even better<br/>
and less verbose options exist. I can try and come up with some patches,<br/>
but I'd like to hear your opinion on Kotlin first. Using it would<br/>
require a few lines in the build.gradle files and then you can start<br/>
migrating one Java class after another. Readability should be no problem<br/>
for someone who knows Java.<br/>
<br/>
That's it for the first round!<br/>
<br/>
Regards,<br/>
Kurt</div>
</div>
</div>
</div></div></body></html>