Static in Android

Ich kann nur meine Verwendung schildern, da ich noch nie Performance oder Speicherprobleme hatte. Das liegt aber auch daran, dass ich static nicht "on mass" benutze.
Ich nutze static hauptsächlich nur für
- Tags, in den Fragment-Klassen
- Tags, zum Loggen in einer Klasse
- Keys, für Bundles, die Fragmenten übergeben werden. Das sind meine einzigen Verwendungszwecke. Ich muss aber noch dazu sagen, dass ich die ganzen statics auch noch final mache.

Dieser Beitrag http://stackoverflow.com/a/17335215 und der erste Kommentar sind interessant.
Edit: Ich habe schon vergessen, dass es hier um static und nicht um final geht. Egal, trotzdem interessant.

— geändert am 08.11.2014, 09:59:13

Kann ich auch nicht nachvollziehen.
Benutze static meist im zusammenhang mit Final und auch für Tags,Keys etc.
Dann habe ich noch eine static Global Klasse in der alles mögliche gespeichert wird.
Bisher sind mir deswegen keine Fehler untergekommen.
Steht ja nirgends explizit dass man keine Static Variablen verwenden soll.
Sinn von OOP ist ja das Progrann in Objekte zu unterteiken.Das passt soweit auch aber statt einer Static Variable kannst du auch eine non static einfach immer weiter übergeben.
Ist umständlich etc. und hat meiner Meinung nach keine Vorteile.
Fazit: Static vars sind nix schlechtes man sollte aber schauen dass man sie nicht immer und zu häufig benutzt sondern auch mal Vars als Methodenparameter übergeben etc.

Lg Pascal

Ich hab mir mal erlaubt deinen Toten Link wiederzubeleben

Jetzt verstehe ich was du meinst.
Ich denke Innherhalb einer Activity ist das Unproblematisch wenn dich der Context nicht ändert.
Du darfst auf die static Dields halt nicht aus anderen Klassen zugreifen das ist so in Android bzw. allgemein Java (desktop) nicht Vorgesehen
Es gibt 1 Klasse, in diesem Fall eine Activity darin kannst du die Views static machen und nach belieben verändern.
Die Views sollten aber nicht public sein, sprich andere Klassen sollen nicht auf Views zugreifen dürfen.

Achso, ja, okay. Diese static Variablen kann man aber gut umgehen. Zumal wüsste ich nicht, wozu man die Views an sich in anderen Klassen unbedingt braucht. Wenn man zum Beispiel den Text eines TextViews verändern will, dann returnt die Methode in einer anderen Klasse den Text, statt dass diese Methode selbst den Text verändert.

@Sven: Genau so ist es richtig
Ich hab da schon komisches Zeugs gesehen:
a la [Bitte kein CopyAndPase verwenden!]

//beleibige Activity
public static TextView txt;
protected void onCreate(...)
{
init();
}

private void init()
{
txt=(TextView)findViewById(R.id.text);
OtherClass otC = new OtherClass();
otC.setText(this);
}


//Other Class:

{
public void setText(MainActivity act)
{
act.txt.setText("MeinText");

}


}

Ist jetzt ein Ausgedachtes Beispiel von mir das man nicht benutzen sollte.
Aber so ähnliche sachen gibt es und man sollte zu IMMER vermeiden.

Halo,
thia ....... nicht alles, was hier geschrieben wurde - so stimmt.
Ob ich das hier verständlich erläutern kann ist fraglich - ich probiere es!

Java ..... Android ist OOP. In den Sprachen / APIs ist die rede von Objekten, Instanzen ... .
Oft macht es sinn sich dazu noch eine Hilfe zu holen. Mit der Hilfe meine ich die statische Vars ... Methoden ... Ich (damit ich es kapieren - aber auch richtig benutzen konnte) habe mir die static als Brücken vorgestellt.
Du siehst eine Stadt von oben (Perfekte OOP Programm- Lösung - also relativ Großes Projekt ) und dazu paar Brücken (auch zwischen den Häusern!).
In der Java (Doku) findet man vieles statisches, in der Android Doku (API) habe ich nur statisches gefunden, was Performance betrifft.
Nun;
Die static wurde zugelassen, um Attribute und Methoden unabhängig von Objekten zu machen. Sich so zusagen eine "andere" Ebene / Schicht -> ("Brücken") zu bauen, um auf der Schicht / Ebene "zu korrespondieren. Du hast in deinem Korrekten OOP Programm, außer einer "Kommunikation- Aufbau" mit ... Attribute, .... Methoden .... Interfacen ... NOCH! auf der Static Ebene dazu!
Jetzt das wichtigste! Warum sind Statische Variablen, Methoden so SCHLIMM?
Sind sie NICHT!!!!! - gerade das gegen teil - die sind sehr nützlich.
Das (static) führt zu Problem(en) weil; - die Eigenschaft wird oft missbraucht.

• bei einem Schlechtem und nicht durch gedachtem Programmentwurf
• für eine art "Notbremse"
• von nicht Erfahrenen Programmieren

Weil in allen von den 3 Punkten, wird das static MIT! einem Objekt "zusammen gekoppelt".
Und gerade DAS -> eine Verbindung / das Koppeln mit einem Objekt ist das BÖSE!

Die (static) dürfen also keinen Zustand von Objekten nutzen wie auch mit denen (Objekten) eine Verknöpfung / Bindung / Referenz .... haben.

Sonst bieten Statische Eigenschaften einen Vorteil mit sich an.

FAZIT:
Wenn man seine Eigenschaften - quasi "Macht" nicht missbraucht und mit den static gut umgehen kann, ist das nur für Vorteil, de facto sehr nette Hilfe

Das Beispiel vom Pascal (was der auch mit >>... zu IMMER vermeiden Betont hat) ist NO GO!

LG
Georg

Ps.
ach so - die "statische Lawine" - die habe ich wirklich erlebt.
Drei tage von meiner Präsentation eines Gerätes sollte noch eine (vorher nicht vorgesehene) Möglichkeit sich bitten. (Das Gerät sollte noch was zusätzliches machen) Das Programm war nicht flexibel genug um dies zu ermöglichen, die Zeit - drängte .... also verbleibt mir nur mit static es zu lösen -> ..... naher (damit alles auch funktioniert) waren ALLE! Klasen, Methoden, .... vars - static! War wirklich so. Naher habe ich die Zeit es zu korrigieren.

Natürlich ging es früher auch ohne OOP(zum Beispiel Basic). Trotzdem zeugt eine Nichtverwendung von static Variablen bei mir für mehr Ordnung/Übersichtlichkeit. Ausgenommen sind Variablen, die in OOP keinen Sinn machen würden(statt MyFragment.ARG_TEXT MyFragment.getArgText() zu verwenden ist ziemlich komisch).
Du hast keinen Vorteil für static Variablen genannt. Abgesehen davon, fände ich es nett, wenn du ein Beispiel für static Variablen zeigst.

Mein Wissen basiert hauptsächlich auf Erfahrung, darum kann ich falsch liegen. Quellenangaben wären in deiner Argumentation überzeugend.

— geändert am 09.11.2014, 01:44:14

Für Konstanten und zustandslose ausgelagerte utility Methoden ist static ja eigentlich die sinnvolleste Notation.
Static Methoden in zustandsvollen Objekten sind idR fehl am Platz und resultieren meist aus dem unbedachten Nutzen der Eclipse Quick-Fixes

Der problematische Fall ist doch eigentlich, wenn man dynamische Objekte in static Variablen speichert.
Dann sollte man wirklich sehr genau verstehen was static bedeutet und den Lifecycle der Objekte daraufhin prüfen, ob man sie wirklich so lange speichern darf und kann ohne Seiteneffekte hervorzurufen.
Man muss sich im Fall von Multithreading überlegen an welchen Stellen man den Zugriff synchronisieren muss, etc. (Beispiel Iteration über Liste und ConcurrentModificationException)

In Android ist static auch manchmal ein gutes Hilfsmittel, um Daten in einer Art "Session" zu speichern,
denn die Daten in einer static Variable werden solange erhalten, bis die VM die Klasse unloaded.
Das passiert "irgendwann" nachdem man die App beendet hat. Das kann nach ein paar Minuten, oder auch Stunden sein.

Ein konkreter Anwendungsfall aus meinen Apps:
Ein boolean Flag in einem Fragment, in dem ich speichere, ob ich dem User eine nicht lebenswichtige Warnmeldung schon angezeigt habe. Der User soll sie einfach nur nicht bei jedem Knopfdruck sehen, sondern "ungefähr einmal pro Ausführung der App".
Z.B. die Meldung, dass die App mit GPS Ortung genauer funktioniert.

Anderes Beispiel: Caching
Ein Cache mit WeakReferences, wie man es häufig in Desktop Java macht, funktioniert in Android nicht, weil WeakReferences laut Doku (und laut meinen Tests) sofort vom GC erfasst werden.
Aufrufe des GeoCoders von Google z.B. kann man ganz wunderbar im Speicher cachen und Traffic sparen. Man sollte nur gut synchronisieren.

Weiteres Beispiel: Singletons
Laut Doku sind Custom Application Klassen in Android einfache Singletons und die Doku sagt ganz offen, man kann auch einfach Singletons nutzen stattdessen. In Android sind Singletons häufig sehr sinnvoll einsetzbar. Ich nutze sie z.B. für die Verwaltung des eingeloggten Users (wieder als eine Art Session) und auch für meine HTTP Klassen.
Speziell bei den HTTP Klassen ist das sehr sinnvoll, weil man über mehrere Fragmente einen HttpClient und damit einen CookieStore teilt. Ein etwaiger Login bleibt also erhalten.

Auch, um auf unkonventionelle Weise einen Listener zu registrieren, ist eine static Methode häufig eine mögliche Wahl.
Manchmal gibt es einfach keinen sinnvollen API Zugriff zwischen zwei Teilen der App und man will beispielsweise ein Event in einem BroadcastReceiver abfangen, aber nur wenn ein bestimmtes Fragment grade sichtbar ist. (Beispiel: Eingehende GCM Nachricht sofort anzeigen, statt Notification)
Man kann im BroadcastReceiver einfach einen static Listener speichern, der über eine static setter Methode gesetzt wird und setzt/löscht ihn beim onStart / onPause des Fragments. Mit einem null-Guard im Broadcast-Receiver funktioniert das ganz wunderbar.
Man muss aber auch hier wissen in welchem Thread ein solcher Aufruf läuft und ihn evtl. gezielt auf den UI Thread umlenken.

Also static ist keine Erfindung des Teufels direkt aus dem neunten Kreis der Hölle.
Es ist, gute Kenntnisse der Plattform vorausgesetzt(!!!) ein weiteres Werkzeug Probleme geschickt zu lösen.

— geändert am 09.11.2014, 14:12:03

@Sven R.
also besser es erläutern als der Rafael K. werde ich nie! können. Der hat eigentlich alle deine Fragen beantwortet.

Ich mache es (nur am Rande) kleine Bemerkung zu deine Post;
Viele benutzen es und nicht wissen, dass es sich eigentlich um Statischen Methoden handelt:

Paradenbeispiel (wird auch bei Android benutzt) die:
- Math.sin(); // eigentlich alle Math Funktionen
....
- Integer.parseInt(); // Parser
... und vielen mehr.

... Quellenangaben wären in deiner Argumentation überzeugend.

Da musste ich alle meine Bücher hier auflisten ....

... Du hast keinen Vorteil für static Variablen genannt. Abgesehen davon, fände ich es nett, wenn du ein Beispiel für static Variablen zeigst.

hier bin ich wieder etwas ... sprachlos.
ABER!

Hier
oder
Hier

LG
Georg

— geändert am 09.11.2014, 18:52:49

Danke Rafael für die ausführliche Erklärung! 😀

Georg C.

Viele benutzen es und nicht wissen, dass es sich eigentlich um Statischen Methoden handelt:

Paradenbeispiel (wird auch bei Android benutzt) die:
- Math.sin(); // eigentlich alle Math Funktionen
....
- Integer.parseInt(); // Parser
... und vielen mehr.

Gegen statische Methoden habe ich nichts 😀

... Aber zurück zum Thema.. Mein Anwendungsfall sieht so aus: Besagte
Klasse, bei der ich die Quick-Fixes herangezogen habe, ist eine Google
Map (v2) in einem Fragment ..... ..... Sinnvoll oder nicht? Ich sehe
in dieser Logik nicht im geringsten ein Problem. ...

ich bin raus hier
wünsche euch allen viel erfolg bei progen

Georg

OK, das mit den Quick-Fixes bitte nicht falsch verstehen.
Ich liebe die! Man kann in Eclipse, wenn man die Tastenkürzel kennt, ganze Klassen quasi per Autovervollständigung schreiben/generieren.
Teilweise sind die Quickfixes gradezu genial, wie "invert equals" ... falls jemand weiß was ich meine
Auch schon "assign to local variable" oder "convert to field", oder "asign to new field" beim Schreiben eines Konstruktors schwärm.
In meiner alten Firma hatte ich irgendwann den Spitznamen Shortcut-King weg
Wenn man dann noch einstellt, dass Member immer ein "m" Präfix haben, kommt da so schöner Code bei raus...

Aber wie immer sollte man wissen was man tut. "Make xyz static" ist ein sehr zweischneidiger Quickfix.
Als Beginner freut man sich natürlich, dass der Fehler-Marker weg ist, aber eigentlich hat man dann meistens nur notdürftig geflickt und es fliegt einem bei nächster Gelegenheit um die Ohren.

Das was du da machst, habe ich in meiner aktuellen Ticket-Sharing App auch drin, aber anders gelöst.
Ich habe in meiner MainActivity eine public non-static Methode drin, die das macht. Die MainActivity ist von jedem Fragment erreichbar und großer Vorteil ist, dass Du bei einem Aufruf der Methode den Context nutzen kannst.
Bei einem static Aufruf kannst Du das nicht, denn die kann theoretisch von überall aufgerufen werden. Außerdem ist das dort von der Semantik her sinnvoll untergebracht.
Zusätzlich speichere ich den non-static member bei onSaveInstanceState, so dass er auch ein class-unloading überlebt, wenn die App minimiert und vom System geschlossen wird (der Wert lebt also länger als static)

    public LatLng getLastLocation() {
            if (mLocationClient != null && servicesConnected() && 
                            mLocationClient.isConnected() && mLocationClient.getLastLocation() != null) {
                Location mLastLocation = mLocationClient.getLastLocation();
                return new LatLng(mLastLocation.getLatitude(), mLastLocation.getLongitude());
            } else if (mLastLocation != null) { 
                Log.w(LOG_PREFIX, "LocationClient not connected, but position cached (probably rotating device). Returning cached position");
                return new LatLng(mLastLocation.getLatitude(), mLastLocation.getLongitude());
            } else {
                if (!mGpsErrorShown) {
                    mGpsErrorShown = true;
                    GuiUtil.showErrorMessage(this, R.string.error_getting_position);
                }
                return SatSettings.CENTER_OF_GERMANY;
            }
        }

Wenn Du beschreibst, dass Du in einem Receiver dann eine static Methode einer Activity nutzt, die einen static Member der Activity liest, fühlt sich das schon falsch rum an. Du greifst damit aus einem UI-losen Service auf die Oberfläche zu. Das finde ich konzeptionell schon falsch. Eigentlich programmiert man mehrschichtige Architekturen immer so, dass die Zugriffe "von oben nach unten" ausgelöst werden. Wenn es nämlich keine Abhängigkeiten von Schicht n-1 zu Schicht n gibt, kann man jede Schicht < n ohne Änderung der Schicht n austauschen.
In meinem Fall habe ich hier einfach eine alternative Implementierung, denn in der Oberfläche kann ich Fehler der Ortung ganz anders behandeln, als in einem Hintergrunddienst. In der Oberfläche kann ich z.B. dem User die Möglichkeit geben die PlayServices nachzuinstallieren.
Im Service habe ich es so gelöst:

       LocationManager locationManager = (LocationManager) getSystemService(LOCATION_SERVICE);
        Location location = locationManager.getLastKnownLocation(LocationManager.GPS_PROVIDER);
        if (location == null) location = locationManager.getLastKnownLocation(LocationManager.NETWORK_PROVIDER);
        if (location == null) location = locationManager.getLastKnownLocation(LocationManager.PASSIVE_PROVIDER);

        LatLng position = null;
        // check if location OK
        if (location == null) {
            Log.w(TAG, "Cant locate user!");
            sendNotification(this, getString(R.string.error_bgs_no_location_title), 
                    getString(R.string.error_bgs_no_location_msg), NOTIFICATION_ID_ERROR, null);
            position = SatSettings.CENTER_OF_GERMANY;
        } else {
            position = new LatLng(location.getLatitude(), location.getLongitude());
        }

Ich frage alle Provider ab, absteigend von genau nach ungenau und wenn einer davon einen Standort liefert, super, wenn keiner einen hat, gibt es eine Meldung und ein Fallback-Wert wird benutzt. (Wobei ich das wohl noch ändern werde).

— geändert am 10.11.2014, 10:38:55

Das problem mit den PlayServices ist das sie nicht direkt eine Location Liefern. Oft bekommst du ein NULL wenn du fragst getLastKnownLocation. Ich löse das inzwischen nur noch mit RxJava/RetroLamdas.
Man kann ja testen ob der User gewisse Location Services angeschaltet hat, in dem Fall sollte man wirklich den User in die Settings leiten um diesen einzuschalten.
Ich hätte mir gewünscht das es in Lollipop evtl. per Code gehen würde solange z.b eine APP im Vordergrund ist. Aber das bringt wiederum andere Probleme....

Aber zum static Code: Static Code sollte statisch sein, er sollte keinen eigenden State haben!

Für mich sind sowas immer Klassen/Methoden die ich in die Kategorie Helper/Util packen kann. Die man von einer menge Klassen aus verwenden kann. Fragments haben sowas ebenfalls mit der newInstance Methode.
Konkrete Fragments bieten aber ebenfalls static Methoden an, wo sie parameter in ein Bunde packen ohne das man sich von aussen drum kümmern muss wie das genau passiert.

bsp:

/**
 * Check if current Thread is the Main/UI Thread
 *
 * @return
 */
public static boolean isUIThread() {
    return Looper.getMainLooper() == Looper.myLooper();
}

public static void close(@Nullable final Closeable closeable) {
    if (closeable == null) {
        return;
    }
    try {
        closeable.close();
    } catch (final IOException e) {
        Log.w(LOG_TAG, "Failed to close", e);
    }
}

Wobei Static Klassen keinen this Pointer auf Klassen haben, dies ist gerade im Android umfeld
meiner Meinung nach wichtig. Sonst hast du schnell den Context oder andere Resourcen die genutzt werden geleakt wenn z.b ein config change auftritt. Wenn eine APP im Manifest stehen hat:

android:configChanges="keyboardHidden|orientation|screenSize"

Dann weiß Ich schon vor dem schauen in den Code, das hier sehr wahrscheinlich sehr viel schiefgehen wird wenn Ich das rausnehme. Spiele dürfen das meiner Meinung nach, diese sind oftmals nur im Landscape wirklich gut nutzbar. AsyncTask und wie sie alle heißen haben mit sowas dann zu kämpfen, weil sie schlichtweg nur für den Gutfall Programmiert wurden.

Ein weites Bsp. für static Code ist das "God Object" ... hier meine Ich das Application Object. Ich hab Projekte gesehen wo wirklich alles da gehalten wurde. Das auf ein vernünftiges mass runterzubiegen kann dauern. Das Application Object ist zwar nicht per se static ist dennoch ein Singleton. Singletons lassen sich schlecht Testen! Auf dem Application Object sollte man z.b den HTTP Client der Wahl ablegen (oder man nutzt z.b Dagger), viel mehr würde Ich da aber nicht unterbringen. Da HTTP Clients oftmals einen ThreadPool haben ist es durchaus Sinnvoll für die Performance diesen auch nur einmal zu erzeugen (z.b auch lazy).

Immer auf den armen GC ... der hat doch so einen harten Job

Nee mal im Ernst. Der GC hat ja damit nichts zu tun.
Man muss halt manchmal ein bisschen mit dem Lifecycle der Activities/Fragments kämpfen bis es passt.
Wenn man sich aber mal ein bisschen ins Thema einarbeitet, wann und wie welche Phasen durchlaufen werden, kriegt man es idR immer gut hin

Fragments sind auch eine pest, nested Fragments hab ich mir abgewöhnt. Das Lustige ist das eben nicht in der Docu beschrieben ist wie beschränkt das ganze ist. Ich hätte mir für Lollipop
da auch mal radikale Veränderungen gewünscht.

Die Trennung von UI und Logik ist halt die Kunst. Android Projekte tendieren ja zur Callback Hölle, was per se keiner mehr wirklich durchschauen kann, HTTP Callback hier, Play Services Callback und und und ...

Seitens GC würde Ich sagen geht das ganze, versuche deine Variablen lokal zu halten wenn möglich. "Teuere" Objekte länger zu halten, ObjectPools könnten da z.b helfen, oder die allseits beliebte HashMap

Ich weiss garnicht was an den Fragments das Problem ist,
das ist doch nur die UI in eine eigene Klasse ausgelagert, die einige Vorteile z.b. Viewpager erweisst.

Man merkt das du keine größeren Projekt damit stemmen musstest, 50+ Fragments.

Ach ja, auf meinen Wunschzettel steht noch folgendes: Resourcen in Unterordner packen zu können, so das Layouts die logisch zueinander gehören auch wiedergefunden werden können.

/layout/userverwaltung/...

Das wäre echt der hit, statt immer zu suchen

@mac:
Da hast du recht.
Bei mir kommen auf eine Activity mal 10 Fragments oder so da ist das noch übersichtlich.

Das mit Den Layouts stiimmt auch. Ich verwende da immer ein präfix etc. so kann man wenigstens etwas überblixk behalten

Joa eben, Präfixe helfen.
Inzwischen kann man in Eclipse ja immerhin von den R-Konstanten zu den Deklarationen in der jeweiligen XML-Datei springen.
Das ist gefühlt schon ein großer Fortschritt.

Und die Umsetzung der Fragmente:
Es gibt ein paar Ecken und Kanten, aber grundsätzlich finde ich das Konzept stimmig und gut skalierbar.

Einige Dinge in Verbindung mit dem Backstack finde ich etwas unglücklich, aber sonst...

Warum rufst Du findViewById an der Activity auf und nicht über getView().findViewById() im Fragment?
Warum speicherst Du die Activity in einer Variable? Über getActivity() kriegst Du die doch überall im Fragment und vor allem kann sich die Instanz bei einem rotate ändern.

— geändert am 11.11.2014, 13:51:08

Wenn sich dein Code im Fragment befindet darfst du UI elemente nicht aus der Avtivity laden.
Das Fragment hat da seine eigene UI in der OnCreateView beim LayoutInflater.
Da musst du diese Zeile dann hinschieben.
Wenn das aber ein Übergrordnetes Feld über alle Fragments ist, dann musst du das Feld. in der Ansteuerungsactivity setzen, da das Fragment unter umständen keinen Zugriff auf die ActivtyUI hat.

Wenn du Fragments nutzt ist deine Activity an sich recht leer, ist nur noch der Container.
Wenn ich mich recht erinnere verhalten sich Fragments im ViewPager wie sonst auch.
Du kannst aber angeben wie viele der Pager halten soll, wenn du nicht sonderlich große Bilder etc
hast sollte das kein Problem darstellen.

Was willst du in Fragmenten denn updaten?
Die anzuzeigenden Daten?
Reicht dafür kein Callback etc?

— geändert am 11.11.2014, 19:31:12

Wie wäre es mit einer DataStorage klasse die alles speichert etc. und dir Frsgmente holen sich davon dann die Daten.

Also ich würde dir dringend empfehlen nochmal die Architektur von Fragmenten zu studieren.
Ich denke 90% des Frustes über Fragmente liegt eigentlich darin, dass die Architektur der App an den vorgesehenen Schnittstellen der Fragmente vorbeiprogrammiert ist.

Martin Pfeffer

Hmm, ein Sammelplatz erfordert ja ebenfalls, dass das Fragment die Daten abholt.
Um nochmal auf den Callback zurück zukommen.. ich richte das Fragment so ein, dass die Informationen aus der Main herausgezogen werden, anstatt dass ich sie von der Main aus versuche "ins Fragment zu drücken"?
Sprich am sinnvollsten wäre es ich starte einen Thread in dem Fragment und rufe von dort einen Getter in Main (bzw. DataStorage ö.ä.) auf, richtig?

Klingt auch wieder etwas schief.
Richtiger klingt für mich:
Das Fragment, das die Anzeige übernimmt, löst eine Aktualisierung aus und registriert sich über ein Interface als Listener.
Die Aktualisierung läuft nicht in einem Thread, sondern in einem AsyncTask, oder Service, je nachdem wie lange und unabhängig von der Oberfläche sie laufen soll.
Der Hintergrund Task informiert in gewissen Abständen die Oberfläche darüber, dass neue Daten da sind,
woraufhin sich die Oberfläche mit den neuen Daten aktualisiert.

Wo Du die Daten speicherst, hängt von deinem Anwendungsfall ab.
Speicher, SQLite DB, ist alles möchlich.

Weil es in Android andere Konzepte für Multithreading gibt, die helfen die Synchronisation mit dem UI-Thread zu erledigen.
Aus einem nativen Thread heraus hast Du keinen Zugriff auf die Oberfläche. AsyncTask hat dafür spezielle Callbacks.

kurz reingeschaut;
und was hat dass alles bitte -> mit >Static in Android< zu tun?

Martin Pfeffer

Hahaha, hab jetzt auch den Bug gefunden. Ich Idiot... Habe nur das Fragment-Objekt in meiner Main auf "nicht-null" geprüft und nicht die View auf ihre Funktionstüchtigkeit.

Genau das meine ich mit "Am Konzept von Fragmenten vorbei programmiert".
Wenn das Fragment die Daten anzeigt, sollte auch das Fragment die Daten holen.
Das Fragment weiß nämlich selbst genau in welchen Zustand es grade ist und du solltest die integrierten Callbacks wie onResume und onPause dafür nutzen zu tracken ob es grade sichtbar ist.

@Georg: Da hast du volkommen Recht.

Deswegen bitte ich alle beteiligten wieder aufs ursprüngliche Thema zurück zu kommen.
Für Smalltalk könnte man ja hier einen Eigenen Thread erstellen à la "Coders talk" etc. da drin ist man auch unabhängig vom Thema.