Is it possible to use esperandro type safe with PreferenceScreens written in xml?

A simple solution for me would be that you just generate string resources for each preference key... So that I can reference them in the xml

Any ideas to that?

It would be nice if I could enable a cache, so that I can fastly recheck a setting without reading the settings file again.

A simple HashMap would be enough and an annotation like @SharedPreferences(..., enableCaching= true). And if the user enables caching, a static HashMap is always kept in sync when writing values and reading is done by accessing the HashMap...

java.lang.ClassCastException: com.google.gson.internal.LinkedTreeMap cannot be cast to com.example.data.Item at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2215) at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2265)

When reading an ArrayList<Item> from SharedPreferences, objects stored in the ArrayList cannot be cast to their initial type (are not de-serialized).

Item class implements Serializable, Esperandro is using its default serializer.

public class Item implements Serializable {
    String title;
    String desc;
}

@SharedPreferences
public interface LocalStorageInterface {
    ArrayList<Item> localItems();
    void localItems(ArrayList<Item> items);
}

Currently one can define default values at compile time using @Default annotation. Unfortunately this works only for simple types and at compile time. If user wants to specify default value for complex object, that can't be passed to annotation, he can't do that.

My propose is to introduce getters with additional parameter that should be used as default. The library can have a convention that such methods should end with *Default

@SharedPreferences
interface MySettings{
    List getMyList(); //common usage
    List getMyListDefault(List defaultValue); //using default value if neccessary
}

The generated code would be not much more complex. Seems that the library would have to check for existence of the value for complex objects. For simple objects it can just pass parameter to shared prefs.

Recently we start hitting quite constantly "GC overhead limit exceeded" error on building our application.

We managed to take heap dump of kotlin deamon process when this happens and, after analyzing it, we saw that ProcessingMessager consumes a lot of kotlin daemon heap memory.

Seems main issue that ProcessingMessager itself is singleton and holds a reference to JavacProcessingEnvironment here https://github.com/dkunzler/esperandro/blob/d88d8e7cee508a24af921190802412167dc2175e/base/src/main/java/de/devland/esperandro/base/processing/ProcessingMessager.java#L37. This prevents GC to remove a lot of portions of heap.

Thanks for creating this project. We're using it in our and and we're quite happy with it.

There's one thing I'd like to get rid of if possible. In all of the editing calls, since #11, there's a check of the current SDK version to see if it's possible to call apply():

@Override
@SuppressLint("NewApi")
public void registrationId(String registrationId) {
  if (Build.VERSION.SDK_INT < Build.VERSION_CODES.GINGERBREAD) {
    preferences.edit().putString("registrationId", registrationId).commit();
  } else {
    preferences.edit().putString("registrationId", registrationId).apply();
  }
}

Our app is has a minSdkVersion of 15, so these calls are useless. I figure there are three ways to get rid of them:

1. Generate 2 implementations of the preference interface: one for Gingerbread containing apply() and one for pre-Gingerbread containing commit(). In the constructor of Esperandro, the current SDK could be checked and the suffix could be determined to be $$GingerbreadImpl or $$PreGingerbreadImpl. The benefit of this approach is that there would only be one SDK check per execution. The downside is that there would be twice as many classes generated and deployed with the APK. A note could be added to the README with the necessary ProGuard lines to delete the pre-Gingerbread implementations if the minSdkVersion is 9 or above.
2. Instead of, or in addition to approach 1 would be to detect the minSdkVersion in the annotation processor and not generate the commit() calls if the minSdkVersion is 9 or above. I'm not sure how easy it is to get the minSdkVersion from the processor, so this might be impossible.
3. Just get rid of the calls to commit() completely and say that Esperandro can only be used when minSdkVersion is 9 or above. :-)

If you have a preferred approach, I'd be willing to implement it if it would be merged.

After seeing the discussion in #62 I think about adding the required naming scheme as additional possibility or changing the syntax completely in a new release.

So this poll is about: a) add the possibility to use set and get additionally to the current method names where only the parameter determine the set/get operation. b) completely remove support for access via only method names and completely change it to set/get

Pros/Cons for the set/get naming scheme:

• (+) compliant to Java Bean Naming Convention and therefore better compatibility with potential other technologies like Kotlin
• (+) more visible distinction between getter and setter
• (-/+) getters with runtime defaults do not necessarily need a prefix and therefore a different name (getProperty(String default) would work whereas now it is property$Default(String default))
• (-) extreme breaking API change
• (-) understanding what the actual name of the preference will be is quite harder. (take the case into account: setProperty would still save into property not Property)

Apologize for tagging you people, but you are the only ones I know that use the library, so to get feedback I specifically ask: @danielneu @mflisar @dmo60 @rguthor2 @anthony3444 @naixx @asadkt Hopefully you are not mad about this :D

Thanks in Advance for feedback

Currently, if I use serializable lists, they are not working, as the generated code is wrapping a list in a container, that is NOT implementing serializable itself...

NOT Working: Using following does crash, as the wrapper class is not serializable:

ArrayList<String> existingSources();
boolean existingSources(ArrayList<String>existingSources);

working

OwnWrapper existingSources();
boolean existingSources(OwnWrapper  existingSources);

With OwnWrapper like following:

public static class OwnWrapper implements Serializable
{
    public ArrayList<String> sources;

    public OwnWrapper ()
    {
        sources = new ArrayList<>();
    }
}

After migration to the compilesdk 29 lots of deprecation warnings regarding the use of android.preference.PreferenceManager are generated. The reason seems to be in the generated files of the annotation processor. Can this be configured to use androidx.preference.PreferenceManager or does this need a new esperandro version?

I have a field like following in my preferences to show some info cards to my users and to know which one they have already seen and dismissed:

List<String> hiddenInfos();
boolean hiddenInfos(List<String> hiddenInfos);
void hiddenInfos$Add(String toAdd);
void hiddenInfos$Remove(String toRemove);

After my last relase I suddenly got a lot of crash reports like following:

[SerializationUtil:43 deserialize]: java.io.InvalidClassException: com.my.app.prefs.PreferenceManager$$Impl$HiddenInfos; Incompatible class (SUID): com.my.app.prefs.PreferenceManager$$Impl$HiddenInfos: static final long serialVersionUID =8736114807095266538L; but expected com.my.app.prefs.PreferenceManager$$Impl$HiddenInfos: static final long serialVersionUID =3661852850784779536L;
	at java.io.ObjectInputStream.verifyAndInit(ObjectInputStream.java:2343)
	at java.io.ObjectInputStream.readNewClassDesc(ObjectInputStream.java:1643)
	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:657)
	at java.io.ObjectInputStream.readNewObject(ObjectInputStream.java:1784)
	at java.io.ObjectInputStream.readNonPrimitiveContent(ObjectInputStream.java:761)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:1985)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:1942)
	at com.swissarmy.utils.SerializationUtil.deserialize(SerializationUtil.java:40)
	at com.my.app.MainApp$1.deserialize(MainApp.java:76)
	at com.my.app.prefs.PreferenceManager$$Impl.hiddenInfos(PreferenceManager$$Impl.java:1182)
	at com.my.app.managers.UpdateManager.onAppStart(UpdateManager.java:208)
	at com.my.app.MainApp.onAfterOnCreate(MainApp.java:151)
	...

I would expect that the serialVersionUID is constant... Maybe it makes sense to define a custom one via annotations? To avoid that the serialVersionUID is constant as this is essential for deserialisation...

Not sure if this is possible, but following (or something functional equivalent) would be nice:

@Default(ofInt = Color.argb(100, 0, 0, 0))
int handleColor();
boolean handleColor(int handleColor);

Any ideas on this?

Bumps gson from 2.8.5 to 2.8.9.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Very much appreciate what you're doing here. A couple of minor items:

• The changelog link on README.md is incorrect ('changelog' in the link needs to be uppercase)
• The changelog itself seems to be lagging the latest 4.0.x release(s). After digging, I found some info on the Migration wiki page, but unsure what other changes have taken place.

Add another processor that generates a class with all known (means same compilation unit) Shared Preference classes.

We then can operate on all of them for example clear all, init defaults for all. This will add some interesting possibilities.