Jetpack — co to jest, komponenty architektury

Czym jest Android Jetpack?

Android Jetpack — to kolekcja bibliotek, narzędzi i zaleceń architektonicznych od Google, zaprezentowana w 2018 roku na Google I/O. Jetpack zastąpił Support Library i Android Architecture Components, łącząc je w jedną ekosystem. Przed Jetpack każda biblioteka Androida aktualizowała się niezależnie, co powodowało konflikty wersji. Jetpack zsynchronizował wersje pod jednolitym identyfikatorem AndroidX i wprowadził model stabilnych wersji głównych z pomniejszymi łatkami.

Biblioteki Jetpack dzielą się na cztery kategorie: Architecture (ViewModel, Room, Navigation, WorkManager), UI (Fragment, Compose, Animation, Palette), Behavior (DownloadManager, Media, Permissions, Sharing), Foundation (Android KTX, Multidex, AppCompat). Każda kategoria rozwiązuje zadania określonej warstwy aplikacji — od zarządzania danymi po interfejs użytkownika.

Filozofia Jetpack

Google promuje trzy zasady Jetpack: accelerate development (mniej boilerplate, więcej logiki biznesowej), eliminate boilerplate (ViewModel eliminuje ręczne zapisywanie stanu, Room — pisanie SQLiteOpenHelper) i build with confidence (każda biblioteka przechodzi 15+ tysięcy testów przed wydaniem). Według Android Developers (2026), aplikacje na Jetpack mają o 30% mniej crashy związanych z cyklem życia.

AndroidX jako podstawa

Wszystkie biblioteki Jetpack są rozpowszechniane pod identyfikatorem AndroidX (artefakty postaci androidx.*). AndroidX zastąpił Support Library (artefakty com.android.support.*), dzieląc monolityczną bibliotekę na modułowe artefakty z niezależnym wersjonowaniem. Migrację na AndroidX wykonuje się poprzez opcję android.useAndroidX=true w gradle.properties — Android Studio automatycznie konwertuje importy.

Komponenty architektoniczne: ViewModel, Lifecycle, LiveData

ViewModel — centralny komponent architektury Jetpack, przechowujący dane UI. W przeciwieństwie do Activity, które jest niszczone przy obrocie ekranu, ViewModel pozostaje w pamięci. Użytkownik wypełnia formularz, obraca telefon — dane nie są tracone. ViewModel automatycznie się czyści, gdy LifecycleOwner (Activity lub Fragment) kończy swój cykl życia na stałe (finish).

class ProfileViewModel : ViewModel() {

    private val _userName = MutableLiveData<String>()
    val userName: LiveData<String> = _userName

    fun loadProfile(userId: String) {
        viewModelScope.launch {
            val user = repository.getUser(userId)
            _userName.value = user.name
        }
    }
}

@OptIn(ExperimentalLifecycleApi::class)
class MyObserver : LifecycleObserver {
    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun onStart() {
        println("Ekran uruchomiony")
    }
}

LiveData — obserwowalny kontener dla danych, uwzględniający cykl życia. Jeśli ekran nie jest widoczny (onStop), LiveData nie wysyła aktualizacji — zapobiega to wyciekom pamięci i crashem przy próbie aktualizacji nieistniejącego Activity. Lifecycle — klasa przechowująca bieżący stan (CREATED, STARTED, RESUMED) i umożliwiająca innym komponentom subskrypcję zmian stanu. Razem ViewModel, LiveData i Lifecycle tworzą fundament reaktywnej architektury Androida.

ViewModelScope i korutyny

viewModelScope — wbudowany CoroutineScope powiązany z cyklem życia ViewModel. Wszystkie korutyny uruchomione w tym zakresie są automatycznie anulowane przy czyszczeniu ViewModel. Eliminuje to ręczne zarządzanie Disposable i CompositeDisposable w każdym ViewModel. Do pracy z viewModelScope wymagana jest zależność androidx.lifecycle:lifecycle-viewmodel-ktx.

Room: praca z bazą danych na Androidzie

Room — to biblioteka ORM Jetpack, zapewniająca abstrakcyjną warstwę nad SQLite. Zamiast pisania surowych zapytań SQL i ręcznego przekształcania Cursor na obiekty, programista deklaruje Entity (tabelę), DAO (Data Access Object) i Database (punkt wejścia). Room sprawdza zapytania SQL na etapie kompilacji przez adnotację @Query — jeśli tabele lub kolumny nie istnieją, kompilacja kończy się zrozumiałym błędem.

@Entity
data class User(
    @PrimaryKey val id: String,
    val name: String,
    val email: String
)

@Dao
interface UserDao {
    @Query("SELECT * FROM User WHERE id = :userId")
    suspend fun getUser(userId: String): User?

    @Insert
    suspend fun insertUser(user: User)
}

@Database(entities = [User::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

Entity User opisuje tabelę z trzema kolumnami. DAO deklaruje suspend-funkcje do pracy z korutynami — zapytanie wykonuje się automatycznie w tle. Room obsługuje migracje przez adnotację @Migration: programista opisuje skrypt SQL przejścia między wersjami, a Room wykonuje go bez utraty danych. W przypadku braku migracji Room rzuca IllegalStateException — w ten sposób projekty są chronione przed przypadkową utratą danych przy aktualizacji schematu.

TypeConverters i relacje

Room przechowuje tylko typy prymitywne i ich opakowania. Do przechowywania list, Date lub niestandardowych obiektów używa się @TypeConverter — statycznej metody konwertującej typ na String (JSON) lub Long (timestamp). Relacje między tabelami modeluje się poprzez zagnieżdżone obiekty z adnotacją @Relation i pomocnicze klasy POJO z @Transaction dla efektywnych zapytań join.

Navigation Component: grafy i argumenty

Navigation Component — biblioteka Jetpack do zarządzania przejściami między ekranami. Zamiast ręcznego wywoływania FragmentTransaction programista tworzy graf nawigacji (plik XML z węzłami-destynacjami), a system generuje klasę Directions z bezpiecznymi typami metod przejść. Navigation Component gwarantuje poprawną pracę back stack, deep links i przekazywania argumentów między ekranami.

// nav_graph.xml
// <fragment android:id="@+id/profileFragment"
//     android:name=".ProfileFragment">
//     <argument android:name="userId"
//         android:defaultValue="-1"
//         app:argType="integer" />
// </fragment>

// W kodzie fragmentu:
class ProfileFragment : Fragment() {
    private val args: ProfileFragmentArgs by navArgs()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        loadProfile(args.userId)
    }
}

Argumenty userId są przekazywane w grafie nawigacji z określeniem typu (integer) i wartości domyślnej. Klasa ProfileFragmentArgs jest generowana automatycznie przez plugin Navigation Safe Args — zawiera wszystkie argumenty z poprawnymi typami Kotlin. Głębokie linki konfiguruje się w grafie: app:deepLink="app://profile/{userId}". Navigation Component sam analizuje URL i tworzy back stack, tak jakby użytkownik przeszedł przez interfejs.

Bottom Navigation i Conditional Navigation

Navigation Component integruje się z BottomNavigationView przez NavController: każda pozycja menu jest przypisywana do destynacji w grafie. Przejście między zakładkami nie odtwarza fragmentu — Navigation Component zachowuje stan przez NavBackStackEntry. Do nawigacji warunkowej (pokazanie loginu, jeśli nie jest zalogowany) używa się navController.navigate(condition) z sprawdzeniem w onCreate.

AndroidX: Support Library nowej generacji

AndroidX — to przeprojektowana architektura Support Library, w której każda biblioteka otrzymała własny artefakt z niezależną wersją. Zamiast jednego com.android.support:appcompat-v7:28.0.0 AndroidX oferuje androidx.appcompat:appcompat:1.7.0, androidx.recyclerview:recyclerview:1.4.0 i tak dalej. Rozwiązało to problem, gdy różne zależności ciągnęły różne wersje Support Library, powodując konflikt.

Migracja na AndroidX wykonywana jest automatycznie w Android Studio 3.2+ przez menu Refactor → Migrate to AndroidX. Studio zastępuje wszystkie importy w plikach Java/Kotlin, manifestach i zasobach. Wsteczna kompatybilność — główna zaleta AndroidX: biblioteki działają na Android 5.0 (API 21) i nowszych, pokrywając 97% aktywnych urządzeń według Google Play Console (2025).

Główne artefakty AndroidX

Najczęściej używane artefakty: appcompat (ciemny motyw, Material Design na starych API), recyclerview (adaptacyjne listy z ViewHolder), constraintlayout (elastyczny kontener z płaską hierarchią), cardview (karty Material Design), preference (ekran ustawień w stylu Material). Każdy artefakt jest wersjonowany niezależnie, przyspieszając otrzymywanie poprawek bez aktualizacji całego pakietu.

Inne ważne biblioteki Jetpack

Oprócz Architecture i AndroidX, Jetpack zawiera wiele wyspecjalizowanych bibliotek do typowych zadań tworzenia aplikacji mobilnych. WorkManager — do zadań w tle z gwarantowanym wykonaniem (synchronizacja, wysyłanie logów), obsługuje zadania okresowe i opóźnione, a także ograniczenia sieciowe i bateryjne. DataStore — zamiennik SharedPreferences oparty na korutynach, obsługujący właściwości typowane (Preferences DataStore) i Protocol Buffers (Proto DataStore).

• Hilt — framework DI oparty na Dagger, upraszczający wstrzykiwanie zależności przez adnotacje @HiltViewModel, @Inject, @Module. Wbudowana integracja z ViewModel i Navigation.
• Paging 3 — biblioteka do stronicowego ładowania danych z sieci/BD z obsługą RemoteMediator (sieć + cache), StateFlow i Compose.
• CameraX — API do pracy z kamerą, abstrahujący różnice producentów (Samsung, Xiaomi, Honor) przez jednolity interfejs CameraController.
• Security Crypto — szyfrowanie danych przez EncryptedSharedPreferences i EncryptedFile oparte na AES-256 z kluczem głównym w Android Keystore.

Każda biblioteka ma własny minimalny SDK i artefakt. Google wydaje główne wersje raz w roku (zbiegając się z wydaniem Androida) i łatki bezpieczeństwa — kwartalnie. Zalecenie — podłączać tylko niezbędne biblioteki, aby nie zwiększać rozmiaru APK. Jetpack w całości (wszystkie artefakty) waży ponad 20 MB, ale typowa aplikacja używa 5–7 bibliotek, dodając do APK 3–5 MB.