Core Data — шта је то, модел података и како функционише

Шта је Core Data и његова улога у iOS

Core Data — је фрејмворк за управљање објектним графом и перзистентношћу, који је део Cocoa Touch-а. Супротно увреженом мишљењу, Core Data није база података, већ слој за управљање објектима који може да користи SQLite као једно од складишта. Главни задатак Core Data-е је да прати промене објеката, управља њиховим животним циклусом и синхронизује стање са диском.

Фрејмворк пружа граф објеката, где сваки Managed Object прати контекст ради промена. Приликом чувања контекста, сви измењени, додати и обрисани објекти се потврђују у трајном складишту једном трансакцијом. Ово ослобађа програмера од писања SQL упита и ручног управљања трансакцијама.

Према статистици Swift Developer Survey (2025), Core Data се користи у 52% iOS апликација које раде са локалним подацима. Упркос појави модерних алтернатива (SwiftData, Realm), Core Data остаје главни фрејмворк у постојећим Аpple пројектима захваљујући зрелости и дубокој интеграцији са системом.

Користите Core Data за пројекте са моделом података средње сложености, где су потребне релације између објеката, поништавање промена и аутоматско кеширање кроз faulting механизам.

Архитектура Core Data-е је изграђена око концепта Managed Object Context-а — радног простора који прати све промене објеката. Контекст подржава поништавање (undo/redo) кроз уграђени NSUndoManager, што омогућава имплементацију нацрта и отказивање радњи без ручног чувања снимака стања. Приликом позива save(), контекст потврђује све промене једном трансакцијом у трајном складишту, гарантујући атомичност и конзистентност података.

Модел података: Entity, Attributes, Relationships

Модел података Core Data се дефинише у датотеци .xcdatamodeld — визуелном едитору Xcode-а, где се описују све Entity, њихови атрибути и релације. Приликом компајлирања, модел се серијализује у .momd и учитава кроз NSManagedObjectModel.

Entity и Attributes

Entity — је опис типа података, аналогно табели у SQL-у. Свака Entity садржи скуп Attributes — именованих поља са типом података (String, Integer, Date, Boolean, Data). За разлику од Room-а, Core Data захтева експлицитан избор типа за сваки атрибут кроз едитор модела.

Relationships

Relationship — веза између Entity, аналогно страном кључу у SQL-у. Core Data подржава све типове веза: један-на-један, један-на-много и много-на-много. За сваку везу се подешава Delete Rule (Cascade, Nullify, Deny) — понашање приликом брисања повезаног објекта.

Избор Delete Rule је критичан за интегритет података: Cascade без провере може да обрише трећину базе, а Deny да блокира операцију са неразумљивом грешком. У продукцијском коду препоручује се Nullify са ручном обрадом осиротелих записа.

У едитору модела Xcode-а, програмер може да подеси не само Entity и атрибуте, већ и constraints (ограничења јединствености), индексе за убрзавање упита и default values за атрибуте. Све измене модела се компајлирају у датотеку .momd, која се учитава при иницијализацији NSPersistentContainer-а. Верзионисање модела (Model Versioning) омогућава одржавање више верзија шеме и извођење миграције између њих.

Стек Core Data: PersistentContainer и Context

NSPersistentContainer — јединствени објекат који управља стеком Core Data од iOS 10 и macOS 10.12. Инкапсулира NSManagedObjectModel, NSPersistentStoreCoordinator и NSManagedObjectContext, аутоматизујући учитавање модела и подешавање складишта. За старије верзије, стек се градио ручно, али сада то није препоручено.

let container = NSPersistentContainer(name: "DataModel")
container.loadPersistentStores { _, error in
    if let error { fatalError("Core Data load failed: \(error)") }
}
let context = container.viewContext

viewContext — главни контекст повезан са главном нити. Сва читања и ажурирања UI-ја се обављају кроз њега. Уписивање података ради перформанси препоручује се да се обавља у позадинском контексту подређеног типа са накнадном синхронизацијом.

NSPersistentStoreCoordinator

Координатор NSPersistentStoreCoordinator повезује модел са физичким складиштем на диску. Core Data подржава неколико типова складишта: SQLite (препоручен), Binary и In-Memory. SQLite складиште подржава миграције, инкременталну резервну копију и отпорност на падове током процеса уписа.

NSFetchRequest и рад са подацима

NSFetchRequest — објекат који описује упит ка Core Data складишту. Садржи име Entity, предикат филтрирања, сортирање и подешавања преузимања. Упит се извршава кроз context.fetch(), који враћа низ NSManagedObject-а.

let request = NSFetchRequest<User>(entityName: "User")
request.predicate = NSPredicate(format: "age >= %d", 18)
request.sortDescriptors = [NSSortDescriptor(key: "name", ascending: true)]
request.fetchLimit = 50

let results = try context.fetch(request)

NSPredicate подржава сложене услове: LIKE, IN, BETWEEN, CONTAINS[c] (неосетљив на велика и мала слова), SUBQUERY за угнежђене упите по повезаним Entity-има. Core Data такође подржава NSFetchedResultsController — класу за реактивно учитавање података у UITableView, која аутоматски прати промене и ажурира табелу са анимираним секцијама.

Core Data у вишевитном окружењу

Рад са Core Data у вишевитној апликацији захтева стриктно поштовање правила: NSManagedObject се не може директно преносити између нити. Свака нит (или ред) мора да користи сопствени контекст. Основни приступ — креирање подређеног NSManagedObjectContext-а са приватним редом (NSPrivateQueueConcurrencyType) за упис и viewContext за читање.

Подређени контекст се чува у родитељски, а затим родитељски — у складиште на диску. Ово гарантује да промене не блокирају главну нит и да UI увек види конзистентно стање кроз mergeChanges или аутоматско ажурирање viewContext-а приликом чувања.

Core Data користи faulting — механизам одложеног учитавања повезаних објеката. Приликом преузимања User-а без захтева за његове addresses, повезани Address се не учитавају док им се не приступи кроз тачкасту нотацију. Faulting штеди меморију и убрзава учитавање, али може изазвати неочекивана обраћања диску на главној нити ако се приступ не контролише у позадинским контекстима.

За ефикасно вишевитно окружење користите NSBatchInsertRequest и NSBatchDeleteRequest за масовно уметање и брисање без учитавања објеката у меморију — ово је критично за синхронизацију података са сервером.

Batch операције се извршавају директно на нивоу NSPersistentStoreCoordinator-а, заобилазећи контекст и граф објеката. Ово омогућава уметање 10.000 записа за неколико милисекунди без креирања 10.000 инстанци NSManagedObject-а у меморији. Након извршења batch упита, контекст се мора ажурирати кроз mergeChangesFromContextDidSaveNotification да би UI одразио нове податке. Аpple препоручује batch операције за почетно учитавање података и ноћну синхронизацију са сервером.

За праћење промена у Core Data користи се NSPersistentHistoryTracking — механизам који бележи сваку трансакцију (уметање, ажурирање, брисање) у засебној историји. Укључивање history tracking-а омогућава синхронизацију података између различитих процеса и апликација које раде са истим SQLite фајлом, на пример између главне апликације и Notification Service Extension-а. Активација се врши кроз NSPersistentStoreDescription са флагом persistentHistoryTrackingKey, а читање — кроз NSPersistentHistoryChangeRequest са филтером по датуму и типу трансакције.

За отклањање грешака и профилисање перформанси Core Data користи се алат Core Data Profiler из комплета Instruments у Xcode-у на macOS-у. Он приказује све операције преузимања, уметања, брисања и чувања са трајањем сваке операције и бројем учитаних објеката у табелама и на графицима временске линије. Програмер може да идентификује проблематична места: вишеструка преузимања истог упита (недостатак кеширања), цурење fault објеката приликом скроловања табеле или блокирање главне нити због синхроног учитавања повезаних ентитета. Препоручује се покретање профилисања на стварном уређају, а не на симулатору, јер перформансе симулатора не одражавају стварно понашање апликације на iPhone-у или iPad-у.