Android Übergeordnete Activity herausfinden?

[kurztipp]

Hallo,

wie finde ich die aufrufende/übergeordnete Activity einer Activity heraus? getCallingActivity() liefert null, da ich nicht startActivityForResult() verwende.
Hintergrund: Durch ein ActionBarItem wird eine Activity gestartet, in der Daten eingegeben und gespeichert werden können. Kommt der Benutzer versehentlich auf die Zurücktaste werden die Eingaben verworfen. Ich möchte dann auf der Activity, auf die er zurück kommt einen Toast anzeigen, der die Möglichkeit gibt, zur Eingabe-Activity zurückzukehren, die dann die vorherig gemachten Eingaben wiederherstellt.

Hierzu müsste ich onBackPressed überschreiben und der übergeordneten Activity ein Intent mit einem Bundle übergeben (das die Eingaben enthält und wieder an die Eingabe-Activity zurückgegeben werden kann). Allerdings weiß ich nicht, wie ich an die übergeordnete Activity komme.

 

[dzim]

Ich versuche immer - wo möglich - Activities zu vermeiden, weil ich dann mitunter vor haargenau dem Selben Problem stehen würde :-D
Grundsätzlich aber würde ich den weg eines Zentralen Models versuchen zu verfolgen, bei dem du vielleicht solche Daten - die ja nicht unbedingt gespeichert werden müssen und nur zu Laufzeit interessant sind - hinterlegst.

Aber auf StackOverflow ist man der Meinung, dass der Beste Weg immer noch #startActivityForResult() ist...

Sending data back to the Main Activity in android - Stack Overflow

 

[kurztipp]

Hallo,

arbeitest Du dann grundsätzlich mit Fragments statt Activities?

Bei einem zentralen Model müsste ich allerdings bei jedem Start der Activities (man kommt in die Editieractivity von mehreren Punkten) das Model auf Daten prüfen. Letztlich verrichtet die App dann häufig unnötige Arbeit.

Gruß

 

[dzim]

Naja, ich habe schon auch noch Activities- irgendwo drauf müssen die Fragmente ja liegen. Aber das meiste sind Fragmente, ja (also auch die Dialoge, versteht sich).

Bei jeder UI musst du, wenn die angezeigt wird, evtl. prüfen, welche Daten angezeigt werden sollen.
"Zentrales Modell" kann auch einfach deine lokale DB darstellen.
Bedenke einfach: Deine Editier-Activity wird jedes mal neu geladen, also musst du sie auch wieder initialisieren. Bei Fragmenten kann das anders aussehen, solange sie nicht bereits durch das System zerstört wurden, sondern noch im Memory herumgeistern. Dann kann man evtl. sogar noch ihre Daten updaten und in der onResume evtl. nur noch mal setzen lassen (wenn du verstehst, was ich meine).

(Bin etwas krank heute und nicht ganz auf der geistigen Höhe.)

 

[kurztipp]

Hallo,

ganz um activities kommt man nicht herum, das ist mir bewusst 😉 Mich würde dann nur der Ansatz interessieren. Denn eigentlich habe ich das so verstanden, dass Activities "eine logische Anzeigeeinheit" bilden. Daher habe eine Activity, welche die Daten (in einem Übersichts- und einem Detailfragment) anzeigt und eine Activity, in der die Daten eingegeben oder editiert werden können. Getrennt, da beide unterschiedliche Aufgaben erledigen.

Prinzipiell ist plane ich, dass die Editier-Activity von unterschiedlichen Activities gestartet werden kann. Daher würde ich eben gerne wissen, welche die Acitivity gestartet hat, um nicht in jeder auf Daten prüfen zu müssen. Um das zu vermeiden habe ich folgendes probiert:

Ich überschreibe onBackPressed() und starte darin einen Toast. Dieser Toast startet die Editieractivity mit einem Intent, das als IntentExtras die vormals eingegebenen Daten enthält, wenn auf den Toast gedrückt wird. Der Toast wird angezeigt, aber auf den click wird nicht reagiert.

    @Override
    public void onBackPressed() {
        LayoutInflater inflater = getLayoutInflater();
        View toastLayout = inflater.inflate(R.layout.toast_undo,
                                            (ViewGroup) findViewById(
                                                R.id.toast_layout_root));
        TextView toastUndoText = (TextView) toastLayout.findViewById(
            R.id.toast_undo_undo_text);
        toastUndoText.setClickable(true);
        toastUndoText.setPaintFlags(
            toastUndoText.getPaintFlags() | Paint.UNDERLINE_TEXT_FLAG);
        toastUndoText.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                Intent intent = new Intent(Edit.this, Edit.class);
                intent.putExtra("someData", Edit.this.someDataEdit
                    .getText().toString());
                startActivity(intent);
            }
        });

        Toast toast = new Toast(this);
        toast.setView(toastLayout);
        toast.setGravity(Gravity.CENTER_HORIZONTAL | Gravity.BOTTOM, 0, 0);
        toast.setDuration(Toast.LENGTH_LONG);
        toast.show();
        super.onBackPressed();
    }

Bei Fragmenten kann das anders aussehen, solange sie nicht bereits durch das System zerstört wurden, sondern noch im Memory herumgeistern.

Gilt das nicht auch für Activities, sofern das System genügend speicher hat?

Gruß

 

[dzim]

Stell dir Activities als immer-in-Vollbild angezeigte SWT-Shell oder JavaFX-Stage vor (weiss nicht, wie es in Swing heisst).
Fragmente sind dann nur in sich geschlossene Teile der UI. In SWT kannst du im Prinzip alle für eine bestimmte UI notwendigen Funktionen in eine von Composite abgeleitete Klasse machen. Der Unterschied ist nur, wie Pausen und Stops behandelt werden. Dichter an das Konzept heran kommt JavaFX mit seinen Controllern, die - wie auch Fragmente - grundsätzlich erst einmal nichts von einander wissen.

In deinem Fall verstehe ich noch nicht das onBackPressed zuüberschreiben um eine andere Activity zu starten (klingt für mich etwas unlogisch), aber ich hoffe mal, du hast dein Bedienkonzept überlegt ;-)

Was die Toast angeht und warum sie nicht auf den Klickreagieren kann ich dir nicht sagen. In der Form habe ich damit noch nicht gearbeitet. Gibt es vielleicht eine spezielle Variante aus der Support-Lib, dass du solche Klickbaren Toasts wie bei einigen Google-Apps bekommst?

 

[kurztipp]

In deinem Fall verstehe ich noch nicht das onBackPressed zuüberschreiben um eine andere Activity zu starten (klingt für mich etwas unlogisch), aber ich hoffe mal, du hast dein Bedienkonzept überlegt ;-)

Naja, onBackPressed wird ja nur überschrieben, um den Toast anzuzeigen. Danach wird super.onBackPressed() ausgeführt, in den Activity Backstack wird damit also nicht eingegriffen.
Lediglich ein click auf den Toast soll halt die eben geschlossene Activity wieder starten.

Was die Toast angeht und warum sie nicht auf den Klickreagieren kann ich dir nicht sagen. In der Form habe ich damit noch nicht gearbeitet. Gibt es vielleicht eine spezielle Variante aus der Support-Lib, dass du solche Klickbaren Toasts wie bei einigen Google-Apps bekommst?

API genau lesen, dann hätte ich mir den Versuch sparen können:

When the view is shown to the user, appears as a floating view over the application. It will never receive focus.

Dadurch, dass der Toast allerdings über der application angezeigt wird, kann ich ihn in der einen Activity starten, diese beenden und er wird in der anderen (oder eben auf dem Homescreen) angezeigt.

Bin allerdings eben auf PopupWindow gestoßen. Mal sehen, ob ich damit weiter komme. Aufgrund der API geh ich aber nicht davon aus:

The popup window is a floating container that appears on top of the current activity.

PopupWindow ist an die activity gebunden. Also wird es mit der super.onBackPressed() auch wieder verschwinden.

 

[dzim]

Nutzt einen Context. Also zum Bsp. auch deineActivity.getApplicationContext() oder so. Sollte also quasi unabhänig von deiner konkreten Activity gehen, oder?