Active: apa itu, status Active dalam siklus hidup iOS

Active: status apa ini

Active — status siklus hidup aplikasi seluler, di mana aplikasi berada di latar depan, ditampilkan di layar perangkat, dan secara aktif berinteraksi dengan pengguna. Dalam status ini, aplikasi menerima semua peristiwa sentuhan, penekanan tombol, data dari akselerometer dan giroskop, serta memiliki akses penuh ke prosesor grafis untuk merender antarmuka.

Di iOS, status Active adalah bagian dari model siklus hidup lima status: Not Running → Inactive → Active → Inactive → Background → Suspended → Not Running. Di Android, padanannya adalah status Activity setelah pemanggilan onResume, ketika Activity berada di puncak tumpukan dan menerima masukan pengguna. Active adalah satu-satunya status di mana UI sepenuhnya interaktif dan merespons gerakan, gulir, klik, dan animasi.

Sistem memberikan aplikasi dalam status Active prioritas maksimum prosesor dan RAM. Ini berarti sistem tidak akan mengakhiri aplikasi semacam itu saat kekurangan sumber daya — pertama-tama proses latar belakang dan yang ditangguhkan akan dibongkar. Namun, aplikasi harus menggunakan sumber daya secara efisien agar tidak menguras baterai dan menyebabkan throttling CPU.

Bagi pengguna, Active adalah status kerja normal dengan aplikasi. Pengguna melihat antarmuka, dapat menekan tombol, mengisi formulir, menggulir umpan. Setiap gangguan status ini (panggilan, notifikasi, geser ke atas untuk Control Center) memindahkan aplikasi ke Inactive, setelah itu dapat kembali ke Active atau masuk ke Background.

Bagaimana sistem menentukan bahwa aplikasi Active

iOS menggunakan UIApplicationMain untuk mengelola status. Saat transisi ke Active, sistem memanggil applicationDidBecomeActive. Untuk SwiftUI, mekanisme serupa adalah mengamati scenePhase melalui Environment. Android menggunakan onResume sebagai indikator aktivitas Activity di latar depan. Kedua pendekatan menjamin bahwa aplikasi menerima pemberitahuan tentang perubahan status dan dapat menyesuaikan perilakunya.

Active di iOS: Swift, UIKit, dan SwiftUI

Di iOS, status Active ditangani melalui UIApplicationDelegate. Metode utama — applicationDidBecomeActive(_:). Ini dipanggil saat pertama kali aplikasi diluncurkan dan saat kembali dari Inactive. Metode ini adalah tempat yang ideal untuk melanjutkan tugas yang ditangguhkan saat masuk ke Inactive: memulai animasi, melanjutkan timer, memulai ulang sensor, memeriksa pembaruan data di server.

UIKit: AppDelegate dan SceneDelegate

Sejak iOS 13, Apple memperkenalkan UISceneDelegate untuk mendukung beberapa jendela di iPad. Dalam hal ini, applicationDidBecomeActive digantikan oleh sceneDidBecomeActive untuk setiap adegan. Aplikasi yang hanya mendukung satu layar dapat terus menggunakan UIApplicationDelegate. Kedua pendekatan dipanggil saat aplikasi atau adegan menjadi aktif.

import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate {

    // Aplikasi menjadi aktif — melanjutkan tugas
    func applicationDidBecomeActive(_ application: UIApplication) {
        resumeAnimations()
        restartTimers()
        refreshDataIfNeeded()
        startObservingSensors()
    }

    // Aplikasi kehilangan aktivitas — menangguhkan
    func applicationWillResignActive(_ application: UIApplication) {
        pauseAnimations()
        stopTimers()
        saveDraftData()
    }

    private func resumeAnimations() {
        UIView.animate(withDuration: 0.3) {
            // Melanjutkan animasi UI
        }
    }

    private func refreshDataIfNeeded() {
        let lastRefresh = UserDefaults.standard.object(forKey: "lastRefresh") as? Date ?? .distantPast
        if Date().timeIntervalSince(lastRefresh) > 300 {
            fetchDataFromServer()
        }
    }
}

Kode menunjukkan penanganan Active yang benar di UIKit. applicationDidBecomeActive melanjutkan animasi, timer, dan memeriksa apakah pembaruan data diperlukan. applicationWillResignActive menangguhkan apa pun yang dapat menghabiskan sumber daya dan menyimpan draf. Sepasang metode semacam itu menjamin bahwa aplikasi merespons perubahan status dengan benar.

SwiftUI: scenePhase

Di SwiftUI tidak ada AppDelegate — pengelolaan status dilakukan melalui Environment<ScenePhase>. Nilai .active diatur ketika adegan berada di latar depan dan interaktif. SwiftUI secara otomatis memulai ulang animasi dan pembaruan saat kembali ke Active. Pengembang hanya perlu berlangganan onChange untuk menjalankan efek samping.

import SwiftUI

@main
struct ActiveDemoApp: App {
    @Environment(\.scenePhase) private var scenePhase

    var body: some Scene {
        WindowGroup {
            ContentView()
        }
        .onChange(of: scenePhase) { oldPhase, newPhase in
            switch newPhase {
            case .active:
                print("Adegan menjadi aktif")
                resumeWork()
            case .inactive:
                print("Adegan menjadi tidak aktif")
                pauseWork()
            case .background:
                print("Adegan masuk ke latar belakang")
                saveState()
            @unknown default:
                break
            }
        }
    }

    private func resumeWork() {
        // Melanjutkan permintaan jaringan, animasi
    }

    private func pauseWork() {
        // Menangguhkan tugas yang sensitif terhadap waktu
    }

    private func saveState() {
        // Menyimpan status aplikasi
    }
}

Di SwiftUI, scenePhase adalah satu-satunya sumber kebenaran tentang status aplikasi. onChange memungkinkan menjalankan tindakan pada setiap transisi. Penting untuk diingat bahwa scenePhase hanya tersedia di iOS 14+ dan di SwiftUI Lifecycle. Untuk aplikasi UIKit dengan layar SwiftUI, gunakan pendekatan dengan UIApplicationDelegate.

Transisi ke status Active

Active dapat dicapai melalui beberapa cara. Pertama dan jelas — mulai dingin: pengguna menekan ikon, aplikasi berpindah dari Not Running melalui Inactive ke Active. Kedua — kembali dari latar belakang: pengguna beralih kembali ke aplikasi melalui App Switcher, aplikasi melewati Inactive dan menjadi Active. Ketiga — kembali dari gangguan sementara: pengguna mengakhiri panggilan, menutup Control Center, atau merespons notifikasi — aplikasi kembali dari Inactive ke Active.

Rantai transisi ke Active

Not Running → Inactive → Active — mulai dingin. Background → Inactive → Active — kembali dari latar belakang. Inactive → Active — kembali dari gangguan sementara. Dalam setiap kasus, applicationDidBecomeActive dipanggil, tetapi konteksnya mungkin berbeda. Saat mulai dingin, sebelum Active, didFinishLaunchingWithOptions dipanggil, saat kembali dari latar belakang — willEnterForeground. Pengembang dapat menggunakan perbedaan ini untuk memilih strategi pemulihan status.

Catatan penting: saat kembali dari Suspended, iOS tidak memanggil didFinishLaunchingWithOptions, karena aplikasi sudah dimuat ke memori. Ini berarti kode inisialisasi yang ditempatkan di metode ini tidak dijalankan lagi. Pengembang sering melupakan hal ini dan memindahkan logika kritis ke applicationWillEnterForeground atau applicationDidBecomeActive untuk kedua skenario.

Active di Android: siklus hidup Activity

Di Android, padanan Active adalah status Activity setelah pemanggilan onResume(). Activity dianggap aktif ketika berada di latar depan dan menerima masukan pengguna. Status ini sesuai dengan puncak tumpukan Activity. Jika Activity lain muncul di atasnya (bahkan sebagian), Activity saat ini masuk ke status onPause — padanan iOS Inactive.

Perbedaan utama Android — beberapa Activity dapat aktif secara bersamaan dalam mode multi-window (split screen, freeform). Dalam hal ini, Activity yang berinteraksi dengan pengguna dianggap aktif, dan yang berdekatan — ditangguhkan (onPause). iOS tidak mendukung multi-window di iPhone, hanya di iPad melalui UIScene.

class MainActivity : AppCompatActivity() {

    override fun onResume() {
        super.onResume()
        // Aplikasi menjadi aktif — melanjutkan tugas
        resumeCameraPreview()
        startLocationUpdates()
        activateSensors()
    }

    override fun onPause() {
        super.onPause()
        // Aplikasi kehilangan aktivitas — membebaskan sumber daya
        releaseCamera()
        stopLocationUpdates()
        deactivateSensors()
    }

    private fun resumeCameraPreview() {
        // Memulai pratinjau kamera (memerlukan izin)
        cameraProvider?.unbindAll()
        cameraProvider?.bindToLifecycle(
            this,
            cameraSelector,
            preview,
            imageAnalyzer
        )
    }

    private fun startLocationUpdates() {
        val locationRequest = LocationRequest.Builder(
            Priority.PRIORITY_HIGH_ACCURACY, 5000
        ).build()
        locationClient.requestLocationUpdates(
            locationRequest,
            locationCallback,
            Looper.getMainLooper()
        )
    }
}

Kode menunjukkan penanganan Active di Android melalui onResume/onPause. onResume melanjutkan kerja dengan kamera, geolokasi, dan sensor — sumber daya yang hanya boleh aktif saat aplikasi terlihat oleh pengguna. onPause membebaskan sumber daya ini agar tidak menguras baterai. CameraX lifecycle-aware API secara otomatis menghentikan pratinjau saat onPause.

Praktik terbaik penanganan Active

Aturan pertama — jangan lakukan operasi berat di applicationDidBecomeActive atau onResume. Memuat data, mengurai JSON, bekerja dengan basis data — semua ini harus asinkron dan tidak memblokir utas utama. Gunakan GCD (DispatchQueue) di iOS dan Coroutines di Kotlin untuk tugas latar belakang. Utas utama hanya boleh memperbarui UI dan memulai operasi asinkron.

Aturan kedua — sinkronkan status setiap kali kembali ke Active. Pengguna mungkin telah mengubah pengaturan di aplikasi sistem, menerima notifikasi push, atau memperbarui data di aplikasi lain. Periksa aktualitas cache saat transisi ke Active — mungkin data sudah kedaluwarsa selama ketidakhadiran pengguna.

Aturan ketiga — jangan hanya mengandalkan Active sebagai satu-satunya status. Aplikasi dapat melewatkan Active dan langsung beralih dari Not Running ke Background (jika dijalankan di latar belakang). Di iOS, ini terjadi saat dijalankan melalui notifikasi push dengan opsi content-available. Di Android — saat dijalankan melalui BroadcastReceiver. Selalu periksa status saat ini sebelum melakukan operasi UI.

Aturan keempat — gunakan Activity Result API di Android, bukan onActivityResult. Ini memungkinkan menangani hasil pemanggilan kamera, galeri, atau izin langsung di status Active tanpa kehilangan data saat pembuatan ulang Activity. Untuk iOS, gunakan async/await dengan UIApplication.shared.open untuk dialog sistem.

import UIKit

final class ActiveStateManager {
    static let shared = ActiveStateManager()
    private var isActive = false

    func setActive(_ active: Bool) {
        isActive = active
        if active {
            NotificationCenter.default.post(name: .appDidBecomeActive, object: nil)
        }
    }

    func performWhenActive(_ block: @escaping () -> Void) {
        if isActive {
            block()
        } else {
            // Tunda eksekusi hingga kembali ke Active
            NotificationCenter.default.addObserver(
                forName: .appDidBecomeActive,
                object: nil,
                queue: .main
            ) { _ in
                block()
            }
        }
    }
}

extension Notification.Name {
    static let appDidBecomeActive = Notification.Name("appDidBecomeActive")
}

Kode menunjukkan manajer status Active yang memungkinkan komponen aplikasi lain memeriksa status aktif saat ini. performWhenActive langsung menjalankan blok (jika aplikasi aktif) atau menunda eksekusi hingga kembali ke Active. Ini berguna untuk layanan yang harus melakukan tindakan setelah pengguna kembali ke aplikasi.