Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Klatsch und Tratsch (https://www.delphipraxis.net/34-klatsch-und-tratsch/)
-   -   Ein Tag im Leben eines FMX-App Programmierers... (https://www.delphipraxis.net/185077-ein-tag-im-leben-eines-fmx-app-programmierers.html)

Mavarik 13. Mai 2015 13:31

Ein Tag im Leben eines FMX-App Programmierers...
 
Aufgabenstellung Badgenummer unter iOS-8 setzen...

08:20 Uhr frohen Mutes die VM gestartet.

Schnell erst checken ob es eine Antwort zum gestrigen Threadthema gibt… Nein… Mist…
Also nochmal im Source nach schauen… - Sollte klappen. Hatte ich das schon getestet?

<F9>Ping e800002D: Starten Sie Ihr iOS-Gerät neu… Na toll fängt ja gut an (Und noch keinen Kaffee)
iPhone direkt mal mit auf die neue Version aktualisieren…

SDK-Aktuallisieren
- Das Application Directory bla bla bla starten Sie den XCodeOrganizer – Ok dann starten wir den mal…
- Roedel Roedel Roedel – Devicemanager starten – Roedel Roedel Roedel das iPhone ist beschäftigt…
- Ach ja wo mit den… Steht doch nur ganz unschuldig in der Ladehalterung.

SDK-Aktuallisieren
- Das Application Directory bla bla bla starten Sie den XCodeOrganizer – Hab ich doch…
- OK SDK löschen… Neues SDK… Lokalen Dateizwischenspeicher aktualisieren…
- OK Keine Fehlermeldung.

<F9>Weitergeben… Erfolg – Aufrufen von… IDE Weiß… Programm reagiert nicht… OK, Out of memory… XE8 neu starten.

<F9>Weitergeben… Erfolg – Aufrufen von… Sanduhr… “Schwerer Debugger-Fehler: Gerät antwortet nicht. Der Debug-Vorgang wird beendet. Prozess kann nicht erzeugt werden: „Zeitüberschreitung beim Verbinden mit den Gerät“ – Und jetzt…

OK Versuchen wir den 3er Trick…
- iPhone reseten
- XE8 neu starten…
- PAServer neu starten – PAServer will ein Return… Wo ist die Mac-Tastatur? OK Return

EIdCouldNotBindSocket: Socket konnte nicht gebunden werden. Adresse und Port werden bereits verwendet… Ach ja? Eine tote Instance vom PAServer?

OK Mac neu Booten…(10:18 Uhr Und immer noch keinen Kaffee) Nein ich will nicht die blöde Quick Tour für die App “Fotos“

PAServer starten – Return – (Warum hat eigentlich das blöde „Developert Toll Access…“ Fenster nie den Focus auf das Passwort?)

<F9>Linken… Weitergabe… Aufrufen… „Can’t start debugserver on device – device support image was not mounted… OK das ist neu…

Und jetzt? XCode starten – hmm device ist da…

OK Doof ist der 2x das gleiche macht und einen Unterschied erwartet…Oder?

<F9>Linken… Weitergabe…Aufrufen… App da… (Also doch nicht so doof)

Attempting to badge the application icon but haven’t received permission from the user to badge the application Prozess…
Sollten mich die ganzen Fehlermeldungen im PAServer interessieren? NICHT JETZT… Weiter im Text

Keine Verbesserung… Nochmal die Beispiel App versuchen…

Warum hatte ich das im Simulator getestet… Ach ja richtig die DProj Datei ist ja defekt und hat iOS Device32 nicht mit dabei – und natürlich kann man die Plattform nicht hinzufügen… Aktuelles SVN Repo versteht sich…

Also Notepad++ <Platform value="iOSDevice32">True</Platform>

<F9>Fehler sind aufgetreten. Missing provisioning information. Distribution certificate has not been specified für the „Debug“ platform configuration… Klar hatte ich wie jedes mal vergessen…

[Warnung keine Übereinstimmung des Bundle-Bezeichners „“ mit AppID in allen Bereitstellungsprofilen gefunden…
Unter Versionsinformationen steht nur CFBundleVersion 1.0.0 drin alle anderen Keys fehlen…

OK DProj killen – na klar wenn der sich nacherstellt gibt es nur iOS-Gerät – 64 bit…

Also Datei – neu – Geräteübergreifende Anwendung – Speichern unter… Unit hinzufügen
Versionsinformation? CFBundleDevelopmentRegion en… -> de
FMLocalNotificationPermission -> true

10:44 Uhr <F9>Fehler sind aufgetreten. Missing provisioning information. Distribution certificate has not been specified für the „Debug“ platform configuration… Klar s.o.

CFBundleSignature ????->iPhone.Developer

<F9>Weitergabe… Pling Package kann nicht installiert werden. (e8008016)
CFBundleIdentifier noch setzen…

<F9>App da… Jedenfalls das Firemonkey Logo… Bildschirm des iPhones schwarz…
PAServer console sagt als letzes „bfd_mach_o_scan_read_syntab_symbol: symbol“_memset_pattern8“ is unsupported ‚indirect‘ reference : settinh to undefined“ aber das lassen wir mal außer acht...

OK… nehme ich mal so hin… (Frau bringt mir nen Kaffee… 10:54 Uhr wurde auch mal zeit…)

<STRG-F2>… mal ohne debugger aufrufen… Console sagt Unknown Process Boot failure…

Und jetzt?

OK – Android testen…

<F9>Startet Bildschirm Schwarz…

Project – Quelltext anzeigen:

Delphi-Quellcode:
Begin
  Application.Initialize;
  Application.Run;
end.
Klar habe das Formular mit Drag an Drop reingezogen… Und Delphi hat nur den Pasfile genommen und nicht den *.fmx…
Main.Pas löschen und per Hinzufügen...

<F9>App Läuft… Natürlich ohne weitere Einstellungen auf Android sofort) Zurück zu iOS…

<F9>App läuft – aber funktioniert immer noch nicht… Der Debugger springt aber an die falsche Stelle im Sourceode… Also nochmal im Simulator testen…

<F9>Läuft aber ohne Funktion… Ach ja die Versionsinformation sind ja andere…
FMLocalNotificationPermission -> true

Cool es kommt endlich die Abfrage: „SettingResettingBadgeNumber“ Would Liket o Send You Notifications“ OK!
OK Da klappt es… Dumm nur das ich die Abfrage jetzt nicht gedebuggt habe – darum ging es eigentlich …

11:10 Uhr Kurzen Programmierpause
13:00 Uhr Weiter geht es

Simulator klappt immer noch…(Leider hat der sich das irgendwo gemerkt und daher kann ich es nicht mehr debuggen.
Also nochmal auf dem Device

<F9>Unable to mound Developer disk image. (e800000e)
Also erst mal Googlen… könnte an der XCode-Version liegen… Oh nein nicht das noch… Hätte ich mein iPhone nicht updaten sollen?

OK, vergessen wir mal die TestApp und versuchen es noch mal mit der richtigen Version…

<F9>Compile…Link…Weitergeben…Aufrufen… Pling Package kann nicht installiert werden. (e800002d). Kennen wir ja schon also iPhone neu starten…

<F9>Weitergabe… Aufrufen…App startet… War das jetzt so schwer?

Debugger sagt SValueStr=““… Boh jetzt habe ich echt die Faxen dicke…

FMX.Flattform.iOS aus Source ins Projektverzeichniss kopieren…
Delphi-Quellcode:
if TOSVersion.Check(8) {and CheckLocalNotificationPermission} then // Und weg damit
<F9>Compile… Linken… Weitergeben… Aufrufen… Shit nimmt den alten Source… Aus dem Editor? Komisch

13:39 Uhr Alle Files schließen und ein Build machen… (650MB in use, hoffe das Memory reicht noch)
13:42 Uhr Hat gereicht… Ja ein Build dauert 3 Min. Trotz SSD/SSD-Controller und i7 mit > 4GHz, 1GB RAM weg IDE neu starten…

<F9>Linken… Weitergeben… Aufrufen… Nöö er weigert sich den Projekt Source zu verwenden… Komisch bei FMX.VirtualKeyboard.ios funktioniert es doch auch…

Mal im Projekt File noch oben kopiert…
Ahh es funktioniert… Nur der Debugger zeigt den falschen Source-File… Es wird auch Sender.RegisterUserNotificationSettings(Notificati onSettings) aufgerufen… Aber die Abfrage kommt trotzdem nicht.

Na Toll: Auf meinem iPhone gibt es schon einen Eintrag für die Benachrichtigungseinstellungen… Steht aber nur auf Banner…
Also manuell setzen.

Und „schon“ funktioniert es…

14:16 Uhr… Auf zum nächsten Problem...

Mavarik

Photoner 13. Mai 2015 14:05

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Du solltest zur Abwechslung mal etwas mit mehr Erfolgsausichten machen um die Stimmung wieder zu heben.

Z.b. den Passierschein A38 besorgen. :thumb:

p80286 13. Mai 2015 15:30

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von Mavarik (Beitrag 1301373)
Aufgabenstellung Badgenummer unter iOS-8 setzen...

08:20 Uhr frohen Mutes die VM gestartet.

Schnell erst checken ob es eine Antwort zum gestrigen Threadthema gibt… Nein… Mist…
Also nochmal im Source nach schauen… - Sollte klappen. Hatte ich das schon getestet?
.......
Na Toll: Auf meinem iPhone gibt es schon einen Eintrag für die Benachrichtigungseinstellungen… Steht aber nur auf Banner…
Also manuell setzen.

Und „schon“ funktioniert es…

14:16 Uhr… Auf zum nächsten Problem...

"ich bin in der Zwischenzeit zu alt für den Scheiß"
Die Abläufe für hardwarenahe Programmierung unter DOS waren irgendwie ähnlich:mrgreen:

Gruß
K-H

Mavarik 13. Mai 2015 15:38

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von Photoner (Beitrag 1301382)
Du solltest zur Abwechslung mal etwas mit mehr Erfolgsausichten machen um die Stimmung wieder zu heben.

Z.b. den Passierschein A38 besorgen. :thumb:

Der... Ja genau

Mavarik 13. Mai 2015 15:39

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von p80286 (Beitrag 1301394)
Die Abläufe für hardwarenahe Programmierung unter DOS waren irgendwie ähnlich:mrgreen:

hmm Z80 ASM... für MZ-800 da kannte ich jedes Byte im Speicher mit Vornamen...

mensch72 13. Mai 2015 18:44

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
bei Z80, dann Intel8051, jetzt Microchip PIC18/24/32 weiß ich bis auf Ethernet&USB auch noch jedes Bit in allen Bytes und kann auch ohne ein OS von "Null" mit einem leerem Projekt anfangen. Am PC ging das nach DOS noch bis WfW311. Ab Win95 und 32Bit war dann am Desktop Schluss mit dem Versuch, alles (voll)verstehen zu wollen/können.

Bei IOS gehen wir radikal vor:
es gibt ein paar VM's, welche mit XCode und passenden IOS Geräten die Referenz sind, um neue Sachen zuerst mit XCode SampleProjects aus dem INet zu testen. Erst wenn das geht, kommt der PAserver drauf und wir beginnen ein Delphi Projekt. Auch hier "kopieren" wir stets ein Standardprojekt, was mal "jemand" mit viel Zeit & Mühe sauber vorkonfiguriert hat.

Ich selbst wäre auch nicht direkt in der Lage, ohne 2 fertige VMs(eine OSX&XCode plus eine Win7&XE?) schnell mal eine Mobile-Anwendung auf einem IOS Device zu erstellen&testen.

Hut ab vor der Geduld und den Willen das mal zu dokumentieren. Trotzdem kopiere ich erstmal weiter unsere VM's mit den Standardprojekten, bevor ich so einen hier beschriebenen StepByStep Versuch mache ;)

himitsu 13. Mai 2015 19:18

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Mein erster Versuch mit Android.

Neue Anwendung erstellen ... nichts verändert ... F9 ... ewig warten, bis das Androidzeugs runtergeladen war ... programm lief nicht (PA-Error 1) ... zugemacht und Tschüß.




Das Selbe vorher übrigens im Android Studio ... neues Programm erstellt ... ausführen ... lief ... Button von in GUI gelöscht (in der Anfangsanwendung war ein Button und ein paar Panele) ... ausführen ... *peng*
(der Erstellungscode des Buttons blieb zurück, aber weigstens lief es am Anfang wenigstens einmal und das ohne viel einrichten und rumfummeln zu müssen, im Gegensatz zu den Produkten Anderer)



Das, was früher mal als "Rapid" (einfach und schnell) beworben war, kann man schon lange vergessen.

Mavarik 13. Mai 2015 20:38

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von mensch72 (Beitrag 1301442)
Hut ab vor der Geduld und den Willen das mal zu dokumentieren. Trotzdem kopiere ich erstmal weiter unsere VM's mit den Standardprojekten, bevor ich so einen hier beschriebenen StepByStep Versuch mache ;)

Ich habe meine App mit XE2 angefangen...

Eigentlich war es so, dass ich immer so gerade rechtzeitig den neuen Compiler bekommen habe um weiter arbeiten zu können.

Neben vielen, vielen Verbesserungen besonders auch bei Android... Die 1. Versionen war nicht zu bedienen so langsam... Daher habe ich meine App so schnell gemacht wie es ging mit allen Tricks die mir eingefallen sind...

Da FMX@Android viel schneller geworden ist mit XE7,XE8 ist meine App jetzt auf Android superschnell...

Aber die Änderungen der Versionen iOS 6->7->8 und Andoid ->5 haben immer viele Änderungen nach sich gezogen und es musste ständig nachgearbeitet werden.

Bestes Beispiel: Die Map...

1. Version handgestrickten Wrapper aus dem Beta Forum! (XE2, XE3)
2. Version mit nativer Komponente aus Japan?!?! (XE4
3. Version von TMS... (XE5)
4. Version Google Maps von TMS (XE6, XE7)
5. Version wieder zurück auf nativ XE8

Ich will die Stunden gar nicht zusammenrechnen...

Eigentlich wollte ich das nächste Update mit XE7 hochladen... Dann hat der Hotfix mein XE7 gekillt... Das geht zwar jetzt wieder, aber ich habe zu viel auf XE8 schon umgestellt. Doof nur das es zahlreiche Designfehler im XE8 gibt, weswegen die Buttons an den falschen Stellen stehen...
Den Fehler hab ich noch nicht gefunden... Also wieder ein Monat dahin...

Mavarik

sh17 13. Mai 2015 22:27

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Ich will jetzt hier keine Stimmung machen, aber nach ausreichendem Testen und Abwägen: Lernt Swift und nehmt XCode - ihr habt mehr Erfolgserlebnisse

mensch72 14. Mai 2015 01:38

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
"aber nach ausreichendem Testen und Abwägen"... genau deshalb nehmen wir doch Delphi mit FMX für Apps!

Der jeweils einmalige (VM) Aufwand bei Updates wird sicher jeweils von einem gemacht, der erstmal Account & Geräte mit AndroidStudio und XCode checkt und dann ein für uns passendes Standardprojekt in Delphi erstellt. Ab jetzt können dann "alle die nur Delphi können" die Sache nutzen.

Wenn die "gebastelte" shared GUI 20% im Projektumfang ist, 20% notfalls "irgendwie" angepasster und aufs nötigste begrenzter Plattformcode ist und ich dann 60% echtes CodeShare für 4 Platformen (Win/OSX,IOS,Android) habe, ist das für uns trotz des Aufwandes "bis bei Updates was läuft" ein Zeitgewinn für das was wir dann machen.

Selbst kommerziell rechnet sich das, denn für XCode mit ObjC/Swift, AndroidStudio mit Java oder VS.NET mit C# gibt es viele junge dynamische Programmierer und Angebote wie Sand am Meer.
Da ist man schnell ersetzbar und muss sich stets großer (Wissens&Angebots)Konkurrenz stellen. Nö, das tuen wir uns nicht an. Deshalb per Delphi-FMX bewusst mit voller Absicht mal was anderes.

Über dem Tellerrand von Desktop&Mobile im Embedded-Bereich auf kleinen Microcontrolern herrscht mit C/C++ zwar noch die große Spracheinigkeit, aber bei LowPower 8/16Bit und nur einigen KB Flash & wenig RAM ist es auch eine "Glaubensfrage" welche Prozessortechnologie und dann welcher Derivatehersteller genutzt wird. (z.B. x51, AVR, PIC, ARM, MSP).
Das INet ist voll von Zeug & Leuten für AVR&ARM, und genau deshalb nehmen wir es als bewusste Entscheidung nicht. Wir machen alles mit MicroChip PIC-18/24/32 einfach aus Prinzip, auch wenn wir manches selbst anpassen und einpflegen müssen.

=> deshalb machen wir uns hier das bewusst gewollte Leben mit FMX eben in Selbsthilfe etwas leichter und erträglicher. Wer es anders sieht kann ja VS.NET,XCode,AndroidStuidio oder was auch immer nehmen und sich damit schneller und einfacher seine Erfolgserlebnisse schaffen;)

Mavarik 14. Mai 2015 02:14

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von mensch72 (Beitrag 1301463)
=> deshalb machen wir uns hier das bewusst gewollte Leben mit FMX eben in Selbsthilfe etwas leichter und erträglicher. Wer es anders sieht kann ja VS.NET,XCode,AndroidStuidio oder was auch immer nehmen und sich damit schneller und einfacher seine Erfolgserlebnisse schaffen;)

Eben... Ich programmiere Delphi seit TP 1.0... Soll ich jetzt für jede Plattform von vorne anfangen? Wofür?

Und keine Zeile Sourcecode von einer Plattform auf die andere übernehmen? Obwohl die App auf allen Plattformen das gleiche machen soll?!?

Zitat:

Zitat von sh17 (Beitrag 1301458)
Ich will jetzt hier keine Stimmung machen, aber nach ausreichendem Testen und Abwägen: Lernt Swift und nehmt XCode - ihr habt mehr Erfolgserlebnisse

Und was hast Du dann... Ne App für iOS... mehr nicht...

Was machst Du mit Android, Windows und Mac?

Dejan Vu 14. Mai 2015 05:32

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Bleibt noch die Frage, ob es wirklich native Entwicklung sein muss. Wir hatten in der Firma Besuch von einem Programmierer aus Ruanda, der für die Regierung dort eine mobile Applikation geschrieben hat, die per Tablet/Fön Landschaften erfasst (Dateneingabe, Photos etc.) Die Anwendung läuft super flüssig, kann auf lokalen Speicher zugreifen (wenn der die Daten doch nicht los wird) und ist sehr sauber bedienbar. Mir ist jetzt nicht aufgefallen, das das eine PHP-Anwendung ist.

Wozu also der Schmunz mit cross plattform Entwicklung? Für Spiele?

Zitat:

Zitat von Mavarik (Beitrag 1301464)
Soll ich jetzt für jede Plattform von vorne anfangen? Wofür?

Um den eigenen Horizont zu erweitern. Und erfahrene Programmierer fangen doch nicht von Vorne an. Die Zeit, die Du mit dem FMX-Kram verbringst, speziell, um dich wegen der Bugs zu ärgern, hättest Du auch locker in das Erlernen eines neuen Frameworks stecken können. Inklusive einer anderen Programmiersprache.

sh17 14. Mai 2015 07:26

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Ich programmiere auch seit 20 Jahren Delphi. Und Swift hat mich jetzt lächerliche 3 Wochen gekostet.Die Erfahrungen mit der Plattform kommen mit der Zeit und man findet auch sehr viel Material im Internet. Genau so mache ich es mit Java und C#, wobei die nicht ganz neu für mich sind.
Außerdem sind die 3 Sprachen nicht gänzlich unterschiedlich zu Delphi, so das es nicht ganz so schwer ist. Man ist mit den IDEs immer aktuell und sie kosten nichts ( VS ggf) . Für den cross platform code nehme ich Elements und erstelle mir eine Bibliothek für alle drei Plattformen. Und sollte mir das alles zu viel werden, suche ich mir entsprechende Programmierer.

sh17 14. Mai 2015 07:33

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von mensch72 (Beitrag 1301463)
Selbst kommerziell rechnet sich das, denn für XCode mit ObjC/Swift, AndroidStudio mit Java oder VS.NET mit C# gibt es viele junge dynamische Programmierer und Angebote wie Sand am Meer.
Da ist man schnell ersetzbar und muss sich stets großer (Wissens&Angebots)Konkurrenz stellen. Nö, das tuen wir uns nicht an. Deshalb per Delphi-FMX bewusst mit voller Absicht mal was anderes.

Ihr setzt auf FMX, damit ihr nicht ersetzbar seid? Nicht schlecht, die Strategie. Würde ich mich als Chef freuen, jahrelang Geld in die Entwicklung einer Codebasis gesteckt zu haben, für die man dann keine Leute findet, wenn ihr ausfallt.

stahli 14. Mai 2015 08:41

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von Mavarik (Beitrag 1301464)
Zitat:

Zitat von mensch72 (Beitrag 1301463)
=> deshalb machen wir uns hier das bewusst gewollte Leben mit FMX eben in Selbsthilfe etwas leichter und erträglicher. Wer es anders sieht kann ja VS.NET,XCode,AndroidStuidio oder was auch immer nehmen und sich damit schneller und einfacher seine Erfolgserlebnisse schaffen;)

Eben... Ich programmiere Delphi seit TP 1.0... Soll ich jetzt für jede Plattform von vorne anfangen? Wofür?

Und keine Zeile Sourcecode von einer Plattform auf die andere übernehmen? Obwohl die App auf allen Plattformen das gleiche machen soll?!?

Zitat:

Zitat von sh17 (Beitrag 1301458)
Ich will jetzt hier keine Stimmung machen, aber nach ausreichendem Testen und Abwägen: Lernt Swift und nehmt XCode - ihr habt mehr Erfolgserlebnisse

Und was hast Du dann... Ne App für iOS... mehr nicht...

Was machst Du mit Android, Windows und Mac?

Du hast aber schon einige Stimmungsschwankungen. Dein Startbeitrag klang ja nicht so begeistert.

Man muss halt (nach einigen Jahren Erfahrung) nicht nur die Idee bewerten, sondern auch die Umsetzung (und ggf. die Haltung des Anbieters).

Dejan Vu 14. Mai 2015 08:52

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von sh17 (Beitrag 1301474)
Ihr setzt auf FMX, damit ihr nicht ersetzbar seid? Nicht schlecht, die Strategie. Würde ich mich als Chef freuen, jahrelang Geld in die Entwicklung einer Codebasis gesteckt zu haben, für die man dann keine Leute findet, wenn ihr ausfallt.

Den Chef will ich sehen, der so doof ist, und die Arbeit seiner Leute nicht hinterfragt.

Und selbst wenn ihr ausnahmsweise :mrgreen: einen Chef habt, der nicht so doof ist: Jeder ist ersetzbar. Immer.

Ach und: Damit verbaut man sich und seiner Firma, zu wachsen, weil: find mal welche, die FMX können. Eure Firma wird auf der Stelle treten und wenn FMX entgültig ein Exot wird, dann ... tja.. finde mal eine Anstellung mit dem Expertenwissen: "Jahrelang auf falsche Pferd FMX gesetzt". Wenn ich bei unseren Bewerbungsgesprächen jemanden mit solchen Kenntnissen finde, schmunzle ich auch immer wieder. Aber vielleicht wollt ihr ja dort alt werden.

mensch72 14. Mai 2015 12:05

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
(ganz neben bei: in meiner Firma bin ich der Chef und die Projektpartner mit denen wir zusammenarbeiten setzen auch unabhängig von uns intern weiter auf eine tote Delphi Codebasis)

- ich entscheide nicht wie wir "neu" schnell&einfach etwas lösen könnten, sondern setze eben andere Prioritäten und verkaufe das auch so

- es stimmt, es gibt so gut wie keine Delphiprogrammierer mehr am Bewerbermarkt.. das ist nicht schlimm(wir schreiben auch nur noch nachweisbare Erfahrung in OO Programmierung bei Stellen aus, ohne Delphi zu erwähnen), denn eine andere IDE&Sprache ist einem gutem flexiblen Entwickler letztendlich binnen weniger Wochen egal. So wie ich wenn ich wollte auch was direkt mit Java, C# oder ObjC machen könnte, will ich lieber sehen schnell wie ein "neuer" sich in Delphi zurecht findet und was dabei raus kommt, oder ob jemand nur murrt, alles Mist mit XY wäre man schon lange fertig

- CrossCode wird überall da sinnvoll, wo die sichere und eventuell sogar funktional zertifizierte lokale Offlineverarbeitung oder Erfassung/Weitergabe von Daten einen Großteil der Funktion ausmacht, und die GUI nur funktional sein muss, also "Optik" keine besondere Rolle spielt

- CrossGUI macht für schnelle erste Prototypen sowie schnelle Testerweiterungen von Bestandsprojekten Sinn. Fertig eingerichtet hat man mit XE? wirklich fix auf einen Schlag was für Desktop und Mobile gezaubert und es ist etwas zusehen. (ob es dann wenn es richtig sicher geht, immer noch ein echtes 100% Crossprojekt ist, oder doch mehrere Plattformprojekte mit 20..40% nativ + 80..60% shared Code draus werden, das weiß ich vorher auch nicht)

RWarnecke 14. Mai 2015 13:31

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von sh17 (Beitrag 1301458)
Ich will jetzt hier keine Stimmung machen, aber nach ausreichendem Testen und Abwägen: Lernt Swift und nehmt XCode - ihr habt mehr Erfolgserlebnisse

:thumb::thumb::thumb:

Mavarik 14. Mai 2015 16:31

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von Dejan Vu (Beitrag 1301483)
find mal welche, die FMX können.

Naja ob einer nun C# lernen soll oder Delphi... Wenn einer Programmieren kann - so schreibt Ihr doch immer - dann kann er ja auch eben mal Delphi lernen...

Das geht in beide Richtungen.

btw.

Ich habe so gut wie keine IFDEF'S im Code nur für Windows einige... Ansonsten ist mein Code zu 99,9% kompatible zu Windows, OSX, iOS & Android...

Höchsten mal wegen unterschiedlicher Font-Größen nach dem Motto:

Delphi-Quellcode:
{$IFDEF iOS}
Button1.Width := 140;
{$ELSE}
  {IFDEF Android}
   Button1.Width := 160;
  {$ELSE}
   Button1.Width := 120;
{$ENDIF}
{$ENDIF}
Mavarik

Harry Stahl 14. Mai 2015 16:47

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von Mavarik (Beitrag 1301538)
Ich habe so gut wie keine IFDEF'S im Code nur für Windows einige... Ansonsten ist mein Code zu 99,9% kompatible zu Windows, OSX, iOS & Android...

Höchsten mal wegen unterschiedlicher Font-Größen nach dem Motto:

Delphi-Quellcode:
{$IFDEF iOS}
Button1.Width := 140;
{$ELSE}
  {IFDEF Android}
   Button1.Width := 160;
  {$ELSE}
   Button1.Width := 120;
{$ENDIF}
{$ENDIF}
Mavarik

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?

Union 14. Mai 2015 16:52

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Vermutlich weil er es schon seit XE2 versucht.

Harry Stahl 14. Mai 2015 20:04

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von himitsu (Beitrag 1301446)
Mein erster Versuch mit Android.

Neue Anwendung erstellen ... nichts verändert ... F9 ... ewig warten, bis das Androidzeugs runtergeladen war ... programm lief nicht (PA-Error 1) ... zugemacht und Tschüß.

Das, was früher mal als "Rapid" (einfach und schnell) beworben war, kann man schon lange vergessen.

Mit "erster Versuch" meinst Du wahrscheinlich unter XE8? Ich hatte hier auch Probleme, mit einem nicht fertig eingerichteten Android SDK (kann aber daran liegen, dass .bat Kommandos mal ne Zeit lang auf dem PC hier nicht funktionierten).

Wie auch immer. Mit "Android Tools" aus der XE8-Programmgruppe die benötigten SDK's (nach-) installiert und dann funktionierte auch direkt das erste Kompilat, das korrekt auf das Device (Sony Ultra Z) übertragen und dort ausgeführt wurde.

himitsu 14. Mai 2015 20:20

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von Harry Stahl (Beitrag 1301574)
Mit "erster Versuch" meinst Du wahrscheinlich unter XE8?

Nee, ist schon bissl länger her, aber installieren und testen hat danach auch noch nie funktioniert.

In XE8 kann man nichtmal in IDE-Optionen schnell was einstellen (z.B. AutoSpeichern), ohne erstmal Android einrichten zu müssen (oder in meinem Fall das Profil erstmal zu löschen).
In XE7 mußte ich auch erstmal das Problem mit dem fehlenden ZipAlign finden, bevor es lief und auf sowas hatte ich jetzt keine Lust.

Peter666 14. Mai 2015 20:29

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Ich kann mich mit Mavariks erstem Post gut identifizieren. Ich habe zuhause und im Büro sieht es ähnlich aus, eine Codebasis aus über 20 Jahren Pascal/Delphi Entwicklung. Vieles ist plattformunabhängig und wenn ein neues Projekt ansteht, auch wenn ich nicht nicht genau den Aufwand abschätzen kann, so habe ich zumindest ein grobes Wissen an was für Code zurückgegriffen werden kann. Das ist jede Menge und selbst wenn ich C "spreche" und C++ bzw. C# ebenso, sowie auch ein gewisses Verständnis für Java hab und trotz meiner Antipathie zu ObjectiveC auch mit XCode erfolge erziehlen kann, so versuche ich fast alles in Delphi umzusetzen. Nicht weil ich zu blöde bin das zu portieren, sondern weil schlichtweg der Aufwand bestehendes für jedes Kackprojekt Wahlweise in Java oder ObjectiveC umzuschreiben. Das aktuelle Dilemma ist, dass Embarcadero einen echt guten Ansatz liefert, aber sobald man ernsthaft eine Anwendung für mehr als Windows erstellen will, ist man mit Problemen konfrontiert die einen zur Weisglut treiben. 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.

Delphi-Laie 14. Mai 2015 21:22

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Bin ich froh, damit nicht mein Geld verdienen zu müssen - ehrlich, ich bekäme als beruflicher Programmierer einen Rappel. Wie haltet Ihr das nur tagtäglich aus? Noch ist Cannabis schließlich nicht legal...

Dejan Vu 14. Mai 2015 21:27

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von Delphi-Laie (Beitrag 1301595)
Noch ist Cannabis schließlich nicht legal...

Konsum schon. Nur das mit dem Besitz ist so eine Sache.

Delphi-Laie 14. Mai 2015 21:31

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von Dejan Vu (Beitrag 1301597)
Zitat:

Zitat von Delphi-Laie (Beitrag 1301595)
Noch ist Cannabis schließlich nicht legal...

Konsum schon. Nur das mit dem Besitz ist so eine Sache.

Was für eine Logik! Hat man es konsumiert, besitzt man den Wirkstoff, und zwar ganz intus. Alternativ kann man seinen Laptop in den Niederlanden aufklappen...

jaenicke 14. Mai 2015 21:37

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von Dejan Vu (Beitrag 1301597)
Zitat:

Zitat von Delphi-Laie (Beitrag 1301595)
Noch ist Cannabis schließlich nicht legal...

Konsum schon.

Leider ist der Konsum legal, ja.
Ein ehemaliger Freund hat leider vor einigen Jahren damit angefangen... meinte das sei ja nicht gefährlich und so einen Schwachsinn. Damals hatte er echt was auf dem Kasten, wir haben gemeinsam in Delphi ein Projekt realisiert. Heute ist er nur noch ein Wrack, Frau und Kind weg, raucht einen Joint nach dem anderen, kann nicht mehr klar denken und vergisst alles...

himitsu 14. Mai 2015 22:04

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Du darfst auch einen Radarwarner besitzen, aber das Benutzen ist illegal.
Man darf Kinder schlagen, solange man ihre Würde nicht verletzt.
In manchen amerikanischen Bundesstaaten darf man seine Frau schlagen, solange der Stock nicht dicker ist, wie der eigene Daumen.
Wenn du Steuern hinterziehst und es sind gaaaaanz Viele, dann ist es weniger schlimm.

Manche Gesetze sind ein bissl "komisch".

Dejan Vu 15. Mai 2015 08:10

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von jaenicke (Beitrag 1301599)
Leider ist der Konsum legal, ja.
Ein ehemaliger Freund hat leider vor einigen Jahren damit angefangen... meinte das sei ja nicht gefährlich und so einen Schwachsinn. Damals hatte er echt was auf dem Kasten, wir haben gemeinsam in Delphi ein Projekt realisiert. Heute ist er nur noch ein Wrack, Frau und Kind weg, raucht einen Joint nach dem anderen, kann nicht mehr klar denken und vergisst alles...

Obwohl das einem mit dem vollkommen legalen Alkohol, Spielautomaten, den falschen Freunden oder einer PS3XBOX genauso und viel schneller passieren kann, lassen wir die Diskussion lieber (es ist eh eine Glaubensfrage, oder da fliegen schnell die Fetzen). Vielleicht nur so viel: THC macht physisch nicht unbedingt körperlich abhängig (keine eindeutigen Belege), Ethanol hingegen schon (unbestritten i.d.Forschung). Beides in den falschen Händen bringt dich jedoch um den Verstand. Ergo: "Dosis sola venenum facit".

greenmile 15. Mai 2015 08:22

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
:thumb:

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 15. Mai 2015 08:32

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von greenmile (Beitrag 1301619)
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 15. Mai 2015 09:33

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von Harry Stahl (Beitrag 1301541)
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:

Zitat von Peter666 (Beitrag 1301580)
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:

Zitat von greenmile (Beitrag 1301619)
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:

Zitat von greenmile (Beitrag 1301619)
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 :coder:

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

Delphi-Laie 15. Mai 2015 12:05

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Davon schreibt auch Michael Nickles: Meldet man irgendwohin einen Hard- oder Softwarefehler, kommt mit Sicherheit zurück: "Das hatten wir noch nie."

Dejan Vu 15. Mai 2015 13:04

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von greenmile (Beitrag 1301619)
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 15. Mai 2015 14:26

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von Dejan Vu (Beitrag 1301654)
Es gibt ja auch keine Programmiersprache für sowohl Frontend, Backend und die Datenbank.

Delphi?

himitsu 15. Mai 2015 15:01

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
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. :stupid:

mkinzler 15. Mai 2015 15:03

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Es gab mal eine Delphi/Pascal Version für GLSL-Shader (fx-pascal) aber eine "SQL" auf Pascalbasis wäre mir neu.

himitsu 15. Mai 2015 15:21

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Postgres sieht schon bissl pascallig aus.

BUG 15. Mai 2015 15:26

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Zitat:

Zitat von himitsu (Beitrag 1301665)
Wobei Delphi (nicht Pascal) ja vorallem für Datenbankanwendungen ausgelegt war.

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

Zitat:

Zitat von himitsu (Beitrag 1301668)
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.


Alle Zeitangaben in WEZ +1. Es ist jetzt 22:29 Uhr.
Seite 1 von 2  1 2      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz