Unowned Reference: ano ito, sintaks at aplikasyon sa mga mobile app

Ano ang Unowned Reference?

Unowned Reference — ay isang hindi nagmamay-aring referensiya sa isang object sa ARC na hindi nagpapataas ng retain count nito. Hindi tulad ng weak, unowned ay hindi ni-zero pagkatapos ng dealokasyon ng object: patuloy itong tumuturo sa lugar ng memorya na pinalaya na. Ang pag-access sa naturang referensiya ay nagdudulot ng runtime crash na may EXC_BAD_ACCESS.

Ang terminong “walang may-ari” ay sumasalamin sa semantika: ang object ay umiiral, ngunit walang may pananagutan sa buhay nito. Ang developer ay tahasang nagpapahayag: “ginagarantiya ko na ang object na ito ay mabubuhay habang ako ay tumutukoy dito”. Hindi sinusuri ng compiler ang garantyang ito — ito ay isang kontrata sa antas ng developer.

Ayon sa Swift.org Documentation, 2026, ang mga unowned referensiya ay mas gusto kaysa weak sa mga senaryo na may garantisadong buhay dahil: hindi nangangailangan ng opsyonal na uri (mas malinis na code), hindi nangangailangan ng unwrap (mas kaunting force-unwrap o guard let), at walang overhead para sa pagpapanatili ng zeroing weak-table. Gayunpaman, anumang paglabag sa kontrata — crash.

Sintaks ng unowned sa Swift

Sa Swift, ang mga unowned referensiya ay idineklara gamit ang keyword na unowned bago ang let o var. Hindi tulad ng weak, ang unowned ay maaaring parehong let at var at hindi nangangailangan ng opsyonal na uri. Ang property na ito ay ginagawang maginhawa ang unowned para sa mga referensiya na hindi maaaring nil ayon sa lohika ng domain.

class Country {
    let name: String
    var capital: City!           // itatakda pagkatapos ng initialization
    init(name: String) { self.name = name }
}

class City {
    let name: String
    unowned let country: Country   // unowned let — garantiya ng buhay

    init(name: String, country: Country) {
        self.name = name
        self.country = country
    }
}

// Paggamit
let france = Country(name: "France")
let paris = City(name: "Paris", country: france)
france.capital = paris
// Country → City (strong), City → Country (unowned) — walang retain cycle

Sa halimbawang ito City unowned let country — ang lungsod ay hindi maaaring umiral nang walang bansa. Kung mawala ang bansa, ang lungsod (at referensiya) ay mawawalan ng kahulugan. Sa semantika, ito ay perpektong kaso para sa unowned: garantiya ng buhay ay umiiral, optional ay hindi kailangan, retain cycle ay hindi nangyayari.

unowned var

unowned var ay pinapayagan ngunit mas bihira. Ginagamit kapag ang referensiya ay maaaring palitan (hal., muling pagkabit ng anak sa ibang magulang). Sa pagpapalit, ang pagpapalaya ng lumang object — responsibilidad ng panlabas na may-ari.

Unowned Optional

Sa Swift 5.0+ idinagdag ang suporta para sa unowned optional (unowned let x: Type?). Ito ay isang kompromiso: ginagarantiya ng unowned na kung ang referensiya ay hindi nil, ang object ay buhay. Pag-uugali sa pagpapalaya — crash, tulad ng karaniwang unowned.

Unowned vs Weak: kailan gagamitin ano

Ang pagpili sa pagitan ng unowned at weak — isa sa mga madalas na desisyon sa pagdidisenyo ng arkitektura ng Swift. Tingnan natin ang mga pamantayan at rekomendasyon para sa bawat kaso.

Praktikal na patakaran

Gamitin ang weak kung may kahit kaunting pag-aalinlangan tungkol sa buhay ng object. Ang weak ay ligtas, nauunawaan, at hindi nangangailangan ng patunay. Gamitin ang unowned lamang kapag naalis mo na ang lahat ng senaryo kung saan ang object ay maaaring mapalaya nang mas maaga. Mga tipikal na kaso: anak na hindi umiiral nang walang magulang; closure na isinasagawa nang sabay; pagtukoy sa object sa loob ng initiator nito.

Ayon sa Airbnb Swift Style Guide, 2025, sa malalaking codebase inirerekomenda na gamitin ang weak bilang default at unowned — lamang na may tahasang komento na nagpapaliwanag ng garantiya ng buhay. Binabawasan nito ang peligro ng hindi inaasahang pag-crash sa refactoring.

Unowned self sa mga closure

Ang mga closure — pangalawang pinakamadalas na senaryo ng paggamit ng unowned pagkatapos ng parent-child na relasyon. Ang capture list [unowned self] ay ginagamit kapag garantisado na ang self ay nabubuhay nang mas mahaba kaysa sa closure. Tingnan natin ang tama at maling senaryo.

Kailan ligtas ang unowned self

Sabay na closure — sorted, filter, map. Agad silang isinasagawa sa kasalukuyang thread, tiyak na buhay ang self. Ang capture list na may unowned ay katanggap-tanggap dito at nagbibigay ng mas malinis na code.

class DataProcessor {
    var items: [Int] = [3, 1, 4, 1, 5]

    func processSorted() {
        // unowned self — sorted ay isinasagawa nang sabay, self garantisadong buhay
        let sorted = items.sorted { [unowned self] a, b in
            return self.customCompare(a, b)
        }
    }

    func customCompare(_ a: Int, _ b: Int) -> Bool { return a < b }
}

Kailan mapanganib ang unowned self

Asynchronous na closure — may pagkaantala, mga kahilingan sa network, mga animation. Ang self ay maaaring mapalaya sa pagitan ng paglalagay ng closure at pagpapatupad nito. Dito unowned self → crash. Gamitin ang [weak self].

class NetworkLoader {
    func loadData() {
        // MAPANGANIB: unowned self sa asynchronous na closure
        URLSession.shared.dataTask(with: url) { [unowned self] data, _, _ in
            self.handleResponse(data)  // CRASH kung ang self ay pinalaya
        }.resume()
    }

    func handleResponse(_ data: Data?) { }

    // TAMA: weak self + guard
    func loadDataSafe() {
        URLSession.shared.dataTask(with: url) { [weak self] data, _, _ in
            guard let self else { return }
            self.handleResponse(data)
        }.resume()
    }
}

Tandaan ang patakaran: unowned self — para lamang sa sabay na closure na agad naisagawa. Para sa asynchronous — palaging weak self + guard let. Pagbubukod: kung tahasang hawak mo ang referensiya sa object hanggang matapos ang closure (hal., sa pamamagitan ng pag-iingat ng malakas na capture sa ibang variable).

Mga peligro ng unowned at paano maiwasan

Ang Unowned — makapangyarihan ngunit mapanganib na kasangkapan. Tingnan natin ang mga tunay na senaryo kung saan ang unowned ay maaaring humantong sa crash at mga pamamaraan ng pagbawas ng peligro.

Refactoring at pagbabago ng mga garantiya

Pangunahing peligro ng unowned — pagbabago ng lohika ng negosyo kung saan ang garantiya ng buhay ay hindi na natutupad. Refactor ng developer ang code: binabago ang pagmamay-ari, nagpapakilala ng naantalang pagpapalaya, nagdaragdag ng caching — at ang unowned referensiya ay nagiging bomba ng oras. Hindi magbibigay babala ang compiler — tanging crash sa device ng user.

Rekomendasyon: gamitin ang unowned lamang kapag ang garantiya ng buhay ay malinaw at naidokumento. Magdagdag ng komento sa bawat unowned: bakit ligtas ang referensiyang ito at sa ilalim ng anong mga kondisyon ito maaaring labagin.

Unowned sa mga hierarchy ng UIKit

UIKit — zone ng mataas na peligro para sa unowned. Ang ViewController ay maaaring mapalaya anumang oras sa navigation (pop, dismiss), pagbaba mula sa memorya, pagbabago ng oryentasyon. Kung ipapasa mo ang ViewController sa isang closure na may unowned self — sa pagbabalik mula sa background o pagtatapos ng animation, ang self ay maaaring nil.

Pinakamahuhusay na kasanayan

Upang mabawasan ang peligro kapag gumagamit ng unowned, sundin ang mga patakarang ito:

• Mas gusto ang weak bilang default — weak ay ligtas, unowned ay optimisasyon, hindi pamantayan
• Dokumentuhan ang mga garantiya — para sa bawat unowned sumulat ng komento na may katwiran
• Iwasan ang unowned sa ViewController — ang siklo ng buhay ng UIKit ay hindi mahuhulaan para sa unowned na garantiya
• Gamitin ang unowned lamang para sa sabay na closure — sorted, filter, map — ligtas na mga kandidato
• Suriin sa code review — bawat unowned ay nangangailangan ng katwiran mula sa may-akda ng code
• Mag-migrate sa weak sa pinakamaliit na pag-aalinlangan — pagkawala sa pagiging madaling mabasa (isang guard let) ay mas mababa kaysa crash sa produksyon

// Halimbawa: dokumentadong unowned referensiya na may malinaw na katwiran
class InvoiceLineItem {
    let productName: String
    let price: Decimal

    // unowned Invoice — InvoiceLineItem ay hindi maaaring umiral nang walang Invoice.
    // Invoice gumagawa ng Item at tinatanggal ito sa sariling pagtanggal.
    // Garantiya: Invoice nabubuhay kahit kasingtagal ng Item.
    unowned let invoice: Invoice

    init(productName: String, price: Decimal, invoice: Invoice) {
        self.productName = productName
        self.price = price
        self.invoice = invoice
    }
}

// Ito ay malakas na garantiya: Invoice tinatanggal lahat ng Item sa deinit.
// paglabag sa garantiya = bug sa lohika ng negosyo na kailangang ayusin.

Ang dokumentasyon ng mga garantiya — propesyonal na pamantayan. Sa malalaking proyekto (Airbnb, Uber) ang code review ay nangangailangan ng katwiran sa bawat unowned. Kung ang garantiya ay hindi malinaw — gamitin ang weak. Ang komento sa unowned ay tumutulong sa mga susunod na developer na maunawaan kung bakit walang weak dito at anong mga kondisyon ang maaaring makasira sa garantiya.