Java Plugin-Klassen richtige Implementierung

mwuehrer · 11. September 2013

Hallo,
ich wollte eine App schreiben, die mit Plugins erweiterbar ist, konkret geht es in der App darum, dass man SMS von einem Web-Sms-Provider (bsp. smstrade.de) sendet und nicht über die Mobilfunkprovider.
Um nun die App einfach mit weiteren Web-SMS-Providern erweiterbar zu machen, wollte ich eine Art Plugins schreiben (die Plugins müssen nicht dynamisch in der App hinzugefügt werden können, sondern einfach zur Compilezeit zur Verfügung stehen)

Über ein Einstellungsmenü kann man den Provider aus der Liste wählen.
Für jeden Provider muss es aber außerdem noch ein eigenes Provider-Einstellungsmenü geben.

Nun habe ich das ganze So gelöst, dass ich im Einstellungsmenü aus einem StringArray die Provider wählen kann und anschließend wird mit String-Vergleichen überprüft, ob es einen solchen Provider gibt. Sollte es diesen geben, wird eine neue Instanz (mit dem Sender, empfänger und dem Text der Nachricht erzeugt)

Code

private SenderPlugin getSenderClass() {
    	SharedPreferences sharedPref = PreferenceManager.getDefaultSharedPreferences(this);
    	String sender = sharedPref.getString(KEY_PREF_SENDER, getString(R.string.pref_sender_default));
    	Log.d(DEBUG_TAG,sender);
    	if(sender.equals("SmsTrade")) {
        	return new SmsTrade(editMessage.getText().toString(),
            	editRecipient.getText().toString(),editSender.getText().toString(),
            	this);
    	} else {
        	return null;
    	}   
	}

Alles anzeigen

Nun brauche ich aber auch noch die Providerabhängige Settings-Klasse und zwar wirklich die Klasse, keine Instanz. Diese Settings-Klasse ist eine Inner-Class der ProviderKlasse. Aber hier muss ich wieder den gleichen Code schreiben, denn ich muss ja dann die Sender-Settings-Klasse über einen Intend starten:

Code

//@TODO: this is not so good, because here we use the same things, as in getSenderClass
	//  so maybe there is a better way to do this.
	private Class&lt;?&gt; getSenderSettingsClass() {
    	SharedPreferences sharedPref = PreferenceManager.getDefaultSharedPreferences(this);
    	String sender = sharedPref.getString(KEY_PREF_SENDER, getString(R.string.pref_sender_default));
    	Log.d(DEBUG_TAG,sender);
    	if(sender.equals("SmsTrade")) {
        	return SmsTrade.SettingsActivity.class;
    	} else {
        	return null;
    	}   
	}   


	private void showSenderSettings() {
    	Class&lt;?&gt; pluginSettings = getSenderSettingsClass();
    	Intent intent = new Intent(this, pluginSettings);
    	startActivity(intent);
	}

Alles anzeigen

Nun habe ich aber in beiden Fällen fast den Gleichen Code.
Wie kann ich das ganze eleganter lösen, dass ich den Code mit den If-Abfragen, die die Senderklasse auswählen nur noch einmal habe? (Ich brauche einmal die Instanz der Basisklasse, das andere mal die Klasse der Kindklasse.)

falls etwas unklar ist, ich habe dieseApp auf Github veröffentlicht, hier kann man sich die Konkreten files ansehen.
https://github.com/mwuehrer/sms_sender

Konkret bezieht sich meine Frage somit auf die Dateien
https://github.com/mwuehrer/sm…_sender/MainActivity.java
https://github.com/mwuehrer/sm…nder/plugin/SmsTrade.java

ich weiß das ist etwas kompliziert geschrieben, aber ich weiß leider nicht, wie ich es anders formulieren soll.

Marco Feltmann · 11. September 2013

Ich glaube, für so etwas solltest du das Factory Pattern nehmen. Diese Aufgabenstellung ist wie geschaffen für dieses Pattern.

Ein ganz schneller Workaround wäre übrigens, die Methode so zu schreiben:

Java

private Class&lt;?&gt; getSenderSettingsClass() {
    String sender =  getSenderString();
    // Hier die IF-Abfrage mit dem String
}


private SenderPlugin getSenderClass() {
    	String sender = getSenderString();
    	// Hier die IF-Abfrage mit dem String
}


private String sender getSenderString() {
    	SharedPreferences sharedPref = PreferenceManager.getDefaultSharedPreferences(this);
    	String sender = sharedPref.getString(KEY_PREF_SENDER, getString(R.string.pref_sender_default));
    	Log.d(DEBUG_TAG,sender);
        return sender;
}

Alles anzeigen

Der Oberbegriff nennt sich im Fachjargon 'Refactoring' und diese Aktion 'Method Extraction'.

Du solltest aber wirklich versuchen, das Factory Entwurfsmuster anzuwenden.
Das macht das Ganze wesentlich einfacher zu erweitern und auch übersichtlicher.

Wenn du Fragen diesbezüglich hast, dann frag.

mwuehrer · 12. September 2013

Danke Lucas für die schnelle Antwort, stimmt, ja dein workaround ist natürlich auch möglich, nur hab ich das ganze einfach nur schnell copy&paste hingeschrieben, weil ich sowieso gehofft hab, dass es das ganze als schönere lösung auch gibt...
aber danke trotzdem dafür.

ich hab schon mal von dem factory-pattern gehört, aber ich bin mir nicht sicher, wie ich die richtig implementieren soll:
ich sag einfach mal, was ich weiß:
es gibt eine factory für jedes plugin (also für jeden sender), diese spezielle sender-factory implementiert ein generisches sender-factory interface.

die if-abfrage mit den strings instanziert die spezielle factory je nach string,
anschließend kann ich mit dieser factory-instanz dann eine methode getSettingsClass und getSenderClass implementieren.

ist das so richtig?

nur muss ich dann die factory an der stelle, an der ich die settings anzeige und an der stelle, an der ich die nachricht sende instanzieren? oder wäre es besser, wenn ich es als klassenmember in der main-activity abspeichere

Marco Feltmann · 12. September 2013

So in etwa, ja.
Ist natürlich etwas komplexer. +seufz+

Als Klassenmember in der MainActivity nützt dir das Ganze vermutlich eher wenig, da du ggf. noch von der SettingsActivity darauf zugreifen musst.
Allerdings bekommst du ja immer eine neue Instanz zurück, was später durchaus zu Probleme führen kann, wenn du auf jeder Activity die Factory auspackst.

Ich muss darüber noch mal in Ruhe nachdenken.

matthias · 12. September 2013

Wie wärs mit nem Handler, der das via Singleton-Pattern hält?

EDIT:
-statisch ... sinnlos xD

Marco Feltmann · 13. September 2013

Kannst du das etwas näher beschreiben?

matthias · 13. September 2013

Najo da es nicht praktikabel ist, die Objekt-Listen in den einzelnen Activitys zu halten, würde ich eine Handler-Klasse erstellen.

Java

class SettingsHandler {
        private static SettingsHandler instance = null; 
        private ArrayList&lt;Settings&gt; mySettings = null; 


        private SettingsHandler() {
                mySettings = new ArrayList&lt;Settings&gt;(); 
        }


        public static SettingsHandler getInstance() {
                if (instance == null) {
                        instance = new SettingsHandler(); 
                }
                return SettingsHandler.instance; 
        }


        public ArrayList&lt;Settings&gt; getAllSettings() {
                return this.mySettings; 
        }
}

Alles anzeigen

Sowas die Richtung. Man hat seine Liste nur 1 mal, sie bleibt bestehen, wenn man die Activity wechselt und kann bequem drauf zugreifen. "Settings" wär hier dann wohl ein Interface oder eine abstrakte Klasse. Pro spezielle Settings eine Unterklasse. Die Liste kann sich dann an entsprechender Stelle geholt werden und dank Polymorphismus bequem durchrödelt werden oder was auch immer man im Schilde führt

Gruß,
Matze

Marco Feltmann · 13. September 2013

Das ist zumindest der Beginn für eine Static Factory.

matthias · 13. September 2013

Joa, irgendwie schon muss zugeben, ich bedenke sehr selten, welches Pattern ich gerade anwende. Gefühl und Erfahrung leiten mich zumeist eh automatisch in diese Richtung

mwuehrer · 14. September 2013

Danke für den Hinweis.
Ich habe das ganze jetzt so implementiert:

Code

public class SenderHandler{
	private static String sender = null;
	private static Class&lt;?&gt; senderSettingsClass = null;
	private static SenderPlugin senderInstance = null;
	private static final String KEY_PREF_SENDER = "pref_sender";


	private static final String DEBUG_TAG = "SenderHandler";


	public static void getInstances(Activity activity) {
    	SharedPreferences sharedPref = PreferenceManager.getDefaultSharedPreferences(activity);
    	String senderString = sharedPref.getString(KEY_PREF_SENDER, activity.getString(R.string.pref_sender_default));
    	sender = senderString;
    	Log.d(DEBUG_TAG,sender);
    	if(sender.equals("SmsTrade")) {
        	senderSettingsClass = SmsTrade.SettingsActivity.class;
        	senderInstance = new SmsTrade(activity);
    	} else {
        	senderSettingsClass = null;
        	senderInstance = null;
    	}
	}


	public static Class&lt;?&gt; getSenderSettingsClass(Activity activity) {
    	if(sender == null) {
        	getInstances(activity);
    	}
    	return senderSettingsClass;
	}


	public static SenderPlugin getSenderInstance(Activity activity) {
    	if(sender == null) {
        	getInstances(activity);
    	}
    	return senderInstance;
	}


	public static void reset() {
    	sender = null;
	}
}

Alles anzeigen

Allerdings muss ich mich somit auch darum selbst kümmern, wenn sich jetzt der gewählte sender ändert.
Dazu habe ich dann bei android deveolpers was gefunden:
https://developer.android.com/…i/settings.html#Listening

hier wird behauptet, dass ich einen onSharedPreferenceChanged-handler machen kann, das funktioniert allerdings nicht.
die hier dargestellten Log-Einträge (DEBUG1, DEBUG2 und DEBUG3) scheinen nämlich nicht in den Logs auf, das bedeutet wohl, dass der code hier nie aufgerufen wird.

Code

public class SettingsActivity extends PreferenceActivity
    	implements SharedPreferences.OnSharedPreferenceChangeListener{


	private static final String KEY_PREF_SENDER = "pref_sender";


	private static final String DEBUG_TAG = "SettingsActivity";


	@Override
	protected void onCreate(Bundle savedInstanceState) {
    	super.onCreate(savedInstanceState);
    	Log.w(DEBUG_TAG, "DEBUG1");
    	// Display the fragment as the main content.
    	getFragmentManager().beginTransaction()
            	.replace(android.R.id.content, new SettingsFragment())
            	.commit();
	}


	public void onSharedPreferenceChanged(SharedPreferences sharedPreferences, String key) {
    	Log.w(DEBUG_TAG, "DEBUG2");
    	if (key.equals(KEY_PREF_SENDER)) {
        	SenderHandler.reset();
        	Log.w(DEBUG_TAG, "DEBUG3");
    	}
	}
}

Alles anzeigen

Hier noch die gekürzte version der MainActivity, wo die SettingsActivity aufgerufen wird.
(Hier wird der DEBUG-Eintrag DEBUG_MAIN ausgeführt)

Code

public class MainActivity extends Activity implements ListDialog.ListDialogListener{
	private static final String KEY_PREF_SENDER = "pref_sender";


	private static final String DEBUG_TAG = "MainActivity";


	@Override
	protected void onCreate(Bundle savedInstanceState) {
    	Log.w(DEBUG_TAG, "DEBUG_MAIN");
    	//blahblah
	}


	@Override
	public boolean onCreateOptionsMenu(Menu menu) {
    	// Inflate the menu; this adds items to the action bar if it is present.
    	getMenuInflater().inflate(R.menu.main, menu);
    	return true;
	}


	@Override
	public boolean onOptionsItemSelected(MenuItem item) {
    	// Handle item selection
    	switch (item.getItemId()) {
        	case R.id.action_settings:
            	showSettings();
            	return true;
        	case R.id.action_sender_settings:
            	showSenderSettings();
            	return true;
        	default:
            	return super.onOptionsItemSelected(item);
    	}
	}


	private void showSettings() {
    	Intent intent = new Intent(this, SettingsActivity.class);
    	startActivity(intent);
	}


	private void showSenderSettings() {
    	Class&lt;?&gt; pluginSettings = SenderHandler.getSenderSettingsClass(this);
    	Intent intent = new Intent(this, pluginSettings);
    	startActivity(intent);
	}

Alles anzeigen

Meine Frage somit, was mache ich beim Aufruf falsch, irgendwie glaube ich werden hier die Methoden überschrieben.

Marco Feltmann · 14. September 2013

Auf den ersten Blick sieht der Aufruf korrekt aus. Allerdings finde ich den Code nicht, in dem du die geänderten Settings speicherst.

Hast du eventuell eine Einstellung in deiner Logausgabe, dass Warnings nicht mit ausgegeben werden? (Hab ich bei mir, weil mir die [gefühlt] 100.000.000.000.000 Warnungen auf den Senkel gehen)

Debugging mit Logausgaben ist übrigens eher ungeil, schmeiß lieber den Debugger an, setze Breakpoints und schau mal, wo du dann landest.

matthias · 16. September 2013

Hoi,

vll. überles ichs ja grad einfach nur, aber wo genau registrierst du in deiner Activity den Listener?

Java

myPreference.setOnPreferenceChangeListener(this);

Gruß,
Matze

mwuehrer · 17. September 2013

Dankeschön matthias.
ich hab die Seite https://developer.android.com/…i/settings.html#Listening mal wieder nicht ordentlich gelesen.

Du hast natürlich recht, ich muss das Event erst registrieren. (Was ja eig. eh logisch ist, denn wie sollte man sonst auf das Event reagieren?)
Ich habs nun geändert und nun funktionierts:

Code

public class SettingsActivity extends PreferenceActivity
        implements SharedPreferences.OnSharedPreferenceChangeListener{


    private static final String KEY_PREF_SENDER = "pref_sender";


    private static final String DEBUG_TAG = "SettingsActivity";


    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        // Display the fragment as the main content.
        getFragmentManager().beginTransaction()
                .replace(android.R.id.content, new SettingsFragment())
                .commit();


        SharedPreferences sharedPref = PreferenceManager.getDefaultSharedPreferences(this);
        sharedPref.registerOnSharedPreferenceChangeListener(this);
    }   


    public void onSharedPreferenceChanged(SharedPreferences sharedPreferences, String key) {
        if (key.equals(KEY_PREF_SENDER)) {
            SenderHandler.reset();
        }
    }   
}

Alles anzeigen

Für alle, die den gesamten Code (das gesamte Projekt) noch brauchen, hab ich die korrigierte Version auf Github hochgeladen:
https://github.com/mwuehrer/sms_sender

Java Plugin-Klassen richtige Implementierung

Jetzt mitmachen!

Teilen

Tags