Jetpack — ce este, componentele arhitecturii

Ce este Android Jetpack?

Android Jetpack — este o colecție de biblioteci, instrumente și recomandări arhitecturale de la Google, prezentată în 2018 la Google I/O. Jetpack a înlocuit Support Library și Android Architecture Components, unindu-le într-un singur ecosistem. Înainte de Jetpack, fiecare bibliotecă Android se actualiza independent, ceea ce crea conflicte de versiuni. Jetpack a sincronizat versiunile sub un identificator unic AndroidX și a introdus modelul de versiuni majore stabile cu patch-uri minore.

Bibliotecile Jetpack se împart în patru categorii: Architecture (ViewModel, Room, Navigation, WorkManager), UI (Fragment, Compose, Animation, Palette), Behavior (DownloadManager, Media, Permissions, Sharing), Foundation (Android KTX, Multidex, AppCompat). Fiecare categorie rezolvă sarcinile unui strat specific al aplicației — de la gestionarea datelor până la interfața utilizatorului.

Filozofia Jetpack

Google promovează trei principii Jetpack: accelerate development (mai puțin boilerplate, mai multă logică de business), eliminate boilerplate (ViewModel elimină salvarea manuală a stării, Room — scrierea SQLiteOpenHelper) și build with confidence (fiecare bibliotecă trece de 15+ mii de teste înainte de lansare). Conform Android Developers (2026), aplicațiile pe Jetpack au cu 30% mai puține crash-uri legate de ciclul de viață.

AndroidX ca bază

Toate bibliotecile Jetpack sunt distribuite sub identificatorul AndroidX (artefacte de tipul androidx.*). AndroidX a înlocuit Support Library (artefacte com.android.support.*), împărțind biblioteca monolitică în artefacte modulare cu versionare independentă. Migrarea la AndroidX se realizează prin opțiunea android.useAndroidX=true în gradle.properties — Android Studio convertește automat importurile.

Componente arhitecturale: ViewModel, Lifecycle, LiveData

ViewModel — componenta centrală a arhitecturii Jetpack care stochează datele UI. Spre deosebire de Activity, care este distrusă la rotirea ecranului, ViewModel rămâne în memorie. Utilizatorul completează un formular, rotește telefonul — datele nu se pierd. ViewModel se curăță automat când LifecycleOwner (Activity sau Fragment) își încheie ciclul de viață pentru totdeauna (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("Ecran pornit")
    }
}

LiveData — un container observabil pentru date care ține cont de ciclul de viață. Dacă ecranul nu este vizibil (onStop), LiveData nu trimite actualizări — acest lucru previne scurgerile de memorie și crash-urile la încercarea de a actualiza un Activity inexistent. Lifecycle — o clasă care stochează starea curentă (CREATED, STARTED, RESUMED) și permite altor componente să se aboneze la modificările de stare. Împreună, ViewModel, LiveData și Lifecycle formează fundamentul arhitecturii reactive Android.

ViewModelScope și corutine

viewModelScope — un CoroutineScope încorporat legat de ciclul de viață al ViewModel. Toate corutinele lansate în acest scope sunt anulate automat la curățarea ViewModel. Acest lucru elimină gestionarea manuală a Disposable și CompositeDisposable în fiecare ViewModel. Pentru lucrul cu viewModelScope este necesară dependența androidx.lifecycle:lifecycle-viewmodel-ktx.

Room: lucrul cu baza de date pe Android

Room — este o bibliotecă ORM Jetpack care oferă un strat abstract peste SQLite. În loc să scrieți interogări SQL brute și să convertiți manual Cursor în obiecte, dezvoltatorul declară Entity (tabel), DAO (Data Access Object) și Database (punct de intrare). Room verifică interogările SQL la compilare prin adnotarea @Query — dacă tabelele sau coloanele nu există, build-ul eșuează cu o eroare clară.

@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 descrie un tabel cu trei coloane. DAO declară funcții suspend pentru lucrul cu corutine — interogarea se execută automat pe un fir de fundal. Room suportă migrații prin adnotarea @Migration: dezvoltatorul descrie scriptul SQL de tranziție între versiuni, iar Room îl execută fără pierdere de date. În lipsa migrației, Room aruncă IllegalStateException — astfel proiectele sunt protejate de pierderea accidentală a datelor la actualizarea schemei.

TypeConverters și relații

Room stochează doar tipuri primitive și wrapper-ele lor. Pentru stocarea listelor, Date sau a obiectelor personalizate se folosește @TypeConverter — o metodă statică care convertește tipul în String (JSON) sau Long (timestamp). Relațiile între tabele se modelează prin obiecte imbricate cu adnotarea @Relation și clase POJO ajutătoare cu @Transaction pentru interogări join eficiente.

Navigation Component: grafuri și argumente

Navigation Component — o bibliotecă Jetpack pentru gestionarea tranzițiilor între ecrane. În loc să apelați manual FragmentTransaction, dezvoltatorul creează un graf de navigare (fișier XML cu noduri-destinații), iar sistemul generează clasa Directions cu metode de tranziție type-safe. Navigation Component garantează funcționarea corectă a back stack, deep links și transmiterea argumentelor între ecrane.

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

// În codul fragmentului:
class ProfileFragment : Fragment() {
    private val args: ProfileFragmentArgs by navArgs()

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

Argumentele userId sunt transmise în graful de navigare cu specificarea tipului (integer) și a valorii implicite. Clasa ProfileFragmentArgs este generată automat de plugin-ul Navigation Safe Args — conține toate argumentele cu tipurile corecte Kotlin. Deep link-urile se configurează în graf: app:deepLink="app://profile/{userId}". Navigation Component analizează singur URL-ul și creează back stack-ul ca și cum utilizatorul ar fi navigat prin interfață.

Bottom Navigation și Conditional Navigation

Navigation Component se integrează cu BottomNavigationView prin NavController: fiecare element de meniu este legat de o destinație în graf. Tranziția între tab-uri nu recrează fragmentul — Navigation Component păstrează starea prin NavBackStackEntry. Pentru navigarea condiționată (afișarea login-ului dacă nu este autentificat) se folosește navController.navigate(condition) cu verificare în onCreate.

AndroidX: Support Library de nouă generație

AndroidX — este o arhitectură reproiectată a Support Library, în care fiecare bibliotecă a primit propriul artefact cu versiune independentă. În loc de un singur com.android.support:appcompat-v7:28.0.0, AndroidX oferă androidx.appcompat:appcompat:1.7.0, androidx.recyclerview:recyclerview:1.4.0 și așa mai departe. Aceasta a eliminat problema când diferite dependențe trăgeau versiuni diferite ale Support Library, provocând conflicte.

Migrarea la AndroidX se efectuează automat în Android Studio 3.2+ prin meniul Refactor → Migrate to AndroidX. Studio înlocuiește toate importurile în fișierele Java/Kotlin, manifeste și resurse. Compatibilitatea retroactivă — principalul avantaj al AndroidX: bibliotecile funcționează pe Android 5.0 (API 21) și superior, acoperind 97% din dispozitivele active conform Google Play Console (2025).

Principalele artefacte AndroidX

Cele mai frecvent utilizate artefacte: appcompat (temă întunecată, Material Design pe API-uri vechi), recyclerview (liste adaptive cu ViewHolder), constraintlayout (container flexibil cu ierarhie plată), cardview (carduri Material Design), preference (ecran de setări în stil Material). Fiecare artefact este versionat independent, accelerând primirea corecțiilor fără actualizarea întregului pachet.

Alte biblioteci importante Jetpack

Pe lângă Architecture și AndroidX, Jetpack include numeroase biblioteci specializate pentru sarcini tipice de dezvoltare mobilă. WorkManager — pentru sarcini în fundal cu execuție garantată (sincronizare, încărcare log-uri), suportă sarcini periodice și amânate, precum și restricții de rețea și baterie. DataStore — înlocuitor pentru SharedPreferences bazat pe corutine, care suportă proprietăți tipizate (Preferences DataStore) și Protocol Buffers (Proto DataStore).

• Hilt — un framework DI bazat pe Dagger, care simplifică injectarea dependențelor prin adnotări @HiltViewModel, @Inject, @Module. Integrare încorporată cu ViewModel și Navigation.
• Paging 3 — o bibliotecă pentru încărcarea paginată a datelor din rețea/BD cu suport pentru RemoteMediator (rețea + cache), StateFlow și Compose.
• CameraX — API pentru lucrul cu camera, care abstractizează diferențele producătorilor (Samsung, Xiaomi, Honor) printr-o interfață unitară CameraController.
• Security Crypto — criptarea datelor prin EncryptedSharedPreferences și EncryptedFile bazate pe AES-256 cu cheia principală în Android Keystore.

Fiecare bibliotecă are propriul SDK minim și artefact. Google lansează versiuni majore o dată pe an (coincizând cu lansarea Android) și patch-uri de securitate — trimestrial. Recomandare — conectați doar bibliotecile necesare pentru a nu mări dimensiunea APK. Jetpack în ansamblu (toate artefactele) cântărește peste 20 MB, dar o aplicație tipică utilizează 5–7 biblioteci, adăugând la APK 3–5 MB.