App Bezahlversion/Lightversion

  • 9 Antworten
  • Letztes Antwortdatum
D

Droidspirit

App-Anbieter (In-App)
50
Hallo,

es gibt ja einmal die Möglichkeit eine App als Light-Version und zusätzlich als kostenpflichtige Vollversion in den Market zu stellen.

Die Leute laden sich zuerst die Light-Version und wenn sie damit zufrieden sind, laden sie sich die Vollversion aus dem Market und deinstallieren die Light-Version.

Das ist ja weitestgehend das häufigste Vorgehen.

Wenn ich nun aber Daten in meiner Light-Version anlege und diese in die Vollversion übernehmen möchte, müßte ich quasi einen Export/Import machen.

Oder aber ich stelle im Market eine Bezahlversion zur Verfügung, die aber nur als "Lizenz" gilt und kaum Funktionalität bietet. Man kauft sich nun also die Bezahlversion. Die Light-Version prüft nun, ob die Bezahlversion installiert ist und schaltet anschließend die App von Light auf Voll. So spart man sich den Export/Import der Daten.

Der Nachteil hierbei wäre halt, das der User, der die Bezahlversion von vornherein kaufen möchte, sich zuerst die Light-Version runterladen und dann _nochmal_ die Voll-Version kaufen muß. So hat er quasi 2 Market-Vorgänge abzuhandeln. Das wäre insofern blöd, wenn man sich z.B. solche Rabatt-Aktionen ansieht, wie es bei Google aktuell der Fall ist. Man kann sich also nicht "einfach" nur die Vollversion laden.


Eine dritte Möglichkeit wäre noch den InApp-Kauf, über den man die Anwendung dann zu einer Vollversion wandeln kann. Damit habe ich mich bis jetzt aber noch nicht auseinander gesetzt. Hier ist z.B. auch noch die Frage, in welcher Kategorie die App am Ende auftaucht. Nutzt man InApp-Käufe, wird die App ja nicht mehr als kostenlos eingestuft.

Hat hier jemand schonmal damit Erfahrung gemacht? Was ist praktikabel? Was gibt es noch zu beachten?

Viele Grüße
 
Zuletzt bearbeitet:
Also ich habe die Variante mit einer Trial & Full gewählt...
Es wird immer auf der Fullversion entwickelt (de.ErniSoft.Remote)...
Für die Trial (de.ErniSoft.Remote.Trial) werden ein Paar "Schalter" umgelegt und einige Anpassungen gamacht (Weil sich das Packet im Manifest geändert hat...)

Welche Variante man wählt hängt davon ab was für eine App man anbietet.
Ich wollte das man die ganze Funktionalität testen kann und habe deshalb die Trial mit vollem Funktionsumfang auf 45min beschränkt.

Grüsse
 
Ich hatte mir zuerst überlegt eine Demo anzubieten. Zwar mit vollem Funktionsumfang, aber mit einem vorgegeben "Beispiel". Aber das halte ich für nicht praktikabel.

Daher setze ich jetzt auf die Light-Version, die zwar vollen Funktionsumfang bietet, lediglich in der Menge der anzulegenden Objekte eingeschränkt ist. In der Light-Version kann man z.B. nur 2 Fotos pro "Fall" anlegen und es werden halt Ads eingeblendet.

Entwickeln tue ich auch nur in einer Version. Anhand des Package-Namens ermittel ich, um welche Version es sich handelt.
 
Hi,

ich hatte damals auch die Lösung Kostenlos / Premium Version gewählt (da gab es auch noch keine InApp Käufe), bin damit aber nicht glücklich. Wenn ich wieder etwas Zeit übrig habe, wechsel ich zu einer Version mit InApp Käufen.

Die Gründe sind einfach: Kommentare und Bewertungen werden nicht auf zwei Apps aufgeteilt, die Wartung für eine App fällt weg, der Kunde muss keine zwei Apps laden und am Ende verwirrt es ihn nicht, wenn er zwei Apps installiert hat.

Soweit ich weiß, werden diese Apps unter den kostenlosen geführt (sieht man ja egtl. im Store bei mehreren Apps).
 
die Frage ist halt wie man das ganze dann bewerkstelligt ...hast du dazu vielleicht eine Anleitung wie man das machen kann? Also ich denke gerade daran das man einige Funktionen mit einen booleanschen Wert versieht und eben wenn der auf true gesetzt ist dann die sachen anbietet. Nur wie wird das dann realisert? Wird wenn der Benutzer es gekauft hat, eine Art update nach geschoben oder wie? Weil man muss ja dann den source code aktualisieren.
 
Wie gesagt, ich habe es noch nicht gemacht, aber prinzipiell sollte man das mit Fragments ziemlich gut lösen können. Ich bin sowieso ein Freund von Fragments, Logik lager ich gerne in ein Non-UI Fragment aus.

Man müsste halt beim Start der Activity abfragen, ob der InApp Kauf getätigt wurde und dann das Light oder Premium Fragment laden. Ist meiner Meinung nach der beste Ansatz.

Andere Ideen?
 
Also wenn ich das nun richtig überflogen hab gibt es einen sogenannten Request wenn man so nen in-App Kauf getätigt hat und mit diesem Request kann man ja dann die Paramter in der App steuern.
 
Ich habe das etwas anders verstanden. Korrigiere mich, wenn ich falsch liege.

In-app Billing Overview | Android Developers

Hier siehst du die grundsätzliche Architektur des InApp-Billing. Demnach erhält der BroadcastReceiver bzw. BillingReceiver alle "Abrechnungen" von GooglePlay. Beim BroadcastReceiver kommt also die relevante Information an, welche Dinge gekauft wurden. Mit diesen Informationen musst du nun selber dafür sorgen, dass deine App entsprechend aktualisiert wird. Dabei hilft dir Google nicht weiter.

In-app Billing Reference | Android Developers

Hier ist genauer beschrieben, welche Intents von Google Play an deine App geschickt werden. Um diese zu erhalten braucht deine App wie gesagt einen BraodcastReceiver.

So ganz durchgestiegen bin ich auch nicht... wenn du mehr raus findest, dann freue ich mich über ein Update ;)
 
ja genau das ist ja der Knackpunkt wenn du da vom Play Store diesen Intent bekommst kannst du ja dementsprechend reagieren und deine Parameter im Programm aktualisieren
 

Ähnliche Themen

G
Antworten
0
Aufrufe
148
Gerdchen07
G
G
Antworten
1
Aufrufe
393
Gerdchen07
G
G
Antworten
13
Aufrufe
620
Gerdchen07
G
L
Antworten
3
Aufrufe
657
mips400
mips400
migi01
Antworten
26
Aufrufe
2.037
migi01
migi01
Zurück
Oben Unten