Common interface for SharedPreferences

Hi,

Is there a reason why the preference fields for shared preferences do not share a common interface that exposes the get and put methods? They all extend AbstractPrefField and all implement a get and put method, but it is not enforced.

However, (to clarify why I ask this question) I am trying to create a wrapper around these preference fields to make them observable (using rxjava). It is possible to make it work as follows:

import org.androidannotations.api.sharedpreferences.AbstractPrefField;
import rx.Observable;
import rx.subjects.BehaviorSubject;

public class PreferenceObservable<T> {

    private AbstractPrefField prefField;
    private BehaviorSubject<T> prefSubject;

    public PreferenceObservable(AbstractPrefField pref) {
        prefField = pref;
        prefSubject = BehaviorSubject.create(getLast());
    }

    public Observable<T> get() {
        return prefSubject.asObservable();
    }

    @SuppressWarnings("unchecked")
    public T getLast() {
        try {
            return (T) prefField.getClass().getMethod("get").invoke(prefField);
        } catch (Exception e) {}
        return null;
    }

    public void put(T value) {
        try {
            for (Method m : prefField.getClass().getMethods())
                if (m.getName().equals("put")) {
                    m.invoke(prefField, value);
                    prefSubject.onNext(value);
                    break;
                }
        } catch (Exception e) {}
    }
}

I am obliged to use reflection to get the methods I need. I know these methods are there, so I ignore error handling. Therefore, it would be better practice to simply expose these methods to avoid having to use this approach? Or maybe I am doing something wrong?

Cheers,

Christophe

@DayS

Please note the methods have different arguments, so that's why a common method is not added to the superclass. Also the parameters are primitives, so we cannot add a generic super method.

But i think we can change them to use wrapper classes, so we could use generic super methods. @DayS, @yDelouis do you think any problem with that?

The only problem I see is that in the put method, what should we do if null is given as argument ?
Should we remove the preference or should we put 0 ? (I vote for the former proposition).

Another problem is that we just provide a more cleaner wrapper for the original Android class. And the original Android class uses primitive values... I am not sure we are in a position to define a new API, and decide what happens with nulls.

Isn't the current wrapper already breaking/extending the original API? E.g. in LongPrefField allowing the preference to possibly be a string and then convert it to long? However, it is true that deciding what happens with null is not on the same level. I would suggest that using null would reset the preference to its default value.

@chvndb

OK, i vote for this change. But we should add JavaDoc on the superclass to document this behavior, and highlight the diff to the original Android class.

@chvndb feel free to contribute this feature.

Ok, I’ll give it a shot when I get the time.

@chvndb

@chvndb did you manage to work on this?

Sorry, not yet. I used my work around for now in my project for which the deadline is next week monday. So, I had no time at all to do this. However, I still planned to do it after my project deadline.

I will probably look into contributing other things as well, seeing that I make heavily use of this great library :-).

Merge pull request #1272 from chvndb/1203-Generic_AbstractPrefField

Navigation Menu

Repository navigation

Common interface for SharedPreferences #1203

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Common interface for SharedPreferences #1203

Description

Activity

WonderCsabo commented on Oct 29, 2014

yDelouis commented on Oct 29, 2014

WonderCsabo commented on Oct 29, 2014

chvndb commented on Oct 29, 2014

WonderCsabo commented on Oct 29, 2014

chvndb commented on Oct 30, 2014

WonderCsabo commented on Nov 21, 2014

chvndb commented on Nov 21, 2014

chvndb commented on Nov 21, 2014

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions