Implementación de GoogleApiClient en Android mvp con daga?

Hay un par de preguntas que tengo,

Primero, como he leído algunos de los artículos, debería implementar LocationListener, ConnectionCallback, OnConnectionFailedListener interfaces en la actividad,

¿Es correcto separar la implementación de estas clases en diferentes archivos?

¿como abajo?

public class LocationListener implements com.google.android.gms.location.LocationListener { @Inject Location mLastLocation; @Override public void onLocationChanged(Location location) { // Assign the new location mLastLocation = location; // Displaying the new location on UI } }

¿Es correcto en mi actividad que manejo Mostrando las propiedades mLastLocation?

 //Fields @Inject GoogleApiClient client; Location mLastLocation; //Fields mLastLocation = LocationServices.FusedLocationApi.getLastLocation(client);

Segundo, ¿Cómo debo escribir el método del proveedor para él? , Mi conjetura será así, ¿qué recomendarán ustedes?

 //Constructor public LocationModule(Context context, GoogleApiClient.ConnectionCallbacks callback, GoogleApiClient.OnConnectionFailedListener listener) { this.context = context; this.callback = callback; this.listener = listener; } @Provides @Singleton GoogleApiClient providesGoogleApi() { return new GoogleApiClient.Builder(context) .addOnConnectionFailedListener(listener) .addConnectionCallbacks(callback) .addApi(LocationServices.API) .build(); }

Y, finalmente, ¿ dónde debo manejar los permisos para android 6 y dispositivos anteriores? , ¿Está en la vista, o en el presentador?

He oído que View debe ser tan estúpido que no es necesario probarlo, ¿Cómo debo mantener este principio?

Si alguien puede darme una referencia, o github código de ejemplo, que coincide con mi caso que sería tan grande.

Lo primero que puedes hacer es pensar en la capa de vista de MVP como el puro módulo de Android, lo que significa que cualquier comunicación con el sistema operativo Android como solicitar permiso debe manejarse usando esta capa y el resultado se remonta al presentador que decide qué hacer a continuación.

Acerca de la separación de la aplicación de la clase, yo por mí mismo como para separar las clases para una visualización más limpia cuando estoy buscando algún código de clase! No creo que nadie pueda sugerir una mejor práctica, ya que depende de su módulo y la implementación. De acuerdo con el libro Clean Code, en este tipo de situaciones de toma de decisiones usted tiene que pensar más acerca de su legibilidad del código.

Por último, sobre el LocationModule , es totalmente correcto, pero si estuviera en tus zapatos incluso pediría Contexto en un componente de nivel superior (por ejemplo ApplicationComponent) y lo quitaría del constructor de LocationModule.

 //Constructor public LocationModule(GoogleApiClient.ConnectionCallbacks callback, GoogleApiClient.OnConnectionFailedListener listener) { this.callback = callback; this.listener = listener; } @Provides @Singleton GoogleApiClient providesGoogleApi(Context context) { return new GoogleApiClient.Builder(context) .addOnConnectionFailedListener(listener) .addConnectionCallbacks(callback) .addApi(LocationServices.API) .build(); }

El Contexto podría proporcionarse utilizando su proveedor relevante en un módulo superior.

Aquí hay un repo ejemplo que realmente podría ayudarle en este sentido: