ios - Caching or Core Data for semi-perminant image and video persistence? -

(note there tldr @ bottom if lot of text)

i'm working on pulls , displays images , videos server. think of different folders pictures , videos behind them can view.

each folder gets updated new pictures , videos consistently, able store many of these pictures , videos @ time minimize loading/requesting-from-database time preloading , saving few.

let me preface saying can wrong write following line. why i'm asking. i'm not 100% clear on capabilities of each approach

i'm going try organized possible here:

reqs/usage:

• save large files (image , video data) quick access (populated server)
• quick rotation on saved data; updated
• files transient, don't want show expired information don't want keep reloading similar stuff every time need see it.
• needs able full store multiple folders worth of data, 8-12mb worth of files per folder on mid-high range (not useful if 1 instantly accessible , rest still have loaded database when viewed)
• efficient network usage (avoid redundant calls repopulate table every time)
• persist across app backgrounds / store new data indefinitely until enough internet upload
• there notable one-to-many relationship of folder files within folder... need able access files within folder easily
• (easier code/maintain... not necessary nice)

my rational core data:

pros:

• supports of want default
• save other aspects of model objects aren't large media files ease (ex. name of folder, etc) in query-able way
• lots of great tools magical record , restkit interact server/make easy
• potential store more data @ time saving file system
• easy persist

cons:

• this isn't typical core data set-up because i'm not particularly concerned permanent storage, want many folders possible instantly available; clearing memory needed.
• speed: minor edits still require entire context re-saved. meaning it's slower load, sync, , flush caching (see this actual speed metrics... not nontrivial). lots of continual writing disk seems problematic in terms of performance.

rational caching:

pros:

• quicker: more in line semi-perminant aspect (quick rotation of saved data, etc)
• easier memory management (won't have continually , manually clearing out old data that's been saved core data no longer need/want)
• less boilerplate/quantity of code

cons:

• doesn't persist default, clears on background
• less memory work with; concerned performance issues of having delete , reload data memory constantly.
• no querying support , (i don't think) no way of selectively clearing properties of objects while keeping other properties (i think you'd have decode entire object, clear info manually, , re-encode?)
• clears when app backgrounds default (i.e less control on when information dumped free memory may needed)

tldr

should use caching or core data save large files going updated server semi-frequently? factors consider me efficiency (minimize server requests; store data until it's overwritten new data), speed (to write/load), amount of data stored/memory available (memory concerns moving large amounts of data using caching, affect performance.. how many files can have in memory @ once before start see adverse performance?), customizability (it seems me need in between two, easier adapt uses)

and importantly.... there else i'm missing completely? sort of file system manager or unique caching ma-jiggy?)

if doing caching files, there not need coredata, file system fast key/value store files.

if want have bunch of associated data files, can set extended attributes on files (though can't efficiently use attributes in search).

if still want use coredata, can so. have several options. common 2 options are:

1. store file's url attribute in coredata entity, , manage storing files directly disk yourself.

2. store data coredata attribute, , select "allows external storage" option attribute. cause coredata own calculation, , if data "small enough" stored in database. if "too large" stored external file.

apple not document cutoff value, experimentation has shown 1mb.

it easier go option 2, core data manage you. viable option, , have used in 1 large application stores bunch of large files (none small enough selected live in database).

there issues migration speed, because core data wants migrate entire store. thus, want take consideration before deciding.

you may want build test app, , add bunch of stuff, , go through various scenarios before deciding, 2 common options available you.