Jetpack — ano ito, mga bahagi ng arkitektura

Ano ang Android Jetpack?

Android Jetpack — ay isang koleksyon ng mga library, tool at rekomendasyon sa arkitektura mula sa Google, na ipinakita noong 2018 sa Google I/O. Pinalitan ng Jetpack ang Support Library at Android Architecture Components, pinagsama ang mga ito sa isang ecosystem. Bago ang Jetpack, ang bawat Android library ay na-update nang nakapag-iisa, na nagdulot ng mga salungatan sa bersyon. Na-synchronize ng Jetpack ang mga bersyon sa ilalim ng isang AndroidX identifier at ipinakilala ang modelo ng matatag na pangunahing bersyon na may mga minor patch.

Ang mga library ng Jetpack ay nahahati sa apat na kategorya: Architecture (ViewModel, Room, Navigation, WorkManager), UI (Fragment, Compose, Animation, Palette), Behavior (DownloadManager, Media, Permissions, Sharing), Foundation (Android KTX, Multidex, AppCompat). Bawat kategorya ay lumulutas ng mga gawain ng isang partikular na layer ng application — mula sa pamamahala ng data hanggang sa user interface.

Pilosopiya ng Jetpack

Itinataguyod ng Google ang tatlong prinsipyo ng Jetpack: accelerate development (mas kaunting boilerplate, mas maraming business logic), eliminate boilerplate (inaalis ng ViewModel ang manu-manong pag-save ng estado, Room — pagsusulat ng SQLiteOpenHelper) at build with confidence (bawat library ay dumadaan sa 15+ libong test bago ilabas). Ayon sa Android Developers (2026), ang mga app sa Jetpack ay may 30% mas kaunting crash na nauugnay sa lifecycle.

AndroidX bilang batayan

Lahat ng library ng Jetpack ay ipinamamahagi sa ilalim ng identifier na AndroidX (mga artepakto na anyong androidx.*). Pinalitan ng AndroidX ang Support Library (mga artepakto na com.android.support.*), hinati ang monolitikong library sa modular na artepakto na may independiyenteng versioning. Ang migrasyon sa AndroidX ay ginagawa sa pamamagitan ng opsyon na android.useAndroidX=true sa gradle.properties — awtomatikong kino-convert ng Android Studio ang mga import.

Mga Bahagi ng Arkitektura: ViewModel, Lifecycle, LiveData

ViewModel — ang sentral na bahagi ng arkitektura ng Jetpack na nag-iimbak ng data ng UI. Hindi tulad ng Activity na sinisira kapag umiikot ang screen, nananatili ang ViewModel sa memorya. Pinunan ng user ang form, pinaikot ang telepono — hindi nawawala ang data. Awtomatikong naglilinis ang ViewModel kapag tinapos ng LifecycleOwner (Activity o Fragment) ang lifecycle nito nang permanente (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("Nagsimula ang screen")
    }
}

LiveData — isang napagmamasdang lalagyan para sa data na isinasaalang-alang ang lifecycle. Kung hindi nakikita ang screen (onStop), hindi nagpapadala ng update ang LiveData — pinipigilan nito ang pagtagas ng memorya at crash kapag sinusubukang i-update ang isang wala nang Activity. Lifecycle — isang klase na nag-iimbak ng kasalukuyang estado (CREATED, STARTED, RESUMED) at nagbibigay-daan sa ibang bahagi na mag-subscribe sa mga pagbabago ng estado. Magkasama, ang ViewModel, LiveData at Lifecycle ay bumubuo ng pundasyon ng reaktibong arkitektura ng Android.

ViewModelScope at coroutine

viewModelScope — isang built-in na CoroutineScope na nakatali sa lifecycle ng ViewModel. Lahat ng coroutine na sinimulan sa scope na ito ay awtomatikong kinakansela kapag naglinis ang ViewModel. Inaalis nito ang manu-manong pamamahala ng Disposable at CompositeDisposable sa bawat ViewModel. Para sa pagtatrabaho sa viewModelScope, kinakailangan ang dependency na androidx.lifecycle:lifecycle-viewmodel-ktx.

Room: pagtatrabaho sa database sa Android

Room — ay isang ORM library ng Jetpack na nagbibigay ng abstract layer sa ibabaw ng SQLite. Sa halip na magsulat ng raw SQL query at manu-manong i-convert ang Cursor sa mga object, ang developer ay nagdedeklara ng Entity (talahanayan), DAO (Data Access Object) at Database (entry point). Sinusuri ng Room ang mga SQL query sa compilation sa pamamagitan ng annotation na @Query — kung ang mga talahanayan o column ay hindi umiiral, ang build ay babagsak na may malinaw na error.

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

Ang Entity User ay naglalarawan ng isang talahanayan na may tatlong column. Nagdedeklara ang DAO ng suspend-function para sa pagtatrabaho sa coroutine — ang query ay awtomatikong isinasagawa sa background thread. Room sumusuporta sa migrasyon sa pamamagitan ng annotation na @Migration: inilalarawan ng developer ang SQL script ng paglipat sa pagitan ng mga bersyon, at isinasagawa ito ng Room nang walang pagkawala ng data. Kung walang migrasyon, nagtapon ang Room ng IllegalStateException — sa ganitong paraan, ang mga proyekto ay protektado mula sa aksidenteng pagkawala ng data kapag nag-a-update ng schema.

TypeConverters at relasyon

Ang Room ay nag-iimbak lamang ng mga primitive na uri at kanilang mga wrapper. Para sa pag-iimbak ng mga listahan, Date o custom na object, ginagamit ang @TypeConverter — isang static na pamamaraan na nagko-convert ng uri sa String (JSON) o Long (timestamp). Ang mga relasyon sa pagitan ng mga talahanayan ay na-modelo sa pamamagitan ng mga nested object na may annotation na @Relation at mga helper na POJO class na may @Transaction para sa mahusay na join query.

Navigation Component: graph at argumento

Navigation Component — isang library ng Jetpack para sa pamamahala ng mga transition sa pagitan ng screen. Sa halip na manu-manong tumawag ng FragmentTransaction, ang developer ay lumilikha ng navigation graph (XML file na may mga node-destination), at ang sistema ay bumubuo ng klase na Directions na may type-safe na transition method. Ginagarantiyahan ng Navigation Component ang tamang operasyon ng back stack, deep links at pagpapasa ng argumento sa pagitan ng mga screen.

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

// Sa code ng fragment:
class ProfileFragment : Fragment() {
    private val args: ProfileFragmentArgs by navArgs()

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

Ang mga argumento na userId ay ipinapasa sa navigation graph na may pagtukoy ng uri (integer) at default na halaga. Ang klase na ProfileFragmentArgs ay awtomatikong nabubuo ng Navigation Safe Args plugin — naglalaman ito ng lahat ng argumento na may tamang uri ng Kotlin. Malalim na link ay naka-configure sa graph: app:deepLink="app://profile/{userId}". Ang Navigation Component mismo ay nag-parse ng URL at lumilikha ng back stack na parang ang user ay nag-navigate sa pamamagitan ng interface.

Bottom Navigation at Conditional Navigation

Ang Navigation Component ay sumasama sa BottomNavigationView sa pamamagitan ng NavController: bawat item ng menu ay nakatali sa isang destination sa graph. Ang transition sa pagitan ng mga tab ay hindi muling lumilikha ng fragment — iniimbak ng Navigation Component ang estado sa pamamagitan ng NavBackStackEntry. Para sa conditional navigation (pagpapakita ng login kung hindi awtorisado), ginagamit ang navController.navigate(condition) na may pagsusuri sa onCreate.

AndroidX: Support Library ng Bagong Henerasyon

AndroidX — ay isang muling idinisenyong arkitektura ng Support Library, kung saan ang bawat library ay nakatanggap ng sarili nitong artepakto na may independiyenteng bersyon. Sa halip na isang com.android.support:appcompat-v7:28.0.0, nag-aalok ang AndroidX ng androidx.appcompat:appcompat:1.7.0, androidx.recyclerview:recyclerview:1.4.0 at iba pa. Inalis nito ang problema kapag ang iba't ibang dependency ay humihila ng iba't ibang bersyon ng Support Library, na nagdudulot ng salungatan.

Ang migrasyon sa AndroidX ay awtomatikong ginagawa sa Android Studio 3.2+ sa pamamagitan ng menu na Refactor → Migrate to AndroidX. Pinapalitan ng Studio ang lahat ng import sa Java/Kotlin file, manifest at resource. Backward compatibility — ang pangunahing bentahe ng AndroidX: gumagana ang mga library sa Android 5.0 (API 21) at mas mataas, sumasaklaw sa 97% ng mga aktibong device ayon sa Google Play Console (2025).

Mga pangunahing artepakto ng AndroidX

Ang pinakamadalas gamitin na artepakto: appcompat (dark theme, Material Design sa lumang API), recyclerview (adaptive list na may ViewHolder), constraintlayout (flexible container na may flat hierarchy), cardview (Material Design card), preference (screen ng setting sa Material style). Bawat artepakto ay may independiyenteng bersyon, pinapabilis ang pagtanggap ng mga pag-aayos nang hindi ina-update ang buong package.

Iba Pang Mahahalagang Library ng Jetpack

Bukod sa Architecture at AndroidX, ang Jetpack ay may kasamang maraming specialized na library para sa karaniwang gawain ng mobile development. WorkManager — para sa background task na may garantisadong execution (synchronization, pag-upload ng log), sumusuporta sa periodic at deferred task, pati na rin sa network at baterya na mga limitasyon. DataStore — kapalit ng SharedPreferences batay sa coroutine, sumusuporta sa typed-property (Preferences DataStore) at Protocol Buffers (Proto DataStore).

• Hilt — isang DI framework na batay sa Dagger, nagpapasimple ng dependency injection sa pamamagitan ng annotation na @HiltViewModel, @Inject, @Module. Built-in na integrasyon sa ViewModel at Navigation.
• Paging 3 — library para sa pag-load ng data nang pahina mula sa network/DB na may suporta sa RemoteMediator (network + cache), StateFlow at Compose.
• CameraX — API para sa pagtatrabaho sa camera, na nag-aaabstract ng pagkakaiba ng manufacturer (Samsung, Xiaomi, Honor) sa pamamagitan ng isang pare-parehong interface ng CameraController.
• Security Crypto — pag-encrypt ng data sa pamamagitan ng EncryptedSharedPreferences at EncryptedFile batay sa AES-256 na may master key sa Android Keystore.

Bawat library ay may sariling minimal na SDK at artepakto. Naglalabas ang Google ng pangunahing bersyon isang beses sa isang taon (kasabay ng release ng Android) at security patch — quarterly. Rekomendasyon — ikonekta lamang ang mga kinakailangang library upang hindi mapalaki ang laki ng APK. Ang Jetpack sa kabuuan (lahat ng artepakto) ay tumitimbang ng higit sa 20 MB, ngunit ang tipikal na app ay gumagamit ng 5-7 library, nagdaragdag ng 3-5 MB sa APK.