Wdrażanie GoogleApiClient na Androidzie MVP za pomocą sztyletu?

Question

istnieje kilka pytanie mam,

pierwsze, jak czytam niektóre z tych artykułów, należy wdrożyć LocationListener, ConnectionCallback, OnConnectionFailedListener interfejsy w działalności,

jest to prawo do oddzielenia realizację tych klas w różnych plikach?

jak poniżej?

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 
} 
} 

czy to w mojej działalności Poradzę Wyświetlam właściwości mLastLocation?

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

sekunda, Jak mam napisać metodę dostawcy dla niego?, moje przypuszczenie będzie takie, co polecacie?

//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(); 
} 

wreszcie gdzie powinien obsłużyć uprawnienia dla Androida 6 i wyżej urządzeniach?, czy to jest na widoku, czy na prezenterze?

Słyszałem, że Widok musi być tak głupi, że nie trzeba go testować, Jak powinienem zachować tę zasadę?

Jeśli ktoś może dać mi referencję lub kod przykładowy github, który pasuje do mojego przypadku, byłoby tak świetnie.

Answer 1

Ostatnia rzecz, to pierwsza warstwa widoku MVP jako czysty moduł Android, co oznacza, że ​​każda komunikacja z systemem operacyjnym Android, taka jak żądanie uprawnień, musi być obsługiwana przy użyciu tej warstwy, a wynik wraca do prezentera, który decyduje, co Zrób następne.

Oddzielając implementację tych klas, ja sam lubię oddzielać klasy w celu czystszej wizualizacji, gdy szukam jakiegoś kodu klasy! Nie sądzę, żeby ktokolwiek mógł zaproponować najlepszą praktykę, ponieważ zależy to od twojego modułu i implementacji. Zgodnie z książką "Czysty kod", w tego typu sytuacjach decyzyjnych musisz pomyśleć więcej o czytelności kodu.

Wreszcie o LocationModule, to jest całkowicie poprawne, ale gdybym był na twoim miejscu bym nawet poprosić o kontekst, w wyższym poziomie komponentu (np ApplicationComponent) i usunąć go z konstruktora 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(); 
} 

Kontekst można podać za pomocą odpowiedniego dostawcy w wyższym module.

Oto próbka repo, które mogą naprawdę pomóc w tym względzie:

https://github.com/mmirhoseini/fyber_mobile_offers