Project Magician: Löscht API-Keys unter Mobile

[Rollo62]

@UweRaabe

Hallo zusammen,

ich weiß nicht, ob dies die richtige Stelle für Fragen an das Project Magician Tool von Uwe ist.
Wenn nicht, dann bitte verschieben.
Auf der Blog-Seite von Uwe habe ich jedenfalls keine Kommentarmöglichkeiten gefunden.

Ich benutze das Tool ab und zu und habe mich gerade gewundert, warum die Einträge für Android Maps-SDK - apiKey in den Project Options/Version Info nicht angenommen werden.
Ich vermute, dass der Grund bei Project Magician liegen wird:
Project settings
\-- Clear settings in child configs
\----- X - Application settings
\----- X - Package settings

waren gesetzt.

Das macht, was es soll und löscht (überschreibt) anscheinend
Project Options\Version Info\Debug configuration\Android32 oder 64\Version code options\apiKey <== Der DEBUG Maps SDK-Key
Project Options\Version Info\Release configuration\Android32 oder 64\Version code options\apiKey <== Der RELEASE Maps SDK-Key

mit dem jeweiligen, leeren apiKey aus
Project Options\Version Info\All configurations\Android32 oder 64\

Weil die apiKeys für DEBUG/RELEASE natürlich unterschiedlich sein sollten, ist das nicht ganz optimal.

Deshalb meine Frage, oder Feature-Request, ob dies selektiv behandelt werden könnte?
Vielleicht ist ja schon eine Einstellmöglichkeit für solche Elemente vorhanden, die Maps-Keys sind bestimmt nicht der einzige Fall.

Seltsamerweise scheint dies Verhalten projektabhängig zu sein, in einem migriertem, alten Rx1130 Projekt belieben die Keys erhalten.
In einem neu angelegten, leeren Projekt, verschwinden die Keys, wie oben beschrieben.

Schalte ich den Projekt Magician ab, die oben genannten Checkboxen, dann bleiben auch die apiKeys wieder erhalten.

[Uwe Raabe]

Kannst du mir mal so eine dproj schicken? Oder besser zwei:

Zitat:

Zitat von Rollo62 (Beitrag 1532768)

Seltsamerweise scheint dies Verhalten projektabhängig zu sein, in einem migriertem, alten Rx1130 Projekt belieben die Keys erhalten.
In einem neu angelegten, leeren Projekt, verschwinden die Keys, wie oben beschrieben.

[Rollo62]

Ich habe mal versucht, das in ein Mini-Projekt auszugliedern.
Es scheint immer zu löschen, dass es mal die Keys behalten hat war wohl nur eine andere Einstellung in Project Magician.
Ich vermute es ist das Flag "Version Info".

Anbei mal beide Projekte, die Namen bitte nicht beachten, beide behalten die Android Maps apiKeys nicht.

Anhang 56603

Gesetzt sind die Project Options so, sonst keine Group oder Global Options:
Anhang 56604

[Uwe Raabe]

Gefunden habe ich es schon mal:

Delphi-Quellcode:

        
  Arg.Remove(sVerInfo_Keys);

Code:

  <VerInfo_Keys>
    package=com.test.$(MSBuildProjectName);
    label=$(MSBuildProjectName);
    versionCode=1043;
    versionName=1.0.43;
    persistent=False;
    restoreAnyVersion=False;
    installLocation=auto;
    largeHeap=False;
    theme=TitleBar;
    hardwareAccelerated=true;
    apiKey=
  </VerInfo_Keys>

Allerdings weiß ich nicht, wie ich das selektiv ausblenden soll. Dazu müsste man den Inhalt manipulieren, aber das wäre dann schon eine Sonderbehandlung gerade dieses Eintrags. Das lässt sich kaum übersichtlich konfigurieren und bei Harcoden habe ich immer etwas Bauchschmerzen.

Ich kann verstehen, dass der Api-Key bei Debug und Release unterschiedlich ist (wie sieht das bei den Platformen aus?), aber es gibt ja vielleicht auch andere (Child-)Konfigurationen. Wo setzt man da am besten an, ohne nur eine spezielle Lösung zu implementieren?

[Rollo62]

Zitat:

Zitat von Uwe Raabe (Beitrag 1532804)

Dazu müsste man den Inhalt manipulieren, aber das wäre dann schon eine Sonderbehandlung gerade dieses Eintrags. Das lässt sich kaum übersichtlich konfigurieren und bei Harcoden habe ich immer etwas Bauchschmerzen.

Genau deswegen wünsche ich mir immer eine Art Text/JSON-Optionseditor, statt der Project Options :stupid:
Nicht nur, dass es dann auch sauber im Git landen würde und vergleichbar würde.

Ich habe es nicht im Detail gecheckt, aber gefühlt denke ich wird es zig solcher Stellen geben,
wo sich DEBUG/RELEASE und/oder andere Stellen unterscheiden müssen.
Das ist nur eins, denke ich von vielen, aber definitiv eine solche Ausnahme, mit der man Testen kann.

Ich weiß auch nicht, wie man das am besten im Project Magician unterbringen kann, vielleicht in einer Art "Exclusions-List",
die erstmal für solche Fälle vorgesetzt sein könnte.
Das könnte eine variable Text-Liste sein (macht Sinn, wenn morgen mal wieder was Neues dazukommt),
oder auch eine feste Checkliste sein, wenn es überschaubar bleibt und dann bei der nächsten Version in Project Magician angepasst werden müsste.
Zumindest würde man dann darauf deutlich hingewiesen, auch wenn eine Änderung der Liste IMHO wenig Sinn macht.
Das Problem ist vielleicht schon, dass diese Optionen keine konkreten Namen haben, welche man in der IDE wiederfinden könnte, oder etwa doch?

[Uwe Raabe]

Zitat:

Zitat von Rollo62 (Beitrag 1532816)

wo sich DEBUG/RELEASE und/oder andere Stellen unterscheiden müssen.

Da liegt genau mein Problem: Ich habe hier diverse Testdateien, bei denen es neben DEBUG und RELEASE auch noch weitere Konfigurationen gibt, und man sich fragen muss, wie die dann in das Schema passen.

Zitat:

Zitat von Rollo62 (Beitrag 1532816)

Ich weiß auch nicht, wie man das am besten im Project Magician unterbringen kann, vielleicht in einer Art "Exclusions-List",
die erstmal für solche Fälle vorgesetzt sein könnte.

Es gibt in der Tat bereits so eine Datei für die Split-Funktion: DprojSplitter.cfg in %APPDARTA%\Embarcadero\BDS\xx.x
Dort stehen die zu splittenden Einträge drin. Existiert keine solche Datei wird ein Standard verwendet.

Aktuell könnte ich mir einen ähnlichen Ansatz vorstellen, bei dem die Nodes für das ClearChildVersionInfo verwendet wird. Damit ließe sich dann aber nur der gesamte Eintrag unter <VerInfo_Keys> ausschließen. Ich weiß auch nicht, ob man wirklich einzelne Einträge dieser Liste vererben kann. Das müsste dann in etwa so aussehen (habe ich aber noch nicht probiert):

Code:

  
  <VerInfo_Keys>
    $(VerInfo_Keys);
    apiKey=xxxx
  </VerInfo_Keys>

Zitat:

Zitat von Rollo62 (Beitrag 1532816)

Das Problem ist vielleicht schon, dass diese Optionen keine konkreten Namen haben, welche man in der IDE wiederfinden könnte, oder etwa doch?

Das wäre dann ja vielleicht in der UI des Project Magician lösbar.

[Rollo62]

Tja, ich muss wohl erstmal damit leben.
Es wird ja immer nur akut wenn es Updates oder neue Versionen gibt.
Der sauberste Weg für mich wäre wohl, wenn man z.B. ein JSON als Mutter aller Settings nimmt und die .dproj daraus erzeugen lässt, ganz ohne diese doch sehr nutzerunfreundlichen IDE Editoren.
Das schliesst den Deployment Editor gleich mit ein.

[Rollo62]

Zitat:

Zitat von Uwe Raabe (Beitrag 1532818)

Es gibt in der Tat bereits so eine Datei für die Split-Funktion: DprojSplitter.cfg in %APPDARTA%\Embarcadero\BDS\xx.x
Dort stehen die zu splittenden Einträge drin. Existiert keine solche Datei wird ein Standard verwendet.

Hallo Uwe, nochmal dazu.

Das geht dann gleich in die komplexe Richtung und wird IMHO deshalb nicht gerne benutzt, wenn es unklar ist, was genau passiert.
Wäre es nicht einfacher, wenn es zusätzliche CheckBoxen geben würde über "Version Info",
welche schonmal für die üblichen Verdächtigen zuständig ist.

Also eventuell, für die, welche man oft anfassen muss oder welche sich sehr wahrscheinlich nie unterscheiden werden:
"Version Info Defaults" ( versionCode, VersionName, CFBundleVersion, CFBundleShortVersionString, .... ) müssen ständig geändert werden
"Version Info Permissions" ( Entitlement List, Uses Permissions, die ganzen NSUsageDescriptions, UIBackgroundModes, ITSAppUsesNonExemptEnryption, .... ) müssen sich IMHO nie unterscheiden
"Version Info Complete" ( der ganze Rest )

Ich würde auch noch "package" und "CFBundleIdentifier" dazunehmen, weil ich keinen Sinn drin sehe, dass dies überhaupt verschieden sein sollte.
Wichtiger wäre mir immer, dass ich mich darauf verlassen kann, dass es in allen Zweigen korrekt gesetzt wurde.

Solche zusätzlichen Checkboxen wären doch leicht machbar.
Was hältst Du davon?
Ich denke, das würde die Arbeit ungemein erleichtern und auch die Portierung auf neue Systeme sehr erleichtern.
(Ich habe jetzt nur mal Android/iOS genommen, es gibt sicher ähnliche Einträge für alle Plattformen).

[Uwe Raabe]

Grundsätzlich bin ich offen für solche Erweiterungen. Mangels eigener Anforderungen bin ich aber darauf angewiesen, dass ich mit jemandem die Details ausarbeiten kann. Wenn du dich da einbringen möchtest können wir das besser auf anderen Kanälen besprechen. Meine Email ist sinngemäß: uwe-uweraabe-de

[Rollo62]

Ok, ich will versuchen, das Verhalten und die relevanten Parameter für alle Plattformen (außer Linux womöglich) rauszuarbeiten,
dann aber nur für die letzte, aktuelle Version.
Im Moment bin ich aber noch zu stark eingebunden, mit den Portierungen und den Deadlines von Apple und Google.
Ich melde mich sobald etwas Luft ist.