Spricht in meinen Augen für folgende Lösung:
- Eine eigene Klasse programmieren, die sowohl das OnClick-Listener-Interface, wie auch das OnCheckedChangeListener Interface implementieren und beide eine Methode (z.B.
e
xecuteCommandForSwitch(final int viewId))
rufen - jeweils mit Übergabe der view-Id.
- Die Methode (wo auch immer die dann angesiedelt ist - vermutlich in der Control-Schicht) trägt dann als statische Konfigurationsinformation noch eine Map in der die Zuordnung von View-Id zu Befehlszeichenkette enthalten ist.
Also in etwa so:
private static final Map<Integer, String> CONFIG = createConfig();
private static final Map<Integer, String> createConfig() {
final Map<Integer, String> config = new HashMap<>();
config.put(R.id.switchVibra, "TOGGLE VIBRATION");
config.put(R.id.switchNightMode, "DISPLAY TOGGLE NIGHTMODE");
[.... weitere 50 Konfigeinträge ....]
return Collections.unmodifiableMap(config);
}
... irgendwo anders ....
public boolean executeCommandForSwitch(final int viewId) {
final String gpsCommand = CONFIG.get(viewId);
boolean commandExecutedSuccessfully = false;
if (gpsCommand != null) {
commandExecutedSuccessfully = mGpsReceiver.execute(gpsCommand);
}
return commandExecutedSuccessfully;
}
Das spart jeglichen s
witch
und ist leicht erweiterbar.
Falls der Schalterzustand on/off zu anderen Befehlsketten führt, kann der Schlüsse der Map auch durch eine Tupel viewId + Zustand gebildet werden, das Muster bleibt das Gleiche.
— geändert am 07.08.2015, 16:58:51
Aktuelles Entwicklungsprojekt: Sudoku Dojo Free
Ich freue mich über Tester/innen.