JAVA & Objektorientiertes Programmieren 2

Diese Methode liest alle Zeilen einer Datei und gibt sie auf der Konsole aus (Zeichen-Datenströme)

(siehe Bild)

(siehe Bild)

Bei plattformübergreifendem Einsatz kommt es damit aber zwangsläufig zu Encoding-Problemen! z.B. Schreiben mit Linux, Einlesen mit Windows 10! 

Darum verwenden wir für Quellcode auch immer UTF-8

Eine Zuordnung, welche Zahlenwerte (bytes) welches Zeichen repräsentieren sollen.
Beispiele:

- 01100001₂ = 61₁₆ = 97₁₀: Dieser Zahlenwert den Kleinbuchstaben "a" (ASCII 7bit)
- ü, ö, ä sind Sonderzeichen in Extended ASCI 8bit

(siehe Bild)

Write once, run anywhere:

Ohne Neukompilierung ist das Programm auf verschiedenen Betriebssystemen direkt lauffähig

- Dateisysteme mit unterschiedlichen Attributen
- Pfaddarstellung und Laufwerke (C:\ temp vs. /tmp)
- Unterschiedliche Byteorder (Little-Endian vs. Big-Endian)
- Zeilenumbrüche: CR+LF vs. LF+CR cs LF
- Zeichensätze/Encodings: ISO-8859-1, cp1252, UTF-8,...

Die Klasse java.io.File (hat nicht direkt mit Ein- und Ausgabe von Streams zu tun)

- File stellt plattformunabhängige BS-Funktionen im Zusammenhang mit Dateien und Verzeichnissen bereit
- Oft muss man aber auch plattformspezifische Unterschiede berücksichtigen, z.B. unterschiedliche Path-Separatoren: ; versus :

Byte-Datenströme: Effizient und kompakt, aber binär.
Zeichen-Datenströme: Für Menschen lesbar.

Bei Zeichen-Datenströme das Encoding beachten. Bei Multi-Plattform-Anwendungen sollte unbedingt ein explizites Encoding eingesetzt werden.

Sauberes Exceptionhandling ist speziell bei I/0-Streams wichtig.

Sie haben einen Zustand und ein Verhalten, lassen sich sehr gut wiederverwenden

- Frame/Window
- Label
- TextField
- Button
- List
- Checkbox
- Radiobutton
- Slider

Container können eine beliebige Anzahl Komponente enthalten (Composite Pattern, GoF)

- Window (Frame) - die Grundfläche einer GUI-Applikation
- Panels - eine (nicht zwingend visuelle) Hilfsfläche zur Zusammenfassung von Einzelkomponenten

(siehe Bild)

Reduziertes Diagramm, zur Illustration der hierarchischen Beziehungen.

(siehe Bild)

Composite-Pattern (Kompositum) nach GoF:
Ein Container kann Komponenten oder aber wiederum Container enthalten.

Konzept der Layouts mit Constraints

Man beschreibt die Anordnung der einzelnen Elemente durch die Organisation mittels sogenannter Layouts

(siehe Bild)

- Die verschiedenen Layout-Manager werden häufig mit- und ineinander (hierarchisch) verknüpft.
- Können mit Bedingungen (Constraints) konfiguriert werden, welche Abstände und Ränder für und um Komponenten festlegen.
- Jedes Element hat eine minimale, optimale und maximale Grösse, abhängig von verwendeten Schriften und Auflösungen.
- Die Elemente organisieren sich innerhalb des Layouts selber und adaptieren ihre Grösse bei einem Resize (Grössenveränderung z.B. eines Dialoges/Fensters)
- Herausforderung: Benötigt einiges an Planung und Erfahrung!
- Kein schnelles «pinseln» von Dialogen!

Sequenzielle Aneinanderreihung von einzelnen Anweisungen (Start und Ende in der main()-Methode)

Laufen in einer vorgesehen Abfolge dennoch immer genau gleich der Reihe nach ab.
Entspricht häufig dem klassischen EVA-Prinzip (Eingabe, Verarbeitung und Ausgabe)

Sehr typische Technik für GUI-Programmierung
- Die meiste Zeit wartet das Programm
- Erst wenn ein Ereignis (Event) eintritt, geschieht etwas (Tastenklick, Maus, Touch, etc)
- Ereignis löst dann eine (vor-)bestimmte Aktion aus

Dem Auslöser einer Aktion und der Aktion selbst

Ein populärer (GUI-)Event in Java, der für unmittelbare Aktionen wie z.B. das Drücken eines Buttons genutzt wird:
- Event-Quelle: z.B. Button-Objekt
- Event Click: ActionEvent-Objekt wird gefeuert
- Event-Verarbeitung: Beliebiges Objekt, welches das ActionListener-Interface implementiert hat, und in der Methode actionPerformed(...) auf Ereignis reagieren kann

Mit MVC (Model-View-Control)
- Model: eigentliche Datenobjekte, z.B. Person
- View: GUI-Komp. welche Daten anzeigt
- Control: Steuerung, welche das Ganze koordiniert

- Model: ist völlig unabhängig und wird nur verwendet
- View: verschiedene Varianten für dasselbe Model möglich
- Control: Verbindet Modell und View, steuert und koordiniert

Model, View, Presenter (GUI-Konzept)
- Model: völlig unabhängig und wird nur verwendet
- View: verschiedene Varianten für dasselbe Model möglich
- Presenter: Vermittelt zwischen Modell und View

- AWT (Seit Java 1.0)
- Swing (Seit Java 1.2), Weiterentwicklung eingestellt, aber grösste Verbreitung
- JavaFX (Seit 1.8), Entwicklung seit 2008, modernstes Framework

Abstract Window Toolkit, wrapped die nativen GUI-Komponenten des jeweiligen BS!
- dadurch schlank, einfach und effizient
- Look&Feel entspricht voll der Zielplattform

Hauptproblem: Weil Java-Programme auf allen Plattformen laufen müssen, wird nur die kleinste gemeinsame Menge der auf allen Plattformen verfügbaren GUI-Komponenten unterstützt!

- Eingeschränkte Möglichkeiten
- auf einzeln. Plattformen fehlen evtl. für typische essentielle Komponenten

Java implementiert für Swing ein eigenes Set von umfangreichen leichtgewichtigen GUI-Komponenten. Quasi eine eigene Oberfläche mit eigenem Look&Feel
- Java-Applikationen sahen nun auf allen Plattformen identisch aus

Implementiert wie Swing eigenständige Komponenten, wurden aber stark erweitert und die API ist mehr "Nutzergetrieben"
- Vereinfachtes, stark modernisiertes Programmiermodell (Stage und Scenes)
- Möglichkeit GUIs per FXML zu definieren
- Möglichkeit Darstellung mittels Stylesheets (CSS) anzupassen (ohne Codeänderung oder Neukompilierung)

Weil es den Aufbau eines GUIs deutlich mehr abstrahiert, vereinfacht und automatisiert!

- Stage ist eine Analogie zum Frame (Window)
- Scene ist eine Analogie zum (Root-)Panel (Content)
- Node ist eine Basisklasse für alle GUI-Elemente / Komponenten
- Scene Graph ist eine logische hierarchische Datenstruktur welche alle Nodes enthält

Es erlaubt (mit JavaFX) das Design der Visualisierung (GUI) vollständig von der eigentlichen Programmierung zu trennen

FXML ist eine auf XML basierende Definition für User-Interfaces