Delphi fuer Mobile

[MichaelT]

Das brauchst du auch nicht, sei froh.

Ich habe damals etwas gesucht was ein wenig zarter ist als ein JBOSS/Wildfly, ganz außer Konkurrenz vom Thema Delphi als Backend. Ich habe mich allein im Zuge dessen mit Delphi als Frontend beschäftigt.

Hot Deployment wäre ein Grund. Camel kann mit fast allen Message Brokern usw... Ein Freund von mir hat viele Hostablöseprojekte gemacht. Ein STOMP Interface war auch weit weg von akzeptiertem Standard.

2010/11/12 war von Delphi auf Linux noch lange keine Rede und FASTCGI ist so gut wie nirgends gegangen.

Alle anderen haben seit gut 10 Jahren Lösungen und bestehende Infrastruktur. Deswegen ist das Thema nicht ganz so kuschelig wie es auf den ersten Blick anmutet.

Denke an AppWeb und ESP, wenn ich so an delphirocks als C/C++ Programmierer denke.

Zitat von Mavarik:

So viele tolle Begriffe...

Ich hab gar keine Zeit mich mit den ganzen unterschiedlichen Dingen zu beschäftigen...

Mit der neuen Version daraus ein Linux bzw. Appache-Modul machen... Was brauchtest Du noch?

Mavarik

[delphirocks]

@Mavarik:
Ist das eine Mooney? Hab' ich auch geflogen, ist allerdings auch schon lange her. Die OE-KOG, stationiert in LOWS.

@Michael: ja, als C++ Programmierer bin ich nicht zu beneiden. Die Sprache an sich ist zwar mittlerweile nicht schlecht, aber trotzdem brauche ich fuer alles gefuehlt 10x so lange wie vor 10 Jahren mit Delphi. Leider kann ich mir's nicht aussuchen.

Zurueck zum Thema:

Go nehm' ich, weil's einfach, schnell und ausserdem ueberall gratis verfuegbar ist.
Sozusagen das Delphi Pendant am Server. Delphi dagegen muss ich mir erst kaufen.

Da bin ich eben gerade am Ueberlegen, weil Embarcadero gerade so eine Aktion um 750 Euro fuer die Professional hat.

[Mavarik]

Zitat von delphirocks:

@Mavarik:
Ist das eine Mooney? Hab' ich auch geflogen, ist allerdings auch schon lange her. Die OE-KOG, stationiert in LOWS.

Im Vorder- und Hintergrund... Ja...

[mensch72]

"als C++ Programmierer bin ich nicht zu beneiden"..."brauche ich fuer alles gefuehlt 10x so lange wie vor 10 Jahren mit Delphi"

sorry, dafür gibt es "C++Builder" oder besser gleich "RADstudio(im Sinne von Kombi aus Delphi & C++ & Mobile)... da kann man Funktion und GUI 1:1 wie Delphi in C++ programmieren oder bei GUI entscheiden, ob man es sogar in Pascal macht und einfach mit dem C++ Zeug zusammen linkt, genau das plus des Mobile inclusive ist der große Vorteil von RADstudioPro was sogar günstiger wie die Enterprise-Versionen ist, wenn es einem "nur" um Mobile inlc. gehen würde.


Aber wenn wir hier schon "alternative" Programmierumgebungen diskutieren, wo man "einfach" native GUI's erzeugen kann, dann sollte man auch https://www.b4x.com/ , also das Portfolio von "Anywhere Software" erwähnen. Die machen nicht groß Werbung, haben aber einige echt gute Referenzen und deren GUI-RAD-Designer ist portabel das Beste, was an den Delphi-FMX-FormDesigner herankommt.

Per JavaTarget für PC&MAC ist quasi alles "frei", und Android&IOS als "Enterprise-Bundle" kostet dort keine 100Eur/Jahr... preiswerter bekommt man keine Umgebung, wo man echt native GUIs per RAD erstellt und sich mit ein paar Zeilen Code im Prinzip alles realisieren kann. Ich bleibe zwar weiter bei RADstudio, aber wer das StandardMobileZeug nur wegen der GUI-Designer von Xcode oder AndroidStudio nicht mag, der könnte dort für wirklich kleines Geld mal einen "Versuch" starten.

[MichaelT]

Für Windows tut es Professional an sich wohl. Aber selbst in dem Fall hast du noch nicht mal C/S DB Anbindung. Wir reden im Fall von Mobile und Backend und Linux eher von Enterprise.

Für Windows ist RAD Studio (aus Sicht von Prof) an sich noch immer viel schneller. Das ist nicht nur gefühlt. In dem Punkt lasse ich über Delphi gar nichts kommen. Man kann jetzt schimpfen was man will - wie du ja sagtest, out-of-the box mit Android ist 'hoabuachan'. Ganz entkommen tut EMB der Toolchain auch nicht.

Nachdem ich mir aber mal die Entwicklung mit out-of-the Box Werkzeugen im Falle von iOS (das war noch durchwegs im Rahmen) und Android habe angeschaut (das war schon eher peinsam über lange Zeiträume und teils peinlich), habe mir auch gedacht - sehr suspekt. Ich bin auch davon ausgegangen, dass man sich auf einem Tablett eine namhafte Applikation kann bauen. Dass es zu Beginn Applikation mit Listen gibt bei schwacher Prozessorleistung, aber heute ... So wirklich besser und mehr... Sobering. Deeply impressed by the Power of Smartdevice bin ich nicht. Nicht dass ich die technische Meisterleistung an sich würde nicht zu würdigen wissen bezüglich des Geräts, aber so wirklich viel damit tun ... Ich möglw. schon ein wenig zu alt...

Mir geht Toolchain am Allerwertesten vorbei - Press F9.

Zitat von delphirocks:

@Mavarik:
Ist das eine Mooney? Hab' ich auch geflogen, ist allerdings auch schon lange her. Die OE-KOG, stationiert in LOWS.

@Michael: ja, als C++ Programmierer bin ich nicht zu beneiden. Die Sprache an sich ist zwar mittlerweile nicht schlecht, aber trotzdem brauche ich fuer alles gefuehlt 10x so lange wie vor 10 Jahren mit Delphi. Leider kann ich mir's nicht aussuchen.

Zurueck zum Thema:

Go nehm' ich, weil's einfach, schnell und ausserdem ueberall gratis verfuegbar ist.
Sozusagen das Delphi Pendant am Server. Delphi dagegen muss ich mir erst kaufen.

Da bin ich eben gerade am Ueberlegen, weil Embarcadero gerade so eine Aktion um 750 Euro fuer die Professional hat.

[sh17]

Um den Thread nochmal auszugraben...

MIT einer riesigen bestehenden Delphi-Codebasis würde Delphi-Mobile also Sinn machen?

Ich bin echt am Überlegen, weil wenn es technisch alles läuft, spricht doch eigentlich nichts gegen Delphi-Mobile.
Auch wenn sich die App nicht ganz Plattform-ähnlich anfühlt, das wäre in meinem Einsatzbereich noch zu verkraften.
Nur funktionieren muss es.

Vielleicht kann ja noch jemand was dazu sagen, der es wirklich nutzt.

//Edit hab mir z.B. auch react native angeschaut, das mag zwar was für JS-Fans sein, aber mir rollen sich da die Fußnägel. Sorry

[Mavarik]

Zitat von sh17:

Vielleicht kann ja noch jemand was dazu sagen, der es wirklich nutzt.

Was willst Du den wissen?

- Funktioniert es? - JA
- Ist es einfach eine App für alle Plattformen zu schreiben? - Nein


Es kommt eben immer darauf an, was man machen will.

Ich entwickele meine App seit 2011 - 17 Forms und 79 Units. Im App-Store & Playstore. Windows-Store folgt, wenn ich die Zeit finde...

Die Statistik sagt seit 2015 sind:

- Windows : 119h in die App geflossen - hiervon 2h compilieren - 96h Debuger-Zeit
- iOS : 61h - hiervon 15h compilieren - 26h Debug-Zeit
- Android : 22h - hiervon 3,5h compilieren - 24h Debug-Zeit

Also 202h + 146h debuggen.

Um es nochmal auseinander zu pflücken...

Nach 215h lief die App unter Windows... Damit es dann auch mit ARC und auf iOS & Android richtig lief, waren nochmal 113h nötig.

Aus dem Bauch raus würde ich sagen 13h look and feel und 100h wegen ARC... (Kostet mich gefühlt auch am meisten nerven)

Mavarik

[sh17]

ja, das ARC ein Thema sein könnte, kann ich mir vorstellen.

Macht es Sinn, die Plattformen in separate Projekte zu packen, anstatt in die Zielplattformen eines Projektes?
Nutze z.B. in unserer Java-Android-Version NFC, was iOS ja nicht kennt. Hab deshalb Unterschiede in der UI.
Oder kann man das gut in einem Projekt handeln?

[Darlo]

Ich mache das in einem Projekt mit IFDEFS. War am Anfang viel Arbeit das nochzupflegen, inzwischen ist das schon fast automatisch. Cool wäre wenn die IDE z.B. bei einem .free das automatisch machen würde.

[MichaelT]

Ausprobieren. Probieren geht über studieren. Funktionieren tut Delphi Mobile auf jeden Fall schon bevor überhaupt der Zugriff auf die ausgewählten Native Controls unter iOS war.

Portabilität im Fall von existierenden Code und die Überschaubarkeit von neuem Code im Sinne von Recompilieren sind 2 verschiedene Paar Schuhe.

Ich würde mir die Kernalgorithmen schnappen, die du bestimmt sauber in Klassen hast verpackt

Die Idee hinter dem Scripting vs. compilieren ist es einer standardisierten Engine zu erlauben den Stream in Richtung Prozessor zu optimieren.

--- losgelöst davon ---

Gutes und schlechtes Beispiel ...
https://www.collabora.com/news-and-b...ysis-in-linux/

'Unsere Engine' bspw. unter Windows sitzt im INTEL Prozessor. Mal abgesehen, dass der Programm Flow anders ausschaut bügelt der Prozessor sogar noch die Opcodes auf spezialisierte. Deswegen holt man auch nicht mehr viel im Intel Ecke.

Ob man einen Prozessor tatsächlich einen optimierten Code-Flow kann übergeben - keine Ahnung.

Eine App profitiert von Services die vom OS bereitgestellt werden. Eine Application weniger.

Eigentlich toben sich 3 Konzepte aus 'JIT' + Scripting vs. Compilieren gegen verschiedene Prozessorarchitekturen beim Einspielen der App vs. compilieren im Vorfeld.

Es kann heute keiner sagen was sich am langen Ende durchsetzt. Das Thema unterschiedliche Prozessoren und Prozessortechnologien zu adressieren ist ein gar nicht so einfaches Thema.

Auf einem Prozessor mit tiefer Pipeline und in Assembler eine Lösung zum parallelisierbaren resp. vektorisierbaren Problem holt man mehr als 40% Speedup raus. Das geht auf 200% bis 300%. Ein Freund von mir auf einer HP Vekotorengine (damals die 'erste' richtige High End Grafikkarte) Mitte der 1990er vs. einen SGI Cluster. Die Parallelisierung auf Core Ebene selbst wenn der Rest in Hardware wurde implementiert (bspw. der Systembus vs. Netzwerkkommunikation) hat damals (Convex Meta Cluster) einen P133 grad noch überholt mit 64 Knoten, aber kein 233 mehr.

Die Diskussion im Umfeld Intel sobald er Algorithmus und dessen Laufzeitkomplexität in Grenzen hält. Es wird aber keiner hergehen Anwendungen oder Apps schreiben und in Assembler noch auf einen spezifischen Prozessor hin optimieren.

--- Beispiel für einen anderen Zugang ---
Hollywood: http://www.hollywood-mal.com/

Aber wie gesagt, entschieden ist gar nichts.

Zitat von sh17:

Um den Thread nochmal auszugraben...

MIT einer riesigen bestehenden Delphi-Codebasis würde Delphi-Mobile also Sinn machen?

Ich bin echt am Überlegen, weil wenn es technisch alles läuft, spricht doch eigentlich nichts gegen Delphi-Mobile.
Auch wenn sich die App nicht ganz Plattform-ähnlich anfühlt, das wäre in meinem Einsatzbereich noch zu verkraften.
Nur funktionieren muss es.

Vielleicht kann ja noch jemand was dazu sagen, der es wirklich nutzt.

//Edit hab mir z.B. auch react native angeschaut, das mag zwar was für JS-Fans sein, aber mir rollen sich da die Fußnägel. Sorry