some feedback for the android app

[Kurt Seebauer]

Hi Matthijs,

thanks for your response!


On 16.04.2018 20:36, Matthijs Tijink wrote:
> Here's my personal reaction (I can't speak for everyone, of course):

Still, our mails didn't start a huge controversy, so I assume the other 
developers tend to agree with you. :-)
>> * the standard java/maven/gradle source layout (...)
> 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.
It's not the most pressing thing to do, but violating standards usually 
means asking for trouble from unexpected sources. Let's wait for the 
feature branches to be 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.
Good point. Maybe someone with access to the playstore can provide us 
with the real numbers?
>> * 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.
I don't see, how exactly including a third party library violates the 
GPL, can you explain that? I see however that we don't want to include 
that stuff in the standard distribution.
Recently I played  around with different build configurations in another 
app, so we could configure on build time wherer Crashlytics should be 
used or not. Developers could decide to turn it on in their 
installations if they want to. That beats the patchset-idea by far.
>
> About Kotlin: I guess it depends on how different it is from Java/C++, and how
> well it integrates into the existing Java code.
It integrates perfectly, you can convert classes randomly with 
CTRL-ALT-SHIFT-K and see how your code looks in Kotlin. Calling Kotlin 
from Java and vice versa works automatically, but some constructs (like 
static methods) are handled differently in Kotlin.
Kotlin has a few key advantages: Types are not-nullable by default, so 
you define at the method level, if a String or a nullable String? is 
returned. Most crashes happen because of NullPointerExceptions. In 
Kotlin you can import xml-fragments and have direct access to the 
elements, no more findById() with type casts. Kotlin is eating Javas 
lunch in the Android universe and there are a lot of tutorials and 
videos out there. I think the best thing I can do is to send some 
well-documented patches and let you decide.
> Learning two languages just to
> dive into the KDE Connect app might be a bit much. What can you tell us about
> that?
Yeah, losing developers because of a third language is certainly the 
last thing we want.

Greetings,
Kurt