Was möchte mir die Doku hier sagen... (Thema: IAB)

Hallo,
kann mir jemand sagen was die Doku zum Thema Security & Design (für In App Billings) vermitteln soll, wenn dort steht:

• Inline methods into other methods.
• Construct strings on the fly instead of defining them as constants.
• Use Java reflection to call methods.

Zum Vergrößern anklicken....

würde den Coder "geeigneter" für Proguard machen...

Je ausführlicher desto besser. Ich habe mir den Text jetzt 3x durchgelesen und werde nicht so wirklich schlau draus(, um nicht zu sagen, dass sie ihn auch in Chinesisch hätten abdrucken hätten können.)

Nachtrag:
Gerade mit Punkt 2 tue ich mir extrem schwer.. Heißt es, wenn man eine "Helfer-Klasse" anlegt, in der man seine Variablen speichert, beeinträchtigt das die Sicherheit?

Vielen Dank vorab

Hi,

eigentlich steht da ja nur, du sollst sehr hässlich programmieren, damit es kein anderer mehr durch Recompiling lesen kann.
Bei "Inline methods" könnte ich mir auch inner Classes vorstellen.
Bei Punkt zwei bedeutet es wohl, dass du keine Strings in Konstanten schreiben sollst.
Also:
public static final String NAME = "mein Name";

Ist nicht so gut, da man es aus dem Code schnell herauslesen kann.

Wenn ich was kann, dann ist es hässlich programmieren
Im Prinzip, hatte ich mir das mit Punkt 2 schon gedacht, aber wollte nochmal sicher gehen. Finds ein bisschen schade, denn hin und wieder hat man einen kleinen Tippfehler im String und schon wird der Alarm nicht ausgelöst, die Einstellung nicht gezogen etc... dafür habe ich immer gerne eine "statische Quelle" - wohl wissend dass diese Programmierweise bei Portalen wie SO absolut in Verruf ist, da die einzelnen Bestandteile in der Anwendung bekanntlich schlecht bzw. nicht austauschbar sind. Meiner Meinung nach halten sich Vor und Nachteile praktisch die Waage (jedenfalls bei meinen Projekten)
Dass sich ein Programm mit dem Unkenntlichmachen von Zeichenketten schwierig tun könnte, macht da für mich schon mehr Sinn, wird aber seltsamerweise wohl kaum so als Grund angeführt.^^
Naja, egal. Ich weiß auf jeden Fall schon Bescheid.

Danke dir

Nachtrag:
Irgendwie kann ich mich von dem Gedanken nicht verabschieden, dass man die Strings nicht dauerhaft irgendwie speichern kann/soll. Gibt es vielleicht noch eine andere Möglichkeit die "Kennungen" in der Anwendung (möglichst sinnvoll) zu verwalten und zu übertragen?
Auf die Schnelle wäre meine Idee jetzt, es mit einer HashMap darzustellen und dann daraus die Werte zu ziehen, praktisch als eine Art "Übersetzer". Die Map kann ja als Member für jede Klasse unstatisch und private existieren und somit sollte es auch nach außen unsichtbar sein, was in der Klasse passiert, bzw. welche Strings nun jetzt an Methode XY gehen.
Allerdings kommt mir die Idee als etwas stümperhaft vor, da sinnlos Speicher verbraten wird (auch wenn dieser wahrscheinlich schneller wieder gesäubert wird, da ja in vielen Fällen nicht alle Klassen über die Laufzeit aufgerufen werden müssen). Wäre jetzt jedenfalls mein Bauchgefühl.