So halten Sie die kostenlose / kostenpflichtige Version der App in Subversion getrennt

8

Ich habe eine kostenpflichtige Anwendung auf dem Android-Marktplatz, möchte jedoch eine kostenlose werbefinanzierte Version veröffentlichen.

Der einfachste Weg, dies zu tun, bestand darin, einen Zweig in meinem Subversion-Repository einzurichten, der den zusätzlichen Code zum Hinzufügen der Anzeigen enthält. Als ich dies jedoch auf dem Android-Marktplatz eingereicht habe, sind eindeutige Paketnamen erforderlich. Diese Lösung funktioniert bei mir nicht mehr, da ich das Paket jeder Klassendatei ändern müsste, was das Zusammenführen von Trunk und Branch sehr schmerzhaft machen würde.

Wie kann ich diese beiden Projekte am besten zusammenhalten und Patches gemeinsam nutzen, aber mit einem anderen Paket?

version-control android svn

— Malfist
quelle

1

Nur eine Anmerkung, dass diese Frage hier bei Programmierern nicht vom Thema abweicht. Die Hauptprobleme betreffen Probleme mit der Projektstruktur und dem Konfigurationsmanagement, die beide hierher gehören (und nicht zu Stack Overflow oder einer anderen Site).

— Thomas Owens

9

Haben Sie Compiler-Direktiven in Betracht gezogen ?

Beispiel:

#define FREE
// ...
#if FREE
Console.WriteLine("Free version");
#else
Console.WriteLine("Paid version");
#endif

Sie können genau dieselbe Codebasis beibehalten und die beiden Builds mithilfe von zwei separaten Build-Skripten oder einem parametrierbaren erstellen.

msbuild /p:DefineConstants=FREE

Lesen Sie dies und das , um dies mit Java zu tun . Und vielleicht das hier .

— Gemeinschaft
quelle

Ich dachte nicht, dass Java diese Dinge hörte

— Malfist

Es existiert auch in Java.

@ Pierre303 Es tut mir leid, ich wusste nicht, dass du das kannst. Es löst das Paketproblem immer noch nicht ... hmmm.

— Michael K

1

@MichaelK: Dies ist leicht mit einer gut organisierten Such- und Ersetzungsaufgabe in Ihrem Build-Skript zu erreichen.

Dies löst auch nicht das Problem der bedingten Ressourcen im Ordner / res.

— Donturner

5

Nur Ihr Anwendungspaket muss eindeutig sein. Siehe hier . Das ist das Paket, das in Ihrer Manifestdatei deklariert ist. Sie können den größten Teil Ihres Codes in com.mydomain.myappund nur eine andere Hauptaktivität in haben com.mydomain.myapp.free.

— Karl Bielefeldt
quelle

3

Wenn Sie wirklich getrennt arbeiten möchten, ist es am besten, es als zwei Teile desselben Repositorys einzurichten. Auf diese Weise können Sie zumindest Änderungen in den verschiedenen Zweigen zusammenführen. Wenn Sie die Dinge völlig getrennt halten möchten, werden Sie eine Menge schleppender Patch-Dateien ausführen.

Ich habe das getan und ehrlich gesagt ist es in der Praxis keine großartige Strategie. Insbesondere in kompilierten Umgebungen ist es viel besser, einen separaten Build-Prozess kostenlos und kostenpflichtig zu haben, sodass es statt zwei eine Codebasis gibt. Wenn es zwei Codebases Dinge werden auseinander.

— Wyatt Barnett
quelle

Das ist die Sache, ich möchte nicht, dass sie getrennt werden. Das einzige, was ich separat möchte, ist der zusätzliche Code, der die Anzeigen hinzufügt. Android zwingt mich jedoch, einen eindeutigen Paketnamen für meine App zu haben. Ich wäre also gezwungen, eine größere Änderung vorzunehmen als nur zwei oder drei Dateien.

— Malfist

Vielleicht sollte auch ein kleiner Precompiler-Voodo funktionieren. Build-Systeme sind großartige Dinge.

— Wyatt Barnett

0

Die Versionskontrolle ist eine schlechte Methode, um solche Dinge zu verwalten. Am Ende steht ein Wartungs-Albtraum - zwei separate Anwendungen, die nahezu identisch sein müssen.

Haben Sie eine Lösung für mehrere Projekte in Betracht gezogen? (caveot:.. Ich habe nicht wirklich das getan, aber es scheint möglich, und ich denke , Android es erlaubt , werde ich es versuchen Sie es später und sehen sicher) Kompilieren Sie alle Ihre App - Code in ein Hauptprojekt jar . Erstellen Sie dann zwei separate Android-Apps, eine für Ihre kostenpflichtige Version und eine für die kostenlose Version. Dies wird Ihr Paketbenennungsproblem lösen. Diese Apps werden für so ziemlich alles nur an das Hauptglas delegiert, außer dass Ihre Anzeigenversion den Code zur Unterstützung der Anzeigen enthält.

Sie können auch feststellen , diese Diskussion zu einem ähnlichen Thema interessant.

— Michael K.
quelle

Der Code ist ein kleiner Teil des Gesamtbilds, und das Aufrüsten hilft nicht dabei, alle zusätzlichen Daten wie Ressourcen, Layouts, Assets usw. zu verarbeiten, die damit einhergehen. Dass man nicht alles ordentlich bündeln kann, ist ein unglückliches Manko in Android, und es schmerzt mich, Dinge stempeln zu müssen, die sich nicht viel ändern oder von außen konfiguriert werden können.

— Blrfl

Genau. Sie haben großartige Arbeit geleistet, um das Erstellen kleiner Apps zu vereinfachen, aber das Erstellen großer Apps, die gewartet werden müssen. Es gibt einige Maven-Lösungen, die vielversprechend aussehen, aber ich konnte sie noch nicht zu genau untersuchen.

— Michael K

0

Wenn Sie Ihre App mit einem feature toggleerstellen, können Sie Ihr Ziel erreichen, müssen jedoch möglicherweise viel Code überarbeiten.

Durch Definieren von 2 (ich würde 3 empfehlen) Feature-Container-Umgebung in einer INI-Datei wie:

[paid]
features.ads = false
features.featureOne = true
features.featureTwo = true
features.premiumFeature = true
features.underDevFeature = false
features.debug = false;

[free:paid]
features.ads = true
features.premiumFeature = false

; And the optionnal third
[development:paid]
features.debug = true
features.underDevFeature = true

Auf diese Weise haben Sie eine Version, die einheitlich ist und nur einen Zweig in Ihrer Versionskontrollquelle benötigt

In Ihren spezifischen Skripten müssen Sie dann überprüfen, ob die Funktion autorisiert ist. Wenn nicht, wird sie nicht angezeigt

— JF Dion
quelle