2016-08-29 8 views
6

Nugat zmienił sposób, w jaki obsługuje CONNECTIVITY_CHANGED intencje (w zasadzie ignoruje go, zmuszając Devs używać harmonogramu pracy), więc to pozostawia mnie zastanawiasz:wykryć zmiany Łączność na Android 7.0 Nugat gdy aplikacja jest w planie

Jeśli mam aplikacja, która jest w trakcie pobierania niektórych danych (i sprawdziłem, czy telefon był w trybie online w momencie, gdy wykonałem żądanie, ale użytkownik jest w ruchu, a telefon łączy się z innym punktem dostępu do sieci Wi-Fi, na przykład) i nie powiedzie się , w jaki sposób mogę wykryć, że połączenie zostało przywrócone, a ja ponowić próbę sfałszowania danych?

Więc w tym przypadku moja aplikacja jest na pierwszym planie, myślę, że Chrome (dla Androida) ma podobną funkcję.

Czy muszę sondować sam? Czy jest jakieś wydarzenie, które jest dozwolone w tym czasie?

Odpowiedz

4

Aplikacje, które są uruchomione, mogą nadal słuchać CONNECTIVITY_CHANGE w głównym wątku, jeśli zażądają powiadomienia za pomocą BroadcastReceiver.

https://developer.android.com/about/versions/nougat/android-7.0-changes.html

+0

Ach tak rejestracji słuchacza w manifeście lub tła wątku już nie działa, ale nadal możesz tak w głównym wątku działania (lub usługi, przypuszczam?) Dzięki! – REJH

+0

Czy jest jakiś sposób, aby w jakiś sposób odsłuchać CONNECTIVITY_CHANGE w tle? –

+1

Tak, powinieneś to zrobić za pomocą Job Scheduler. Więc nie wystrzeli natychmiast. Taki jest pomysł, ponieważ każdy programista myśli, że jego aplikacja powinna o tym wiedzieć, a zatem Twój telefon spowalnia do indeksowania, gdy tylko zmienisz sieć: P – REJH

9

Chociaż odpowiedź Andromedy może być stosowany, że rozwiązanie nie jest przeznaczone wybór Google'a. Pytanie brzmiało, co zrobić, gdy połączenie zostało utracone i konieczne jest wznowienie działania po powrocie usługi sieciowej.

Podczas gdy CONNECTIVITY_CHANGE technicznie działa, to zawsze było trochę hack do tej konkretnej potrzeby i przestanie działać w Nougat, jak tylko aplikacja będzie działać w tle. To, czego naprawdę powinieneś użyć, to API harmonogramu zadań. Google oferuje nam wiele opcji o różnych wymaganiach i funkcjach.

  1. JobScheduler

JobScheduler dodano Lollipop i dodaje harmonogram, który może czekać do łączności sieciowej, aby zaplanować pracę. Może nawet zależeć od rodzaju połączenia, sprawdzając połączenia niemierzaste lub nieruchome. Ta opcja nie ma zgodności wstecznej, ale działa bez Usług Google Play.

  1. GCM Network Manager

GcmNetworkManager bezpośredni port funkcjonalności JobScheduler do wersji przed Lollipop, ale wymaga Google Play. GcmNetworkManager został w większości odrzucony przez Firebase Job Dispatcher.

  1. Firebase Praca Dyspozytor

Firebase JobDispatcher przewiduje inne środki do planowania pracy dla wersji przed lizak, który korzysta z usług Google Play domyślnie, ale może być skonfigurowany tak, aby nie wymagać ta zależność.

Wszystkie trzy opcje zaspokoją Twoje potrzeby w sposób przyjazny dla baterii, a Twoje zadania będą nadal planowane, nawet jeśli urządzenie zostanie na chwilę wybudzone z trybu Doze.

Oto więcej informacji na temat różnych opcji z przykładów dostarczonych przez Google:

https://developer.android.com/topic/performance/scheduling.html https://developer.android.com/topic/performance/background-optimization.html#sched-jobs

+0

Dzięki za pełne ujawnienie, ale moje pytanie dotyczyło tylko tego, kiedy aplikacja jest na pierwszym planie:) – REJH

+0

Moje rozwiązanie obejmuje również tę sprawę. W większości przypadków jest bardziej elastyczny i stanowi lepszą praktykę niż inna odpowiedź. Jedyny przypadek, którego nie obejmuje, to ten, którego potrzebuję w tej chwili, czyli jak wykryć wszelkie zmiany w sieci, takie jak przełączanie się między działającymi połączeniami sieciowymi i budzenie aplikacji, jeśli nie jest ona aktywna. – colintheshots

+0

Zalogowałeś się tylko po to, by dać temu kciuki. Naprawdę świetne informacje! – vvolkgang

2

W moim przypadku mam abonamentu na nadawanie z CONNECTIVITY_CHANGE filtra w służbie i to działa.

Jak utrzymać Service żywy jest inna historia :)

+0

Chyba musisz go uruchomić na pierwszym planie? To dziwne, że Android nadal akceptuje usługi (które są prawie zawsze procesami w tle), aby nasłuchiwać zmian w łączach. Ponieważ posiadanie usługi jest ogólnie łatwiejsze niż używanie harmonogramu zadań, więc każdy dev byłby bardzo kuszony, aby po prostu wykonać usługę i zapomnieć o niej ...? UPD: i w zasadzie udowadniasz mój punkt widzenia: P Korzystanie z usługi zamiast JobSch – REJH

+0

Moja aplikacja już ją miała, więc właśnie zarejestrowałem tam transmisję – Penzzz

3

Według doc:

kierowania Aplikacje Android 7.0 (API poziom 24) i wyższe nie otrzymują CONNECTIVITY_ACTION transmisje jeśli deklarują odbiornik przekazu w oczywisty. Aplikacje będą nadal otrzymywać transmisje CONNECTIVITY_ACTION, jeśli zarejestrują swoje BroadcastReceiver z Context.registerReceiver() i ten kontekst jest nadal ważny.

+0

Bezpośrednia i poprawna odpowiedź – saksham

0

public class ConnectivityReceiver {

public static boolean getWifiStatus(Context context) 
{ 
    // To get System Connectivity status 
    ConnectivityManager cm = (ConnectivityManager) context 
      .getSystemService(Context.CONNECTIVITY_SERVICE); 


    NetworkInfo activeNetwork = cm.getActiveNetworkInfo(); 
    if (null != activeNetwork) 
    { 
     // Check For Wifi Status 
     if(activeNetwork.getType() == ConnectivityManager.TYPE_WIFI) 
      return true; 
     else 
      return false; 
    } 

    return false; 
} 

public class NetworkMgr rozciąga BroadcastReceiver {

@Override 
public void onReceive(Context context, Intent intent) { 

    ConnectivityReceiver cf = new ConnectivityReceiver(); 
    boolean status = cf.getWifiStatus(context); 

    if(status) 
    { 
     Toast.makeText(context,"Wifi Connection is On.", Toast.LENGTH_SHORT).show(); 
    } 
    else 
    { 
     Toast.makeText(context,"Wifi Connection is Off.", Toast.LENGTH_SHORT).show(); 
    } 
} 

}

Powiązane problemy