# zurück Schaltfläche in voriges Layout



## ole (12. Mrz 2014)

Hallo zusammen, ich habe folgendes Problem,
wir arbeiten zu dritt an einem kleinen Projekt eine Schuleapp zu erstellen 
Ich bin für die Strukturierung zuständig und habe in Eclipse mehrere Layouts erstellt, die durch betätigen eines Buttons in das jeweilige Unterlayout, wieder mit Buttons gehen soll...das funktioniert auch prima.
Habe eine Klasse in der dann(MainActivity) alle Layouts mit einer Methode und Onclick...in welches Layout er springen soll strukturiert.

Wie bekomm ich denn nun am besten hin, mit der zurück Taste in das jeweilig vorige Layout zurück zu springen, bis zum Hauptmenu ?

Ich habe es mit Intends probiert über Keycode_Back, versucht ein Listener zu schreiben der die schaltfläche abhört, oder mir gedanken gemacht eine switch Case zu nehmen um mir die anzahl der Rücksprünge mit einer Variable zu merken.

Aber mir gelingt einfach nichts

fällt denn jemanden eine Methode ein, die ich einfach benutzen kann, um aus den Unterlayouts, wieder in das übergeordnete Layout zu kommen ?

Hoffe auf eure Ratschläge oder weiteren fragen bezüglich unserer App Konstellation, um eine Lösung herbei zu führen.

beste grüße !


----------



## hauptDev (13. Mrz 2014)

Soweit ich weis (etwas länger her), musst du eigentlich nur der neuen Activity das Intent übergeben beim Starten, wenn man dann auf den "Zurück-Pfeil" geht, sollte es automatisch von statten gehen.

So in der Art:

Intent i = new Intent(this, ActivityBla.class);
startActivity(i);


----------



## dzim (13. Mrz 2014)

Jep, so wie es hauptDev sagt, sollte es sein. Bei Activities greift der reguläre Mechanismus des Back-Buttons. Erst bei Fragments musst du dann eventuell nachhelfen (je nachdem, wie man die Fragmente einbindet).

BTW: Ich habe in unserer App vor kurzem viel unternommen, tiefere Activity-Strukturen zu vermeiden und nutze jetzt noch weit mehr Fragmente als vorher. Ist sicher z.T. auch nur Geschmackssache, aber Fragmente sind einfacher wiederzuverwenden, bis dahin, dass man eine Tablet-UI erstellen kann, mit der man mehre Fragmente z.B. in einem Master-Details-Block darstellen kann (Bsp.: Google-Mail auf Tablets - links die Liste der Mails ("Master") und Rechts die "Details" (die konkrete angewählte Mail)).

Darüber hinaus ist es schwierig dir Hinweise zu geben, weil du kaum etwas über die Struktur verrätst.


----------



## ole (13. Mrz 2014)

Vielen dank erst mal für antworten !

HauptDev antwort bezieht sich aber sicher ehr auf eine Lösung, wenn ich noch andere Klassen in der src ausser die MainActivity habe denk ich !

Wir haben nur die MainActivity. Aufgebaut ist die Struktur so, das sobald sich die App öffnet, der Benutzer mehrere möglichkeiten hat einen Button anzutippen, um immer sich immer mehr in die Untermenüs(die wieder mit Buttons bestückt sind) durch zu tippen.

Ich habe also viele Buttons im Drawable Ordner drin, die einen bestimmten Namen besitzen.
Dazu viele Layouts in denen ich durch... "androidnclick=drawable" den Button sozusagen zuweise.

danach geh ich in die Klasse MainActivity und gebe den Namen des Onclick an... so sowie in welches Layout er dann springen soll.  bsp...

public void fachr_btn(View view) 

	    {
	   	 setContentView(R.layout.fachr_menue);
	    }

//Methode, die bei Klick auf Fachr_btn auf das nächste Layout verweist !


Wen der Benutzer also in den tiefen des Layouts nach unten gelangt ist, oder auch mittendrin wieder ein einen schritt in das Layout zurück möchte, weiß ich einfach keine Lösung dazu !


Hab ich es von der Grundstrukur schon falsch aufgebaut, sodass ich lieber mit mehreren Klassen arbeiten sollte, oder kann ich so weiter fahren, und ihr könnt mir eine Lösung verraten?

wäre euch natürlich sehr dankbar !

beste grüße !


----------



## mance (13. Mrz 2014)

Ich weiss nicht ob ich alles richtig verstanden habe, aber ich versuche dir mal so zu helfen wie ich es verstanden habe. Wenn ich das jetzt richtig verstanden habe dann willst du beliebig viele Unterlayouts öffnen und diese dann nacheinander schliessen? 
Vielleicht könntest du das so machen, dass du eine ArrayList erstellst und jedes mal wenn du einen neuen Unterlayout anzeigst fügst du die jeweilige ID in die ArrayList ein. Dann wenn du auf den Zurückbutton drückst löschst du den letzten Eintrag deiner Liste und settest das ContentView auf das neue letzte Element. So z.B. 

void openLayout(){
int deinLayout = R.id.deinLayout;
list.add(deinLayout);
setContentView(deinLayout);
}

void onBackPressed(){
list.remove(list.size()-1);
setContentView(list.get(list.size()-1));
}


----------



## dzim (14. Mrz 2014)

Also ich denke, dass der Weg über das setzen von #setContentView() einfach fundamental der falsche ist. An dieser Stelle mit Klassen zu sparen ist IMHO falsch, weil deine Activity dann (neben des schrägen @Overrides von #onBackPressed()) auch das verhalten SÄMTLICHER Layouts managen muss! Deine Klasse wird dann schnell sehr unübersichtlich, vermute ich.

Der Weg, den Android früher (bis Android 3) gegangen ist, war je eine Activity für eine logische Gruppe von UI - ein einziges Mal (in onCreate) wird #setContentView() ausgeführt. Nicht mehrfach. Jede UI kümmert sich um das Handling seiner Layouts separat.

Seit Android 3 aber gibt es Fragmente. Wieder wird hier die UI logisch gekapselt, man ist aber in der Lage, mehrere (entweder nacheinander oder nebeneinander - wie man möchte) auf einer einzigen Activity anzuzeigen.

Letzteres ist der Weg, den du gehen solltest. Keine obskure Vergewaltigung des Systems, die dich zwingt deinen eigene #onBackPressed()-Mechanismus zu schreiben. Das geht auch eher schnell in die Hose, wie ich in meiner etwas naiveren Android-Lernphase auch schon feststellen durfte. Macht mehr Arbeit als es lohnt...

Ich empfehle dir, die folgenden Tutorials von Lars Vogel zu Rate zu ziehen. Ich denke er hat einige (wen auch mitunter nicht sofort verständliche) Wege zusammengesammelt, wie man in die Android-Entwicklung rein kommt.
Android Development

Warum ich das sage ist ganz einfach: Ich möchte in deinem Wohl verhindern, dass du einen nicht "konformen" Weg gehts, es dir so merkst und am Ende mehr Ärger als Nutzen hast.


----------

