Android: Ein Activity-View updaten

B

broadcastIntent

Neues Mitglied
0
Hi,
bin neu in Android und bin auf das Problem gestoßen ein Activity-View in Abhängigkeit von einem Timer zu aktualisieren. Nun sind zwei Ansätze (A) und (B) denkbar:

(A)
Auf dieser Seite wird ein Vorgehen mit Handlern und Runnables als einzige Lösung unter Android propagiert: How to Update the Android GUI From a Timer | TechSono Software Consulting - Miami Beach, FL

(B)
Nun kennt man ja vielleicht auch das Observer-Pattern, bei dem sich ein Observer (O) bei einem Observable (OV) zur Laufzeit registrieren kann und dann O immer dann informiert wird, wenn OV sich ändert. Der Vorteil liegt ja in der losen Kopplung und der beliebigen Austauschbarkeit der Views ohne zusätzlichen Wartungsaufwand.

Dieser Vorteil ist ja beim (A)-Ansatz nicht gegeben, denn hier besteht erhöhter Wartungsaufwand durch die Notwendigkeit die Activity im Code stets über die Views, die aktualisiert werden wollen, auf dem Laufenden zu halten.

Warum ist man bei Android vom bewährten B-Ansatz abgewichen?
 
Leider öffnet sich der Link bei mir gerade nicht.
Was genau möchtest du denn aktualisieren?

Das Problem ist doch, dass eine View innerhalb der Activity normalerweise niemals allein dort steht.
Deshalb bringt es ja nichts, wenn die Activity weiß, dass sich die View geändert hat, sie muss im Zweifel trotzdem alles neu zeichnen. Da sich evtl auch die Größe geändert hat und damit die anderen Views auch neu gezeichnet werden müssen.

Oder meinst du was komplett anderes?

EDIT:
Jetzt hat sich der Link doch noch geöffnet.
Ich seh das Problem das dort besprochen ist gar nicht so.
Statt einem Handler kann man auch die runOnUiThread Methode aufrufen.
 
Zuletzt bearbeitet:
Hallo amfa,
eine Activity-View, damit meinte ich eher die komplette Oberfläche (Bildschirmseite inkl aller Widgets und Bedienelemente verwirrenderweise auch Views genannt), die von einer Activity gezeichnet wird.
Hm, also wegen des Observer-Patterns. Es ging mir um die grundsätzliche Funktionsweise der Architektur des Android-Frameworks. Für mich war das Observer-Pattern immer das Nonplusultra, um Komponenten, die etwas darstellen (View, Observer) an Komponenten, die Informationen bereitstellen (hier: Activities, Observables) lose zu koppeln.
Aus Wikipedia:
Das beobachtete Objekt [Observable] bietet einen Mechanismus, um Beobachter [Observer] an- und abzumelden und diese über Änderungen zu informieren. Es kennt alle seine Beobachter nur über die (überschaubare) Schnittstelle Beobachter. Es meldet jede Änderung völlig unspezifisch an jeden angemeldeten Beobachter, braucht also die weitere Struktur dieser Komponenten nicht zu kennen.

Der letzte Satz trifft ja bei Android nicht zu. Die Activity kennt ja alle Views und seine Widgets und Bedienelemente über deren Id. Widgets ud Bedienelemente sind also nicht ohne umfangreiche Änderungen in den Activities austauschbar.

Andererseits wäre das Observerpattern in Android ja auch gar nicht möglich, da die Views dort keine eigene Funktionalität implementieren können. Sie liegen ja "nur" als XML Dateien vor, könnten im Falle von neuen Informationen durch die Activity ihr Aussehen gar nicht selber anpassen.

Views werden also komplett durch Activities (im MVC Modell wären es wohl die Controller) verwaltet.

Hm, ich glaub jetzt bin ich mir selbst darüber klar geworden.
 
Du musst vorallem auch überlegen, das ja auch Views in anderen Views vorhanden sind.
Deshalb klappt das mit dem Observer pattern auch nicht.

Ich glaube Google hat sich da schon seine Gedanken gemacht und ich persönlich finde, dass sie das ganze ganz gut gelöst haben, zumindest ich verstehe ihre Gedanken und das hilft mir ungemein beim Programmieren, wenn ich verstehe was sich der "Künstler" dabei gedacht hat :D
 

Ähnliche Themen

J
  • Juleru
Antworten
8
Aufrufe
497
Juleru
J
M
Antworten
4
Aufrufe
1.173
swa00
swa00
5
Antworten
0
Aufrufe
1.150
586920
5
Zurück
Oben Unten