2012-01-15 17 views
6

de Google market_billing sample, al igual que otros como this one, se conecta al servicio remoto IMarketBillingService a través de un contenedor de servicio local de , BillingService.¿Por qué otro servicio además de IMarketBillingService?

Entiendo que los servicios tienen la ventaja de hacer cosas en segundo plano, pero ¿no es el control remoto IMarketBillingService suficiente?

¿Cuál es la ventaja de agregar otra capa a esta cebolla?

¿Qué puedo perder si trato de conectarme con el control remoto IMarketBillingService directamente desde mi actividad principal, en el hilo de la interfaz de usuario?

Si no es aconsejable conectarse al control remoto IMarketBillingService directamente en el hilo de la interfaz de usuario, ¿se puede reemplazar el BillingService local por otro hilo en la actividad principal?

Respuesta

1

El servicio de facturación local maneja las devoluciones de llamadas de IMarketBillingService cuando su actividad no se está ejecutando.

La referencia (http://developer.android.com/reference/android/app/Activity.html) dice:

"Si está en pausa o se detiene, el sistema puede dejar caer la actividad de la memoria, ya sea que le pide finalizar, o simplemente matando a su proceso Cuando una actividad. se vuelve a mostrar al usuario, debe estar completamente reiniciado y restaurado a su estado anterior ".

Si, por ejemplo, invoca una solicitud de facturación RESTORE_TRANSACTIONS, las respuestas de Android Market Service pueden tardar un poco en llegar. Al utilizar un servicio, usted sabe que siempre estará cerca para manejar las respuestas, independientemente del ciclo de vida de la actividad.

Solo por diversión, traté de escribir una pequeña aplicación de prueba y estaba seguro. Un hilo en ejecución puede invocar métodos en una actividad detenida o detenida. El hilo también puede modificar su interfaz de usuario, incluso cuando la actividad no está en primer plano. Ejecute la siguiente aplicación, presione la pantalla de inicio para detener la aplicación. Regrese después de 10 segundos, y vea que TextView ha cambiado ...

package com.example.playground; 

import android.app.Activity; 
import android.os.Bundle; 
import android.util.Log; 
import android.widget.TextView; 

public class MyActivity extends Activity { 

    private static String TAG = MyActivity.class.getName(); 

    /** 
    * Called when the activity is first created. 
    */ 
    @Override 
    public void onCreate(Bundle savedInstanceState) { 
     super.onCreate(savedInstanceState); 
     setContentView(R.layout.main); 

     Thread t = new Thread(new Runnable() { 
      public void run() { 
       try { 
        Thread.sleep(10000); 
        someMethod(); 
       } catch (InterruptedException e) { 
        Log.e(TAG, e.getMessage(), e); 
       } 
      } 
     }); 
     t.start(); 
    } 

    private void someMethod() { 
     Log.d(TAG, "Some method called"); 
     TextView tv = (TextView) findViewById(R.id.textfield); 
     tv.setText("Called later"); 
    } 
} 
+2

Gracias +1 ya por una gran respuesta. La necesidad de un servicio está bien explicada y ejemplificada aquí * pero ... * ¿no es suficiente un solo servicio ('IMarketBillingService')? ¿Por qué dos? ¿Por qué tanto local * como * remoto? –

+0

Si observa el IMarketBillingService, se declara como interfaz pública. IMarketBillingService amplía android.os.IInterface. Esto no es un servicio, solo un stub que usa para comunicarse con el Servicio remoto, en realidad se ejecuta en la aplicación Android Market si no me equivoco. La parte de "Servicio" del nombre de Classe es confusa. –

Cuestiones relacionadas