MDE / Windows CE / WebFrameWork: Delphi Anwendung im Web / extpascal

[Furtbichler]

Ich habe eine Billiganwendung VT-100 geschrieben und auf dem Symbol (MDE) eine Terminalemulater installiert. Sehr einfach, sehr billig. Läuft. Also eigentlich hatte ich das VT-100 Teil schon vorher und keine Lust, etwas auf dem MDE umzusetzen (keine Ahnung gehabt, damals).

Danach habe ich eine kleine ASP.NET Anwendung für das Teil geschrieben und auf dem Symbol den Browser gestartet. Genausogut, allerdings musste ich eine mini C#-Anwendung schreiben, die aus nichts anderem als dem Browser bestand, weil.. ich glaube, damit sich die Verbindung immer wieder neu aufgebaut wird, wenn es mal mit der VErbindung nicht klappte und der Browser sonst ne Meldung ausgespuckt hätte.

Und das war zu einem Zeitpunkt, als ich auch noch exklusiv und nur Delphi-Anwendungen gemacht habe.

Eine dritter Versuch bestand aus einem selbstgeschriebenen TCP-Server in Delphi, einem blöden Übertragungsprotokoll und ein paar Screens/Formularen in C# für WinCE. Das Protokoll bestand eigentlich nur darin, die Screens zu aktivieren und zu parametrieren und dann die Eingaben der Screens wieder zurückzuschicken. So konnte ich einen einfachen Dialog dynamisch zusammenstellen.

Das hatte mich jeweils maximal ne Woche gekostet.

Was ich damit sagen will: Nehmt einfach das naheliegende, traut euch an C# ran. Alles ist einfacher, als umständlich Pascal auf so einem Teil zum Laufen zu kriegen. Denke ich.

[dunningkruger]

Zitat von Furtbichler:

Ich habe eine Billiganwendung VT-100 geschrieben und auf dem Symbol (MDE) eine Terminalemulater installiert. Sehr einfach, sehr billig. Läuft. Also eigentlich hatte ich das VT-100 Teil schon vorher und keine Lust, etwas auf dem MDE umzusetzen (keine Ahnung gehabt, damals).

Danach habe ich eine kleine ASP.NET Anwendung für das Teil geschrieben und auf dem Symbol den Browser gestartet. Genausogut, allerdings musste ich eine mini C#-Anwendung schreiben, die aus nichts anderem als dem Browser bestand, weil.. ich glaube, damit sich die Verbindung immer wieder neu aufgebaut wird, wenn es mal mit der VErbindung nicht klappte und der Browser sonst ne Meldung ausgespuckt hätte.

Und das war zu einem Zeitpunkt, als ich auch noch exklusiv und nur Delphi-Anwendungen gemacht habe.

Eine dritter Versuch bestand aus einem selbstgeschriebenen TCP-Server in Delphi, einem blöden Übertragungsprotokoll und ein paar Screens/Formularen in C# für WinCE. Das Protokoll bestand eigentlich nur darin, die Screens zu aktivieren und zu parametrieren und dann die Eingaben der Screens wieder zurückzuschicken. So konnte ich einen einfachen Dialog dynamisch zusammenstellen.

Das hatte mich jeweils maximal ne Woche gekostet.

Was ich damit sagen will: Nehmt einfach das naheliegende, traut euch an C# ran. Alles ist einfacher, als umständlich Pascal auf so einem Teil zum Laufen zu kriegen. Denke ich.

Lobpreiset dem Herrn Furtbichler, denn seine Gnade überschüttet uns mit Informationen über des Herren SagIchNichtWeilIchTollBin.

Vielen Dank mit Fu0kuss/Käsesockenlutschen!

[DSCHUCH]

ich sag mal - no comment... ^^
ich habe mir jetzt nochmal 2 stunden intraweb angeschaut und bissl rumgetestet, für einfach click bum websites, so wie wir es eigentlich brauchen (der anwender soll nur 2 knöpfe haben - der rest ergibt sich aus dem ablaufplan und sonstiger logik) scheint intraweb ausreichend zu sein, funktioniert auch ganz gut : einfache tabellen, edit, loginform.

schönes bsp-video gibt es hier auch:
http://www.youtube.com/watch?v=Tg_J3huoazE

elegant finde ich gerade

* Weiterverwendung deer Buisinesslogik, alles nichtvisuelle kann einfach eingebunden werden.
* Auslieferung einer einfachen Exe, welche selbst den Webserver integriert, damit muß eigentlich garnichts im netzwerk gemacht werden, ausser die firewall einrichten.

[DSCHUCH]

und hier habe ich gerade noch ein video gefunden, was man machen muß damit das ganze nicht ausschaut, wie ein "müllhaufen". hier wird das jquery layout für mobile mit vcl for the web kombiniert.
http://www.youtube.com/watch?v=75DnldrcJNU

[Furtbichler]

Zitat von dunningkruger:

Lobpreiset dem Herrn Furtbichler, denn seine Gnade überschüttet uns mit Informationen über des Herren SagIchNichtWeilIchTollBin.

Vielen Dank mit Fu0kuss/Käsesockenlutschen!

Suchst Du Anschluß? Oder bist Du nur neidisch?

Was ich damit ausdrücken wollte, das es viele Möglichkeiten gibt und das die Möglichkeiten, die ich aufgezählt habe, funktionieren. Wenn ich protzen wollen würde, dann bestimmt nicht mit diesen teilweise doch sehr hemdsärmeligen Lösungen von mir.

Ist die Hardware geeignet, HTML5/JQuery Apps auszuführen?

[DSCHUCH]

Zitat von Furtbichler:

Ist die Hardware geeignet, HTML5/JQuery Apps auszuführen?

das müssen wir testen. ob man das nun mit jquery umsetzt, sei jetzt einmal dahingestellt, es war aber ein bsp-video wie das sonst vom design her müllisch aussehende VCL For the Web modern ausschaut.

letztendlich können wir unseren Kunden die Hardware vorschreiben (bzw. die Anforderungen), insb. da die Software mit diesen Methoden nur ein bruchteil kostet. Welche MDE da jetzt geeignet sind werden wir testen müssen.

Hast Du schonmal MDE Entwicklung betrieben? Durch die millionen Geräte Varianten kommt für uns nur eine Lösung in Frage, welche absolut plattformunabhängig ist. Das ist von uns immer eine Speziallösung, die vielleicht 20 mal pro Jahr installiert wird. Beim nächsten Setup gibt es evtl bereits wieder neue Geräte oder der Ablauf beim Kunden ist anders, so dass sowieso alles angepasst werden muß. idR haben unsere Kunden zwar große Netzwerke, aber wiederrum keinen der sowas gern Administriert, bzw wir sind es nicht, daher ist webserver aufsetzen auch wieder so ein Ding (es geht was im Firmennetzwerk nicht => das liegt an der neuen Software, die haben etwas auf dem Server installiert.... blabla, kennt sicher jeder). Alles Gründe die für die VCL Lösung sprechen.



by side....
In der Vergangenheit konnten wir uns schon mit IT-Abteilungen rumärgern, die behauptet haben das unsere SQL Datenbanken Festplatten kaputt gemacht haben. (es gab ein RAID-Systemabsturz (Hardware) nachdem wir unsere Datenbanken installiert hatten, vermutlich ein deffekt der durch die hohe Belastung des Installationsvorgangs dann durchgeschlagen hat, kühlung, what ever)

[Furtbichler]

Zitat von DSCHUCH:

Hast Du schonmal MDE Entwicklung betrieben? Durch die millionen Geräte Varianten kommt für uns nur eine Lösung in Frage, welche absolut plattformunabhängig ist.

Die beiden Ansätze 'VT-100' (weil 0 Anpassung) und 'Browser-App' (=ASP.NET) sind ziemlich plattformunabhängig, also: Ja.

Der 3.Ansatz (proprietär) ist bezüglich Win CE (Compact Framework) allgemeingültig, aber eben nicht vollkommen plattformunabhängig.

Falls Du mit 'plattformunabhängig' iOS/Android/Windows meinst => vergiss es bzw. plane, wie bei normaler Webentwicklung endlose Spezialfallbehandlungen ein.

Mein IOS-Guru meint, das er zwar schon akzeptable HTML5-Anwendung für iPad gesehen hat, aber die ruckelten immer noch ein wenig, ergo würde er immer noch native iPad-Apps entwickeln. In 2-3 Jahren gehts vielleicht auch mal mit Delphi, aber bis dahin => Objective C.

Im Industriesektor hat sich imho Window eh )noch) durchgesetzt. Hier würde ich mir zudem einen Anbieter aussuchen (Symbol ist eine gute Wahl) und die Sonderlocken dieses Anbieters auch ausnutzen. Beispielsweise ist es nicht trivial, den Scanner in einer Web-App normal zu benutzen. Hier hat Symbol eine Speziallösung.

Und wenn Du seriös bleiben willst, dann unterstütze nicht jedes x-beliebige Gerät, denn das bedeutet, das Du den Kunden mit seinen gerätespezifischen Problemen alleine lässt. Und das ist einfach nicht gut.

[mjustin]

[QUOTE=DSCHUCH;1200758]

Zitat von Furtbichler:

Hast Du schonmal MDE Entwicklung betrieben? Durch die millionen Geräte Varianten kommt für uns nur eine Lösung in Frage, welche absolut plattformunabhängig ist.

Plattformunabhängigkeit ist aber mitunter auch ein Problem, wenn es um die Ansteuerung von gerätespezifischen Schnittstellen geht.

Eine auf Telnet-basierende Client-Anwendung auf dem MDE kann man zwar zum Beispiel einen Barcodescan auslösen, dessen Ergebnis in einem Eingabefeld eingetragen und zum Server gesendet wird.

Aber wenn das Gerät darüber hinaus weitere Hardware hat, ist schon "Ende Gelände" mit der Plattformunabhängigkeit, wenn man sie nicht aus der Telnetsitzung ansprechen kann.

Beispiel: es gibt MDEs mit eingebauter Kamera. Diese kann über zum Beispiel eine API (Windows Mobile) angesprochen werden, doch dazu muss Software zum Beispiel in C# geschrieben werden die lokal läuft. Weder aus dem Telnetclient noch über eine Weboberfläche kann man dann "plattformunabhängig" arbeiten. Benutzer müssen dann tatsächlich zwei Anwendungen auf dem MDE gleichzeitig verwenden, was natürlich eine grauenvolle Lösung ist (Aus Telnetsitzung in C# App wechseln, damit Foto machen und an Server senden, zurück in Telnet Sitzung...).

[Furtbichler]

Ich habe stets den Weg des kleinsten Widerstands bzw. geringsten Auffands gewählt. 2D-Barcodes gehen mit dieser Telnet-Frickelei z.B. nicht mehr.

Wie ich bereits ausführte, habe ich nur gezeigt, das viele Wege nach Rom führen. Darunter waren auch Feldwege.

[QuickAndDirty]

Morfik wäre das spacige internettige was gesucht wird?