dkunzler / esperandro

Easy SharedPreference Engine foR ANDROid
Other
180 stars 14 forks source link

Support usage of Kotlin properties in interface definition #62

Closed dmo60 closed 4 years ago

dmo60 commented 5 years ago

Hey! Thank you for your work on this library!

I think it would be nice if Esperandro would support an interface like this defined in Kotlin:

interface MyPrefs {
    var stringPref: String
    var isEnabled: Boolean
}

Kotlin exposes getter and setter functions for these properties in Java, but those are prepended with a get/set prefix (https://kotlinlang.org/docs/reference/java-to-kotlin-interop.html#properties). Esperandro basically sees this:

public interface MyPrefs {
    String getStringPref();
    void setStringPref(String value);

    boolean isEnabled();
    void setEnabled(boolean value);
}

Due to Esperandro requiring the getter and setter to have the same name, this interface definition does not work (it compiles fine, but does not behave as expected).

I would love to see Esperandro adding support for Kotlin properties. I see a couple of advantages over a traditional Esperandro interface defined in Java:

I could imagine Esperandro mapping getter and setter method names to the same key, if they just differ in their prefix (basically implement the mapping that Kotlin does). Maybe this mapping is enabled by default or it can be enabled via an annotation parameter (sth like @SharedPreference(normalizeAccessorNames = true)).

Let me know what you think.

dkunzler commented 5 years ago

I like the idea. Honestly I already questioned the decision to not use this syntax in the first place.

Since it requires some development in a few different places I can't give a time estimation. But I will definately add it to the list of desired features.

dkunzler commented 4 years ago

I know that this is already very old...

but I implemented a first working version and released a snapshot.

If you add the following repository: maven { url "https://oss.sonatype.org/content/repositories/snapshots/" }

and use version 4.0.0-SNAPSHOT

you can use get and set method names. The old version does not work anymore without some work. I added @Get and @Put annotations to mark a method as a get, respective put method for a given preference. That should make it easier in transition because you don't need to change all method names across your code, but just mark the interface with additional annotations.

If you try it and see anything weird please reach back to me. I promise it will be done in a substantially shorter amount of time.

dkunzler commented 4 years ago

version 4.0.0 released.