Suite in Future?

[tuxedo]

Hallo zusammen,

aktuell ist die KONNEKTING Suite ja eine Java-basierte Desktop-Anwendung. Sie verwendet ein UI Framework (Java'ianer kennen das) namens Swing.
Swing ist von der Technologie her soweit ausgereift und stabil, aber auch tot. Tot weil: Es wird hier nicht mehr weiter entwickelt. Der "Nachfolger" nennt sich Java FX (https://openjfx.io/).

Da die KONNEKTING Suite ja noch die nächsten Jahre/Jahrzehnte laufen können soll, haben wir als den Grundlegenden Weg "Java" gewählt. Das garantiert uns zum einen eine kostenlose Entwicklung (die Sprache und die Tools kosten nichts) und auch einen gewissen Fortbestand (Java wird als Sprache nicht so schnell sterben, da unheimlich weit verbreitet).
Was mich aber bewegt ist das Thema Userinterface und der Tod von Swing.


Der aktuell anhaltende Hype heißt ganz klar "Webanwendung". Es gibt auch gute webbasierte Anwendungen die man "lokal" installieren und nutzen kann. Sie laufen dann eben im Browser (mein aktueller Favorit den ich auch benutze heißt PG-Admin4 (https://www.pgadmin.org/, ein Tool zur Postgres Datenbank-Administration).
Das Problem das ich hierbei sehe: Web-Technologie wandelt sich furchtbar schnell. Was heute noch gut läuft, wird im Browser von morgen schon nicht mehr korrekt angezeigt. Da auf dem laufenden zu bleiben braucht Zeit und Geduld und Ressourcen.

Wie seht ihr das? Seid ich ein Freund von Web-basierten Anwendungen und Tools? Oder seid ihr (wie ich zum großen Teil) "old-school" und bevorzugt eine stabile Desktop-Anwendung? Oder wird für euch das Thema "administrieren mit dem Tablet" auch immer wichtiger?

Ich will einfach eine kleine Momentaufnahme von euch wie ihr Software benutzt und was ihr für Ansprüche an eine Software wie die Suite habt: Muss es eine Desktop Anwendung sein, muss es auf einem Tablet laufen, ist Browser ein Thema für euch ..

Tobt euch aus und gebt mir einen Eindruck ...

Gruß
Alex

[ur63]

Aus den von Dir angeführten Gründen, und da es um eine Entwicklungsumgebung geht: Old School - stabile. nutzerfreundliche, "einfach" wartbare Desktop-Anwendung.

[Eugenius]

meine 2 cents:
Ich bin Fan von WEB-Anwendung. Mit ETS4 hatte ich damals das Problem, dass ich nicht unter Win10 laufen lassen konnte... nur als Beispiel.
Ja, mit Java sollte es nicht passieren. Aber wie du es selbst schreibst: Swing ist z.B. tot. Wo ist die Garantie, dass nach 2-3 Jahren das selbe nicht dem Java FX passiert und du evtl. keine neue Features mehr einbauen kannst, oder oder oder.
Nachteil von WEB-Anwendung wäre in Addition zu deinen Punkten: man braucht ja einen Server. Dabei ist es egal ob es HW (z.B. Raspi) oder SW Server ist -> extra Aufwand. Oder gibt es einfache SW-Server die man wie eine Anwendung starten kann? (ich kenne mich da leider nicht aus).

Ich würde wetten: Alle Konnekting User haben irgendein HW Server Zuhause wegen Visualisierung am laufen. 90% davon wären sogar wohl Linux-Basiert und freikonfigurierbar. Also Server wäre wohl doch kein Problem...

[jentz1986]

Hi! Ich bin persönlich kein Freund von Java und habe daher auch keinen besonderen Bezug zu der einen oder anderen UI-Framework-Technologie. Was mich gerade gedanklich umtreibt ist die Frage inwiefern sich Frontend und Backend trennen lassen. Ich habe mir die Suite im Code (noch) nicht angeschaut.

Ganz egal was jetzt kommt: Erstmal vielen Dank für Dein Engagement und die geleistete Arbeit, die sicher für viele Dinge eine geniale Grundlage ist.

Gedanken (völlig frei):

• Was wäre, wenn es einen Backend-Server gibt, der mittels einer Standardtechnologie angesprochen werden kann (REST, SOAP, ...) und die eigentliche Kommunikation von einem Objektmodell zur Hardware moderiert. Das Objektmodell wird dann per API angeboten und kann darüber angesteuert werden. Ich hoffe ich habe damit jetzt nicht nur einfach die bereits existierende Lib beschrieben.
• Frontend ist im Standard eine mature (manche sagen vllt altbackene) Anwendung, die die ganzen user-seitigen Dinge tut, kann ja Swing bleiben. Hier wird das wiedergegeben, was im Backend-Server angekommen ist.
• Server kann ja auch in der GUI im Hintergrund mitgestartet werden!
• Die API ermöglicht vielleicht auch Module, die Gerätespezifisch sind in einer anderen Sprache (Verantwortung des Geräteentwicklers!!), egal was das dann wieder für ein Frontend ist.
• Damit würde der Weg frei, die Logik des Backendservers vom "Komfort" des Frontends zu entkoppeln.

Anforderungen an das Frontend sind ja:

• Ich will mein Gerät konfigurieren inkl. der neuen Dateiupload-Schnittstelle, ...
• Ich will sehen, warum mein Gerät sich so und so verhält (Debugging auf der Konfigurationsebene)
• b) Ich bin Hardwareentwickler und will meine Gerätekonfigurationsdefinition weiterentwickeln

Mein Hintergrund: Ich habe Labormessgeräte für chemische Produktion mittels .Net-GUI und -Server an überlagerte Standardlogistiksysteme angebunden und Produktionslogistiksysteme mit WPF-GUI gebaut. Aktuell manage ich Cloudlösungen auf GCP und AWS aus Infrastruktur- und Securitygesichtspunkten. Zuhause hantiere ich viel mit Python (SHNG) rum und "fummele" ab und zu mit Arduino und fertigen libs was zusammen. Die Hardware von Masifi begeistert mich immer wieder (EnOcean-Gateway und 1-Wire-Gateway) ich würde hier gerne die Gerätesoftware mit weiterentwickeln, ohne mich "tief" in Java einzufuchsen. Hier hatte ich ja schon den Gedanken geäußert für diese modularen bzw. Interface-Geräte auch ein Modulkonzept für das Management zu ermöglichen. Das widerspricht natürlich den anderen Geräten, die einen klar statisch definierten Funktionsumfang haben (10 Relais bleiben 10 Relais). Ich weiß, was Softwareentwicklung bedeutet und das Anwender furchtbar ungeduldig sind. Ich möchte zur Lösung beitragen und unterstützen. Java hemmt mich persönlich dabei. Ich kann aber jeden versteht der dabei bleibt.

Nochmal: Lib+Suite: Klasse Arbeit, die ich auf keinen Fall kleinreden will!

[andi11]

Prinzipiell bin ich ein Fan von Web Anwendungen. Das kommt aber aus dem Job da ich mir so Themen wie Updatefunktionen usw. quasi sparen kann.
Wenn Webanwendung dann würde ich dass in meinem Fall auf dem Hausserver mit laufen lassen wollen (Linux System)

Für die Suite allerdings reicht mir eine einfache Oberfläche, die nicht optimiert sein muss für Tablet oder sonstwas. Aktuell kopier ich, wenn dann überhaupt Adressen aus meinem Excelsheet ,wo die ganze Elektrik geplant ist, rüber.
Was ich nicht beurteilen kann, was aber berücksichtigt sein sollte, wäre Konfiguration von Spezial Geräten wie KNX=>RX485 Koppler. Hier müssen ggf. auch mal viel mehr Konfiguration übertragen werden? Macht hier eine Plugin Schnittstelle sein?

Bei mir war es so, dass die einfache Suite einen ordentlichen Teil beigetragen hat, das ich vom Start weg Konnekting für das ganze Haus benutzen will. Bei der Inbetriebnahme war es sogar ganz praktisch, dass ich keinen Server gebraucht habe.



=> Ich rede mir sehr leicht, aber mein Fazit ist: Der Suite Ansatz und die Umsetzung sind bisher echt super so. Wenn es den Leidensdruck gibt an der Technologie was zu wechseln, dann wechseln. Aber ansonsten lassen.

[Ing-Dom]

ich finde ich diesem Fall die Desktop-Anwendung genau richtig. Und bzgl. des Alterns des UI Frameworks..

Ich kenne jetzt als Entwickler nur Microsoft, aber selbst heute kann ich noch mit C++ und MFC arbeiten, dabei gabs schon vor 15 Jahren .Net mit Windows.Forms.

Ich würde hier so lange mit "Swing" weitermachen bis es entweder gar nicht mehr geht oder es beim Pflegen soviel Schmerzen bereitet, dass man lieber doch einen Rewrite in Angriff nimmt.

[henfri]

Ich sehe es wie SirSydom.

[BlackDevil]

Webanwendungen sind mMn die Zukunft, das aktuelle Visual Studio ist ja quasi auch eine. Es kommt aber ein wenig auf die Anwendung an. Datenbankgetriebene oder Anwendungen in denen Kollaboration gefragt ist sind im Browser gut aufgehoben. Reine Single Client Anwendungen taugen auch als Desktop Anwendung.

[ChriD]

Ich sehe das grundsätzlich wie Jentz1986 & BlackDevil

Ich mach jetzt fast überall wo es auch nur ein wenig sinn macht 3tier bzw. server-client Applikationen.
Bei der Suite macht das eventuell dahingehend Sinn, dass man den DEV workload auf GUI und Backend aufteilen könnte.
Aber halt auch nur dann wenn sich Leute finden die aktiv mitarbeiten. Ansonsten sehe ich keinen Grund dazu. (auch wenn ich persönlich es besser finden würde)
Web GUI's sind halt fancy. Java GUI's halt eher mau. Aber in dem Fall der Suite gehts mir nur um die Funktion und Haptik.

"Web-Technologie wandelt sich furchtbar schnell. Was heute noch gut läuft, wird im Browser von morgen schon nicht mehr korrekt angezeigt."

Naja.. So arg empfinde ich das auch nicht. Wenn man die Standards einhält passt das schon und wenn man zum Beispiel Electron oder Konsorten verwendet hast du das Problem gar nicht.

Oder seid ihr (wie ich zum großen Teil) "old-school" und bevorzugt eine stabile Desktop-Anwendung?

Ob eine Anwendung stabil ist oder nicht hat jetzt aber mal nichts damit zu tun ob es ne Webanwendung ist oder eine Desktopanwendung ;-)
Ich bin mir ziemlich sicher das ich dir eine instabile Desktop-Anwendung bauen kann.


Und außerdem nochmal ein große Dankeschön an Dich für Deine Arbeit hier!!!!

[ChriD]

Ich kenne jetzt als Entwickler nur Microsoft, aber selbst heute kann ich noch mit C++ und MFC arbeiten, dabei gabs schon vor 15 Jahren

Naja wenn du mit C++ nichts mehr machen kannst würd Java auch bald nimma gehen. java ist in C++ geschrieben

[Ing-Dom]

Naja wenn du mit C++ nichts mehr machen kannst würd Java auch bald nimma gehen. java ist in C++ geschrieben

das bezog sich auch nicht auf C++ als Sprache, die ist quicklebendig! Sondern um das MFC Framework. Das ist seit ~ 2002 eigentlich durch .NET abgelöst, aber ich kann auch mit Visual Studio 2019 noch eine neue MFC Anwendung erstellen bzw. pflegen. Und die laufen auch einwandfrei auf dem aktuellsten Win 10.

[jentz1986]

Ich nutze auch eine Java Anwendung (neben Eclipse / Arduino): Hibiscus fürs Online-Banking. Das ist ein Plugin für eine SWT-basierte Applikation namens Jameica.
Vielleicht wäre eine solche Architektur auch für die Weiterentwicklung der Suite denkbar, oder ggf. sogar eine potentielle Grundlage?
https://www.willuhn.de/products/jameica/
Da ist dann auch ein Jetty im Bauch, wenn man das möchte; Siehe Webadmin: https://www.willuhn.de/products/jameica/extensions.php

SWT, bzw. Jameica würde natürlich einen kompletten Rewrite bedeuten, das ist auch zuviel.

Ich finde es persönlich gut, ohne das ich es selbst nutze, dass mittels Java eine Möglichkeit besteht, das Tool auf Windows, Mac und Linux zu nutzen. Das sollte nicht verschwinden.

Und noch was: Das "geile" an Konnekting ist nicht die Grafik auf dem PC, sondern die Kommunikationsplattform von, zum und mit dem "eigenen" KNX Gerät, konkreter als mit Calimero alleine.

[tuxedo]

Erstmal Danke für die vielen und vor allem aus ausführlichen Antworten.

KONNEKTING ist auf PC-Seite (wie fast alles bei KONNEKTING) modular aufgebaut:

Es gibt ein Projekt/Library das sich mit dem XML-Thema befasst: KONNEKTING XML Schema: Wie komme ich von meiner kdevice.xml oder kconfig.xml zu einem Java-Objekt-Baum um bequem damit zu arbeiten.
Es gibt ein Projekt/Library das sich der ganzen Konfiguration annimmt: KONNEKTING DeviceConfig: Einlesen der XML Files, bereitstellen der notwendigen Klassen/Interfaces um die Programmierung/Parametrisierung anzustoßen, die ganze Config zu speichern und wieder in XML zu gießen. Quasi "KONNEKTING Suite in Library-Form".
Und dann, on-top, gibt es die Suite selbst, welche KONNEKTING DeviceConfig benutzt.

Im Prinzip steckt also die ganze "Business-Logik" nicht in der Suite, sondern in KONNEKTING DeviceConfig. Damit ist UI und Logik weitestgehend sauber voneinander getrennt.

Es wäre kein Problem auf DeviceConfig eine REST Schnittstelle drauf zu legen. Damit ließe sich dann ein beliebiges UI bauen.

Jetzt noch mal ein wenig zum UI Thema an sich:

"Web-Technologie wandelt sich furchtbar schnell. Was heute noch gut läuft, wird im Browser von morgen schon nicht mehr korrekt angezeigt."


Naja.. So arg empfinde ich das auch nicht. Wenn man die Standards einhält passt das schon und wenn man zum Beispiel Electron oder Konsorten verwendet hast du das Problem gar nicht.

Naja, schau mal wie alt Electron ist. Bei der heutigen Schnelllebigkeit von Webtechnologie und Frameworks kann es sein, dass Electron morgen tot ist, die Browser sich weiter entwickeln und die Anwendung übermorgen nicht mehr läuft.

Ob eine Anwendung stabil ist oder nicht hat jetzt aber mal nichts damit zu tun ob es ne Webanwendung ist oder eine Desktopanwendung ;-)

Das "stabil" bezieht sich nicht unbedingt auf die Anwendung selbst, sondern auf das "drum herum". Eine Desktop-Anwendung die für sich stabil ist, läuft solange stabil, bis das Betriebssystem sie nicht mehr ausführen kann weil X-Generationen zwischen liegen.
Eine Webanwendung wird dann instabil, wenn der Browser anfängt zu zicken. Sei es weil irgendwas im Javascript nun nicht mehr unterstützt wird, oder weil der User einen Browser benutzt der ein Feature nicht nicht unterstützt. Klar, Frameworks helfen da, sind aber keine 100,0% Garantie.
Was ich damit sagen wollte: Eine Desktop-Anwendung wird erfahrungsgemäß ohne Zutun länger lauffähig sein als eine Webanwendung.

Auf der einen Seite gefallen mir die Vorteile einer Webanwendung:

* Man kann es so ausrichten dass es auch auf dem Tablet läuft
* Man muss lokal nichts installieren. Browser auf, läuft.

Auf der anderen Seite wird das System auch komplexer:
Mit der aktuellen Suite brauchst du nix, außer eine ZIP-File und einen Rechner. Auspacken, starten, läuft. Wenn was nicht geht: Log-File einsenden, fertig. An und für sich ziemlich straightforward.
Mit der Webanwendung muss ich irgendwo eine Serversoftware laufen lassen. Ggf. muss ich die Adresse im Browser kennen um drauf zuzugreifen. Eine Firewall kann hier nochmal zusätzlich Probleme machen. Fehler sind dann entweder im Serverbackend ODER im Browser (Entwicklerkonsole...) ODER irgendwo dazwischen zu suchen.

Die Fallstricke für den User sind bei Webanwendungen sicherlich vielfältiger. Und Fehler sind aufgrund der zunehmenden Komplexität des Setups auch schwieriger zu finden, nachzustellen und zu analysieren.

Auch wenn ich die Vorteile trotzdem toll finde, ich glaube für's erste bleibt die Suite wie sie ist:

Ich werde Beta5 nach wie vor mit Swing ausliefern. Auch wenn Swing "tot" ist und nicht mehr weiterentwickelt wird: Swing ist unabhängig. Es rendert aufgrund seiner "Leichtgewichtigkeit" in jedem Java-unterstütztem OS und ist weitgehend unabhängig von der Weiterentwcklung des OS.

SWT wäre definitiv schwergewichtig, da es auf native UI-Elemente des OS aufbaut. Hab in der Vergangenheit da schon viel erlebt. Vor allem viel negatives. SWT ist für mich definitiv raus.

JavaFX ist ähnlich wie Swing. Das schlimmste was hier passieren kann ist, dass es nicht mehr weiter entwickelt wird (also wie bei Swing), was aber nicht heißt dass man es nicht mehr benutzen kann.
Die Umstellung auf JavaFX wäre ein großer Schritt. Aber theoretisch wird der resultierende Code "wartbarer" als der von Swing.


Was noch einen Schritt weiter gehen würde, wären Frameworks wie Jameica (was aber wegen SWT eher raus ist), Eclipse RCP (was aber auch SWT benutzt ...) oder soetwas wie die Netbeans Platform. Ich hab mir vor vielen Jahren ein Netbeans Platform 7 Buch gekauft. Aber irgendwie war die Not nie ausreichend groß mich damit wirklich zu befassen. Weshalb ich immer Swing-Anwendungen gebaut habe.



Also halten wir fest:

* Beta5 und Version 1.0.0 bleiben erstmal bei Swing
* Es wird eine Plugin-Schnittstelle geben, mit der man einfache Dinge einfach nachrüsten kann.
* Ggf. folgt ein Update auf JavaFX
* Dank der Modularität ließe sich z.B. eine REST Schnittstelle auf das "backend" setzen um dann Dinge im Browser anzubieten.

Vielleicht drehen wir den Spieß um und ich frage einfach mal in die Runde: Was für Use-Cases falln euch ein, in denen eine Webanwendung in Verbindung mit KONNEKTING wirklich hilfreich wäre und wo eine leichtgewichtige Desktop-Anwendung eher hinderlich wäre?


Gruß
Alex

[tuxedo]

Ich hab gerade ein wenig gegoogelt. Bei JavaFX hat sich die letzten Jahre wohl doch so einiges getan:

Anscheinend lassen sich JavaFX basierte Anwendungen auch als Mobile-Apps compilieren: https://youtu.be/GU-z9JlydKc?t=1654
Werde das weiter beobachten. Erstmal Beta5 und 1.0.0 releasen, dann sehen wir weiter...

[jentz1986]

Use-Cases fallen euch ein, in denen eine Webanwendung in Verbindung mit KONNEKTING wirklich hilfreich wäre und wo eine leichtgewichtige Desktop-Anwendung eher hinderlich wäre?

Mir: Keine, so lange die Anwendung so leichtgewichtig bleibt, wie sie ist!

* Es wird eine Plugin-Schnittstelle geben, mit der man einfache Dinge einfach nachrüsten kann.
(...)
* Dank der Modularität ließe sich z.B. eine REST Schnittstelle auf das "backend" setzen um dann Dinge im Browser anzubieten.

Klasse! Weiter so!