Die Weichen für Delphi XE6 sind gestellt

[Olli73]

Zitat:

Zitat von Mavarik (Beitrag 1218194)

Eigentlich müsste Android jetzt werben mit: Nuten Sie Android, den mit iOS sind sie den halben Tag mit Ihrem iPhone beschäftigt, anstatt zu arbeiten... ;-)

Damit hat ja auch schon MS bei WP7 geworben, allerdings mit der Argumentation, dass man durch die Live-Tiles schneller seine Informationen zusammen hat und zurück im Leben ist ;)

[Mavarik]

Zitat:

Zitat von Olli73 (Beitrag 1218229)

Zitat:

Zitat von Mavarik (Beitrag 1218194)

Eigentlich müsste Android jetzt werben mit: Nuten Sie Android, den mit iOS sind sie den halben Tag mit Ihrem iPhone beschäftigt, anstatt zu arbeiten... ;-)

Damit hat ja auch schon MS bei WP7 geworben, allerdings mit der Argumentation, dass man durch die Live-Tiles schneller seine Informationen zusammen hat und zurück im Leben ist ;)

Ich sag ja alle iOS User lieben es einfach das iPhone zu streicheln...

Hätte man nen Stifft, könnte man auch die Button kleiner machen..:stupid:

[Uwe Raabe]

Zitat:

Zitat von Mavarik (Beitrag 1218304)

Ich sag ja alle iOS User lieben es einfach das iPhone zu streicheln...

Hätte man nen Stifft, könnte man auch die Button kleiner machen..:stupid:

Hab einen! http://www.amazon.de/gp/product/B007MAUFT2

Andernfalls käme ich wohl nur mit einem Galaxy Note klar. Dann könnte ich mich auch beim Telefonieren verstecken.

[Der schöne Günther]

Die Stifte funktionieren doch genauso wie ein Finger, da könnte man auch eine Wurst nehmen.

(Siehe auch http://www.rp-online.de/digitales/in...chen-1.2185417)

[TReader]

Ich versteh einfach nicht, weshalb sie sich nicht ein Beispiel an RemObjects nehmen. Deren Architektur erlaubt es, dass alle SDK's verwendet werden - ohne Wrapper. So gehörts gemacht und nicht anders. Selbiges wäre auch für Android, Mac und was sonst auch erwünscht aber naja.. die einen könnens, die anderen eben nicht.

[jaenicke]

Zitat:

Zitat von TReader (Beitrag 1218407)

Deren Architektur erlaubt es, dass alle SDK's verwendet werden - ohne Wrapper. So gehörts gemacht und nicht anders. Selbiges wäre auch für Android, Mac und was sonst auch erwünscht aber naja.. die einen könnens, die anderen eben nicht.

Das hat aber nicht nur Vorteile. Man muss dadurch z.B. mehr Code redundant schreiben.
Dass es auch viele Vorteile gibt, ist natürlich klar.

[Daniel]

Zitat:

Zitat von TReader (Beitrag 1218407)

Ich versteh einfach nicht, weshalb sie sich nicht ein Beispiel an RemObjects nehmen.

Bitte nicht. Wenn ich mit deren Werkzeugen eine GUI basteln möchte, bin ich wieder auf den XCode Interface-Builder angewiesen. XCode ist ein mächtiges Werkzeug, aber wenn ich das eh schon nutze, dann doch gleich "in echt" mit ObjectiveC. Der "Witz" an Delphi ist ja gerade, dass er den Delphianer dort abholt, wo er sich befindet und einen Weg in die Welt von Apple ermöglicht. Das sind zwei grundverschiedene Ansätze mit ihren Vor- und Nachteilen.

[jensw_2000]

Zitat:

Zitat von Uwe Raabe (Beitrag 1218148)

Woher denn auch. Zumindest normal sterbliche iOS-Entwickler können seit heute das SDK und die Preview runterladen.

Indem man nich die Schnapsidee verfolgt, und alle nativ vorhandenen Controls als OpenGL Clone nachmalt.
Selbst Firemonkey scheint es "richtig" zu können :wink:

Siehe TMS iCL
Dieser Weg ist aus meiner Sicht sinnvoll und wird eine spitzen Zukunft haben.

Es ist ja nicht nur so, dass bei den EMBT OpenGL FM iOS Controls der Style nicht mehr unter iOS7 stimmen wird...
Man kann damit keine Business Apps bauen die täglich viele Stunden genutzt werden sollen.
Das OpenGL Rendering frisst Rechenleistng und Akku wie verrückt.
Die Devices werden heiß und Programme die z.B. eine Schicht lang durchgehd genutzt werden müssen, kommem bei intensiver Nutzung nicht ohne Nachladen aus. OpenGL gehört in die Spiele-Szene und ist keine plattformunabhängige Primärwaffe für alle Anwendungsfälle ...

[jensw_2000]

Zitat:

Zitat von Daniel (Beitrag 1218414)

Zitat:

Zitat von TReader (Beitrag 1218407)

Ich versteh einfach nicht, weshalb sie sich nicht ein Beispiel an RemObjects nehmen.

Bitte nicht. Wenn ich mit deren Werkzeugen eine GUI basteln möchte, bin ich wieder auf den XCode Interface-Builder angewiesen. XCode ist ein mächtiges Werkzeug, aber wenn ich das eh schon nutze, dann doch gleich "in echt" mit ObjectiveC. Der "Witz" an Delphi ist ja gerade, dass er den Delphianer dort abholt, wo er sich befindet und einen Weg in die Welt von Apple ermöglicht. Das sind zwei grundverschiedene Ansätze mit ihren Vor- und Nachteilen.

Da stimme ich zu.
Bisher bin ich der Meinung, dass Oxygene der bessere Weg ist, weil dort direkt mit dem Cocoa Framework und dem iOS SDK gearbeitet wird.
Deshalb habe ich FMX bei Seite gelegt und versuche seither mit Oxygene etwas zu Stande zu bringen.
Die Lernaufwand ist enorm. Dafür geht alles. Doch bis man "alles" sicher beherrscht vergehen vermutlich Jahre. Besonders wenn wir über iOS, Android und Win RT reden.
Man muss am Anfang unheimlich viel recherchieren und ein paar Hunderter für Trainingsmaterial locker machen wollen....
Da stecken schon ein paar komplizierte Themen drin (Xcode, Pascal Code mit OC Sprachnotation, Android Ressourcensystem, Java und vieles mehr).

Ich hoffe, dass FMX meine Oxygene Lernkurve irgendwann kreuzt und mir den ganzen Ballast abnimmt.
Die Basis für eine robustes native Cocoa Entwicklung ist in FMX offensichtlich vorhanden.
Die Herangehensweise von TMS iCL ist denke ich mittelfristig der beste Weg für FMX Mobile Development.
Falls EMBT das genauso sieht und das OpenGL Renderung für Standardcontrols irgendwann verwirft, dann bin ich wieder im Boot. iCL fehlen noch ein paar native NavigationController und ViewController für FMX und schon ist das Ganze sehr gut nutzbar.