Auf dieser Seite:

Auf eigenen Unterseiten:

Architekturbasis

Java

JDK11 oder höher (wir versuchen aber von Anfang an alles auf die neueren Konzepte - insbes. Modularisierung - anzupassen).

CommunityMashup

Über MashupConnector wird DataSet geladen (in Klasse org.soziotech.cmf3.CommunityMirror)

In den View-Klassen werden dann über das DataSet-Objekt InformationObject-Objekte geladen (konkret Objekte der Klassen Person, Organisation und Content); zusätzlich wird in den View-Klassen (konfigurierbar) ein DataSetChangeObserver instantiiert (TBD: Wie bekommen VisualItems von Änderungen mit?)

Zu klären/dokumentieren:

  • Wie genau werden Medienobjekte (insbes. Images) aus dem Mashup geladen / gecached etc. - Hier gibt es vermutlich noch das ein oder andere Speicherleck

Siehe hierzu auch CommunityMashup

Grafik/Touch: JavaFX

JavaFX 11 - https://openjfx.io

Siehe auch JavaFX für CMF 3.0

Sonstige Bibliotheken

Apache commons-configuration2

  • Zur Konfiguration des CommunityMirror - wie bisher
  • Konfigurationsdateien
    • Defaults in mehreren Dateien unter resources/META-INF/configuration
    • Überschreiben durch eine Datei, deren Name beim Start angegeben wird (normalerweise unter resources, aber auch anderswo)
    • Überschreiben durch Umgebungsvariablen (Eclipse Run Configuration, -D beim direkten Start) 

SLF4J und Logback

  • nur noch für Debug-Logging
  • das Event-Logging für Evaluation und Dashboards wird über ein eigenes Evaluationsframework abgewickelt (siehe dazu separater Punkt unten)

Eigentliches CMF

Allgemeines

  • Views - Vollbildschirmdarstellungen von visuellen Objekten und Interaktionsmöglichkeiten
    • beinhalten
      • Objekte (VisualItems), die Informationspartikel aus CommunityMashup darstellen
      • Objekte (VisualComponents oder davon vererbt) ohne Verbindung zum Mashup
    • liest Konfiguration und generiert passende Objekte daraus (Nicht-Informations-Objekte aber bei Bedarf auch Informationsobjekte)
    • holt Informationspartikel vom Mashup und generiert Objekte daraus - konfigurierbar (neu)
    • Objekte sind organisiert in mehreren Gruppen von VisualComponents (organisiert in VisualGroups) - von denen jeweils eine Gruppe die andere überdeckt (Vordergrund/Hintergrund-Beziehung) - innerhalb einer VisualGroup gibt es keine klar definierten Vordergrund/Hintergrund-Beziehungen
    • Erst mal nur FlowView (wie bisher) - Später weitere Views, zwischen denen umgeschaltet werden kann
  • VisualItems
    • sozusagen "VisualInformationObjects" - Visualisierung gekoppelt an ein InformationObjekt aus dem CommunityMashup
      • Klassen für Person, Organisation, Content und Unterkategorien von Content - konkret erst mal: EventItem, PictureItem, LongMessageItem (BlogPost, News), ShortMessageItem (Microblog)
    • in Bewegung (Animation - eigentlich nur gleichmäßige Bewegung in verschiedene Richtungen), an fester Position
    • verschiebbar, nicht verschiebbar
    • vergrößerbar, nicht vergrößerbar
    • Darstellungsmodi: inMicro (normal, in FlowView), inDetail (Detailansicht), inTeaser ("Plakat")
    • Definition über FXML und CSS
  • VisualComponents
    • in Bewegung, an fester Position
    • VisualItems sind von VisualComponents abgeleitet
    • Drawing wird über eigene Klasse realisiert, hier auch User/Interaction-Logging-Methoden und Interaktion
    • Definition von Aktionen, die bei Klick/Touch ausgelöst werden (Öffnen anderer Objekte, Schließen des aktuellen Objektes, ...)
    • Beispiele: Wetteraussichten, Busabfahrtszeiten, Speiseplan, Video-Fenster in andere Räume, Buttons, ....
  • Generell
  • CommunityInteractionFramework - wird gestrichen - Event-Handling direkt in VisualComponents - basierend auf JavaFX/TUIOFX-Events
  • Explizite Berücksichtigung Distributed Display Environment (DDE), also mehrere an unterschiedlichen Orten aufgestellte Displays mit ggf. identischer Datenbasis
    • Filterung von zu ladenden/priorisierenden InformationObjects konfigurierbar (To-be-Specified) 
  • Remote Management Schnittstelle (z.B. aktueller Screendump etc) - für Management-Cockpits / Dashboards
  • Laufender Export von Log-Daten für Management / Evaluation (Benutzer/Interaktions-Logging)
    • über Interface
    • Abspeicherung in Log-Datei möglich
    • direkte Abspeicherung in zentrale Datenbank möglich
    • "Sensoren" in View, VisualInformationObjects, VisualComponents
    • jedes Objekt/Component hat dazu eindeutige (konfigurierbare) ID
    • rudimentäres Auswertungstool enthalten; zusätzliche Nutzung / Auswertung der Daten in Dashboard / Cockpit-Implementierungen
    • Distrubuted Logging Unterstützung (zentralisiertes Logging mehrerer Deployments mit verschiedenen Großbildschirmen sowie ggf. unterschiedlichen Mashup-Datensätzen)
    • Framing: Möglichkeit zur (teilautomatisierte) Definition von "Interaktionsslots" inkl. Kommentarfunktion, z.B. InfoPartikel wird angezeigt, Nutzer bleibt davor stehen, interagiert aber nicht, Offline-Erfassung des Grundes durch Ex-Post-Befragung und Eintrag in Kommentarfeld durch "Beobachter".
    • Einbindung Kinect als weiterem "Sensor" für datenschutztechnisch unbedenkliches teilanonymisiertes Nutzertracking; TBD: Library dafür, vgl. auch Kinect-Logging nach Jan Schwarzer oder anderer Ansatz, z.B. http://www.tutego.de/blog/javainsel/2015/04/xbox-360-kinect-unter-java-ansprechen/
    • mehr Details auf separater Architektur/Konzeptseite: Logging-/Evaluationsframework

Noch unklar

  • Graph ... was nehmen wir zum Browsen ... eventuell bisher genutztes Framework weiterverwenden / oder woanders entwickeltes / gepflegtes Framework (2D-Physik-Engine ...) nutzen

Dokumentation

Package/Klassen-Struktur

  • org.sociotech.cmf3.
    • CommunityMirror.java - Basisklasse
    • .view.*
      • View.java
    • .components.* - VisualComponents
      • VisualComponent.java
      • VisualItem.java
    • .view.flow.
      • FlowView.java
      • .components
        • FlowVisualItem.java
    • .context - ContextManager und andere Komponenten zur Verwaltung von Information zur lokalen Instanz des CM
    • .configuration
    • .logging - User/Interaction-Logging
    • .remote - Remote Management Funktionalität

Ableitungsstruktur der zentralen VisualComponent und VisualItem-Klassen:

Wie und wo werden VisualComponent-Objekte erzeugt:

  • FlowView.onInit()
  • - javafx.scene.Group-Objekte für die verschiedenen Ebenen
  • - addStickyVisualComponents() - Objekte nach Konfiguration, erzeugt/eingefügt über addVisualComponentToView(classname, posX, posY, scaleX, scaleY, layer, aname);

Handhabung der Interaktion:

  • "ganz normal" mit JavaFX-Mitteln - d.h. es könnten mit den Funktionen von JavaFX.scene.Node wie z.B. setOnTouchMoved Event-Handler registriert werden
  • Einfacher:
    • VisualComponent.makeTouchable
    • VisualComponent.makeDragable
    • dadurch Registrierung von Event-Handlern, die dann Methoden handleMouseEvent(), handleTouchEvent() in der Klasse aufrufen (können überladen werden)

Programmstart

Ablauf beim Programmstart

  • org.sociotech.cmf3.CommunityMirror.main()
  • - doStaticInitialization()
  • — loadConfiguration()
  • --  Initialize RemoteManager (if mirror.remote.enable = true)
  • - Application.launch(args); — damit wird JavaFX gestartet und es geht weiter mit
  • org.sociotech.cmf3.CommunityMirror.start()
  • - connectToCommunityMashup()
  • - manageScreenSetup()
  • - createMainView()
  • — new main view class: org.sociotech.cmf3.view.TestView
  • — view.init() -> onInit() in der View-Klasse

FlowView

  • in onInit():
  • ...

Alles weitere erfolgt ereignisbasiert …

In der Basisklasse CommunityMirror wird Mittels eines JavaFX TimelineBuilders ein JavaFX Timeline-Objekte erzeugt und dann .play() darauf aufgerufen. Die handle()-Funktion ruft dann auf allen Controller-Objekten und View-Objekten die Funktion update() auf, welche wiederum die Funktion onUpdate() aufruft.

Benötigte Bibliotheken

.. sind im Eclipse-Projekt (mit allen Abhängigkeiten) direkt enthalten.

Folgende Bibliotheken werden benötigt: (und sind im modulepath enthalten und in module-info.java angegeben)

  • commons-configuration2 2.4
    • commons-logging 1.2
    • commons-beanutils
    • commons-text-1.6.jar
    • commons-lang3-3.8.1.jar
  • logback-core 1.3.0
  • logback-classic 1.3.0
  • slf4j-api 1.8.0-beta4
  • json-20160810

CommunityMashup ...

Für das CommunityMashup werden folgende drei Bibliotheken benötigt: (ebenso im modulepath enthalten)

  • org.sociotech.communitymashup.core.jar
  • org.sociotech.communitymashup.data.DataObservers.jar
  • org.sociotech.communitymashup.framework.CommunityMashupApplicationFramework.jar

Ausserdem werden von diesen Bibliotheken (teilweise erst zur Laufzeit) weitere Klassen / Bibliotheken nachgeladen (diese sind größtenteils im classpath enthalten):

  • httpclient-4.2.2
  • httpcore-4.2.2
  • org.eclipse.emf.common-2.9.2
  • org.eclipse.emf.ecore-2.9.2
  • org.eclipse.emf.ecore.xmi-2.9.1
  • Common-1.0.0
  • Lpg.runtime.java-2.0.17
  • Org.eclipse.core.contenttype-3.7.300
  • Org.eclipse.core.jobs-3.10.300
  • Org.eclipse.core.runtime-3.15.200
  • Org.eclipse.emf.query-1.2.100
  • Org.eclipse.equinox.app-1.4.100
  • Org.eclipse.equinox.common-3.10.300
  • Org.eclipse.equinox.preferences-3.7.300
  • Org.eclipse.equinox.registry-3.8.300
  • Org.eclipse.ocl-3.2.1
  • Org.eclipse.ocl.ecore-3.2.ß
  • Org.eclipse.osgi-3.13.300

Todos

  • Testen von TouchEvents auf geeigneter Hardware
  • StickyComponents wieder einbauen (Weather, Bus)
  • Bei Sticky Components noch mehr auf FXML bauen
  • VisualItems: FXML-Rendering weiter machen
  • SelectionStrategyDefault weiter implementieren (aktuell wird nur nach metatag selektiert)
  • Laden VisualItems basierend auf Context (Location etc.) - Regeln in Konfiguration einstellbar
  • Log-Framework/Factory etc erstellen um Log-Meldungen an konfigurierbare Quelle abzusetzen
  • Möglichkeit zum Anmelden/Abmelden von Benutzern über Remote-Schnittstelle einbauen; Benutzer dann als Teil des Kontextes verfügbar
  • Build-Prozess: Klären, wie man mit JDK 11 und JavaFX 11 in Eclipse ein "Fat-JAR" erzeugen kann - also ein JAR, das alles enthält, was man zum Starten der CommunityMirror-App braucht - insbesondere die JavaFX-Bibliotheken/Modul - siehe z.B. http://rimdiary.com/javafx-on-jdk-11/ für einige Hinweise, wie das gehen könnte ...
  • Check in wie weit JavaFX Multi-Touch und Multi-Displays (neue Hardware) unterstützt; dabei insbesondere: wie funktioniert Screen-übergreifendes Multi-User-Multi-Touch bei einem Großbildschirm bestehend aus einer Display-Matrix (mehrere Einzeldisplays)
  • Check 2D-Physik-Engines für JavaFX, z.B. Phys2D vgl. dazu u.a. auch https://books.google.de/books?id=D0Ml8WugPm8C&lpg=PA114&ots=BiHa9fhaCX&dq=Phys2D%20javafx&hl=de&pg=PA114#v=onepage&q=Phys2D%20javafx&f=false
  • Check Behandlung von Image-Objekten in Mashup und das Durchreichen zu JavaFX
  • Check Logging-Framework für Java, ggf. SL4J + Logging-Server? Vgl. z.B. https://stackify.com/slf4j-java/ oder https://tech.europace.de/eine-migration-auf-slf4j-und-logback-lohnt-sich/
  • Keine Stichwörter