Context?

[StefMa]

Hi,

ich habe das mit dem Context nicht wirklich verstanden!

Wie kann ich z.B. einen Dialog, der in Activity B also Methode dargestellt wird, in Activity A anzeigen lassen?!

MfG Ice

 

[mradlmaier]

Hi,

ich habe das mit dem Context nicht wirklich verstanden!

Wie kann ich z.B. einen Dialog, der in Activity B also Methode dargestellt wird, in Activity A anzeigen lassen?!

MfG Ice

Du bräuchtest eine Referenz auf eine Instanz der Activity B. Nachdem aber der Lebenzyklus einer Activity vom ActivityManager gemanaged wird, glaub ich nicht daß das funktioniert. Du hast ja keinerlei Kontrolle wann Activity B instanziert wird oder zerstört wird.
Im übrigen:
Activities erben von Context. Deswegen ist 'this' innerhalb einer Activity die Referenz auf den Context.
Wieso schreibst Du Methoden, die von anderen Activities gebraucht werden, in eine Activity? Warum nicht in einer normalen, seperaten Klasse?

 

[StefMa]

Achso oO..

Achja, normale Klassen gibt es ja auch in Java da kann ich also ganz normal einen Dialog schreiben und den dann in einer Activity anzeigen lassen?

Gruß

Gesendet mit der Android-Hilfe.de-App

 

[mradlmaier]

Achso oO..

Achja, normale Klassen gibt es ja auch in Java da kann ich also ganz normal einen Dialog schreiben und den dann in einer Activity anzeigen lassen?

Gruß

Gesendet mit der Android-Hilfe.de-App

Eigentlich schon: aber Android unterstützt nicht alle Packages von Java SE, unter anderem nicht Swing und AWT. Meine Aussage bezieht sich darauf, dass Du typische Entwurfsmuster verwenden kannst, und eben auch normale Java Klassen. Da ja Android nicht Fenster unterstützt, musst Du für die GUI natürlich Views etc. verwenden. Es gibt auch einige Android-Klassen für dies kleinen, modalen Popups. Ich glaube Toasts werden diese genannt.

Guck Dir mal android.widget.PopupMenu an.

 

[v Ralle v]

Du kannst den Dialog darstellen lassen, wenn die Methode static ist. Allerdings braucht jeder Dialog einen Context, den du der statischen Methoden übergeben müsstest. Dann würde in Activity B auch nicht mehr der this Operator in der statischen Methode funktionieren (was ja logisch ist).

Ich erstelle mir in meinen Apps in der Regel eine DialogFactory Klasse. Die beinhaltet nur statische Methoden und ich übergebe halt den Context. Dann kann man aus jeder Activity die Dialoge erzeugen.

 

[mradlmaier]

Du kannst den Dialog darstellen lassen, wenn die Methode static ist. Allerdings braucht jeder Dialog einen Context, den du der statischen Methoden übergeben müsstest. Dann würde in Activity B auch nicht mehr der this Operator in der statischen Methode funktionieren (was ja logisch ist).

Ich erstelle mir in meinen Apps in der Regel eine DialogFactory Klasse. Die beinhaltet nur statische Methoden und ich übergebe halt den Context. Dann kann man aus jeder Activity die Dialoge erzeugen.

Ralle, ich weiss nicht ob jeder hier versteht was ein Factory Entwurfsmuster ist. Veilleicht eine kurze Erläuterung?

 

[v Ralle v]

Ich habe nie von dem Pattern gesprochen. Nur weil meine Klasse "Factory" enthält ^^

Habe mal ein Beispiel erstellt, es handelt sich aber NICHT um das Factory Pattern! Ich packe in diese Klasse alle Dialoge um die Übersicht zu behalten und die Anzahl der Klassen klein zu halten.

public class SimpleDialogFactory {
	
	public static Dialog createSimpleExampleDialog(Context context) {
		return new AlertDialog.Builder(context).setTitle("Title").show();
	}

	public static void createExtendedExampleDialog(Context context) {
		new ExtendedDialog(context);
	}
	
	private static class ExtendedDialog extends AlertDialog.Builder {

		public ExtendedDialog(Context context) {
			super(context);
			
			setTitle("Title");
			setMessage("message");
			
			//more
			
			show();
		}
		
	}
}

Wenn ein Beispiel mit dem Pattern gewünscht ist, kann ich es gerne schreiben. Das dauert aber etwas länger. Inwieweit das richtige Pattern auch sinnvoll ist, ist ein andere Frage. Es würde sich beispielsweise anbieten, die Factory abstrakt zu erstellen und eine Instanz der Factory entsprechend der Android Version zu erstellen (was zur Laufzeit festgelegt wird). Diese Factory würde dann auch entsprechend der Android Version die Dialoge erstellen. Sinnfrei ist dieses Beispiel deshalb, weil Android sich selber darum kümmert mit den Layouts.

Ich hoffe ich konnte helfen =)

 

[StefMa]

Haha

danke Ralle, deine erste Erklärung hat gereicht um es zu realisieren

MfG ice

 

[mradlmaier]

Ich habe nie von dem Pattern gesprochen. Nur weil meine Klasse "Factory" enthält ^^

Habe mal ein Beispiel erstellt, es handelt sich aber NICHT um das Factory Pattern! Ich packe in diese Klasse alle Dialoge um die Übersicht zu behalten und die Anzahl der Klassen klein zu halten.

public class SimpleDialogFactory {
	
	public static Dialog createSimpleExampleDialog(Context context) {
		return new AlertDialog.Builder(context).setTitle("Title").show();
	}

	public static void createExtendedExampleDialog(Context context) {
		new ExtendedDialog(context);
	}
	
	private static class ExtendedDialog extends AlertDialog.Builder {

		public ExtendedDialog(Context context) {
			super(context);
			
			setTitle("Title");
			setMessage("message");
			
			//more
			
			show();
		}
		
	}
}

Wenn ein Beispiel mit dem Pattern gewünscht ist, kann ich es gerne schreiben. Das dauert aber etwas länger. Inwieweit das richtige Pattern auch sinnvoll ist, ist ein andere Frage. Es würde sich beispielsweise anbieten, die Factory abstrakt zu erstellen und eine Instanz der Factory entsprechend der Android Version zu erstellen (was zur Laufzeit festgelegt wird). Diese Factory würde dann auch entsprechend der Android Version die Dialoge erstellen. Sinnfrei ist dieses Beispiel deshalb, weil Android sich selber darum kümmert mit den Layouts.

Ich hoffe ich konnte helfen =)

irgendwie nimmt ja dieser Thread eine seltsame Wendung....IceClaw wollte eine Erklärung des Contents haben... so jetzt sind wir bei Dialogen...
Ich hab da mal eine blöde Frage:
Welchen Vorteil hat es, das die Dialoge statisch sind? Wenn ich static richtig verstehe ist das für Klassenvariablen im Gegensatz zu Instanzvariablen? Was ist verkehrt daran innerhalb einer Activity, wenn diese einen Dialog aufbaut, dem Benutzer anzeigt und danach der Dialog zerstört wird?
Nur wegen der Übersicht und Anzahl der Klassen?

 

[v Ralle v]

Du beschwerst dich, welche Wendung dieser Thread nimmt und fragst dann nach static

Aus Sicht der Objektorientierung ist static böse. Aber manchmal kommt man nicht drum herum oder es vereinfacht die Dinge. Wie in diesem Fall. Ich habe nur eine Klasse meines Styles gezeigt. Es brauch sich keiner angegriffen fühlen. Es führen viele Wege zum Ziel.

Der Vorteil hier ist, dass diese Dialoge aus jeder Klasse ausgerufen werden können, ohne eine Instanz von DialogFactory erzeugen zu müssen. Mir hilft es - wie gesagt - besonders bei der Übersicht. Natürlich kannst du auch in einer Activity eine Member Methode anlegen. Aber dann kannst du die Methode auch nur in der Activity aufrufen (oder du übergibst eine Instanz der Activity).

Das sind alles Design Aspekte und jeder hat einen verschiedenen Geschmack. Dies ist nur eine Variante.

Um nochmal auf die Ausgangsfrage zurück zu kommen: IceClaw wollte wissen, wie aus 2 Activity's den selben Dialog aufrufen kann, ohne den Code zu kopieren. Das habe ich gezeigt. Und wie gesagt, er könnte der zweiten Activity auch eine Instanz der ersten übergeben (sofern die erste die Methode für den Dialog beinhaltet), muss dann aber dem Dialog den Context der zweiten Activity übergeben, damit es sauber bleibt.

 

[mradlmaier]

Du beschwerst dich, welche Wendung dieser Thread nimmt und fragst dann nach static

Aus Sicht der Objektorientierung ist static böse. Aber manchmal kommt man nicht drum herum oder es vereinfacht die Dinge. Wie in diesem Fall. Ich habe nur eine Klasse meines Styles gezeigt. Es brauch sich keiner angegriffen fühlen. Es führen viele Wege zum Ziel.

Der Vorteil hier ist, dass diese Dialoge aus jeder Klasse ausgerufen werden können, ohne eine Instanz von DialogFactory erzeugen zu müssen. Mir hilft es - wie gesagt - besonders bei der Übersicht. Natürlich kannst du auch in einer Activity eine Member Methode anlegen. Aber dann kannst du die Methode auch nur in der Activity aufrufen (oder du übergibst eine Instanz der Activity).

Das sind alles Design Aspekte und jeder hat einen verschiedenen Geschmack. Dies ist nur eine Variante.

Um nochmal auf die Ausgangsfrage zurück zu kommen: IceClaw wollte wissen, wie aus 2 Activity's den selben Dialog aufrufen kann, ohne den Code zu kopieren. Das habe ich gezeigt. Und wie gesagt, er könnte der zweiten Activity auch eine Instanz der ersten übergeben (sofern die erste die Methode für den Dialog beinhaltet), muss dann aber dem Dialog den Context der zweiten Activity übergeben, damit es sauber bleibt.

Ich beschwere mich überhaupt nicht. Gerade weil das Design Aspekte sind, ist es wichtig welche Vor- und Nachteile ein bestimmtes Design hat. Deswegen meine Frage.

Es gibt nämlich viel zu viele nachlässig designete Android Apps. Apple Fanboys werfen dass uns Android Entwicklern mit einem gewissen Recht vor.

 

[v Ralle v]

Es kam aber etwas beschwerend rüber Ist jetzt alles geklärt?

 

[swordi]

Apple Fanboys werfen dass uns Android Entwicklern mit einem gewissen Recht vor.

sorry, aber was wollen apple fanboys darüber wissen? so ein blödsinn. nicht immer sind die apple fanboys die bösen.

es gibt genauso genug spagetthi code in ios apps. nur weils kontrolliert wird, heißt es nicht, dass apple den source der entwickler einsehen darf. jeder ist noch immer für seinen eigenen code verantwortlich