© Excellent backgrounds/Shutterstock.com
Java Magazin
Wie kann ich mit meiner App Geld verdienen?

In-App Billing reloaded!

Generell gibt es da zwei Varianten: Entweder ich schalte in meiner App Werbung oder ich bringe meine Nutzer dazu, für meine App zu bezahlen. Letzteres ist gar nicht so einfach. Das Standardmodell, dass ich meine App in einer kostenlosen „Lite“-Version und einer kostenpflichtigen „Pro“-Version anbiete, ist zwar einfach zu realisieren, führt aber dank hoher Hürde (Benutzer muss erneut in den Play Store und die App suchen und installieren) selten zum Erfolg. Vielversprechender ist da schon das In-App Billing, bei dem der Benutzer einfach direkt in der App durch Bestätigung eines Knopfs den Kauf der Pro-Version durchführen kann. Leider ist diese Variante für den Entwickler deutlich komplexer und schwieriger umzusetzen. Grund genug, das neue In-App-Billing-API näher zu beleuchten.

Arne Limburg, Lars Röwekamp


In-App Billing wurde zum ersten Mal im März 2011 veröffentlicht [1]. Seit diesem Zeitpunkt gibt es die Möglichkeit, aus der eigenen App heraus über den Google Play Store Erweiterungen zu verkaufen. Seither hat sich viel getan. Die verbreitetste Version des In-App-Billing-API ist aktuell die Version 2, seit Dezember letzten Jahres ist aber auch Release 3 verfügbar. Wie lässt sich In-App Billing in die eigene App integrieren? Wo liegen die Unterschiede zwischen Version 2 und 3 und lohnt sich ein Umstieg? Diese Kolumne wird Antworten auf diese Fragen liefern.

Komplexe Architektur in Version 2

Die Version 2 des In-App-Billing-API ist komplett asynchron und kommuniziert über Broadcast Intents mit der Applikation. Dieser Ansatz wirkt zwar auf den ersten Blick elegant und sinnvoll, weil es sich bei dem Billing-Aufruf ja um einen Remote-Call handelt, der sich direkt mit Googles Server für die Kaufabwicklung verbindet. In der Praxis erweist sich diese Architektur aber als äußerst unpraktisch, weil so viele Komponenten implementiert und registriert werden müssen, um In-App Billing zu realisieren [2].

Die Komponente in Android, die für das In-App Bill­ing in der Version 2 zuständig ist, ist der IMarketBill­ingService, an den man sich wie in Android gewohnt, binden kann (Listing 1).

Listing 1private boolean bindToMarketBillingService() { String action = "com.android.vending.billing.MarketBillingService.BIND" return bindService( new Intent(action), serviceConnection, Context.BIND_AUTO_CREATE); }

Der Service besteht im Wesentlichen nur aus der Methode sendBillingRequest, die sowohl als Parameter ein Bundle erwartet, als auch als Ergebnis ein Bundle liefert. Das Ergebnis-Bundle enthält allerdings nur einen Statuscode. Die tatsächliche Antwort erfolgt, wie bereits erwähnt, asynchron über ein Broadcast, sodass auch noch ein Broadcast Receiver implementiert und registriert werden muss. Damit nicht genug: Die Regeln zur Implementierung eines Broadcast Receivers besagen, dass dieser nur sehr kurz laufen darf, damit er nicht vom Android-System beendet wird. Daher sollte die tatsächliche Abwicklung des In-App Billing nicht im Broadcast Receiver erfolgen, sondern in einem separaten Service, der dann auch noch implementiert werden muss. Bei dem hier beschriebenen Aufwand handelt es sich nur um den Aufwand, der betrieben werden muss, um das In-App Billing abzuwickeln.

Zusätzlich sollte man bei jedem Start der App überprüfen, welc...

Java Magazin
Wie kann ich mit meiner App Geld verdienen?

In-App Billing reloaded!

Generell gibt es da zwei Varianten: Entweder ich schalte in meiner App Werbung oder ich bringe meine Nutzer dazu, für meine App zu bezahlen. Letzteres ist gar nicht so einfach. Das Standardmodell, dass ich meine App in einer kostenlosen „Lite“-Version und einer kostenpflichtigen „Pro“-Version anbiete, ist zwar einfach zu realisieren, führt aber dank hoher Hürde (Benutzer muss erneut in den Play Store und die App suchen und installieren) selten zum Erfolg. Vielversprechender ist da schon das In-App Billing, bei dem der Benutzer einfach direkt in der App durch Bestätigung eines Knopfs den Kauf der Pro-Version durchführen kann. Leider ist diese Variante für den Entwickler deutlich komplexer und schwieriger umzusetzen. Grund genug, das neue In-App-Billing-API näher zu beleuchten.

Arne Limburg, Lars Röwekamp


In-App Billing wurde zum ersten Mal im März 2011 veröffentlicht [1]. Seit diesem Zeitpunkt gibt es die Möglichkeit, aus der eigenen App heraus über den Google Play Store Erweiterungen zu verkaufen. Seither hat sich viel getan. Die verbreitetste Version des In-App-Billing-API ist aktuell die Version 2, seit Dezember letzten Jahres ist aber auch Release 3 verfügbar. Wie lässt sich In-App Billing in die eigene App integrieren? Wo liegen die Unterschiede zwischen Version 2 und 3 und lohnt sich ein Umstieg? Diese Kolumne wird Antworten auf diese Fragen liefern.

Komplexe Architektur in Version 2

Die Version 2 des In-App-Billing-API ist komplett asynchron und kommuniziert über Broadcast Intents mit der Applikation. Dieser Ansatz wirkt zwar auf den ersten Blick elegant und sinnvoll, weil es sich bei dem Billing-Aufruf ja um einen Remote-Call handelt, der sich direkt mit Googles Server für die Kaufabwicklung verbindet. In der Praxis erweist sich diese Architektur aber als äußerst unpraktisch, weil so viele Komponenten implementiert und registriert werden müssen, um In-App Billing zu realisieren [2].

Die Komponente in Android, die für das In-App Bill­ing in der Version 2 zuständig ist, ist der IMarketBill­ingService, an den man sich wie in Android gewohnt, binden kann (Listing 1).

Listing 1private boolean bindToMarketBillingService() { String action = "com.android.vending.billing.MarketBillingService.BIND" return bindService( new Intent(action), serviceConnection, Context.BIND_AUTO_CREATE); }

Der Service besteht im Wesentlichen nur aus der Methode sendBillingRequest, die sowohl als Parameter ein Bundle erwartet, als auch als Ergebnis ein Bundle liefert. Das Ergebnis-Bundle enthält allerdings nur einen Statuscode. Die tatsächliche Antwort erfolgt, wie bereits erwähnt, asynchron über ein Broadcast, sodass auch noch ein Broadcast Receiver implementiert und registriert werden muss. Damit nicht genug: Die Regeln zur Implementierung eines Broadcast Receivers besagen, dass dieser nur sehr kurz laufen darf, damit er nicht vom Android-System beendet wird. Daher sollte die tatsächliche Abwicklung des In-App Billing nicht im Broadcast Receiver erfolgen, sondern in einem separaten Service, der dann auch noch implementiert werden muss. Bei dem hier beschriebenen Aufwand handelt es sich nur um den Aufwand, der betrieben werden muss, um das In-App Billing abzuwickeln.

Zusätzlich sollte man bei jedem Start der App überprüfen, welc...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang