Delphi fuer Mobile

[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

[Rollo62]

Delphi im Sinne von Win32 Komponenten auf Mobile packen ...

Das kannst du ziemlich vergessen.
Mobile ist Alles anders, und die bewährten VCL Komponenten machen keinen Sinn mehr.

Dafür gibt es dann ganz gut passende FMX Controls, aber ich benutze nur die untersten 10-20% davon, weil der Großteil auch irgendwo Probleme machen kann.
Da muss man sich eben vorsichtig rantasten, damit du nicht komplett Alles umschreiben musst, und viel Testen.

Die Basis-FMX Komponenten machen aber eigentlich weniger Probleme als das Ganze drumrum, von Hardware, Keyboard bis zu AppStores.

Dein Delphi für Mobile wäre mit Sicherheit kein "Delphi" mehr,
deshalb heisst es ja auch FireMonkey

Was ich übrigens sehr schätze ist das Debuggen auf MacBook oder Win32, weil gleiche CodeBasis ist das echt flott und gute Debugging Unterstützung.
Nur muss dan am Ende doch auf dem Mobile getestet werden, da kann man dann schon wieder Überraschungen der Dritten Art erleben.

Rollo

[Mavarik]

Zitat von 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?

Ich habe für alle Plattformen einen eigenen Projektfile... Achtung: Die Mainforms müssen unterschiedlich heißen, wenn Du alle in einer Projektgroup hast... (RSP-14878)

Zitat von Rollo62:

Nur muss dan am Ende doch auf dem Mobile getestet werden, da kann man dann schon wieder Überraschungen der Dritten Art erleben.

OK, Ich dachte schon das würde nur mir passieren...

[MichaelT]

Ho(s)tpatch ...

Zitat von Rollo62:

Delphi im Sinne von Win32 Komponenten auf Mobile packen ...
Das kannst du ziemlich vergessen.
Mobile ist Alles anders, und die bewährten VCL Komponenten machen keinen Sinn mehr.

Ich hätte den Wunsch von SH17 mal so eingeschätzt, dass seine Applikation auf einem Tablet laufen soll.

Das Feld kann MS nicht aufgeben, sonst sind sie der Elephant in den Nischen und passen nirgends mehr rein. Für Delphi aufgelegt wäre ein Tablet Revival auf ARM unter irgendeinem gängigen UNIX. 'Rechenzentrum am Tablet'.

Phones und Pads werden die Rollen so schnell nicht spielen. Es gibt ja wohl gut laufende Alternativen zu den jetzigen Phone OSes. Sailfish OS bspw...

Embarcadero Phone - Press F9 to connect... Wenn du eine App aufmachst - Press F7 to trace into.

Zitat von Rollo62:

Dafür gibt es dann ganz gut passende FMX Controls, aber ich benutze nur die untersten 10-20% davon, weil der Großteil auch irgendwo Probleme machen kann.
Da muss man sich eben vorsichtig rantasten, damit du nicht komplett Alles umschreiben musst, und viel Testen.

Zur Zeit der Umfragen aus denen Codegear hat die Strategie abgeleitet war Tablet eine valide mögliche Option. Beim Phone ginge ich soweit, dass ich eher den FMX Core als Basis sehe. Um den geht es. Die Controls wird man anbinden können müssen mit halbwegs vertretbaren Aufwand.

Zitat von Rollo62:

Die Basis-FMX Komponenten machen aber eigentlich weniger Probleme als das Ganze drumrum, von Hardware, Keyboard bis zu AppStores.

Das ist Rundherum ist für d'Weiber, stimmt, ein Mann ein Wort!

Zitat von Rollo62:

Dein Delphi für Mobile wäre mit Sicherheit kein "Delphi" mehr,
deshalb heisst es ja auch FireMonkey

Apple hat unter anderem auch für Applescript schon zuvor die Schnittstellen zum Betriebssystem wie Services resp. Objekte wirken lassen. Das 'Applescript' von Google ist Java/Dalvik. Kess formuliert ist Swift/Cooca/iOS ein abgehobenes TCL/TK der besonderen Form und Güte und Java/Dalvik ist die 'Gefangen in Island' Variante davon. Mit Objective hat Apple quasi C/C++ und Applescript verbunden.

Mac und iDevices resp. iOS und OS/X sind beinahe lückenlos miteinander verbunden. Bei Windows und Android bspw. ist die harmonische Verbindung schon durch eine breite sich verbreitende Lücke gestört. Es geht eben nicht darum die Applikation auf mehreren Devices zu haben, sondern eine Brücke zwischen ihnen.

Delphi hat auch eine Brücke gebildet zwischen Windows, dem beinahe nicht mehr vorhandenem Host und den noch nicht vorhandenen Webtechnologien als es beinahe 'hypte'. (aus Sicht einer Brücke).

Kraut und Rüben Applikationen ist die Domäne von MS und Linux auf PC. Eine Anwendung auf einem Tablet ist bis heute noch nicht so klar definiert. Phones und Pads lassen nicht mehr allzuviel Spielraum für 'Kreativität'.

Debuggen am Mac geht ganz gut und Applikationen funktionieren auch.