-1

Say I'm building an app that fetches the RSS feed for a specific website. The user might ask for the articles for the New York Times, then finish with that and ask for articles from The Boston Globe.

It makes sense to store it in Core Data for me (correct me if I'm wrong though) as I want to be able to search easily, and with NSFetchedResultsController I can present the data easily.

But how do I handle the fact that I don't want to keep things around forever? In the above example, once the user asks for The Boston Globe, I have no more need to store the data on the New York Times, and it actually is annoying to have around for when NSFetchedResultsController requests what to show and it's still in the store.

Doug Smith
  • 29,668
  • 57
  • 204
  • 388
  • Doug, no offense but that isn't a very good way to use Core Data. I wouldn't build a store in order to get rid of it after few taps. You say that a user must be able to search but don't want to keep things around forever. Does that mean deleting data every time the user exit the app? Please clarify. – carlodurso Oct 03 '14 at 19:58
  • @carlodurso No offense taken, if that's the case I want to learn! And it doesn't need to persist from app launch to launch, in fact it shouldn't, be that from deleting it or the OS just cleaning it up. The feed can just be reloaded on launch in order to get new items. I'd love to hear what you recommend. – Doug Smith Oct 03 '14 at 20:40
  • 1
    Great. Teaching and learning, it's all I'm aiming for :-) I'll post an answer, there are few things I want to share with you. – carlodurso Oct 03 '14 at 20:47

3 Answers3

1

One problem I see with using Core Data for temporary storage is cleanup. Core Data does not provide an API to delete rows in bulk, say, by specifying a NSPredicate, forcing you to use loops when deleting your rows.

Still, the convenience of using NSFetchedResultsController may be well worth the trouble with the deletion: this answer provides a solution for deleting all the data programmatically (the other answer that suggests deleting underlying files may not work in the newest versions of iOS).

If you do not mind writing some SQL queries, running against the "raw" SQLite, without using the Core Data layer, may provide a cleaner alternative, because you can offload deletions onto the backstore with very simple SQL DML commands.

Community
  • 1
  • 1
Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
  • "running against the "raw" SQLite may provide a cleaner alternative". Until Core Data's schema or defaults change, and this doesn't handle correctly notifying Core Data that the underlying storage has changed. Modifying the SQLite data of a Core Data NSSQLiteStoreType store directly is *extremely* dangerous. – quellish Oct 06 '14 at 00:38
  • @quellish I think you have completely misunderstood my point: I mean using SQLite directly, scraping the Core Data layer altogether. – Sergey Kalinichenko Oct 06 '14 at 00:55
  • You should update your answer to make that clear. The original question is about Core Data, and the text of your answer right now does not make it clear that you are suggesting an approach that abandons the Core Data approach. – quellish Oct 06 '14 at 00:56
  • @quellish Well, OP did ask if we could suggest a better alternative in his second paragraph, but I made my point explicit in the edit. – Sergey Kalinichenko Oct 06 '14 at 01:02
0

You should use in-memory store option NSInMemoryStore instead of Sqlite for your NSPersistentStoreCoordinator if you don't want to save to disk.

Razvan
  • 4,122
  • 2
  • 26
  • 44
0

Using a neologism with web development I wouldn't create a SQL table for every user session, then delete it when he/she exits the site.That would be expensive in terms of CPU. Think of Core Data in those terms. Use it for persistent data.

There are aspects of your app which are not very clear, but in general I would rather use a NSDictionary to store data. Then moving that data to an NSArray, which works well with NSPredicate, whenever a search is triggered.

Now, if your case is specific and you consider that Core Data would add performance or UX value to your app, then you can insert objects in Core Data and delete them when applicationDidEnterBackground or applicationWillTerminate.

[NSEntityDescription insertNewObjectForEntityForName:@"feed" inManagedObjectContext:context];
[context deleteObject:aManagedObject];

This is my 2 cents.

carlodurso
  • 2,886
  • 4
  • 24
  • 37