initDefaults broken about esperandro

[dkunzler]

I will have a look!

[MFlisar]

Thanks. Just take your time, I don't need the new features in the project where I need the initDefaults... I can simply continue using v2.2.0 for now

[dkunzler]

Hi, I looked into it and guess it is a user error 😁
(And a lack of documentation from my side)

Initidefaults uses (at least in the newer versions, I can't remember the old ones) the getter and setter methods since the getters already contain the complete logic to generate the correct defaults.
If setter or getter is missing no default initialization is generated for this specific preference. I even can't decide how to init them, so it wouldn't make sense to generate them.

Can you check and confirm for your examples that this is the case for the different files you use?

[MFlisar]

In this very old app of mine I use it like following:

@SharedPreferences(name = Preferences.PREF_NAME, mode = SharedPreferenceMode.PRIVATE)
public interface Preferences extends SharedPreferenceActions
{
    String PREF_NAME = "APP_PREFERENCES";
    
    public static final String userKnowsNavigationDrawer = "userKnowsNavigationDrawer";
    @Default(ofBoolean = false)
    boolean userKnowsNavigationDrawer();
    boolean userKnowsNavigationDrawer(boolean userKnowsNavigationDrawer);
    
    public static final String language = "language";
    @Default(ofString = "0")
    String language();
    boolean language(String language);
}

Should work, shouldn't it?

[dkunzler]

Yeah, that's the bug I found after writing my comment 👍
If you had a commit setter (boolean return type) it also didn't work. This is fixed locally. I will also remove the need for a setter and use the normal SharedPreference object for writing, and then push a new version.

[MFlisar]

great, thanks a lot

[dkunzler]

I just pushed 2.7.1 to maven central. initDefaults should no show better results.

[MFlisar]

Great, works. Thank you