Custom Dialoge

hottiwf · 16. Februar 2014

Hi,
ich hab eine Frage zum Thema Dialoge.
Ich habe eine App in der ich ein paar unterschiedliche ListViews habe. Bei langem oder einfachem Click auf die einzelnen Elmente
soll sich jetzt ein custom Dialog öffnen, der zum Beispiel einmal die Buttons: Delete, Update, Show enthält, ein anderes Icon soll aber
im Dialog nur Delete anbieten, bei einem anderen dann wieder Update, Teilen etc.

Also es soll quasi immer der "gleiche" Dialog sein, der aber je nach Item eine bestimmte Kombination von Buttons enthält.

Nun meine Frage zum Konzept....
wie genau würdet Ihr das bewerkstelligen?

Die simpelste Lösung wäre ja für jeden Dialog eine eigene XML Datei und eine eigene Handler Klasse anzulegen.
Aber ist das der Weisheit letzter Schluß? Gibt es da eine elegantere Lösung?

Hatte so an Sachen gedacht wie Vererbung aber das ist ja bei XML Dateien so nicht möglich?! Dann bin ich über den Begriff imports gestoßen.

Hatte dann gedacht ich mache eine XML Datei mit ALLEN möglichen Buttons und blende je nach HandlerKlasse entsprechende Buttons aus....habe das aber mit setVisibility irgendwie nicht recht hinbekommen und meine Frage wäre dann, sind die Buttons dann auch noch richtig angeordnet oder an der Stelle wo der Button eigentlich wäre eine leere Stelle?

Gruß Marcel

Marco Feltmann · 17. Februar 2014

Moin.

Also ich bin ja nach wie vor ein Freund von 'Machs wie Dein OS' und würde an Stelle eines eigenen Dialogs die Menüs benutzen.
Da könnte man dann ziemlich simpel Einträge hinzufügen, löschen oder austauschen.

Alternativ ließe sich je Dialog eine XML-Datei anlegen und eine eigene Handler Klasse basteln. Ist natürlich ein bisschen mühsam immer den Handler umzuschreiben…

Java

switch(position) {
  case 0:
    AllButtonsDialogHandler handler = new AllButtonsDialogHandler();
  break;


  case 1:
    DeleteDialogHandler handler = new DeleteDialogHandler();
  break;


  default:
    SynchronizeDialogHandler handler = new SynchronizeDialogHandler();
  break;
}

Alles anzeigen

Da tippt man sich ja tot und es sieht auch noch scheiße aus.

Da Du ja gern herumvererben möchtest wäre doch so etwas eine Alternative:

Java

MyButtonsHandler handler;
switch(position) {
  case 0:
    handler = MyButtonsHandler.getInstance(MBH_ALL_BUTTONS_HANDLER);
  break;


  case 1:
    handler = MyButtonsHandler.getInstance(MBH_DELETE_BUTTON_HANDLER);
  break;


  default:
    handler = MyButtonsHandler.getInstance(MBH_SYNCHRONZIE_BUTTON_HANDLER);
  break;
}

Alles anzeigen

Im Prinzip also ein Anwendungsbeispiel des Static Factory Pattern.

Von einer All-In-One Lösung mit Ausblenden nicht benötigter Elemente rate ich Dir ab.
Das wird unglaublich unübersichtlich und unsagbar schwer anzupassen.

hottiwf · 17. Februar 2014

Zitat von Marco Feltmann

Moin.

Also ich bin ja nach wie vor ein Freund von 'Machs wie Dein OS' und würde an Stelle eines eigenen Dialogs die Menüs benutzen.
Da könnte man dann ziemlich simpel Einträge hinzufügen, löschen oder austauschen.

Hi!
Also Du würdest die Einträge in der Liste bei anklicken als makiert setzen und dann unten im Menü die entsprechenden Optionen anzeigen? Oder
in der ActionBar? Ist es so unüblich bei längerem drücken auf ein List Element ein PopUp Dialog erscheinen zu lassen? Hatte eigentlich so im Gefühl, dass ziemlich viele Apps das so machen!?

Zitat von Marco Feltmann
Alternativ ließe sich je Dialog eine XML-Datei anlegen und eine eigene Handler Klasse basteln. Ist natürlich ein bisschen mühsam immer den Handler umzuschreiben…
Java
switch(position) {
  case 0:
    AllButtonsDialogHandler handler = new AllButtonsDialogHandler();
  break;


  case 1:
    DeleteDialogHandler handler = new DeleteDialogHandler();
  break;


  default:
    SynchronizeDialogHandler handler = new SynchronizeDialogHandler();
  break;
}
Alles anzeigen
Da tippt man sich ja tot und es sieht auch noch scheiße aus.

Sehe ich genauso, wollte das auf keinen Fall so machen!

Zitat von Marco Feltmann
Da Du ja gern herumvererben möchtest wäre doch so etwas eine Alternative:
Java
MyButtonsHandler handler;
switch(position) {
  case 0:
    handler = MyButtonsHandler.getInstance(MBH_ALL_BUTTONS_HANDLER);
  break;


  case 1:
    handler = MyButtonsHandler.getInstance(MBH_DELETE_BUTTON_HANDLER);
  break;


  default:
    handler = MyButtonsHandler.getInstance(MBH_SYNCHRONZIE_BUTTON_HANDLER);
  break;
}
Alles anzeigen
Im Prinzip also ein Anwendungsbeispiel des Static Factory Pattern.

Habe jetzt eine Klasse. Also meinen Basic Dialog und da die statische Methode > getInstance implementiert.
Dieser uebergebe ich entsprechend welcher Dialog erstellt werden soll und diese liefert mir entsprechend das
Objekt so wie ich es haben möchte.

Zitat von Marco Feltmann

Von einer All-In-One Lösung mit Ausblenden nicht benötigter Elemente rate ich Dir ab.
Das wird unglaublich unübersichtlich und unsagbar schwer anzupassen.

Denke da es maximal 10 unterschiedliche Buttons geben wird, ist es noch handlebar. Ich wollte jetzt nicht für jeden
Dialog der gesamten App eine SuperDialogHandlerKlasse bauen

Werde gleich mal weiter proggen und mich bestimmt hier nochmal zu Wort melden, weil so ganz Licht am Ende des Tunnels seh
ich noch nicht

Marco Feltmann · 17. Februar 2014

Zitat von hottiwf

Also Du würdest die Einträge in der Liste bei anklicken als makiert setzen und dann unten im Menü die entsprechenden Optionen anzeigen?

Auf gar keinen Fall. Das ist totaler Blödsinn.
Wobei einige Implementierungen in der Tat nach einem langen Anklicken ihre Toolbar anpassen. Man muss abwarten, ob das die Zukunft wird. Ich bin ein Freund von Kontextmenüs.

Jedenfalls werden Kontextmenüs und Kontext-Actionbars in einem Android Guide beschrieben.

hottiwf · 17. Februar 2014

Zitat von Marco Feltmann

Auf gar keinen Fall. Das ist totaler Blödsinn.
Wobei einige Implementierungen in der Tat nach einem langen Anklicken ihre Toolbar anpassen. Man muss abwarten, ob das die Zukunft wird. Ich bin ein Freund von Kontextmenüs.

Jedenfalls werden Kontextmenüs und Kontext-Actionbars in einem Android Guide beschrieben.

Ah, erst einmal Danke! Bin jetzt umgeschwenkt zu
Using the contextual action mode
Finde das auch schicker, mal sehen ob ich das "Standard" alte Context Menue (Creating a floating context menu
) für Api kleiner 11 noch unterstütze. Das unterscheidet sich ja auch (vom Aussehen) sehr gering zu meinem AlertDialog den ich bisher
realisiert habe. Mal sehen wie ich das Ganze hinbekomme. Werde bestimmt nochmal nerven (müssen)

hottiwf · 17. Februar 2014

Hi,
so ich bin nun so weit und habe fast alles umgestrickt und benutze nun einen
android.widget.AbsListView.MultiChoiceModeListener

public boolean onCreateActionMode(ActionMode mode, Menu menu)
{
// Inflate the menu for the CAB
MenuInflater inflater = mode.getMenuInflater();
inflater.inflate(R.menu.context_menu, menu);
return true;
}

Jetzt meine Frage zum Thema Menue und dynamisch. Kann ich anstatt R.menu.context_menu ein dynamisches Menü per Java Code
erstellen? Und wie rufe ich dann am Besten die CreateActionMode Methode auf? Da es sich um ein Interface handelt kann ich ja nicht einfach statische
Methoden implementieren, die mir eine entsprechend dynamische Instanz zurückgeben oder doch?

Marco Feltmann · 18. Februar 2014

Zitat von hottiwf

Jetzt meine Frage zum Thema Menue und dynamisch. Kann ich anstatt R.menu.context_menu ein dynamisches Menü per Java Code
erstellen?

Natürlich kannst Du das.

Zitat von hottiwf

Und wie rufe ich dann am Besten die CreateActionMode Methode auf?

Java

private int delete_item_id;


public boolean onCreateActionMode(ActionMode mode, Menu menu)
{
    // Inflater? Brauchen wir hier nicht. Wir haben ja bereits eine Instanz des Menüs.
    MenuItem editItem = menu.add("Edit"); 
    editItem.setIcon(R.drawable.edit_pencil);


    MenuItem deleteItem = menu.add("Delete");
    delete_item_id = deleteItem.getItemId();


    MenuItem syncItem = menu.add("Synchronize");
    if(has_internet_connection) {
        syncItem.setEnabled(true);
    }
    else {
        syncItem.setEnabled(false);
    }


    MenuItem debugItem = menu.add(R.string.debug_info_text);
    if(is_debug_enabled) {
        debugItem.setVisible(true);
    }
    else {
        debugItem.setVisible(false);
    }
    return super.onCreateActionMode(mode, menu);
}

Alles anzeigen

Zitat von hottiwf

Da es sich um ein Interface handelt kann ich ja nicht einfach statische
Methoden implementieren, die mir eine entsprechend dynamische Instanz zurückgeben oder doch?

Hängt von der statischen Methode ab.

hottiwf · 18. Februar 2014

Super! Das hat mir erstmal echt weitergeholfen.
Hätte jedoch gern noch die Möglichkeit der Methode

onCreateActionMode(ActionMode mode, Menu menu)

irgendwie ein weiteres Argument uebergeben zu koennen? Also quasi eine Liste welche Buttons in dem Menue aktiviert sein
sollen, oder ein int Wert welches Menue ich aktivieren will oder so? Haettest Du da einen Tip?

Hatte mir überlegt in meiner Klasse eine statische Variable anzulegen die ich MenueArt nenne und die ich im KOnstruktor setze...nun hab ich ja aufgrund des implements android.widget.AbsListView.MultiChoiceModeListener
eine Klasse die ein Interface ist und somit keinen Konstruktor in dem Sinne hat. Rufe das Ganze nämlich so auf:

theListView = (ListView) findViewById(R.id.list);
theListView.setChoiceMode(ListView.CHOICE_MODE_MULTIPLE_MODAL);
theListView.setMultiChoiceModeListener(new Basic());

hätte jetzt gern so was wie die Möglichkeit:

new Basic(int menue1);
new Basic(int menue2);
new Basic(int menue3);

oder

new Basic(int[] buttonIDs);

oder Ähnliches......

Verstehst Du was ich will ???

Marco Feltmann · 18. Februar 2014

Eine Klasse kann kein Interface sein. Sie kann nur ein Interface implementieren.
Dass Du keinen Konstruktor hast liegt daran, dass deine Elternklasse keinen Konstruktor braucht.
Das hindert Dich ja nicht daran einen zu erstellen.

Du kannst den Basic Krams durch eine eigene Subklasse ersetzen und darin herumfuhrwerken wie Du möchtest.

Ich habe wirklich absolut keine Ahnung was das werden soll…

Auch weiß ich nicht, wie Du es schaffen möchtest je nach ausgewähltem Element unterschiedliche Menüeinträge zu präsentieren.

hottiwf · 18. Februar 2014

Zitat von Marco Feltmann

Eine Klasse kann kein Interface sein. Sie kann nur ein Interface implementieren.
Dass Du keinen Konstruktor hast liegt daran, dass deine Elternklasse keinen Konstruktor braucht.
Das hindert Dich ja nicht daran einen zu erstellen.

Habe nun einen angelegt, aber wenn ich den Konstruktor aufrufe wird im Debug nicht mehr onCreate aufgerufen und mein Menue entsprechend gar nicht mehr gesetzt.

Zitat von Marco Feltmann

Du kannst den Basic Krams durch eine eigene Subklasse ersetzen und darin herumfuhrwerken wie Du möchtest.

? Das hab ich nun gar nicht verstanden weil ich dachte der Basic Kram wäre schon meine Unterklasse :)!?!?!

Zitat von Marco Feltmann

Ich habe wirklich absolut keine Ahnung was das werden soll…

ALSOOOoooo....was ich eigentlich möchte....ich möchte ein java File haben in dem ich eine Klasse Basic habe. Diese Klasse implementiert das Interface
android.widget.AbsListView.MultiChoiceModeListener. In dieser Klasse möchhte ich die komplette Menue Erstellung bzw das handling realisieren.

Zitat von Marco Feltmann

Auch weiß ich nicht, wie Du es schaffen möchtest je nach ausgewähltem Element unterschiedliche Menüeinträge zu präsentieren.

NEIN nein...ich möchte nur beim Erstellen das Menu dynamisch gestalten. Sprich es soll wie folgt sein.
Activity1 ruft new Basic(menu1) auf
Activity2 ruft new Basic(menu2) auf
jetzt unterscheidet sich menu1 in dem Fall, dass es zum Beispiel keinen share Button hat.

Also ich möchte ein dynamisches Menue je entsprechend pro Activity oder besser gesagt pro ListView der jeweiligen Activity.

Es kann sein, dass ich absolut auf dem Holzweg bin...vom Konzept her. Aber wir waren uns ja eigentlich einig, dass X belieb viele Menues unter den Resourcen zu erstellen Humbuk wäre....`!?!?

Marco Feltmann · 18. Februar 2014

Aha.

Okay. Warum legst Du dann nicht den Konstruktor für Basic entsprechend an?

Java

public class Basic // extends und implements und so weiter und so fort
{
    static int INFO_MENU_TYPE = 0; // Die 0 ist eigentlich immer dabei.
    static int DELETE_MENU_TYPE = 1;
    static int EDIT_MENU_TYPE = 2;
    static int SYNCHRONIZE_MENU_TYPE = 4;
    static int SHARE_MENU_TYPE = 8;


    uint menu_type = 0;


    public Basic() {
        this(DELETE_MENU_TYPE+EDIT_MENU_TYPE+SHARE_MENU_TYPE);
    }


    public Basic(uint menu_type) { // Wir hätten hier gern ein uint, da der Menütyp nie kleiner 0 werden soll.
        this.menu_type = menu_type;
    }


    public void getMenuItems(Menu theMenu) {
        int i = menu_type; // Der cast von uint zu int ist gewollt! uint kann nicht kleiner 0 werden, muss es aber hier.
        // Davon abgesehen wollen wir den menu_type unverändert beibehalten, weshalb wir eine lokale Variable nehmen.


        // Eine lokale Variable auf das aktuelle MenuItem setzen
        MenuItem currentItem = null;


        if(i &gt; 15) {
            // Hier hat ein Scherzkeks einen ungültigen Wert eingegeben. 
            // Ich habe mir erlaubt die Zahl auszuschreiben statt die Konstanten zu addieren – kann aber im späteren Verlauf fehleranfällig werden.
            // Eine eigene Funktion dafür wäre eh geiler. ;)
            
            // Wer möchte kann Exceptions werfen. Ich möchte nicht.
            return;
        }


        // Jetzt schön von hinten nach vorn durchgehen. ;)
        if((i-8) &gt;= 0) {
            // Wir wollen SHARE
            currentItem = theMenu.add("Share");


            // Den dekorieren wir noch ein bisschen…
            currentItem.setIcon(R.drawable.ac_share_icon);
            currentItem.setTitle("Share this entry with the network of your choice");
            currentItem.setCondensedTitle("Share");


            // Und den Wert abziehen.
            i-=8;
        }
        if((i-4) &gt;= 0) {
            // Wir wollen SYNC
            currentItem = theMenu.add("Synchronize");
            i-=4;
        }
        if((i-2) &gt;= 0) {
            // Wir wollen EDIT
            currentItem = theMenu.add("Edit");
            i-=2;
        }
        if((i-1) &gt;= 0) {
            // Wir wollen DELETE
            currentItem = theMenu.add("Delete");
            i-=1;
        }
        if(i == 0) {
            // Wir bekommen INFO eigentlich immer.
            currentItem = theMenu.add("Info");
        }
    } 
}

Alles anzeigen

Entsprechend gehst Du dann halt in Deiner überschriebenen Methode vor:

Java

public boolean onCreateActionMode(ActionMode mode, Menu menu)
{
    Basic specializedBasic = new Basic(Basic.EDIT_MENU_TYPE+Basic.DELETE_MENU_TYPE);
    specializedBasic.getMenuItems(menu);
    return super.onCreateActionMode(mode, menu);
}

Zumindest hoffe ich, dass das so geht und das Referenzen auf 'menu' übergeben werden.
Häng seit Wochen in C fest und komm dementsprechend leicht mit den Konzepten durcheinander.

ABER:
Wenn sich Deine Menüs lediglich von Activity zu Activity unterscheiden, dann ist der Ansatz mit mehreren XML Menüs plötzlich gar nicht mehr so blöd.
Es entfallen ja die dämlichen Switch-Anweisungen. (Ich ging von unterschiedlichen Menüeinträgen je ausgewählter Zeile ein und desselben ListViews aus.)
Hinzu kommt der Vorteil der einfachen Lokalisierung. Es ist wesentlich einfacher pro Sprache ein paar neue Menu_<details>.xml im passenden Unterordner zu erstellen als das Ganze im Code anzupassen.

hottiwf · 18. Februar 2014

Zitat von Marco Feltmann

Zumindest hoffe ich, dass das so geht und das Referenzen auf 'menu' übergeben werden.
Häng seit Wochen in C fest und komm dementsprechend leicht mit den Konzepten durcheinander.

Zitat von Marco Feltmann

ABER:
Wenn sich Deine Menüs lediglich von Activity zu Activity unterscheiden, dann ist der Ansatz mit mehreren XML Menüs plötzlich gar nicht mehr so blöd.
Es entfallen ja die dämlichen Switch-Anweisungen. (Ich ging von unterschiedlichen Menüeinträgen je ausgewählter Zeile ein und desselben ListViews aus.)
Hinzu kommt der Vorteil der einfachen Lokalisierung. Es ist wesentlich einfacher pro Sprache ein paar neue Menu_<details>.xml im passenden Unterordner zu erstellen als das Ganze im Code anzupassen.

Du machst mich echt fertig ;-P
Okay! Bin jetzt konzeptionell wieder zurück gerudert und nehme unterschiedliche XML Files. Ich poste mal eine wenig Code wenn ich dann endlich
an einem Punkt bin wo die ersten grundlegenden Sachen funktionieren und ich wieder Rat brauche

Hab erstmal sau viel Dank für Deine ganzen Mühen! Denke mal der Schups mit dem contextual action mode
war schon gut. Ich bastel jetzt erstmal ein wenig (hoffe mal ein paar größere Schritte machen zu können) und dann melde ich mich
nochma.

Erstmal vielen Dank!

Jetzt mitmachen!

Teilen