In-App billing per comuni mortali puntata 3 – Le richieste

 Come fare le richieste – Ecco appunto Come farle? 🙂

A questo punto abbiamo tutti gli strumenti base per cominciare a fare le nostre richieste al MarketBillingService.

Come avevamo detto le richieste si faranno mediante il metodo sendBillingRequest, questo metodo come argomento prende un Bundle per la richiesta, e ne torna uno sincrono con la risposta.

Il Bundle della richiesta é composto minimo da tre campi:

  • BILLING_REQUEST (stringa)- che contiene il tipo di richiesta che andremo a fare (CHECK_BILLING_SUPPORTED, REQUEST_PURCHASE, etc)
  • API_VERSION (intero)- La versione delle API del servizio che andremo ad usare, al momento che sto scrivendo questo articolo vi sono solo due versioni di API (versione 1 e 2) , la 2 si differenzia dalla 1 perche contiene il nuovo servizio di Subscription tramite l’in-app billing, che nion andremo a vedere in questa guida, comunque.
  • PACKAGE_NAME (stringa) – il nome del package che sta effettuando la richiesta

Quindi supponiamo che sia il pcakage name e la versione delle API che vogliamo usare siano sempre le stesse,  l’unico campo che varierá per le richieste sará BILLING_REQUEST.

Per esempio il package dell’applicazione sará com.italialinux.billing e la versione delle API che stiamo utilizzando sia la  1. Visto che per ogni richiesta noi dovremo sempre aggiungere questi tre parametri la cosa migliore da fare é creare un metodo che lo fará per noi, che a questo punto prenderá solo un argomento che indicherá il metodo del market che vogliamo invocare (Per la lista dei metodi disponibili vi rimando al paragrafo Come fare le richieste – Binding del servizio).

protected Bundle makeRequestBundle(String method) {
    Bundle request = new Bundle();
    request.putString("BILLING_REQUEST", method);
    request.putInt("API_VERSION", 1);
    request.putString("PACKAGE_NAME", getPackageName());
    return request;
}

Con il Bundle  che vi viene tornato da questo metodo noi possiamo o effettuare direttamente la richiesta per i metodi che non prendono parametri aggiuntivi, o aggiungere eventuali parametri mancanti e procedere con l’invio della richiesta. Un esempio di iterazione con la makeRequestBundle é:

   Bundle request = makeRequestBundle(requestedmethod);
   Bundle response = myBillingService.sendBillingRequest(request);

La risposte sincrone possono contenere le seguenti chiavi:

  • RESPONSE_CODE Indica lo stato della nostra richiesta (se é stata consegnata correttamente). Notare che non ha nulla a che vedere con l’esito della transazione, se riceviamo un RESPONSE_OK vuol solo dire che la nsotra richiesta é stata consegnata correttamente.
  • PURCHASE_INTENT Questa viene generata nel caso facciamo una REQUEST_PURCHASE e contiene l’intent che verrá mostrata per eseguire l’acquisto effettivo del nostro componente.
  • REQUEST_ID Indica l’id della richiesta, utile per gestire le risposte asincrone.

I valori aggiuntivi nelle risposte si potranno avere utilizzando i metodi getInt, getLong, getParceleable, etc della classe bundle, per esempio per ottenere il valore del RESPONSE_CODE che é un intero avremo una riga di codice simile alla seguente:

int code = response.getInt("RESPONSE_CODE");
Il caso del PURCHASE_INTENT lo speigheremo piú avanti.

Gestire le risposte asincrone

Bene ora che abbiamo visto come fare le richieste, passiamo alla fase successiva quella in cui andremo a occuparci delle risposte asincrone. Come abbiamo visto durante la fase di modifica del Manifest, le risposte asincrone che possono essere spedite dal servizio in-app billing le ricordiamo e sono:

  • com.android.vending.billing.RESPONSE_CODE
  • com.android.vending.billing.IN_APP_NOTIFY
  • com.android.vending.billing.PURCHASE_STATE_CHANGED

Questo tipo di risposte vengono gestite dal nostro BroadCastReceiver. Che ricordo é stato definito nel manifest:

<receiver android:name=".billing.ItalialinuxBillingReceiver">

oltre a questo abbiamo appunto definito a quali messaggi Broadcast dovrá rispondere la nostra classe. Quindi iniziamo con il creare lo scheletro di ItalialinuxBillingReceiver:

public class ItalialinuxBillingReceiver extends BroadcastReceiver  {
	private static final String TAG = "ItalialinuxBillingReceiver";
 
	@Override
	public void onReceive(Context context, Intent intent) {
	}
 
}

Non é scopo di questo articolo spiegare come funzionano i BroadcastReceiver (se vi interessa saperne un pó di piú consultate la pagina relativa sul sito di android: http://developer.android.com/reference/android/content/BroadcastReceiver.html) quello che ci basta sapere in questa sede é che il metodo onReceive() (ereditato dalla classe astratta BroadcastReceiver) é quello che viene chiamato ogni volta che si riceverá il/i messaggio/i di BroadCast che abbiamo dichiarato nel manifest (in questo caso appunto RESPONSE_CODE, IN_APP_NOTIFY e PURCHASE_STATE_CHANGED).

Per sapere quale é l’azione che é stata ricevuta ci basta usare il metodo getAction a partire dalla intent che viene passata al metodo onReceive. Quindi una volta ottenuto l’intent dovremo fare delle cose diverse a seconda del tipo che abbiamo ricevuto. Dal momento che le azioni altri non sono delle stringhe, ci basterá fare una semplice serie di confronti fra stringhe. Quindi aggiorniamo il nosto metodo onReceive:

	@Override
	public void onReceive(Context context, Intent intent) {
            String action = intent.getAction();
            if(action.equals("com.android.vending.billing.RESPONSE_CODE")){
                //do something
            } else if(action.equals("com.android.vending.billing.IN_APP_NOTIFY")) {
                //do something
            } else if(action.equals("com.android.vending.billing.PURCHASE_STATE_CHANGED"){
                //do something
            }
	}

Questi saranno i soli casi che dovrá gestire la nostra classe. Vi ricordo che il BroadcastReceiver si occupa di gestire i messaggi asincroni che arrivano dal market, mentre il servizio gestisce i messaggi che la nostra applicazione deve spedire al market e gestisce anche le risposte Sincrone. Quindi quello che succederá sará che il nostro receiver  normalmente invierá le istruzioni al servizio su quale richiesta é stata ricevuta, le informazioni extra contenute e quale azione dovrá intraprendere.

Per oggi ci fermiamo qui, la prossima volta cominceremo una carrellata sui comandi disponibili.

3 thoughts on “In-App billing per comuni mortali puntata 3 – Le richieste”

    1. Ciao,
      sai che mi ero quasi dimenticato di questo tutorial!
      In realtá lo devo finire, almeno due capitoli, il quarto è quasi pronto, visto che ho scoperto qualcuno interessato potrei pubblicarlo, e appena ho cinque minuti terminare anche l’ultima parte.

Leave a Reply

Your email address will not be published. Required fields are marked *