Ein Konzept von Swing ist es, dass man Container einsetzen kann.
Das ist auch der Inhalt der Frage 3. Wozu braucht man die?
Die kann man nutzen, um diese Oberflächen zu strukturieren, zu gliedern.
Vor dir zehn, jetzt weiter, diese Flächen,
Oberflächen bestehen ja immer aus Teilen und häufig ist es so,
dass es gut ist, ein Teil wieder aus anderen Teilen zusammensetzen und das vielleicht wieder austeilen.
Hat den Vorteil, dass man sie strukturieren kann.
Zum einen, wenn man sie ansprechen will,
das will ich aktualisieren oder das irgendwo hin bewegen
und man kann sie auch wiederverwenden
Container können dabei oder diese Komponenten können dabei wieder Komponenten enthalten.
Deswegen sprechen wir von hierarchischer Anordnung bis zu irgendwie atomaren Komponenten.
Das sind die, die wir gerade auf den vorangegangenen Folien gesehen haben.
Und jetzt gibt es noch das Konzept der Container.
Container sind Komponenten, die andere enthalten.
Wir haben hier ein Bildchen von diesem russischen Spielzeug Matrioschka,
das ist also in einer steckt wieder eine drin.
Die kann man aufmachen, steckt wieder einer drin,
wieder eine drin, wieder eine drin.
So ist das mit den Containerkomponenten halt auch. Wir haben die Möglichkeit,
Möglichkeit, da Dinge hinzuzufügen und dadurch Sachen zusammenzusetzen, grafische Elemente zusammenzusetzen.
Schauen wir uns an, wie das aussieht. Also zum Beispiel
, wir wollen so ein ganz einfaches Fenster machen.
Das hat irgendwie eine Überschrift, dass halt ein Titel für
eine Eingabe fällt und dann ein Text fällt und unten drei Bestätigungsfelder.
Die sind jetzt mal farbig markiert, damit wir besser sehen, was es ist.
Normalerweise werden die halt so in der Farbe des Betriebssystems gefärbt.
So, und das, wenn man das aufbauen möchte,
dann würde man zunächst erst mal, also zum Beispiel,
dass die grünen Dinger, die sind Buttons,
die würde man zusammenfassen zu einem Panel.
Und das ist schon mal
so ein Strukturierungselement
Ja, dieses Panel ist der erste Form von Container,
die wir jetzt hier sehen. Und die anderen Sachen hier oben,
also die zwei Labels und die zwei Eingabefelder, ja,
sind auch hier im NMPanel zusammengefasst, hier in dem gelben Panel.
Ja, also wir sehen hier Label, Textfeld, Label
, Textfeld. Ja, dass hier noch welche unbenannten,
welche Sorte von Panel das ist, das ist erstmal noch unerheblich.
Und das Ganze, da gehört noch ein Label dazu und
insgesamt wird das von einem Frame zusammengefasst.
Ja, also deswegen sehen wir auf diese Weise,
wie wir das gliedern können.
Und nun könnten wir hier unten das zum Beispiel
auch wieder verwenden,
wenn wir es mehrfach brauchen
Diese Container, wenn wir sagen, wir haben eine Hierarchie,
das ist also eine Baumstruktur, dann gibt es etwas,
was an der Spitze dieser Hierarchischen Struktur steht.
Ja, und das können wir dann durch die Fenster des Betriebssystems bilden. Ja,
also das Fenster des Betriebssystems wird das oberste Fenster haben,
wird im obersten Fenster zugeordnet und die Unterteilungen,
die werden dann von Java vom Java-System verwaltet.
Solche Top-Level-Container können Frame sein, das haben wir eben gesehen,
es könnte aber auch ein Dialog sein,
Option Pain oder Applet
Ja, ein J-Frame enthält ein Content-Pain. Content-Pain ist dann wieder so ein Container,
in dem die anderen Komponenten eingetragen werden können, zugeordnet werden können.
So, und jetzt schauen wir uns gleich mal an,
dass das Frame enthält ein Content-Pain, ja,
nimmt da Titelzeile und vielleicht noch Menüzeile,
die man noch hat, die vom Betriebssystem meistens gesteuert wird.
Also wir steuern, was da reinkommt als Programmierer,
aber das Betriebsteam stört die Erscheinung und ob es aktiv ist und so.
Und hier ist dann das Content-Pain, in dem dann wirklich
Inhalte angeordnet werden
Soweit erst mal zu dem, zu dem Aufbau der Container.
Aber wir wollen ja eigentlich daraus ein Werkzeug bauen.
Wir erinnern uns, die Werkzeugklasse und die UI-Klasse bilden zusammen
ein Werkzeug. Und dabei ist die Werkzeugklasse das,
was die Vermittlung macht mit Services, mit der Materialbearbeitung.
Und die UI-Klasse wird von dieser Werkzeugklasse erzeugt.
Die UI-Klasse braucht deswegen etwas, um das Ganze zu strukturieren.
Und deswegen Das Layout ist eigentlich die Anordnung, also die Anordnung zu steuern und verwalten.
Wenn Sie sich vielleicht fragen, eine Anordnung steuern,
was ich sage, das sind das und das dorthin.
Naja, ein bisschen komplizierter ist das schon noch.
Man kann ja das Fenster in der Größe anders haben,
entweder bei meinem kleineren Bildschirm hat oder wenn man es zusammengeschoben hat,
dann ist das mit der Anordnung, was wird gescrollt,
was wird einfach nur weggeschoben, unsichtbar.
Das ist schon noch erheblich. So, diese User-Interface-Klasse,
die dafür zuständig ist, das Erzeugen der Komponenten,
das Layouten und das Verwalten, was im Wesentlichen ansprechen ist,
das ist nicht für eine User-Interface-Framework lassen,
wie J. Frame and Panel abhängig,
sondern üblicherweise ist das in einem J. Frame definiert.
Aber erbt nicht davon. Es enthält die User-Interface-Elemente über Ghetter
. Und dann haben wir die Elementtypen,
wie sie ändern sich an das Bild mit dem Pfeil.
Die sind nicht davon abhängig und es ist intern
eine interne Klasse
Das schauen wir uns nochmal im Bild an. Also wir hatten hier
dieses Bild auf Folie 5, wo wir gesagt haben,
die User-Interface-Klasse ist Teil des Werkzeugs, sie ist eine interne Klasse.
Sie ist nur hier drin, sie ist nirgendwo anders ansprechbar.
So, und deswegen, Paket interne Klasse, Unabhängigkeiten zu anderen Teilen des Frameworks.
So, was wir bisher soweit wissen, nochmal Material enthält die Werkzeugklasse andersrum.
Die Werkzeugklasse erhält das Material beim Initialisieren, also über Konstruktor,
Parameter, ja, oder sie holt sie sich über Services.
Die Werkzeugklasse bekommt die Services auch bei der Initialisierung,
als Konstruktorparameter. Und wenn die Werkzeugklasse gebaut wird,
erzeugt sie sich ein Exemplar der User-Interface-Klasse mit eigenem Konstruktur.
Wir wissen ja jetzt, die User-Interface-Klasse ist eine interne Klasse.
Die ist von außen nicht sichtbar. Ja,
und diese User-Interface-Klasse, die kümmert sich um die GUI-Komponenten.
Das sind diese Elemente, die wir hier schon gesehen haben,
die Bausteine, erzeugt die euch bestimmt über das Layout,
um bestimmt über die Verwaltung zu weit.
Dazu erst mal. So, und jetzt ist noch mal,
möchte ich noch einen weiteren Aspekt reinbringen, den Begriff reaktive Systeme.
Ja, wenn wir, wir hatten schon vorher gesagt,
wir bauen ein interaktives System, das sind Systeme,
die mit den Menschen zusammenarbeiten, reaktiv bedeutet der Benutzer steuert und das Programm reagiert nur.
Es ist nicht so, dass das Programm die Störung hat.
So, wir kennen das zum Beispiel von Icons hier,
von einem Tablet oder von einem Smartphone, die Icons,
die warten im Prinzip darauf,
dass wir sie bedienen
Ja, und als Entwickler eines solchen Programmes,
was hinter dem Icon steht, wissen Sie nicht vorher,
in welcher Reihenfolge das benutzt wird.
Das Gleiche auf dem Smartphone, das Gleiche hier beim Windows
, mit diesen Kacheln. Reaktive Software,
ob den Begriff benutzen wir in einer Form,
dass wir sagt, der Kontrollschuss wird nicht vom Einwendungsentwickler gesteuert,
sondern von eben jemand anders.
Deswegen reaktiv, wir reagieren nur.
Hat für uns
zwei Vorteile
Dass wir uns, dass wir über die Events uns nicht kümmern müssen,
die Events werden zum Beispiel klicken, wischen, irgend so was.
Und es ist leichter, die grafische Nutzeroberfläche von der fachlichen Logik,
von der Applikationscode zu trennen. Das ist diese bessere Endbartbarkeit
. Ja, ein kleiner Nachteil hat sowas auch.
Es gibt immer Nachteile und der Nachteil ist jetzt hier,
dass wir die Gui-Bibliotheken kennen müssen, kennenlernen müssen. So,
und die grundlegende Idee sieht so aus,
dass wir also irgendwo Systemcode Diese Buttons und sowas auswertet,
ja, wenn so, wenn der Mensch ja draufklickt,
dann wird über das Betriebssystem ein Event erzeugt und über dieses Event wird mein eigener Code aufgerufen, gestartet.
Während die Inhalte eben, wenn irgendwo ein Feld ist,
das wird auch durch eigenen Code bereitgestellt.
Und durch das Frame oder sowas vom Betriebssystem verwaltet, gestartet,
aktualisiert, nach vorne geholt, größtleiden gemacht und so weiter.
Soweit dazu, wir machen gleich weiter mit Events,
denn diese, ich habe die eben schon erwähnt,
Was wir bei der interaktiven Bedienung als Menschen machen,
wir lösen Ereignisse aus.
Im Betriebssystem werden die als Ereignisse verwaltet. Beispiele, Mausbewegung
, Mausklegt, Tastentruck, Bildschirmberührung. Ich habe hier mal
ein paar Suggesten angebracht. Diese werden teilweise als recht komplexe
Events behandelt. In der Gui werden die natürlich verarbeitet.
Aber eigentlich in Zusammenarbeit mit dem Betriebssystem.
Es wird immer ein Ereignis erzeugt, so ein Event.
Und es gibt ganz einfache Dinge bis zu komplizierten.
Also gerade diese hier mit mehreren Fingern und dann irgendwie größer,
kleiner oder drehen. Das sind schon etwas kompliziertere Aktionen. So,
und dann gibt es noch richtig Dinge, die zusammengesetzt sind,
gleich richtig Aktionen werden, wie Button Prest oder sowas.
Und dass diese Informationen über Aktionen, die passiert sind,
wird per Ereignis an die Gui-Komponente geschickt.
Und zwar an die Gui-Kommunite, die sich angemeldet hat.
Damit wissen wir schon, aha, anmelden, das ist sowas mit Beobachtern.
Das ist sowas mit Subscribe, ja, ein Publish Subscribe.
Also dieses Prinzip hatten wir ja beim letzten Mal schon.
Weiter geht es in der nächsten Folie