Delphi-PRAXiS
Seite 2 von 2     12   

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)

jaenicke 15. Mai 2015 17:06

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

Zitat von himitsu (Beitrag 1301665)
auch wenn es da etwas komisch ist, daß es kein ordentliches Grid gibt. :stupid:

Naja, das Standard TDBGrid ist gar nicht mal so schlecht, dazu noch z.B. der Lookup-Tree von den JEDIs... (schade, dass es für den keine richtige Doku gibt, der ist eigentlich echt genial)

Dejan Vu 15. Mai 2015 19:17

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

Zitat von Mavarik (Beitrag 1301664)
Zitat:

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

Delphi?

Äh, wie geht eine Query über 20 Tabellen in 'Delphi' nochmal? Also: Effektiv.

Dann doch eher C# mit LINQ(toSQL) (ich hätte erwartet, das das jetzt kommt).

Rollo62 12. Mai 2017 21:18

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Hallo Frank,

der Thread ist ja schon was älter, dann bist du wohl durch damit.

Heute war jedenfalls mein großer Updatetag, und ich könnte das Dingen mehrfach aus dem Fenster werfen :twisted:

Zitat:

<F9>Linken… Weitergabe… Aufrufen… „Can’t start debugserver on device – device support image was not mounted… OK das ist neu…
Das ging bei mir übrigens erst nachdem ich ein TestProjekt in XCode angelegt hatte, und das mal aufs Phone gespielt hatte.
Der Trick hat mir schon öfters den Tag gerettet.
Irgendwas macht XCode dann doch was RadStudio (hoffentich noch) nicht drauf hat.


Ok, jetzt ein bischen Sekundenschalaf, morgen gehts weiter ...

Rollo

Mavarik 13. Mai 2017 08:06

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

Zitat von Rollo62 (Beitrag 1371185)
Hallo Frank,
der Thread ist ja schon was älter, dann bist du wohl durch damit.

Durch, Nein...

Komisch finde ich auch, dass App's, die erfolgreich installiert wurden und liefen (1 Jahr alt) nicht mehr starten und sofort beendet werden. nicht mal der Splashscreen kommt.

Auch der Wechsel zwischen 10.1 <> 10.2 unter Android um Veränderungen zu testen macht immer Probleme - also immer erst deinstallieren usw.

Mavarik

Rollo62 18. Mai 2017 09:31

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Liste der Anhänge anzeigen (Anzahl: 4)
Was gestern lief muss es heute nicht mehr tun ...
Ich verstehe langsam die (Apple) Welt nicht mehr.

Ich habe folgende Konfiguration:
- XCode 8.3.2 (aktuell für Debug)
- XCode 8.2.1 (für AppStore Package)
- iPhone mit iOS 10.3.1 (14E304)

Den Fehler mit dem
Zitat:

„Can’t start debugserver on device – device support image was not mounted
konnte ich durch einfaches Projekt mit XCode aus Phone spielen, mehrfaches Reinstöpseln, Neustarten, beheben.
- Ich konnte in der Konfiguration XCode8.3.2 iOS 10.3.1 debuggen (zumindest vorgestern noch)

Seitdem habe ich da nichts angefasst, und jetzt kommt immer wieder die o.g. Meldung und kann mit XCode8.3.2
nicht mehr debuggen.

Das Problem scheinen die Apple-Abhängigkeiten von XCode/iOS/iTunes und was weiss ich noch zu sein.
Es gibt viele Beschriebungen im Netz wie man XCode8.2.1 zum Laufen bringe, dabei wird dann das fehlende
"device support image" einfach in das Xcode reinkopiert.

Das Problem ist jetzt meine iOS Version:
- In XCode 8.3.2 gibt es "device support image" 10.3 (14E269) - das konnte ich in den AppStore bekommen
- In XCode 8.2.1 gibt es "device support image" 10.2 (14C89)

aber mein Phone braucht iOS 10.3.1 (14E304)

# Wo bekomme ich denn das passende "device support image" 10.3.1 (14E304) her ?
# Ist das 10.3.1 womöglich eine Beta-Version ?
Es gibt auch schon iOS 10.3.2, aber auch da gibt es kein "device support image".
# Kann man diese "device support image" einfach umbenennen und reinwerfen ?
Das würde ich normalerweise nicht so machen, aber was bleibt mir übrig ...

Weil XCode 8.3.2 aber selbst Projekte erzeugen kann sollte das "device support image" doch bereits da sein,
oder nicht ?
Es könnte auch sein das Apple ihr bewährtes System seit 8.3.2 wieder komplett umgestellt haben, glaube
ich aber eigentlich nicht.
Das "device support image" müsste so eine Art SDK-Library für die jeweilige iOS Version sein wenn ich das richtig sehe.

Hat vielleicht jemand einen guten Tipp für mich, damit ich endlich wieder weiterarbeiten kann :gruebel:

Edit
Habe nochmal gecheckt:
XCode 8.3.2 ist aktiv (mit Terminal-Befehl: xcode-select -p --> /Applications/Xcode.app/Contents/Developer) OK
Anhang 47369
XCode selbst bietet bei mir auch kein 10.3.1 Package an (bis zuletzt war das noch so) siehe Bild :shock:
Anhang 47370

Also XCode selbst fehlt 10.3 auch, und kompiliert mit 10.2 ???
Wo kann man denn das XCode aktualisieren, bei den DeveloperTools habe ich auch nichts passendes gefunden.

Edit2
Hab ganz neues XCode Projekt angelegt, nochmal mit XCode 8 Kompatibilität (Standard scheint XCode 3.2 zu sein).
Anhang 47374
Danach ist auch iOS 10.3 wieder auswählbar.
Anhang 47375

Rx10.2 gestartet, debuggen läuft wieder :thumb:

Warum XCode seine Einstellungen vergessen kann möchte ich langsam gar nicht mehr wissen ...

Rollo

Rollo62 22. Mai 2017 08:20

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Hier sind die Erzählungen von noch einem Leidensgenossen ..

Darlo 22. Mai 2017 09:28

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

Zitat von Rollo62 (Beitrag 1372284)
Hier sind die Erzählungen von noch einem Leidensgenossen ..

Ja, da sieht man was für eine Qual die Entwicklung für iOS sein kann. Die Geschichte könnte auch von einem xCode-Entwickler sein und hat nicht nur auf Firemonkey bezogen Gültigkeit.

Rollo62 22. Mai 2017 10:09

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Genau, Apple ist das Haupt-Problem für mich (jetzt leider auch Android, nach dem Rx-Update).
Fmx versucht das nur für uns bestmöglich abzufedern, aber kann leider nicht Zaubern.

Ich habe mittlerweile einen Horror vor jeglichem Update, und da gibt es ja inzwischen einige:
RadStudio, Win, Mac OSX, iOS, XCode, iTunes, Java, Android, Android-SDK, (Linux ?), ...

Ich versuche es erstmal solange Laufen zu lassen wie es eben geht, nur wenn ich neue Features/Bugfixes nutzen möchte wage ich ein früheres Umsteigen, so wie jetzt.
ansonsten stehe ich auch zu der alten Regel: Abwarten bis UPD1

Rollo

sko1 22. Mai 2017 11:40

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

Zitat von Rollo62 (Beitrag 1372284)
Hier sind die Erzählungen von noch einem Leidensgenossen ..

Datiert mit dem 1.4.2017 :-D

Ciao
Stefan

Rollo62 22. Mai 2017 18:39

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Wenn das Alles nur ein Scherz sein soll kann ich da langsam nicht mehr drüber Lachen :cry:

RWarnecke 22. Mai 2017 19:01

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Das sind ja recht komisch Geschichten, die Ihr hier erzählt. Irgendwie habe ich ein Déjà-vu. Also ich habe keine Probleme mit Updates von macOS, Xcode, iOS oder sonst irgendetwas, seit ich 2014 auf Objective-C umgestiegen bin. Auch das Android Studio läuft bestens mit den Android Apps und alles auf dem Mac. :duck: Ich habe dadurch ein viel ruhigeres Leben und programmiere deutlich einfacher und schneller Apps als ich das unter Delphi getan habe.

Ich überlege die ganze Zeit, ob ich noch einen Versuch wagen sollte mit 10.2 wegen Linux, aber was ich hier alles so lese hält mich das immer noch von ab.

Rollo62 22. Mai 2017 19:14

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Ich gebe ja zu das Xcode das Update bei eigenen Projekten immer hingekriegt hat.
Aber es gibt genug Apple-Foren die ähnliche Probleme mit nicht-passenden XCode iOS DebugImages hatten.
Das ist nicht nur ein Fmx Problem.

Mir scheint es so als wäre das (wie damals M$) Apples Versuch sich unliebsame Konkurrenz vom Hals zu halten.
Wahrscheinlich arbeitet bei Apple eine ganze Abteilung an den Anti-Fmx, Anti-Unity, Anti-Xamarin Projekten :stupid:

Rollo

RWarnecke 22. Mai 2017 19:42

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

Zitat von Rollo62 (Beitrag 1372427)
Ich gebe ja zu das Xcode das Update bei eigenen Projekten immer hingekriegt hat.
Aber es gibt genug Apple-Foren die ähnliche Probleme mit nicht-passenden XCode iOS DebugImages hatten.
Das ist nicht nur ein Fmx Problem.

Ich gebe ja zu, dass so ab und zu Xcode mich mit komischen Fehlermeldungen überrascht und auch manchmal nervt. Aber es sind bis jetzt immer Sachen gewesen, wo etwas falsch konfiguriert war. Deshalb sehe ich das nicht als Fehler von Apple sondern als Fehler bei mir aus Unwissenheit oder weil ich es vergessen habe.

Darlo 22. Mai 2017 19:56

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Ich bin mir sicher, dass jeder Entwickler der aus dem Windows-Desktopbereich kommt Schwierigkeiten mit iOS hat... Bin froh um FMX, und würde nichtmehr ohne arbeiten wollen. Ich habe gerade ein Projekt mit einem DatasnapServer, iOS/Android und Win/Osx. Was will man da ohne Delphi machen, außer das Team zu verdoppeln?

RWarnecke 22. Mai 2017 21:21

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Ist das eigentlich immer noch so, dass man bei jedem neuen iOS Release seine Delphi iOS Apps testet, damit man sicher ist dass diese unter dem neuen iOS noch laufen ? Ich kann hier ganz ruhig schlafen und brauche das nichtmal zu machen.

Zitat:

Zitat von Darlo (Beitrag 1372437)
Ich bin mir sicher, dass jeder Entwickler der aus dem Windows-Desktopbereich kommt Schwierigkeiten mit iOS hat... Bin froh um FMX, und würde nichtmehr ohne arbeiten wollen. Ich habe gerade ein Projekt mit einem DatasnapServer, iOS/Android und Win/Osx. Was will man da ohne Delphi machen, außer das Team zu verdoppeln?

Du brauchst doch schon ein größeres Team, dass für Dich testet ob immer noch alles läuft nach einem Update.

Jeder macht es auf seine Weise und ich bereue bis heute nicht, dass ich in der mobilen Entwicklung Delphi den Rücken zugekehrt habe.

Darlo 22. Mai 2017 21:27

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

Zitat von RWarnecke (Beitrag 1372447)
Ist das eigentlich immer noch so, dass man bei jedem neuen iOS Release seine Delphi iOS Apps testet, damit man sicher ist dass diese unter dem neuen iOS noch laufen ?.

Nein, da kann ich auch ruhig schlagen ;-)

Zitat:

Zitat von RWarnecke (Beitrag 1372447)
Du brauchst doch schon ein größeres Team, dass für Dich testet ob immer noch alles läuft nach einem Update.

Validiert Ihr nicht nach einem Major Release von xCode?

Zitat:

Zitat von RWarnecke (Beitrag 1372447)
Jeder macht es auf seine Weise und ich bereue bis heute nicht, dass ich in der mobilen Entwicklung Delphi den Rücken zugekehrt habe.

Ja gut so, freut mich dass du für Dich Deine Lösung gefunden hast. Solange Du in Deinen Post zwischen den Zeilen vermittelst, dass FMX nicht funktioniert und Mist ist, werde ich nicht müde das Gegenteil zu behaupten und zu belegen ;-) (nicht bös gemeint)

RWarnecke 23. Mai 2017 05:51

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

Zitat von Darlo (Beitrag 1372448)
Validiert Ihr nicht nach einem Major Release von xCode?

Was meinst Du genau damit ? Zum Beispiel diese App, die habe ich letztes Jahr im März veröffentlicht. Die Läuft heute noch ohne jegliche Änderungen.
Zitat:

Zitat von Darlo (Beitrag 1372448)
Ja gut so, freut mich dass du für Dich Deine Lösung gefunden hast. Solange Du in Deinen Post zwischen den Zeilen vermittelst, dass FMX nicht funktioniert und Mist ist, werde ich nicht müde das Gegenteil zu behaupten und zu belegen ;-) (nicht bös gemeint)

Ich habe das auch nicht so aufgefasst. Ich bin immer für eine gute sachliche Diskussion zu haben. Ganz nebenbei, ich bin Freelancer und entwickel die Apps komplett alleine. Und eines sei noch bemerkt, ich bewundere euch, das Ihr mit FMX produktive Apps entwickelt und vertreibt. Ich habe einfach nicht den Nerv dazu.

Ich habe noch eine App, die in Delphi FMX geschrieben ist, die ich bis heute nicht umgestellt habe. Aber diese App läuft schon lange nicht mehr unter iOS und Android. Bei iOS ist diese App ich glaube beim Wechsel von iOS 7 auf 8 ausgestiegen und bei Android hat ist sie glaube ich bei Android 5 das Zeitliche gesegnet. Ich habe dann die App aus den AppStores genommen, weil die App eh nicht richtig lief. In der App waren lediglich einige HTTP-Abfragen die ein JSON-Ergebnis zurückgeliefert haben und dieses dann entsprechend in der App angezeigt wurden. Das war für mich ein wesentlicher Grund, warum ich von FMX auf Xcode (Objective-C) und Android Studio (Java) gewechselt bin. Da ich viel mit fremden SDKs arbeite und diese nur in Objective-C/Swift oder Java bekomme spare ich mir die Übersetzung nach Delphi.

Sherlock 2. Jun 2017 13:29

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Verdammt! Ich hab jetzt seit langem wieder iOS als Ziel und bekomme ständig nur
Zitat:

[DCC Fataler Fehler] F2588 Linker-Fehlercode: 1 ($00000001)
Habe alle Zertifikate aktualisiert, und überhaupt ist das ein neues Projekt, für das ich ein Provisioning Profile erstellt habe, das auch gefunden wird. Weiss grad gar nicht, was nicht stimmt. Zwischenzeitlich hab ich alles neu gestartet, ohne Erfolg.

:cry:

Sherlock
Achja: Berlin Upd2, XCode 8.3.2, iOS 10.3

Mavarik 2. Jun 2017 14:18

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

Zitat von Sherlock (Beitrag 1373323)
Verdammt! Ich hab jetzt seit langem wieder iOS als Ziel und bekomme ständig nur
Zitat:

[DCC Fataler Fehler] F2588 Linker-Fehlercode: 1 ($00000001)
Habe alle Zertifikate aktualisiert, und überhaupt ist das ein neues Projekt, für das ich ein Provisioning Profile erstellt habe, das auch gefunden wird. Weiss grad gar nicht, was nicht stimmt. Zwischenzeitlich hab ich alles neu gestartet, ohne Erfolg.

:cry:

Sherlock
Achja: Berlin Upd2, XCode 8.3.2, iOS 10.3

Das hast Du aber bezüglich XCode 8.3 gelesen, oder?

Sherlock 2. Jun 2017 14:28

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Danke, das war's nicht. Ich will ja nix in den Appstore stellen, sondern nur eben mal ad-hoc verteilen.
Notiz an mich: Immer alle alten Beiträge lesen und gegebenenfalls herumexperimentieren.
http://www.delphipraxis.net/1337610-post24.html
Der Subst bringt's scheinbar nicht mehr, hab das Projekt nach c:\temp kopiert und schon ging es wunderbar.

Gnarf!!

Sherlock

Rollo62 18. Jan 2018 08:22

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Ein zu alter Thread ?
Für mich nicht, denn der Wahnsinn geht weiter :stupid:

Bis gestern ging Alles noch wie geschmiert, und dann plötzlich aus heiterem Himmel ...

Gestern:
Plötzlich Fehler 0xE8000004, - Kann mit iPhone nicht connection
- Ok, SIM.Karte war ziemlich abgelaufen (nur noch 0.74 EUR drauf), und er hatte gemeckert
- SIM-Karte geladen
- Neustart des iOS Gerätes
- Dann ging es wieder

Heute:
- Morgens funktionierte es noch ..

Plötzlich Fehler 0xE8000084, - Kann mit iPhone nicht connection
- Dafür gibt es Hinweise, aber nur zu Windows.
Natürlich habe ich das Phone an einen MAC-OS angeschlossen (VmWare, mit MacOs).
https://discussions.apple.com/thread/4313565
https://www.usp-forum.de/itunes-iclo...xe8000084.html
- Ich versuche mal Alles zu Re-Starten


Wie immer Nützliche Hinweise sind sehr willkommen :stupid:

Rollo

mensch72 18. Jan 2018 08:59

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Liste der Anhänge anzeigen (Anzahl: 1)
manche schwören darauf...

Darlo 18. Jan 2018 10:23

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Ich lege für jedes Projekt ein leeres xCode-Projekt mit dem gleichen identifier an. Wenn der deploy dann nicht funktioniert, xCode öffnen, Projekt wählen, deploy. Entweder habe ich im Anschluss eine verständliche Meldung oder es geht wieder.

Rollo62 19. Jan 2018 07:47

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Dankesehr für die Infos und Tipps.

TunesCare:
Das TunesCare habe ich mal drüberlaufen lassen, hat etwas gemacht aber es ist nicht klar was genau.
Eine konkrete Fehlermeldung hatte ich jedenfalls nicht.
Naja, Optimierungen sind immer gut :)

Ich bin mit solchen Tools immer vorsichtig, manche machen Sinn, manche machen es nur noch Schlimmer.
Ist gut wenn man sich da über solche Erfahrungen austauscht :thumb:
Jedenfalls geht es heute auch wieder, mit oder ohne TunesCare.
Ich hoffe das es auch mal eine Weile so bleibt.


Projekte per XCode:
Das Anlegen der Projekte in XCode wollte ich auch so einführen, da werde ich aber erst bei neuen Projekten zu kommen.
Was mir dabei nicht so klar ist:
- Legst du die Projekte auch komplett über XCode an, oder machst du das noch weiterhin manuell ?

Ersteres wäre für mich der entscheidende Vorteil, weil dann die ganze Zertifikatskram von XCode erledigt wird.
Allerdings sind die XCode-Zertifikate etwas speziell, und entsprechen nicht 1:1 den manuell angelegten.

Kommt RadStudio mit den von XCode angelegten Zertifikaten klar ?

Rollo

MEissing 19. Jan 2018 08:18

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

Zitat von Rollo62 (Beitrag 1391353)
Kommt RadStudio mit den von XCode angelegten Zertifikaten klar ?

Natürlich.... welche denn sonst?!?

Rollo62 19. Jan 2018 08:53

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Na die von Hand im MemberCenter angelegten.

XCode macht da etws wie *Xc.... davor oder dahinter, wenn ich mich recht erinnere.
Das sieht für mich ganz so aus als könnten die XCode-erzeugten Zertifikate sich anders Verhalten als die von Hand angelegen Zertifikate.

Wenn das nicht der Fall ist wäre das ja ein(zig) Problem(e) weniger :thumb:

Warum empfiehlt Embarcadero dann das Vorgehen nicht so, oder warum finde ich da keine Tutorials im Web ?
Das würde Einsteigern viel Ärger ersparen.

Rollo

Sherlock 19. Jan 2018 09:46

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Rollo, du meinst doch jetzt nicht hoffentlich sowas https://www.embarcadero.com/starther...plication.html, oder?

Sherlock

Rollo62 19. Jan 2018 10:08

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Nein, ich mine das Anlegen der Provisioning und anderen Zertifikate im AppStore.

Dann kommt man auf den MANUELLEN Weg im Web ...
Der ist aber sowas von ... :stupid:

Einfacher haben das die XCode Entwicler, den die können Alles das (oder fast), was man da im Web kann, aber es wird komplett über XCode gesteuert, so wie ich das verstehe.

Also korrigiert mich wenn ich falsch liege,
- in XCode neues Dummy-Projekt anlegen
- neue Bundle-ID vergeben
- Entwickler / Team auswählen
- zusätzlich auch andere Zertifikate anlegen lassen (InApp Purchase, etc.)
- Alle Zertifikate von XCode erzeugen lassen
- Projekt deployen aus iPhone
- XCode kümmert sich um alle DebugImages und sonstigen Kram der erstmal aufs iPhone muss
- Fertig mit iOS, XCode kümmert sich um Alles

Ok, dann gibt es ein Projekt unter XCode mit meinem gewünschten Bundle-ID.
- also lege ich das eigentliche RadStudio-Projekt in gleicher Weise an
- wichtig sind hoffentlich nur die gleichen Bundle-ID und gleichen Services
- RadStudio sucht dann die Provisioning Zertifikate (die XCode angelegt hat)
- und findet sie hoffentlich auch (denn das ist das Einzige was ich noch nicht gecheckt habe)
- Kopilieren, Deployen, Debuggen und Testen
- Upload in den AppStore
- Fertig mit dem RadStudio Projekt

So ungefähr stelle ich mir das vor, also muss man diesen Zertifikatswahnsinn nicht mehr von Hand machen.
Die Beiträge unten zeigen mir ja das es wohl so gehen wird.

Was ich darüber hinaus noch mehr erwarte ist:
- bei abgelaufenen Zertifikaten, einfach mit XCode neue compilieren, neu erzeugen lassen
- ich hoffe das sich XCode wieder komplett darum kümmert.
- Zertifikateupdate fertig (hoffentlich :shock:)

! Man muss natürlich aufpassen das man nicht das Dummy-XCode Projekt in den AppStore hochlädt :stupid:

Rollo

Rollo62 22. Jan 2018 13:34

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Ich habe es gerade mal an einer neuen App ausprobiert.
Es scheint zu funktionieren, wenn auch nicht Alle Schritte.
Hier ist mal eine perfekte Zusammenfassung des ganzen Wahnsinns, von Ray Wenderlich.
Und hier der Teil 2.

Das ist mal von 0 auf 100 was man Alles (mindestens) machen muss um der Apple Bürokratie Herr zu werden.
Dankesehr von mir an Ray Wenderlich.

Ich fasse das für mich mal so zusammen:
XCode-Prozedur:
  • Apple-ID, Devices, etc. vorbereiten (da gehe ich mal von aus das es Alles gibt)
  • App-ID für neues Projekt muss man MANUELL im MemberCenter anlegen.
    Bundle-ID muss korrekt definiert sein.
  • Neues Projekt in Xcode anlegen
    Bundle-ID muss korrekt definiert sein.
    Entwickler/Team definieren, etc.
  • Ich musste auch ein Distribution Provisioning Zertifikat manuell anlegen, weil es nicht automatisch von XCode erzeugt/erkannt wurde. Hab ich was falsch gemacht ?
  • Compilieren, Debuggen und Testen
  • In iTunes das neue Projekt MANUELL anlegen
    Bundle-ID muss korrekt definiert sein.
  • Wenn OK, dann Product\Archive um Projekt für AppStore vorzubereiten (Release)
  • Upload zu App-Store via XCode (das ist noch die Dummy-App)


XCode Vorbereitung für RadStudio:
  • XCode Preferences\Account
  • Mit "Manage Certificates" Zertifikate checken
  • Mit +\/ Popup öffen, und iOS Development / iOS Distribution wählen, um Provisioning Zertifikate zu aktualisieren
  • Zur Sicherheit DummyApp noch einmal auf iPGone Target starten, damit XCode das Provisoning korrekt überträgt

RadStudio Prozedur:
  • Neues MultiDevice Projekt in Delphi anlegen
    Bundle-ID muss korrekt definiert sein.
  • PAServer muss auf dem Mac laufen
  • iOS Device anschliessen
  • Project Debug
  • Compilieren, Debuggen und Testen
  • Wenn OK, dann Build\Release\Applicationstore
  • Project Deploy
  • Upload IPA-File zu App-Store via ApplicationLoader
  • Im Testflight muss noch die Export Compilance abgenickt werden, dann ist es im Test verfügbar

Zwischendurch sehe ich das neue Provisioning Zertifikate angelegt wurden, und dementsprechnd eine Meldung in RadStudio kommt:
Zitat:

[PAClient Error] Error: E0264 iPhone Developer: Vorname Nachname (XYZ1234567): ambiguous (matches "iPhone Developer: Vorname Nachname (XYZ1234567)" and "iPhone Developer: Vorname Nachname (XYZ1234567)" in /Users/"vornachname"/Library/Keychains/login.keychain-db)

[PAClient Error] Error: E0264 iPhone Distribution: Firma Vorname Nachname (ABC1234567): ambiguous (matches "iPhone Distribution: Firma Vorname Nachname (ABC1234567)" and "iPhone Distribution: Firma Vorname Nachname (ABC1234567)" in /Users/"vornachname"/Library/Keychains/login.keychain-db)
Zertifikate in Keychain löschen hilft, aber wer, wann und warum werden zwei doppelte Zertifikate angelegt ?
Ich wollte jetzt nichts riskieren, also habe ich die neuen gelöscht damit die alten Projekte noch weiterlaufen.
Womöglich hätte ich aber auch die älteren Zertifikate löschen können, und die alten Projekte dann damit weiterlaufen lassen.

Sind diese Prozeduren jetzt der ideale, korrekte Weg um XCode mit einzubinden, oder gehts auch einfacher ?

Fazit für mich:
  • Anscheinend kann XCode nicht Alles 100% anlegen, es sind noch ein paar manuelle Eingriffe in MemberCenter und iTunesConnect nötig, aber das hält sich in Grenzen.
  • Ich musste doppelte Zertifikate löschen, nach Anlegen eines neuen Projektes.
    Kommt das vielleicht das ich halb manuelle und halb XCode-Verwaltete Projekte nutze ?

Anregungen, Vereinfachungen, Verbesserungsvorschläge, Fehlermeldungen, etc. sind immer willkommen :stupid:

Codehunter 22. Jan 2018 15:20

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Ich bin auf diesen Thread aufmerksam geworden, weil er in letzter Zeit immer mal wieder auf der Startseite aufgetaucht ist. Habe mir mal den Eröffnungspost angeschaut und kam aus dem Lachen nicht mehr raus (sorry Mavarik ^^). Deine Leidensgeschichte kam mir seeeeehr bekannt vor.

Mein erstes FMX-Projekt war gleich ein ziemlicher Kracher: Ich musste eine hardwarenahe Client-Bibliothek von Honeywell zum Ansprechen eines 2D-Imagers in Form einer JAR-Datei in das Android-Projekt einbinden. Zu Zeiten von XE4 + Mobile Addon gabs da nicht mal Anleitungen für, wie man die Basisbibliotheken von FMX patchen und das Dingens da rein mogeln kann. Nach drei Wochen (!!!) lief der Krempel dann.

Zwar will die IDE das Projekt bei F9 auf dem Zielgerät nicht mehr starten (Kompilieren, Linken und Draufkopieren tuts, nur Ausführen tuts nicht) aber da ist mir dann der Faden gerissen. Ich starte das Projekt dann eben manuell auf dem Clientdevice, PAClient wartet ja gnädigerweise so lange bis das erledigt ist.

Ich glaub wer von der VCL kommt und mit solchen Alpträumen in die FMX-Welt startet, der wird so schnell kein Freund mehr davon werden :twisted: Von iOS habe ich gleich ganz die Finger gelassen, weil so viele Verrenkungen wie man da machen muss bis man das als Zielplattform mit Delphi ansprechen kann, da müsst mir echt was fehlen :lol:

Zum Glück ist FMX bei mir eher die Ausnahme als die Regel. Leider ist die Rente noch ein bissi zu weit weg als dass ich Mobile komplett ausblenden könnte :(

Mavarik 22. Jan 2018 15:39

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

Zitat von Codehunter (Beitrag 1391660)
Von iOS habe ich gleich ganz die Finger gelassen, weil so viele Verrenkungen wie man da machen muss bis man das als Zielplattform mit Delphi ansprechen kann, da müsst mir echt was fehlen :lol:

Ich würde viel lieber die Hände von Android lassen... Das es auf iOS läuft ist - nicht mehr - so ein Problem, aber auf Android knallt es dann immer noch an zig stellen...

Android kosten mich immer noch doppelt so viel Zeit wie iOS... Wenn nicht mehr...

Mavarik

Rollo62 22. Jan 2018 17:20

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

Deine Leidensgeschichte kam mir seeeeehr bekannt vor.
Ja hier snd wohl Blut, Schweiss und Tränen der letzten 3-5 Jahre angesammelt :stupid:

Das Ganze wird wohl bald mal als drehbuchfähiger Thriller in Buchform erscheinen, und dann von der UFA mit 3 Pilotfilmen und ca. 15 Fortsetzungen als ZDF Fernsehspiel verfilmt werden ...
(Hauptrollen Till Schweiger und Matthias Schweighöfer)

Rollo

Mavarik 22. Jan 2018 17:35

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

Zitat von Rollo62 (Beitrag 1391670)
Ja hier snd wohl Blut, Schweiss und Tränen der letzten 3-5 Jahre angesammelt :stupid:

Ja... Man hätte nie mit Version 1.0 (oder war es 0.8ß) anfangen dürfen...

Vor XE8 alles viel zu viele Fehler... Aber man wollte auch nicht warten und den Anschluss an den Mitbewerb verpassen..

Meine Mitbewerber haben bis heute keine App - die glücklichen - besser keine App als eine unfertige...

Mittlerweise läuft mein Zeug schon nicht mehr mit 10.0.

Mavarik

Codehunter 22. Jan 2018 17:41

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

Zitat von Mavarik (Beitrag 1391671)
Vor XE8 alles viel zu viele Fehler... Aber man wollte auch nicht warten und den Anschluss an den Mitbewerb verpassen..

Es war noch nie eine gute Idee, Entwicklungstools agil zu entwickeln. IMHO kämpft Embadera hier doch irgendwie auf verlorenem Posten gegen Kleinfirmen wie Google und Apple. Die Taktschläge kommen immer schneller, teilweise bekomt man selbst mit aktuellstem Delphi seine Apps nicht mehr in die Stores weil irgendwas fehlt (x64 etc.) Wenn mein Haupterwerb vom App-Verkauf abhinge, ich würde kaum auf Delphi setzen - so traurig wie es auch ist.

Zitat:

Zitat von Mavarik (Beitrag 1391664)
Ich würde viel lieber die Hände von Android lassen... Das es auf iOS läuft ist - nicht mehr - so ein Problem, aber auf Android knallt es dann immer noch an zig stellen...
Android kosten mich immer noch doppelt so viel Zeit wie iOS... Wenn nicht mehr...

Dafür kostet iOS-Entwicklungshardware das Doppelte ^^

Spaß beiseite. Bei Embedded-MDA für Lager & Logistik vollzieht sich ja derzeit gerade so mit Mühe die Wachablösung von Windows CE/Mobile/Phone zu Android. Von iOS ist da weit und breit nichts zu sehen. Wie auch, Apple hat kein Interesse an Custom-Hardware.

Mich hat das ganze Drumherum bei iOS abgeschreckt. Man braucht irgendeine OSX-Kiste, man braucht XCode, man braucht iOS-Hardware etc. Kostet alles eine Menge Schotter, den mein Brötchengeber nur allzu ungern her gibt.

Mavarik 22. Jan 2018 18:51

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

Zitat von Codehunter (Beitrag 1391673)
Mich hat das ganze Drumherum bei iOS abgeschreckt. Man braucht irgendeine OSX-Kiste, man braucht XCode, man braucht iOS-Hardware etc. Kostet alles eine Menge Schotter, den mein Brötchengeber nur allzu ungern her gibt.

Mag sein... MacBook sowieso - Sieht man ja immer wieder... Ich erinnere mich an die Delphi-Tage vor längerer Zeit: 4 Speaker auf dem Podium; alle zeigen etwas auf Windows, jeder hat ein MacBook...

Damit kann man dann auch die iOS Sachen in den Store bringen... IPhone als Telefon liegt sowieso vor... Und ein iPad fürs auf dem Klo Boom Beach zu spielen... Also ist schon alles an Hardware da was benötigt wird... :stupid:

Zum Glück ist noch ein altes Android Handy vom Kollegen da - der hat ein neues bekommen und das war nix mehr Wert...

Naja - ein Mac-Mini war dann doch einfacher als das Notebook... Kein Lüfter, SSD, läuft einfach 24/7 mit und steht einfach hinter einem Monitor... per Umschalter und USB Tastatur/Maus...

Läuft...

Mavarik

Rollo62 22. Jan 2018 19:10

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

IMHO kämpft Embadera hier doch irgendwie auf verlorenem Posten
Genau da hoffe ich doch immer das sich genug Community um FMX scharen wird, damit es von Allen Seiten befeuert losstarten kann.
Das sowas tatsächlich gut funktionieren kann sieht man doch überall (sogar FreePascal, Lazarus, Castle Game Engine, ... um nur mal auf Pascal zu schauen).
Also die Hoffnung stirbt zuletzt.

Rollo

Darlo 22. Jan 2018 21:33

AW: Ein Tag im Leben eines FMX-App Programmierers...
 
Ich habe meine Anfänge mit der erste Freepascal-Lösung FMX von Delphi gesammelt. Das ist inzwischen ja doch schon paar Jährchen her. Seit dem hat sich aber auch eine Menge getan. Ich entwickel alles außer Reportlösungen mit FMX und bin mehr als begeistert! Gerade in Verbindung mit Datasnap hat man unendliche Möglichkeiten. Ich behaupte für meinen Teil schneller als meine Konkurrenz außerhalb von Delphi zu sein. Sicher hilft hier eine riesige Erfahrungssammlung an Workarounds ;-)

Codehunter 22. Jan 2018 23:00

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

Zitat von Rollo62 (Beitrag 1391684)
Genau da hoffe ich doch immer das sich genug Community um FMX scharen wird, damit es von Allen Seiten befeuert losstarten kann.

Genau da sind wir wieder bei meinem Lieblingsthema: Der Lizenzpolitik bei Embadera. Ich fände es sinnvoller, Basistechniken wie alle Compiler und UI-Frameworks in die kleinen Delphi-Editions zu packen, damit sie sich verbreiten können und Delphi eine breitere Nutzerbasis bekommen kann. Es macht einfach keinen Sinn, die unterschiedlichen Ziel-Plattformen in verschiedene Preisklassen zu stecken. Projekte wie CrossVCL machen das überdeutlich. Dagegen würde ich sofort zustimmen wenn man sagt, Luxus-Features wie Datasnap oder Livebinding müssen nicht unbedingt in den Free-Editions enthalten sein. Kurz gesagt: Die Featurematrix der Delphi-Editions ist über Jahre gewachsen und niemand hat sie mal unter dem Gesichtspunkt sich verändernder Märkte überarbeitet.

Zu den verändernden Märkten zähle ich auch FPC/Lazarus. Alles was dort enthalten ist sollte auch bei Delphi kostenlos verfügbar sein um die Community nicht weiter zu spalten und den Wettbewerb zwischen beiden Projekten zu erhalten.


Alle Zeitangaben in WEZ +1. Es ist jetzt 11:23 Uhr.
Seite 2 von 2     12   

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