2012-04-26 9 views
5

Tengo una aplicación VOIP, necesito iniciar sesión en segundo plano en el inicio del dispositivo.Android: Hacer inicio de sesión de aplicación en segundo plano en el arranque

Actualmente el inicio de mi aplicación se realiza en UI Activo (onCreate()).

Tengo las siguientes cosas en mente, ¿alguien puede ayudar y aclarar mis dudas.

  1. ¿El diseño del servicio es imprescindible para lograr esta tarea?
  2. ¿Cuál Service Remote(AIDL) o Servicio local y por qué?
  3. ¿Cómo ocurre la interacción UI y Service?
  4. Después de UI está activo ¿quién recibe las retrollamadas? UI o Service?
  5. ¿Debo hacer Service como mi Controller es decir Service a UI datos Pasar Viceversa?

Aplicación de ejemplo: Skype.

Respuesta

5

Así que hay muchas maneras de lograr lo que desea, es una cuestión de lo que se adapta mejor a su estilo y diseño. Es de esperar que encuentre útil esta información.

  1. Para que la aplicación inicie sesión en segundo plano durante el inicio, hay algunas opciones. Lo primero que necesitará es un BroadcastReceiver que se define como un receptor en el manifiesto. Haga que BroadcastReceiver capte el intento ACTION_BOOT_COMPLETED. Desde aquí puede iniciar su Servicio. Esto lleva al # 2.

  2. Si todo lo que estás haciendo son llamadas RESTful entonces realmente un IntentService sería ideal. La diferencia entre IntentService y Service es simple: IntentService se ejecuta fuera del hilo principal, ejecuta su 'código' y muere. Un servicio, sin embargo, se ejecuta en el hilo principal (esto es un hecho importante) y se ejecuta durante mucho tiempo, por lo que debe indicarse al stopSelf(). Para llevar las cosas más lejos, es menos probable que se mate un Servicio en comparación con una Actividad (los componentes de la aplicación se eliminan para dejar espacio en la memoria para las aplicaciones recién lanzadas), es decir. toma mayor precedencia. El servicio también se puede declarar como un servicio foreground que requiere una notificación pero otorga una precedencia aún mayor. Creo que en su caso un Servicio sería perfecto.

  3. Una vez que se abra su UI (Actividad), la mejor manera de conectarse al Servicio sería el Binder. Esto permitirá múltiples interfaces al Servicio desde diferentes aplicaciones/componentes si es necesario. AIDL es bastante genial, pero por mi experiencia es mucho más difícil de manejar ya que todos los parámetros deben ser primitivos o Parcables. AIDL también es más lento y menos eficiente porque es realmente una forma de IPC. Cuando un Servicio se inicia con un intento, se llama al método onStartCommand(). Si el servicio se inicia con una aplicación que intenta enlazarse, se llama al método onBind(). Pero puede iniciar el Servicio con Intento y luego vincularlo. Si prefiere el enfoque RESTful donde solo tiene llamadas rápidas de datos, puede usar un servicio de intención con un ResultReceiver. This is a great article escrito sobre ejemplos de E/S de Google y, en general, bien implementado si está interesado en IntentService y ResultReceiver.

  4. Depende de usted. Al usar el Cuaderno o AIDL, tu Actividad puede llamar a los métodos de Servicio al igual que el método de objeto donde la 'devolución de llamada' sería simplemente el retorno del método. Si usa un receptor de resultados, la actividad que interactúa con el receptor sería la devolución de llamada. También podría pasar Intents de un lado a otro, pero esto podría ser complicado. Nuevamente para su caso, el enfoque de Binder sería bueno y también un Receptor.

  5. Considere el Servicio como un modelo en el sistema MVVM: úselo como un ayudante para obtener datos, no como algo que controle la lógica de la aplicación.

Disculpe si esto parece complicado, hay tantas maneras de lograr lo que está buscando. Es solo una cuestión de lo que mejor se adapte a tu situación, lo que "sientes" es mejor. Sin mencionar que el Android SDK es bastante grande. Traté de abordar todos los temas que podrían ayudarte. ¡Buena suerte!

+0

La respuesta es relevante para mi pregunta, por lo que lo marque como respuesta. Gracias jjNford – NitZRobotKoder

+1

@NitZRobotKoder no hay problema, todos los servicios y cómo se utilizan pueden ser complicados. ayuda a saber dónde mirar hacia adelante. ¡buena suerte! – jjNford

0

puede autenticar el inicio de sesión de usuario por servicios de fondo paquete com.javaorigin.android.sample.service;

import android.app.Service; 
import android.content.Intent; 
import android.os.IBinder; 
import android.util.Log; 
import android.widget.Toast; 

public class MyService extends Service { 

    String tag="TestService"; 
    @Override 
    public void onCreate() { 
     super.onCreate(); 
     Toast.makeText(this, "Service created...", Toast.LENGTH_LONG).show();  
     Log.i(tag, "Service created..."); 
    } 

    @Override 
    public void onStart(Intent intent, int startId) {  
     super.onStart(intent, startId); 
     Log.i(tag, "Service started..."); 
    } 
    @Override 
    public void onDestroy() { 
     super.onDestroy(); 
     Toast.makeText(this, "Service destroyed...", Toast.LENGTH_LONG).show(); 
    } 

    @Override 
    public IBinder onBind(Intent intent) { 
     return null; 
    } 
} 


public class SampleAction extends Activity { 
    @Override 
    protected void onCreate(Bundle savedInstanceState) {  
     super.onCreate(savedInstanceState); 
     TextView view = new TextView(this);  
     view.setText("Service Test"); 
     Intent i = new Intent(); 
     i.setClassName("com.javaorigin.android.sample.service", 
     "com.javaorigin.android.sample.service.MyService"); 
     bindService(i, null, Context.BIND_AUTO_CREATE); 
     this.startService(i);  
     setContentView(view); 
    } 
} 
+0

Deepak, u r Iniciando la actividad luego Iniciando el servicio ... Mi aplicación debe iniciar sesión sin UI ... – NitZRobotKoder

+0

¿cómo obtiene el usuario los acuses de recibo? –

+0

Imagine un caso donde el usuario ya lo configuró, y la configuración es como no pregunte por el tiempo de vida ... – NitZRobotKoder

1

Pruebe un servicio con un cargador de arranque. Here is an example que encontré después de una búsqueda rápida en Google. Luego, asegúrese de almacenar en la información de inicio de sesión para cuando se inicie la aplicación. No estoy seguro de las retrollamadas que podría tener, por lo que realmente es difícil responder a esa parte. Diría que si las devoluciones de llamadas afectan la interfaz de usuario, deje que la actividad se haga cargo de ellas cuando se inicie. Si necesita una IU cuando solo se está ejecutando el servicio, probablemente sea mejor lanzar una notificación y hacer que llame a la actividad apropiada con los datos de devolución de llamada.

+0

@Mikelsrael Gracias por su entrada ... Calchacks se trata de éxito/fracaso de la conexión o UP/DOWN de la red, etc. Pero no entendí este contexto de su Comentario ... "Si necesita una IU cuando solo el servicio se está ejecutando, probablemente sea mejor lanzar una notificación y hacer que llame a la actividad apropiada con los datos de devolución de llamada ". – NitZRobotKoder

+1

@NitZRobotKoder Estaba diciendo que una buena manera de lidiar con la notificación al usuario es a través de la barra de notificaciones. Así que solo haga un servicio que intente iniciar sesión y se registre como un receptor de difusión para cambios de red. Luego, cuando el servicio llega a un evento que necesita notificar al usuario, aparece una notificación en la barra de notificaciones. Consulte este enlace para obtener más información sobre las notificaciones http://developer.android.com/guide/topics/ui/notifiers/notifications.html – MikeIsrael

+0

@Mikelsrael, sí, está bien ... Pero quién va a actuar como controlador. – NitZRobotKoder

0

Si inicia sesión tarda tanto tiempo use [AccountManager][1] y hágalo solo una vez. La idea detrás del token AccountManager o cualquier credencial que necesite usar en su Service.

En su caso particular, creo que la mejor manera de comunicar su Activity con Service es vinculante.

0

La mejor fuente de conocimiento sobre el uso básico de Service es SDK. La larga historia abreviada AIDL se usa para las comunicaciones IPC y siempre que ejecute el servicio en el mismo proceso, no lo necesita. Supongo que tienes dos opciones:

  1. Si lo único que se necesita es simplemente iniciar sesión, puede iniciar un servicio en el arranque, inicio de sesión y luego es decir, enviar una emisión persistente con los datos de inicio de sesión liado que será recibida a continuación, en aplicación. Consulte this question para obtener un buen conjunto de formas de iniciar un servicio en el arranque.

    @Override 
    public void onCreate() { 
        Data data = performLogin(); 
        Intent i = new Intent(ACTION_VOIP_LOGIN); 
        i.putExtra(EXTRA_LOGIN_DATA, data); 
        mContext.sendStickyBroadcast(i); 
    } 
    
    ... 
    
    private final class LoginReceiver extends BroadcastReceiver { 
        @Override 
        public void onReceive(Context context, Intent intent) { 
         // You may use a Bundle instead 
         Data data = intent.getParcelableExtra(); 
         processLoginData(data) 
        } 
    } 
    
    protected void onCreate(Bundle savedInstanceState) { 
        ... 
        IntentFilter filter = new IntentFilter(ACTION_VOIP_LOGIN); 
        mContext.registerReceiver(new LoginReceiver(), filter); 
    } 
    
  2. En segundo caso, es posible que desee mover toda tu lógica para el servicio. Aquí extenderás la clase Binder. Consulte esto SDK article para más detalles.

Cuestiones relacionadas