Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash When Using EditTextPreference with Numerical Default #5

Closed
denley opened this issue Sep 30, 2015 · 5 comments
Closed

Crash When Using EditTextPreference with Numerical Default #5

denley opened this issue Sep 30, 2015 · 5 comments
Labels

Comments

@denley
Copy link

denley commented Sep 30, 2015

When using a numerical value as the defaultValue attribute in an EditTextPreference, PSync seems to determine that the preference value associated with the key should be an int rather than a String (as it would be if the defaultValue attribute was omitted).

The problem is that EditTextPreference saves the value into the SharedPreferences file as a String, so it causes a crash when trying to read the value using PSync.

The following example will cause the crash:

<PreferenceScreen xmlns:android="http://schemas.android.com/apk/res/android">

    <EditTextPreference
        android:key="a_number"
        android:title="Test Number"
        android:inputType="number"
        android:defaultValue="0"
        />

</PreferenceScreen>
public class SettingsActivity extends PreferenceActivity {

    @Override protected void onCreate(final Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        addPreferencesFromResource(R.xml.preferences);


        // This crashes, because EditTextPreference always saves the value as a String, not an int
        P.aNumber.get();
    }

}

I think the most ideal solution here would be to detect the desired type from the inputType xml attribute and have PSync load the String value and parse it to the appropriate type. Though that may be difficult to get right in every case. If that proves unfeasible, PSync should just use a String type for EditTextPreference values.

@ZacSweers
Copy link
Contributor

Interesting! I haven't used EditTextPreference personally, so this is an
edge case I didn't consider. I'll add this under the other issue with
custom xml attributes, as this is definitely a good example for it.
On Wed, Sep 30, 2015 at 4:41 AM Denley Bihari notifications@github.com
wrote:

When using a numerical value as the defaultValue attribute in an
EditTextPreference, PSync seems to determine that the preference value
associated with the key should be an int rather than a String (as it
would be if the defaultValue attribute was omitted).

The problem is that EditTextPreference saves the value into the
SharedPreferences file as a String, so it causes a crash when trying to
read the value using PSync.

The following example will cause the crash:

<EditTextPreference
    android:key="a_number"
    android:title="Test Number"
    android:inputType="number"
    android:defaultValue="0"
    />

public class SettingsActivity extends PreferenceActivity {

@Override protected void onCreate(final Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    addPreferencesFromResource(R.xml.preferences);


    // This crashes, because EditTextPreference always saves the value as a String, not an int
    P.aNumber.get();
}

}

I think the most ideal solution here would be to detect the desired type
from the inputType xml attribute and have PSync load the String value and
parse it to the appropriate type. Though that may be difficult to get right
in every case. If that proves unfeasible, PSync should just use a String
type for EditTextPreference values.


Reply to this email directly or view it on GitHub
#5.

@ZacSweers ZacSweers added the bug label Sep 30, 2015
@ZacSweers ZacSweers mentioned this issue Sep 30, 2015
3 tasks
@denley
Copy link
Author

denley commented Oct 1, 2015

In case anyone else runs into this issue, I've been able to work around it by subclassing EditTextPreference to make it save int values instead of Strings, like so:

public class IntegerEditTextPreference extends EditTextPreference {

    public IntegerEditTextPreference(final Context context) {
        super(context);
    }

    public IntegerEditTextPreference(final Context context, final AttributeSet attrs) {
        super(context, attrs);
    }

    public IntegerEditTextPreference(final Context context, final AttributeSet attrs, final int defStyleAttr) {
        super(context, attrs, defStyleAttr);
    }

    public IntegerEditTextPreference(final Context context, final AttributeSet attrs, final int defStyleAttr, final int defStyleRes) {
        super(context, attrs, defStyleAttr, defStyleRes);
    }

    @Override protected String getPersistedString(final String defaultReturnValue) {
        int defaultAsInt;
        try {
            defaultAsInt = Integer.parseInt(defaultReturnValue);
        } catch (NumberFormatException e) {
            // No default is set
            defaultAsInt = 0;
        }

        final int intValue = getPersistedInt(defaultAsInt);
        return Integer.toString(intValue);
    }

    @Override protected boolean persistString(final String value) {
        try {
            return persistInt(Integer.parseInt(value));
        }catch(NumberFormatException e) {
            // This shouldn't happen as long as it has inputType="number"
            return false;
        }
    }

}

@dadouf
Copy link

dadouf commented Dec 1, 2015

Sorry to point it out @hzsweers, but this is no corner case! I've run into the problem in two of my projects and every time I need to use the fix. Cheers!

@ZacSweers
Copy link
Contributor

Sorry I've been really busy the past few months. Pull requests are totally
welcome though!

On Tue, Dec 1, 2015, 10:02 AM David Ferrand notifications@github.com
wrote:

Sorry to point it out @hzsweers https://github.com/hzsweers, but this
is no corner case! I've run into the problem in two of my projects and
every time I need to use the fix. Cheers!


Reply to this email directly or view it on GitHub
#5 (comment).

@ZacSweers
Copy link
Contributor

This issue was moved to ZacSweers#4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants