Wir haben eine Anwendung, die selbst kostenlos heruntergeladen werden kann, aber mit kostenpflichtigen, lizenzierten Daten arbeitet. Einige Benutzer kaufen eine bestimmte Version der Daten, während andere sich für eine gewisse Zeit das Recht nehmen, die neuesten Daten zu verwenden. Während die Anwendung weiterentwickelt wird, hört sie schließlich auf, Daten zu unterstützen, die älter als ein Datum sind. Also offensichtlich Benutzer, die diese Daten lizenziert haben, aber keine Lizenz für neuere Daten wollen nicht upgraden. Aber wenn wir eine neue Version auf dem Markt veröffentlichen, würden sie es sehen und wenn sie upgraden, werden sie Probleme haben, zurück zu der Version zu degradieren, die tatsächlich für sie funktioniert.
Können wir die Marktanwendung irgendwie anweisen, keine Upgrades für bestimmte Benutzer oder Hacks anzubieten, um dieses Ziel zu erreichen?
Wir verwenden zur Zeit Mechanismen, die völlig unabhängig vom Markt sind, um Lizenzen für die Daten zu verkaufen und zu prüfen, könnten aber andere Mechanismen (wie Android-In-App-Billing-Support oder etwas anderes) in Erwägung ziehen, um das Problem zu lösen.
Ich habe eine Option gefunden, dass der Markt ein Installationsprogramm enthält, das ein weiteres .apk herunterlädt und installiert, das den Kern der Anwendung lokal enthält.
Wir haben bereits einen Installer-Dialog in der Anwendung zum Herunterladen der Daten und der Benutzer muss ihn eingeben, wenn er die Anwendung zum ersten Mal benutzt, damit er auch für den Anwendungskern verantwortlich gemacht werden kann.
Wie ich es sehe, haben Sie zwei Möglichkeiten, Upgrades zu "deaktivieren":
Die zweite Option ist möglicherweise eine bessere Übereinstimmung, da Sie Upgrades ggf. für Bug-Fixes durchführen können, aber auch sicherstellen können, dass vollständig neue Versionen nicht als Upgrade erkannt werden.
BEARBEITEN:
Ich stimme völlig zu, dass die oben genannten Optionen umständlich sind und das Problem nicht wirklich lösen, wie es ist.
Wie Sie bereits erwähnt haben, könnten Sie In-App-Abrechnung , aber angesichts der Art Ihrer Anforderungen müssten Sie nicht verwaltete Käufe verwenden, was bedeutet, dass Sie eine Infrastruktur benötigen, um die Autorisierung von Käufen zu verwalten und zu verhindern, dass Benutzer dieselbe Lizenz zu oft kaufen.
Ich vermute, Sie haben bereits einen Großteil dieser Infrastruktur, um die Verteilung der Daten zu bewältigen.
Können die Daten am Anfang der Datei keine "Formatversion" -Nummer enthalten?
Dann können Sie die App so programmieren, dass sie Dateien der Version 1 liest, eine neue App benötigt mehr Felder in der Datenquelle, also erstellen Sie Daten der Version 2, die zusätzliche Felder hinzufügen, Version 1 App, die Daten benötigen eine neuere App, also weist den Benutzer an, zu aktualisieren.
Die App der Version 2 sollte wissen, wie man Dateien der Version 1 und der Version 2 liest (vielleicht eine Leserschnittstelle erstellen und Loader für die verschiedenen Dateiversionen implementieren).
Sie müssen die fehlenden Daten in v1 / alten Dateien im Loader in der v2 App behandeln. Das Laden älterer Dateien ist für den Kunden der angenehmste Weg, da die App nach einem Upgrade nicht mehr aufhören soll.
Wenn Sie eine Kopie der Daten jedes Formats behalten, können Sie schnell Tests ausführen, um zu überprüfen, ob der Loader der neuen Version jede Datei korrekt laden kann. Wenn die App einen Fehler enthält, müssen Sie nicht einfach mehrere App-Versionen reparieren der aktuelle.
Ok .. Ich habe gesehen, dass eines der Poster andeutet, dass Sie die alten Daten lesen können.
Zuerst ist das wahrscheinlich die beste Option, aber wie du sagst, sind deine Apps ein Durcheinander.
Sie sollten etwas Zeit in die Migration Ihrer Daten lesen / schreiben auf eine Abstraktionsschicht investieren. Der Schmerz, den Sie auf einem (wahrscheinlich weniger als 4 Jahre alten Projekt) haben, wird nur noch schlimmer werden.
Okay ... also hier ist, wie ich es in langlebigen Apps behandelt habe.
Erstellen Sie einen Migrationspfad. Erstellen Sie einen neuen Klassenaufruf. Migrieren. In ihm haben mehrere Funktionen, um die Version der Datei von n zu n-1 zu konvertieren convert_1_to_2 (Dateiname) {Überprüfen Sie die Version und aktualisieren Sie die Daten.) convert_2_to_3 (Dateiname) ...
Ich vermute, dass Sie Ihren alten Code haben, und Sie könnten eine Methode schreiben, um ein Datenbit in das nächste umzuwandeln. Wenn Sie den Daten neue Funktionen hinzufügen, erstellen Sie eine neue Konvertierung. Es ist keine Kenntnis der früheren erforderlich, und alles wäre nett und eigenständig. Sie könnten sogar Submigrationen haben, also könnten Sie convert_3a_to_3b haben, also einen Teil entlang des Entwicklungszyklus.
Jetzt ... könnten Sie die ursprüngliche Version der Daten archivieren, falls der Benutzer zurückgehen möchte.
Wenn auf die Daten remote zugegriffen wird, könnte die App die Version oder einen Hash von sich selbst enthalten, wenn Sie sie anfordern. Und dann filtern Sie die bereitgestellten Daten basierend auf diesen Informationen.
Wenn Sie bereits über In-App-Käufe und die entsprechende Infrastruktur verfügen, müssen Sie nur nach neuen Daten suchen, wenn die App aktualisiert wird. Wenn der Benutzer die Lizenz für aktuelle Daten erworben hat, geben Sie diese an. Ansonsten fahre einfach mit den vorhandenen Daten fort.
Tags und Links android google-play