1. Nimm jetzt an unserem Uhans - 3. ADVENT - Gewinnspiel teil - Alle Informationen findest Du hier!

Preferences innerhalb der App holen

Dieses Thema im Forum "Android App Entwicklung" wurde erstellt von Scogit, 19.08.2009.

  1. Scogit, 19.08.2009 #1
    Scogit

    Scogit Threadstarter Android-Hilfe.de Mitglied

    Beiträge:
    69
    Erhaltene Danke:
    2
    Registriert seit:
    16.08.2009
    Phone:
    Samsung Galaxy
    Hi,

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

    Code:
    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
    Weis jemand Rat?
     
  2. Temar, 19.08.2009 #2
    Temar

    Temar Erfahrener Benutzer

    Beiträge:
    214
    Erhaltene Danke:
    14
    Registriert seit:
    25.06.2009
    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.
     
  3. Scogit, 19.08.2009 #3
    Scogit

    Scogit Threadstarter Android-Hilfe.de Mitglied

    Beiträge:
    69
    Erhaltene Danke:
    2
    Registriert seit:
    16.08.2009
    Phone:
    Samsung Galaxy
    Das ist soweit klar aber was ist die Lösung?
     
  4. Temar, 19.08.2009 #4
    Temar

    Temar Erfahrener Benutzer

    Beiträge:
    214
    Erhaltene Danke:
    14
    Registriert seit:
    25.06.2009
    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:

    Code:
    public class MainActivity extends Activity
    {
        public static Application app;
    
        @Override
        public void onCreate(Bundle savedInstanceState)
        {
            app = getApplication();
        }
    }
    
    und dann:

    Code:
    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;
        }
    }
    
     
    Zuletzt bearbeitet: 19.08.2009
  5. Scogit, 20.08.2009 #5
    Scogit

    Scogit Threadstarter Android-Hilfe.de Mitglied

    Beiträge:
    69
    Erhaltene Danke:
    2
    Registriert seit:
    16.08.2009
    Phone:
    Samsung Galaxy
    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.
     
  6. Temar, 20.08.2009 #6
    Temar

    Temar Erfahrener Benutzer

    Beiträge:
    214
    Erhaltene Danke:
    14
    Registriert seit:
    25.06.2009
    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.
     
  7. Scogit, 20.08.2009 #7
    Scogit

    Scogit Threadstarter Android-Hilfe.de Mitglied

    Beiträge:
    69
    Erhaltene Danke:
    2
    Registriert seit:
    16.08.2009
    Phone:
    Samsung Galaxy
    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.
     
  8. Dida, 23.08.2009 #8
    Dida

    Dida Neuer Benutzer

    Beiträge:
    21
    Erhaltene Danke:
    0
    Registriert seit:
    12.06.2009
    Ein Singleton würde auch passen.

    Singletonklasse
    Code:
    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)
    Code:
            MyPreferences prefs = MyPreferences.getPreferences(this);
    
    Beispielzugriff
    Code:
                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.
     
  9. Scogit, 23.08.2009 #9
    Scogit

    Scogit Threadstarter Android-Hilfe.de Mitglied

    Beiträge:
    69
    Erhaltene Danke:
    2
    Registriert seit:
    16.08.2009
    Phone:
    Samsung Galaxy
    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.
     
  10. friedger, 25.08.2009 #10
    friedger

    friedger Erfahrener Benutzer

    Beiträge:
    175
    Erhaltene Danke:
    15
    Registriert seit:
    15.01.2009
    Ich würde den Wert aus den Präferenzen übergeben, dann braucht man die Prefs gar nicht in Deinem CommandWrapper...

    Friedger
     
  11. Scogit, 25.08.2009 #11
    Scogit

    Scogit Threadstarter Android-Hilfe.de Mitglied

    Beiträge:
    69
    Erhaltene Danke:
    2
    Registriert seit:
    16.08.2009
    Phone:
    Samsung Galaxy
    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.
     
  12. friedger, 26.08.2009 #12
    friedger

    friedger Erfahrener Benutzer

    Beiträge:
    175
    Erhaltene Danke:
    15
    Registriert seit:
    15.01.2009
    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
     

Diese Seite empfehlen