Skip to content
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
This repository was archived by the owner on Feb 26, 2023. It is now read-only.

@PreferenceChange minor parameter related changes #1394

Closed

Description

@athkalia

You are supporting a Boolean parameter on the @PreferenceChange annotation (but not mentioned in documentation), and you are not supporting a

 Set<String>  

parameter (but is reported in the documentation, you probably only meant to say that Set is supported) Finally the Long parameter is not supported (and correctly not reported in the documentation).
Maybe while you are at it you can also change @SharedPref to support Double, and also make @PreferenceChange support doubles?

Activity

  1. WonderCsabo commented on May 4, 2015

    @WonderCsabo
    Member

    What Preference uses a Long value? I quickly read throught the Preference subclasses in the android.preference package:

    EditTextPreference: String
    ListPreference : String
    MultiSelectListPreference : Set<String>
    CheckBoxPreference : Boolean

    Of course one could use other subclasses from libraries or own code, which use different values.

  2. athkalia commented on May 4, 2015

    @athkalia
    Author

    I am always keeping in mind your @SharedPref annotation.
    In my implementation I have linked a ListPreference to have longs and store it:

    @SharedPref(value = SharedPref.Scope.UNIQUE)
    public interface Settings {

    @DefaultRes(keyRes = R.string.list_preference_key,value = 60000)
    long automatedFollowSignalsInterval();
    

    }

    and the xml:

       <ListPreference android:key="@string/list_preference_key"
                        android:title="Title"
                        android:dialogTitle="Dialog Title"
                        android:entries="@array/entries"
                        android:entryValues="@array/entry_values"
                        android:defaultValue="60000"/>
    

    and the 2 arrays:

       <string-array name="entries">
        <item>1 minute</item>
        <item>5 minutes</item>
        <item>20 minutes</item>
        <item>1 hour</item>
        <item>3 hours</item>
        <item>6 hours</item>
        <item>24 hours</item>
    </string-array>
    
    <string-array name="entry_values">
        <item>60000</item>
        <item>300000</item>
        <item>1200000</item>
        <item>3600000</item>
        <item>10800000</item>
        <item>21600000</item>
        <item>86400000</item>
    </string-array>
    
  3. WonderCsabo commented on May 4, 2015

    @WonderCsabo
    Member

    These are not longs, these are strings. You will have a String object as the newValue parameter. Looking at the code, ListPreference is only capable of storing Strings actually.

    Our @SharedPref only works for you because we parse the string to a long (#503). Maybe we should do it here, too (it is little bit more compliated then in SharedPref)?

  4. athkalia commented on May 4, 2015

    @athkalia
    Author

    Ah, I just noticed now that you mentioned it. Well it wouldn't be too bad to have unless it's difficult to implement

  5. WonderCsabo commented on May 4, 2015

    @WonderCsabo
    Member

    OK, i can think of this generated code:

    @PreferenceChange
    void myPreferenceChanged(Integer value) {
       // TODO
    }
    
    if (newValue instaceof String) {
       int value = Integer.parseInt(newValue);
       myPreferenceChanged(preference, value)
       // this will throw a `NumberFormatException` if the String does not store an int, that is OK
    } else if (newValue instaceOf Integer) {
       myPreferenceChanged(preference, (Integer) value)  
    } else {
      throw new NumberFormatException("only can convert strings to numbers")
    }

    This ugly snippet is only generated if the parameter type is Integer, Float, Double or Long.

  6. WonderCsabo commented on May 4, 2015

    @WonderCsabo
    Member

    OK, actually this branch

    else if (newValue instaceOf Integer) {

    will be never used with the android default Preference class implementations. I am not sure we should prepare for other ones, since they could use any type.

  7. self-assigned this
    on May 5, 2015
  8. WonderCsabo commented on May 9, 2015

    @WonderCsabo
    Member

    Fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions