Połącz z siecią

Aby wykonywać operacje sieciowe w aplikacji, plik manifestu musi zawierać te uprawnienia:

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

Sprawdzone metody bezpiecznej komunikacji sieciowej

Zanim dodasz do aplikacji funkcje sieciowe, musisz się upewnić, że dane i informacje w aplikacji są bezpieczne podczas przesyłania przez sieć. Aby to zrobić, postępuj zgodnie z tymi sprawdzonymi metodami dotyczącymi bezpieczeństwa sieci:

  • Zminimalizuj ilość poufnych lub osobistych danych użytkownika przesyłanych przez sieć.
  • Wysyłaj cały ruch w sieci z aplikacji przez SSL.
  • Rozważ utworzenie konfiguracji zabezpieczeń sieci, która pozwoli aplikacji ufać niestandardowym urzędom certyfikacji lub ograniczyć zestaw systemowych urzędów certyfikacji, którym ufa, w celu zapewnienia bezpiecznej komunikacji.

Więcej informacji o stosowaniu zasad bezpiecznego korzystania z sieci znajdziesz we wskazówkach dotyczących bezpieczeństwa sieci.

Wybieranie klienta HTTP

Większość aplikacji połączonych z siecią używa protokołu HTTP do wysyłania i odbierania danych. Platforma Androida zawiera klienta HttpsURLConnection, który obsługuje TLS, strumieniowe przesyłanie i pobieranie, konfigurowalne limity czasu, IPv6 i pule połączeń.

Dostępne są też biblioteki innych firm, które oferują interfejsy API wyższego poziomu do operacji sieciowych. Obsługują one różne funkcje ułatwiające pracę, takie jak serializacja treści żądań i deserializacja treści odpowiedzi.

  • Retrofit: bezpieczny pod względem typów klient HTTP dla JVM od Square, zbudowany na bazie OkHttp. Retrofit umożliwia deklaratywne tworzenie interfejsu klienta i obsługuje kilka bibliotek serializacji.
  • Ktor: klient HTTP od JetBrains, stworzony całkowicie dla Kotlina i oparty na współprogramach. Ktor obsługuje różne silniki, serializatory i platformy.

Rozpoznawanie zapytań DNS

Urządzenia z Androidem 10 (poziom interfejsu API 29) i nowszym mają wbudowaną obsługę specjalistycznych wyszukiwań DNS zarówno w trybie tekstu nieszyfrowanego, jak i DNS-over-TLS. Interfejs API DnsResolver zapewnia ogólne, asynchroniczne rozpoznawanie, które umożliwia wyszukiwanie rekordów SRV, NAPTR i innych typów. Przetworzenie odpowiedzi należy do aplikacji.

Na urządzeniach z Androidem 9 (poziom interfejsu API 28) lub starszym resolver DNS platformy obsługuje tylko rekordy A i AAAA. Umożliwia to wyszukiwanie adresów IP powiązanych z nazwą, ale nie obsługuje żadnych innych typów rekordów.

Informacje o aplikacjach opartych na NDK znajdziesz w android_res_nsend.

Hermetyzacja operacji sieciowych za pomocą repozytorium

Aby uprościć proces wykonywania operacji sieciowych i ograniczyć powielanie kodu w różnych częściach aplikacji, możesz użyć wzorca projektowego repozytorium. Repozytorium to klasa, która obsługuje operacje na danych i zapewnia przejrzystą abstrakcję interfejsu API nad określonymi danymi lub zasobami.

Za pomocą Retrofit możesz zadeklarować interfejs, który określa metodę HTTP, adres URL, argumenty i typ odpowiedzi dla operacji sieciowych, jak w tym przykładzie:

Kotlin

interface UserService {
    @GET("/users/{id}")
    suspend fun getUser(@Path("id") id: String): User
}

Java

public interface UserService {
    @GET("/user/{id}")
    Call<User> getUserById(@Path("id") String id);
}

W klasie repozytorium funkcje mogą hermetyzować operacje sieciowe i udostępniać ich wyniki. Dzięki tej enkapsulacji komponenty, które wywołują repozytorium, nie muszą wiedzieć, jak dane są przechowywane. Wszelkie przyszłe zmiany sposobu przechowywania danych są również izolowane w klasie repozytorium. Możesz na przykład wprowadzić zmianę zdalną, taką jak aktualizacja punktów końcowych interfejsu API, lub wdrożyć lokalne buforowanie.

Kotlin

class UserRepository constructor(
    private val userService: UserService
) {
    suspend fun getUserById(id: String): User {
        return userService.getUser(id)
    }
}

Java

class UserRepository {
    private UserService userService;

    public UserRepository(
            UserService userService
    ) {
        this.userService = userService;
    }

    public Call<User> getUserById(String id) {
        return userService.getUser(id);
    }
}

Aby uniknąć tworzenia interfejsu, który nie reaguje, nie wykonuj operacji sieciowych w głównym wątku. Domyślnie Android wymaga wykonywania operacji sieciowych w wątku innym niż główny wątek UI. Jeśli spróbujesz wykonać operacje sieciowe w głównym wątku, zostanie zgłoszony błąd NetworkOnMainThreadException.

W poprzednim przykładzie kodu operacja sieciowa nie jest wywoływana. Element wywołujący UserRepository musi implementować wątki za pomocą współprogramów lub funkcji enqueue(). Więcej informacji znajdziesz w ćwiczeniu z programowania Pobieranie danych z internetu, w którym pokazano, jak zaimplementować wątki za pomocą współprogramów w języku Kotlin.

Zachowywanie stanu po zmianach konfiguracji

Gdy następuje zmiana konfiguracji, np. obrót ekranu, fragment lub aktywność są niszczone i tworzone na nowo. Wszystkie dane, które nie zostały zapisane w stanie instancji aktywności fragmentu (który może przechowywać tylko niewielkie ilości danych), zostaną utracone. W takim przypadku może być konieczne ponowne wysłanie żądań sieciowych.

Możesz użyć ViewModel, aby dane nie zostały utracone podczas zmian konfiguracji. Komponent ViewModel służy do przechowywania danych związanych z interfejsem i zarządzania nimi w sposób uwzględniający cykl życia. Korzystając z poprzedniego UserRepository, ViewModel może wysyłać niezbędne żądania sieciowe i przekazywać wynik do fragmentu lub aktywności za pomocą LiveData:

Kotlin

class MainViewModel constructor(
    savedStateHandle: SavedStateHandle,
    userRepository: UserRepository
) : ViewModel() {
    private val userId: String = savedStateHandle["uid"] ?:
        throw IllegalArgumentException("Missing user ID")

    private val _user = MutableLiveData<User>()
    val user = _user as LiveData<User>

    init {
        viewModelScope.launch {
            try {
                // Calling the repository is safe as it moves execution off
                // the main thread
                val user = userRepository.getUserById(userId)
                _user.value = user
            } catch (error: Exception) {
                // Show error message to user
            }

        }
    }
}

Java

class MainViewModel extends ViewModel {

    private final MutableLiveData<User> _user = new MutableLiveData<>();
    LiveData<User> user = (LiveData<User>) _user;

    public MainViewModel(
            SavedStateHandle savedStateHandle,
            UserRepository userRepository
    ) {
        String userId = savedStateHandle.get("uid");
        Call<User> userCall = userRepository.getUserById(userId);
        userCall.enqueue(new Callback<User>() {
            @Override
            public void onResponse(Call<User> call, Response<User> response) {
                if (response.isSuccessful()) {
                    _user.setValue(response.body());
                }
            }

            @Override
            public void onFailure(Call<User> call, Throwable t) {
                // Show error message to user
            }
        });
    }
}

Aby dowiedzieć się więcej na ten temat, zapoznaj się z tymi przewodnikami: