1

Typically I use Core Data in my applications, but for my current project I don't need data to persist launch to launch.

Because of that, I'm wondering how I should store my data. It's not going to be tens of thousands of items or anything, hundreds at the high end most likely.

I'm still going to create an NSObject subclass to represent each "entry" in the database, but what should I store that in? A simple NSMutableArray that's a property? Should I have a distinct model class? Should I still be using Core Data somehow?

What's the accepted/best practice for a situation like this?

Doug Smith
  • 29,668
  • 57
  • 204
  • 388
  • Depends on how you need to access it. If you need to random searches you must figure out the scheme you're going to use for that. It may be simpler to use CoreData or SQLite than to manage your own scheme. – Hot Licks Apr 03 '14 at 15:49

3 Answers3

3

The persistence aspect is only one part of core data. The fetch requests, object graph maintenance and entity modeller are arguably just as important.

If you don't want to persist your data, use the in-memory store type when creating your core data stack.

jrturton
  • 118,105
  • 32
  • 252
  • 268
  • Ah, fair enough! If I'm creating something as simple as a list of posts, similar in concept to an RSS feed that I don't want to persist, is there much advantage to using Core Data? I guess searching and whatnot through fetch requests would be a primary one. – Doug Smith Apr 03 '14 at 17:03
  • Do you know of any tutorials outlining Core Data usage with in-memory stores? I'm having difficulty encountering any. – Doug Smith Apr 03 '14 at 17:23
  • @DougSmith All the tutorials about core data apply to the in-memory store option as well. You do everything the same just nothing hits disk. There is no need for specific tutorials on that store type. – Marcus S. Zarra Apr 03 '14 at 17:25
  • @MarcusS.Zarra How do I specify that option then? – Doug Smith Apr 03 '14 at 18:56
  • 2
    When you add a persistent store (`addPersistentStoreWithType:...`), you specify the in-memory store type instead of the SQLLite store type, and you don't need a URL. That's the only difference. – jrturton Apr 03 '14 at 21:58
1

I would say that if you are familiar with Core Data why dont use it?

But alternatively of course you can stick with NSUserDefault. Atm i'm using the NSCache class.

Good explanation of NSCache and how to use it

Apple's Doc

I would give it a shot if you dont like to use CD for your current Project..

Community
  • 1
  • 1
SaifDeen
  • 862
  • 2
  • 16
  • 33
  • NSCache is a terrible idea. Things could be removed from the cache at any point, outside of your control. – jrturton Apr 03 '14 at 16:30
  • 1
    Because Core Data is a persistent store model, which fundamentally I don't need? It's also a big headache for multi-threading, which if I could avoid, why not? And why would I use NSUSerDefaults if I don't need persistent store? That's its very purpose. And NSCache deletes items randomly as it's a caching mechanism. Have you read my question at all? – Doug Smith Apr 03 '14 at 17:00
  • Yes I read your Question but you're asking for something where there not really much possibilities.. – SaifDeen Apr 03 '14 at 17:21
  • @DougSmith Core Data is object hierarchy that can persist to disk. Persisting is not actually its primary function. Being your object model is its primary function. It will give you everything you need/want as far as database like structure. Everything is complicated in a multi-threaded environment, just some APIs are silent about it and quietly corrupt your data or crash :) Core Data just happens to not be silent about it. – Marcus S. Zarra Apr 03 '14 at 17:24
  • 1
    @SaifDeen This is exactly my point. If the OP wanted something like NSMutableArray or NSMutableDictionary, then just use those. But you're asking a broad questions for other people's opinions and then get rude that they gave their opinions. Fact is, NSUserDefaults is great because if you don't want the "persistence" part, then simply remove the data when you're done with it, that's literally 1 line of code. – Karim Apr 03 '14 at 18:37
  • Do I got rude? Sorry for it, didn't mentioned todo – SaifDeen Apr 07 '14 at 19:44
0

Since you're not worried about persistence, it seems simplest to just use a wrapper around an NSMutableArray (or NSMutableDictionary if indexing is more important that ordering) Since you can apply NSPredicates to arrays you've still got the ability to do very dynamic database style sorting and searching without some of the drawbacks of core data.

Use a wrapper instead of just using an array because that gives you a convenient place to put sorting and searching options, as well as possibly giving you better access to KVO operations.

David Berry
  • 40,941
  • 12
  • 84
  • 95