Preferences innerhalb der App holen

[Scogit]

Hi,

vielleicht hab ich hier auch ein absolutes Verständnisproblem aber wie kann ich auf preferences wieder zugreifen?

package de.avdr.CommandWrappers;

import android.content.SharedPreferences;
import android.preference.PreferenceManager;

public class CWFactory {
    public enum Wrapper {
        SVDRP
    }

    public CommandWrapper createWrapper(Wrapper wrapper) {
        SharedPreferences preferences = PreferenceManager.getDefaultSharedPreferences(this);

        CommandWrapper objWrapper;

        switch(wrapper) {
            case SVDRP:
                objWrapper = new Svdrp();
                break;
            default:
                objWrapper = null;
        }

        return objWrapper;
    }
}

Als Error hab ich hier

The method getDefaultSharedPreferences(Context) in the type PreferenceManager is not applicable for the arguments (CWFactory)

Weis jemand Rat?

 

[Temar]

The method getDefaultSharedPreferences(Context) in the type PreferenceManager is not applicable for the arguments (CWFactory)

Naja, so wie's da steht halt. getDefaultSharedPreferences() erwartet als Parameter einen Context. Das kann z.B. eine Activity sein. Deine CWFactory ist aber weder von Activity noch von Context abgeleitet. Daher funktionier "this" als Parameter nicht.

 

[Scogit]

Naja, so wie's da steht halt. getDefaultSharedPreferences() erwartet als Parameter einen Context. Das kann z.B. eine Activity sein. Deine CWFactory ist aber weder von Activity noch von Context abgeleitet. Daher funktionier "this" als Parameter nicht.

Das ist soweit klar aber was ist die Lösung?

 

[Temar]

Das ist soweit klar aber was ist die Lösung?

Hehe, du übergibst ihr einen Context

Aber Spass beiseite. Ich löse das immer so, dass ich meiner MainActivity, also der die über den Launcher gestartet wird eine statische Application-Variable verpasse und diese gleich am Anfang initialisiere:

public class MainActivity extends Activity
{
    public static Application app;

    @Override
    public void onCreate(Bundle savedInstanceState)
    {
        app = getApplication();
    }
}

und dann:

public class CWFactory {
    public enum Wrapper {
        SVDRP
    }

    public CommandWrapper createWrapper(Wrapper wrapper) {
        SharedPreferences preferences = PreferenceManager.getDefaultSharedPreferences(MainActivity.app);

        CommandWrapper objWrapper;

        switch(wrapper) {
            case SVDRP:
                objWrapper = new Svdrp();
                break;
            default:
                objWrapper = null;
        }

        return objWrapper;
    }
}

 

[Scogit]

Naja gefällt mir ned wirklich weil du dich dadurch abhängig von der Activity machst solltes du die mal tauschen must daran denken das mitzunehmen oder wenn du wenn mal ne andere Activity als start festlegen willst.

Ich werds über das Registry Pattern lösen. Ich hab eine abstracte activity Klasse in der auch das Menü definiert ist - von dieser leiten bei mir eh alle activity's ab - dort übergeb ich das einfach der Registry Klasse.

Ok trotzdem vielen dank ich kannte die Methode getApplication noch nicht.

 

[Temar]

Naja gefällt mir ned wirklich weil du dich dadurch abhängig von der Activity machst solltes du die mal tauschen must daran denken das mitzunehmen oder wenn du wenn mal ne andere Activity als start festlegen willst.

Jo, stimmt. Das ist auch nur ein vereinfachtes Beispiel. In wirklichkeit bau ich das bei mir in den Main-Application Context rein und der ändert sich nicht.

Alternativ kannst du dem Constructor deiner Klasse ja auch einfach nen Context übergeben. Dann haste gar keine Abhängigkeiten. Das mach ich aber recht ungern bei Klassen die im Prinzip nix über die GUI Wissen müssen.

 

[Scogit]

Jo auch ganz gut ja meine Methode fällt mir auch noch ned wirklich.
Weil bei Android lässt sich gut das MVC Pattern umsetzen. Und das Modell sollte davon definitv keine Ahnung von haben ... und hier wären ja die Activitys die Controller.

 

[Dida]

Ein Singleton würde auch passen.

Singletonklasse

import android.content.*;
import android.preference.PreferenceManager;

// Singleton for Preferences
public class MyPreferences {

    private static MyPreferences thePrefernces=null;
    private SharedPreferences prefs = null;
    // Privater Konstruktor
    private MyPreferences(Context c){
       prefs=PreferenceManager.getDefaultSharedPreferences(c);
    }

    // Fuer den ersten Aufruf    zum Initialisieren
    public static MyPreferences getPreferences(Context c){
        if(thePrefernces==null){
            thePrefernces = new MyPreferences(c);
        }
        return(thePrefernces);
    }
    
    // Fuer alle weiteren Aufrufe
    public static MyPreferences getPreferences(){
        if(thePrefernces==null){
            throw new IllegalStateException("Problem with preferences");
        }
        return(thePrefernces);
    }

    // Zugriffs methoden wie gewuenscht
    public String getString(String key) {
        String strVal = prefs.getString(key, "");
        return strVal;
    }
    
    public void setString(String key, String val) {
        SharedPreferences.Editor editor = prefs.edit();
        editor.putString(key, val);
        editor.commit();
    }
}

Erster Aufruf zum Initialisieren zum Beispiel in "onCreate" der StartActivity (kann auch an mehrereren Stellen stehen)

        MyPreferences prefs = MyPreferences.getPreferences(this);

Beispielzugriff

            MyPreferences prefs = MyPreferences.getPreferences();
            String s = prefs.getString("irgendein_key");

Vorteile:

• Gekapselt wie gewünscht. => Könnte auch durch einen anderen Mechanismus für Preferences ersetzt werden.
• Vererbung ist immer noch möglich. => Der Zugriff merkt nichts davon
• Ebenso wenn man eine Methode überschreiben würde.
• Konfiguration während der Laufzeit möglich.

Nachteile

• Erhöhte Laufzeit, was beim Dateizugriff der Prefernces sowieso ein Problem ist.

 

[Scogit]

Stimmt aber ich versuche möglichst Singleton's und static Variablen zu vermeiden ist ein wenig vergleichbar mit globalen Variablen die mitgeschleppt werden müssen.

In Verbindung mit den Registry Pattern lässt sich das Verkraften da man hier alle weiteren Singleton Instancen vermeiden kann da diese in der Registry abgelegt werden.

 

[friedger]

Ich würde den Wert aus den Präferenzen übergeben, dann braucht man die Prefs gar nicht in Deinem CommandWrapper...

Friedger

 

[Scogit]

Ja das hab ich mir auch schon überlegt ... das Problem dabei ist nur ich will recht flexible dabei bleiben. Der CommandWrapper soll nur die entsprechenden Funktionen der eigentlichen Kommunikationsklasse sein.

Ich bilde gerade noch mal mein komplettes Konzept in XML ab ... mal schauen wo das Ding noch Schwachstellen hat.

 

[friedger]

Oh, das hört sich komplex an. Hier geht es aber um mobile Geräte, die ohne Atomkraftwerk auskommen sollen, oder?

Keine Ahnung ob das relevant ist, aber die Session Google I/O - Coding for Life -- Battery Life, That Is
sollte man immer im Hinterkopf haben.

Friedger