iOS Tastatur - Return

[arnof]

Zitat:

Mit FireMonkey kann man Cross Platform RAD Entwicklung machen, ohne sich mit den Details der Zielplattform befassen zu müssen.

Ja genau deshalb benutze ich das auch, da man sich nicht erst ein jahr (oder länger) in ein System einarbeiten muss!

Zitat:

Ich bin so froh, dass es kein FireMonkey für Busfahrer und Herzchirurgen gibt!

Im Urlaub hatte ich genau diesen Busfahrer ... Ich dachte der kommt gerade vom Eselreiten, so ist der gefahren ....

[eddie11]

Danke jensw_2000,

damit könnte ich mein Problem ja grundsätzlich lösen, aber wenn man auf Deine Signatur schaut dann weiss man schon, dass das genau nicht der richtige Weg für mich ist. Ich möchte ja gerade mit Firemonkey entwickeln, nicht mit XCode. Meine App soll unter iOS und später (XE5?) dann auch unter Android laufen, ohne allzusehr auf die Unterschiede eingehen zu müssen - das wollte ich eigentlich von Embarcadero gelöst haben .

Dann wird's wohl bei "Return" bleiben.

[jensw_2000]

Zitat von eddie11:

Danke jensw_2000,

Ich möchte ja gerade mit Firemonkey entwickeln, nicht mit XCode. Meine App soll unter iOS und später (XE5?) dann auch unter Android laufen, ohne allzusehr auf die Unterschiede eingehen zu müssen - das wollte ich eigentlich von Embarcadero gelöst haben .

Du kannst das ziemlich sicher mit Delphi lösen.
Für FMX sind Wrapper Units für das UIKit enthalten.
Ergo, musst Du damit auch an die o.a. TextField/TextView Klassen und an das Interface UITextInputTraits herankommen.
Und wenn Du da heran kommst, dann wirst Du es auch benutzen können.

Ich habe den für iOS "natürlichen" Weg zum Ändern des Return-Key Titels gegeben, damit Du weist, nach was Du in den FMX units forschen musst um ans Ziel zu kommen.
Native sage ich nicht mehr....ist zu verschlissen.

Wenn der Return Buttun in Deinem Projekt unter iOS, Android und irgendwann WinRT überall die gleiche Bezeichnung haben soll, dann musst Du eben ein paar ifdefs einbauen und auch forschen, wie man es unter den anderen Plattformen löst.
Letztendlich wird es nur so funktionieren.

Oder du lässt wirklich "return" stehen und lässt den iOS spezifischen Kram weg.
Dieser Denkansatz bedeutet aber unter dem Strich, dass man immer nur die kleinste Schnittmenge der Features nutzt, die auf allen Plattformen verfügbar ist.

[Phoenix]

Zitat von jensw_2000:

Oder du lässt wirklich "return" stehen und lässt den iOS spezifischen Kram weg.
Dieser Denkansatz bedeutet aber unter dem Strich, dass man immer nur die kleinste Schnittmenge der Features nutzt, die auf allen Plattformen verfügbar ist.

Und das heisst konkret: Du hast überall eine suboptimale (lies: schlechte) Lösung.

[eddie11]

naklar, ich muss mich ohnehin auf die jeweilige Plattform einstellen, einige Dinge gibts ja nur auf der einen, andere Dinge nur auf der anderen Plattform. Diese Dinge nicht zu nutzen, um immer nur die gemeinsame Schnittmenge nutzen zu können wäre in der Tat falsch. So muss ich z.B. den Aktivitäts-Indikator, der in der Statusleiste angezeigt wird auch direkt iOS-spezifisch ansprechen.

Aber von einer Cross-Plattform erwarte ich halt, dass die jeweiligen Eigenheiten "durchgereicht" werden und beim Ändern der Zielplattform halt entsprechend abgehandelt werden. teilweise ist das ja auch umgesetzt (z.B. Retina-Properties, die unter Win32 ignoriert werden, und für die es unter Android wahrscheinlich auch keine Entsprechung gibt).

Ich bin halt 'n Programmierer, will mich mit der Anwendung und deren Inhalten auseinandersetzen, ohne allzuviel mit Systemspezifika 'rumzutrödeln .

[Phoenix]

Zitat von arnof:

Zitat:

Mit FireMonkey kann man Cross Platform RAD Entwicklung machen, ohne sich mit den Details der Zielplattform befassen zu müssen.

Ja genau deshalb benutze ich das auch, da man sich nicht erst ein jahr (oder länger) in ein System einarbeiten muss!

Ich glaube, Du hast die Intention der Signatur nicht verstanden.

Wenn Du Dich nicht in ein System einarbeitest, und Dinge so anbietest, wie es der Nutzer dieses Systems erwartet, wirst Du auf diesem System keinen Erfolg haben.

[arnof]

Zitat von Phoenix:

Zitat von arnof:

Zitat:

Mit FireMonkey kann man Cross Platform RAD Entwicklung machen, ohne sich mit den Details der Zielplattform befassen zu müssen.

Ja genau deshalb benutze ich das auch, da man sich nicht erst ein jahr (oder länger) in ein System einarbeiten muss!

Ich glaube, Du hast die Intention der Signatur nicht verstanden.

Wenn Du Dich nicht in ein System einarbeitest, und Dinge so anbietest, wie es der Nutzer dieses Systems erwartet, wirst Du auf diesem System keinen Erfolg haben.

Das ist wie immer eine Glaubensfrage .....

Wenn das Programm das macht, was der User erwartet und auch möglichst problemfrei ist, dann ist der user zufrieden. Wenn der user das 10 oder mehrfache bezahlen muss, damit auch die letzte Kleinigkeit zu dem System passt (look & feel), dann sagen 90% der user "das ist mir egal" es gibt natürlich auch welche (meistens die über andere Leute Geld entscheiden) das muss 100% so sein wie überall.

Das passt dann nicht zu diesem Forumsteil nicht Crossplattform sondern Singleplattform

[jensw_2000]

Zitat von arnof:

Zitat von Phoenix:

Zitat von arnof:

Zitat:

Mit FireMonkey kann man Cross Platform RAD Entwicklung machen, ohne sich mit den Details der Zielplattform befassen zu müssen.

Ja genau deshalb benutze ich das auch, da man sich nicht erst ein jahr (oder länger) in ein System einarbeiten muss!

Ich glaube, Du hast die Intention der Signatur nicht verstanden.

Wenn Du Dich nicht in ein System einarbeitest, und Dinge so anbietest, wie es der Nutzer dieses Systems erwartet, wirst Du auf diesem System keinen Erfolg haben.

Das ist wie immer eine Glaubensfrage .....

Wenn das Programm das macht, was der User erwartet und auch möglichst problemfrei ist, dann ist der user zufrieden. Wenn der user das 10 oder mehrfache bezahlen muss, damit auch die letzte Kleinigkeit zu dem System passt (look & feel), dann sagen 90% der user "das ist mir egal" es gibt natürlich auch welche (meistens die über andere Leute Geld entscheiden) das muss 100% so sein wie überall.

Das ist aber nur die halbe Wahrheit.
Wenn man plattformnative Frameworks, Entwicklungsumgebungen und Technologien benutzt (argh, jetzt musste es das "native" Unwort sein sein..), dann hat man automatisch 100% natürliches "Look & Feel". Überall. Meistens mit viel weniger Quellcode und mit einem besseren Endergebnis.
Also dreht es sich aus meiner Sicht eher um eine Einstellungshaltung von uns Entwicklern.

Möglich ist:
Ich lerne wie die Plattformen ticken und kann danach Apps schreiben die 100% der Plattform auf den vorgesehenen Wegen nutzen können.
Oder...
Ich suche mir eine "Abstraktionsschicht" für die Entwicklung, die alle nötigen Plattformen unterstützt, und lebe damit, dass viele Features einfach nicht realisierbar sind bzw. dass das realisierbare Niveau nur so gut sein kann wie die Abstraktionsschicht selbst. Man muss also bereit sein, die Erwartungshaltung an seinem eigenen Ergebnis herunterzuschrauben.

Nicht möglich ist:
Ich nutze mit einer abstrahierten Entwicklungsumgebung alle Features aller Plattformen auf natürlichem Wege ohne zu wissen wie diese ticken ...

PS:
Ich sehe das wie "Bauer Horst" aus dem Werner Film.
Soll'n sey doch alle mock'n watt sey woll'n ...

[arnof]

So ist es, Crossplattform: es geht vieles aber nicht alles.

[jensw_2000]

Zitat von arnof:

So ist es, Crossplattform: es geht vieles aber nicht alles.

Wir sollten den Thread umbenennen lassen. Sonst gibt es bestimmt bald was auf die Finger

Das hängt von der Wahl der Waffen ab ...

Cross Plattform bedeutet nicht zwangsläufig, dass ein und der selbe Code auf allen möglichen Plattformen läuft.
Wenn das die Lösung aller Probleme wäre, dann hätten wir heute nur noch Java Applikationen am Markt und iOS gäbe es nicht.

Ich bekomme keine Provision von RemObjects. Will ich auch nicht haben. Ist auch nicht mein Ziel.

Für Windows Anwendungen möchte ich nie von Delphi und der VCL weg.
Bei alle anderen Plattformen bin ich sehr glücklich mit Oxygene. Die Philosophie in Bezug auf Cross Plattform gefällt mit deutlich besser als der Ansatz von FMX.
Ich beharre natürlich auch nicht darauf, dass dies alle so sehen wie ich. Wozu auch.

>Mit Oxygene arbeite ich seit einiger Zeit an einem "Lern"Projekt mit einer zentralen Business Logic, die ein Delphi Webservice (via RemObject SDK) bereitstellt.
Die Client Applikationen für ASP.Net, iOS, Android und Windows Phone liegen in einer zentralen Oxygene Projektgruppe. Diese 4 Client-Projekte haben einen zentralen plattformunabhängigen "Shared Code-Teil" und einen "UI Teil", der mit den Bordmitteln der Zielsysteme (und Pascal Code) erstellt wird.
Man programmiert mit einer modernen Pascal Syntax unter Verwendung der natürlichen SDKs der Zielsysteme.
Eine traumhafte Kombination für einen eingerittenen Delphianer...

Meine Erwartungshaltung musste ich lediglich dahingehend herunterschrauben, dass man schnell die GUIs zusammenklickt und in ein paar Wochen fertige Projekte für alle Zielsysteme hat.
Seit 3-4 Monaten lerne ich wie iOS und Cocoa Touch ticken. Ab Jahresende muss ich mich auf die Denkweisen hinter Java und Dalvik stürzen und WinRT ist nach dem Frühjahr 2014 dran.
Dafür habe ich am Ende eine konsistente App "Familie", die auf Windows, im Browser, auf iOS, Android und WinRT kompromisslos und mit natürlichem Nutzerempfinden läuft.
Dadurch dass man den Code in einer IDE aufbaut und ihn im gewohnten Pascal schreiben kann, ist der plattformabhängige "UI Teil" garnicht sooo kompliziert.
Man muss die Konzepte hinter der UI lernen und die Syntax von ObjectiveC und Java kapieren.
Danach hat man eine Flut von Beispielen und Lösungen, die man 1:1 in Pascal Syntax übernehmen kann.
Es ist auch schön, dass man die regulären Entwickler-Dokus der Hersteller nutzen kann.

Bei mir ist das Zittern auf alle Fälle raus aus den Fingern.
Nachdem ich den Kampf mit den "fremden Welten" mit Oxygene begonnen habe und TMS kurz danach die ersten "echten nativen" iOS Controls für FMX veröffentlicht hat, habe ich schon sehr neidisch auf Delphi zurückgeschaut und diese lästige Apple iOS Doku noch mehr gehasst.
Jetzt - ein viertel Jahr später - bin ich mir sicher, dass ich richtig herum auf dem richtigen Pferd sitze und keine der anderen beiden Kombinationen "ausprobiere".