Ein Tag im Leben eines FMX-App Programmierers...

[greenmile]

Ich kenne die Probleme nur zu gut. Was gestern abend lief, muss heute morgen nicht zwangsläufig noch laufen. Wer kennt das Spielchen nicht, dass die FMX Form am nächsten Tag ohne irgendwelche Änderungen völlig verschoben aussieht. Ich habe, nachdem ich die Beiträge hier gelesen habe, nicht auf XE8 aktualisiert. Mit jeder neuen Delphi Version muss ich wieder lernen, wie ich mit den Bugs umzugehen habe. Hatte diesmal echt keinen Bock drauf, dass die App, die ich unter XE7 irgendwie ins laufen gebracht habe, plötzlich nicht mehr läuft, weil Methode/Funktion in Unit irgendwas umgezogen ist oder sich plötzlich irgendwas völlig anders verhält.

Blöd nur, dass ein Auftraggeber / Chef genau diese Zeit (die man für das korrigieren / recherchieren braucht) nicht zahlen will.

Letztendlich ist Dein Beitrag aber nur ein ungehörter Hilferuf. Es bringt nichts, wütend, sauer zu sein oder mit Abwanderung zu einer anderen Sprache. Es wird sich nichts ändern. Da ich auch nicht für jede Plattform eine eigene Sprache lernen/haben möchte (was für eine uneffektive Idee ist das bitte?), muss ich irgendwie damit leben. Ist wie eine Ehe: Nicht immer super, aber es gibt auch schöne Zeiten

PS: Mein nächster Traumjob steht aber fest: Ich möchte im Qualitätsmanagement von Embarcadero arbeiten. Da hat man nicht sehr viel zu tun.

[RWarnecke]

Zitat von greenmile:

Letztendlich ist Dein Beitrag aber nur ein ungehörter Hilferuf. Es bringt nichts, wütend, sauer zu sein oder mit Abwanderung zu einer anderen Sprache. Es wird sich nichts ändern. Da ich auch nicht für jede Plattform eine eigene Sprache lernen/haben möchte (was für eine uneffektive Idee ist das bitte?), muss ich irgendwie damit leben. Ist wie eine Ehe: Nicht immer super, aber es gibt auch schöne Zeiten

Dazu habe ich zwei Fragen. Hast Du schonmal Objectiv-C oder Java ausprobiert in zusammenhang mit mobilen Apps ? Hast Du Deine Android Apps nachkontrolliert ? Denn hier ist gerade bei FMX Vorsicht geboten.

[Mavarik]

Zitat von Harry Stahl:

Nur mal aus Interesse gefragt: Seit XE7 kann man das doch in den unterschiedlichen Views direkt wie gewünscht designen, dann brauchst Du für Design-Aspekte eigentlich keine IFDEF's mehr.

Gibt es einen speziellen Grund, warum Du es hier (dennoch) mit IFDEF's zur Laufzeit löst?

Richtig... Das gab es noch nicht in XE2-XE6 Außerdem designe ich so gut wie keine Fenster in der IDE... Weil sich das alles dynamisch berechnen muss... Daher finde ich auch die Deviceansicht von zig Geräten so was von schwachsinnig... 90% des Designs entscheiden sich zur Laufzeit und sind noch Style-Abhängig. ggf. Wird der Style auch durch eine User-Einstellung noch geändert...

Zitat von Peter666:

Seit XE2 ist die IDE immer instabiler geworden und ohne jedes Mal auf eine neue Version upzugraden ist es unmöglich für iOS und Android zu entwickeln.

Das ist leider so... Hinzu kommt das durch Änderungen von iOS6->iOS7-iOS8 wieder unzählige Änderungen nötig waren. Leider habe ich nicht 24/7 Zeit meine App zu schreiben... Wenn ich mal 3 Monate aussetzt komme ich schon kaum mit den Änderungen nach...
Ich führe meine Änderungen an der RTL seit XE4 mit und ändere jedes mal die neuen Sourcen.

Zitat von greenmile:

Ich habe, nachdem ich die Beiträge hier gelesen habe, nicht auf XE8 aktualisiert. Mit jeder neuen Delphi Version muss ich wieder lernen, wie ich mit den Bugs umzugehen habe. Hatte diesmal echt keinen Bock drauf, dass die App, die ich unter XE7 irgendwie ins laufen gebracht habe, plötzlich nicht mehr läuft, weil Methode/Funktion in Unit irgendwas umgezogen ist oder sich plötzlich irgendwas völlig anders verhält.

Ja das ist ein großes Problem... Auch das die Forms leider NIE abwärtskompatible sind, weil immer ein schwachsinniges Feld hinzugekommen oder weggefallen ist. Ich wäre noch auf XE7 aber das kann kein Android mehr compilieren. Aber man will auch immer auch die neuen Features haben und hofft, dass die RTL besser und fehlerfreier ist.

Zitat von greenmile:

Letztendlich ist Dein Beitrag aber nur ein ungehörter Hilferuf. Es bringt nichts, wütend, sauer zu sein oder mit Abwanderung zu einer anderen Sprache. Es wird sich nichts ändern. Da ich auch nicht für jede Plattform eine eigene Sprache lernen/haben möchte (was für eine uneffektive Idee ist das bitte?), muss ich irgendwie damit leben. Ist wie eine Ehe: Nicht immer super, aber es gibt auch schöne Zeiten

Ein Hilferuf an EMBT - vielleicht... Aber auch an die Delphi Gemeinde... Nur wenn wir die gefundenen Probleme melden, können diese beseitig werden... Bei EMBT arbeitet wahrscheinlich NIEMAND so lange und oft wie "Wir" mit FMX... Ich denke es Fehlen uns 2 Sachen.

1. Ein deutscher Entwickler von EMBT als Schnittstelle (Egal wie gut wir alle englisch sprechen)
2. Viele Viele QC Einträge die nicht gemacht werden weil
- zu lästig
- man als Antwort nur erhält "as Designed" (Schwachsinn) oder das mehr Infos, ein Beispiel, oder was auch immer benötigt wird.
- Der Fehler mitten bei Debuggen gefunden wurde und eigentlich überhaupt nicht klar wie man das
a) beschreiben soll
b) reproduzieren soll
c) als Beispiel liefern soll - klar ich zippe mal eben die 40 Units und schicke sie als Public in das QC.

Ich habe mich mit einem Unterhalten:
"Das glaube ich nicht, ist hier in keinem Test passiert" - Eh mann ich sehe es auf meinen Bildschirm...
"Deinen Fehler kann ich nicht nachvollziehen" - Dann halte Dich doch mal an meine Steps dann wirst Du ihn sehen...
"Ist hier nie aufgetreten ich schließe den Fall"...

Ich mache daher seit dem JEDES mal ein Video mit Camtasia... Das ist dann nicht weg zu diskutieren...

Mavarik

PS.: Zu den Kiffer-Beiträgen sage ich nix... gehört nicht hierher...

[Delphi-Laie]

Davon schreibt auch Michael Nickles: Meldet man irgendwohin einen Hard- oder Softwarefehler, kommt mit Sicherheit zurück: "Das hatten wir noch nie."

[Dejan Vu]

Zitat von greenmile:

Da ich auch nicht für jede Plattform eine eigene Sprache lernen/haben möchte (was für eine uneffektive Idee ist das bitte?), muss ich irgendwie damit leben. Ist wie eine Ehe: Nicht immer super, aber es gibt auch schöne Zeiten

So lange es noch nichts Anständiges gibt, wirst Du wohl oder übel deinen Horizont erweitern müssen. Es gibt ja auch keine Programmiersprache für sowohl Frontend, Backend und die Datenbank. Da muss man -fürs Erste- mehrere Sprachen können. Wenn man eine One-Man-Show ist, wenn nicht, gibt es eben Frontend-, Backend-, und Datenbankentwickler.

[Mavarik]

Zitat von Dejan Vu:

Es gibt ja auch keine Programmiersprache für sowohl Frontend, Backend und die Datenbank.

Delphi?

[himitsu]

Wobei Delphi (nicht Pascal) ja vorallem für Datenbankanwendungen ausgelegt war (drum auch Delphi, da Oracle)
auch wenn es da etwas komisch ist, daß es kein ordentliches Grid gibt.

[mkinzler]

Es gab mal eine Delphi/Pascal Version für GLSL-Shader (fx-pascal) aber eine "SQL" auf Pascalbasis wäre mir neu.

[himitsu]

Postgres sieht schon bissl pascallig aus.

[BUG]

Zitat von himitsu:

Wobei Delphi (nicht Pascal) ja vorallem für Datenbankanwendungen ausgelegt war.

Ich vermute eher, dass Datendefinitions- und -manipulationssprachen (DDL/DML) gemeint waren.

Zitat von himitsu:

Postgres sieht schon bissl pascallig aus.

Das pascallige kommt vermutlich daher, das SQL erst als natürliche Sprache für Nutzer gedacht war. Leicht zu lesen, wie die Lehrsprache Pascal.