4

Can people give me examples of why they would use coreData in an application?

I ask this because most apps are just clients to a central server where an API of some sort gives you the information you need.

In my case I'm writing a timesheet application for a web app which has an API and I'm debating if there is any value in replicating the data structure on my server in core data(Sqlite)

e.g

Project has many timesheets employee has many timesheets

It seems to me that I can just connect to the API on every call for lists of projects or existing timesheets for example.

I realize for some kind of offline mode you could store locally in core data but this creates way more problems because you now have a big problem with syncing that data back to the web server when you get connection again.. e.g. the project selected for a timesheet no longer exists.

Can any experienced developer shed some light on there experiences on when core data is best practice approach?

EDIT

I realise of course there is value in storing local persistance but the key value of user defaults seems to cover most applications I can think of.

Derek Organ
  • 8,323
  • 17
  • 56
  • 75

4 Answers4

6

You shouldn't think of CoreData simply as an SQLite database. It's not JUST an SQLite database. Sure, SQLite is an option, but there are other options as well, such as in-memory and, as of iOS5, a whole slew of custom data stores. The biggest benefit with CoreData is persistence, obviously. But even if you are using an in-memory data store, you get the benefits of a very well structured object graph, and all of the heavy lifting with regards to pulling information out of or putting information into the data store is handled by CoreData for you, without you necessarily needing to concern yourself with what is backing that data store. Sure, today you don't care too much about persistence, so you could use an in-memory data store. What happens if tomorrow, or in a month, or a year, you decide to add a feature that would really benefit from persistence? With CoreData, you simply change or add a persistent data store, and all of your methods to get information out or in remain unchanged. The overhead for that sort of addition is minimal in comparison to if you were trying to access SQLite or some other data store directly. IMHO, that's the biggest benefit: abstraction. And, in essence, abstraction is one of the most powerful things behind OOP. Granted, building the Data Model just for in-memory storage could be overkill for your app, depending on how involved the app is. But, just as a side note, you may want to consider what is faster: Requesting information from your web service every time you want to perform some action, or requesting the information once, storing it in memory, and acting on that stored value for the remainder of the session. An in-memory data store wouldn't persistent beyond that particular session.

Additionally, with CoreData you get a lot of other great features like saving, fetching, and undo-redo.

jmstone617
  • 5,707
  • 2
  • 24
  • 26
  • Can you give me an example of when you used it? What did the app do? – Derek Organ Apr 03 '12 at 12:27
  • I've used it for both scenarios. In the scenario where I was pulling down data from the web, I would just pull the data once and parse, and create NSManagedObjects for that stuff. Then I could pass that around in the app however and whenever I wanted. I used a persistent SQLite store because even though it was web data, I didn't want a user to HAVE to be connected to the web for it to be a useful app. I polled the web feed for changes and CD would commit only the changes (deltas), not the whole object. – jmstone617 Apr 03 '12 at 12:30
  • 1
    +1 Would like to add: Core Data also ensures the consistency of your object graph – Andy Friese Apr 03 '12 at 12:32
  • Absolutely. CD has so many benefits that it's hard to make a case against it, except for in rare edge cases, or if your app is just too simple to really warrant the time it would take to set up the data model (which you can do graphically and without much actual code). – jmstone617 Apr 03 '12 at 12:35
  • It feels like the logic for syncing in my case could get quite complex and even impede on the user experience in terms of expectation of what will happen but I take your point – Derek Organ Apr 03 '12 at 12:35
  • The in memory store is great for doing unit tests of your model. Just construct an in memory instance in the setUp method and use it in the tests. – JeremyP Apr 03 '12 at 15:43
  • Or just don't send any save messages to your managed object context. That's how I've tested stuff when I have an actual persistent store. That, or just nuke whatever is currently in the store on each load. I'm sure there are better ways. – jmstone617 Apr 03 '12 at 15:50
3

There are basically two kinds of apps. Those that provide you with local functionality (games, professional applications, navigation systems...) and those that grant access to a remote service.

Your app seems to be in the second category. If you access remote services, your users will want to access new or real-time data (you don't want to read 2 week old Facebook posts) but in some cases, local caching makes sense (e.g. reading your mails when you're on the train with unstable network).

I assume that the value of accessing cached entries when not connected to a network is pretty low for your customers (internal or external) compared to the importance of accessing real-time-data. So local storage might be not necessary at all.

If you don't have hundreds of entries in your timetable, "normal" serialization (NSCoding-protocol) might be enough. If you only access some "dashboard-data", you will be able to get along with simple request/response-caching (NSURLCache can do a lot of things...).

Core Data does make more sense if you have complex data structures which should be synchronized with a server. This adds a lot of synchronization logic to your project as well as complexity from Core Data integration (concurrency, thread-safety, in-app-conflicts...).

If you want to create a "client"-app with a server driven user experience, local storage is not necessary at all so my suggestion is: Keep it as simple as possible unless there is a real need for offline storage.

John Topley
  • 113,588
  • 46
  • 195
  • 237
Martin Ullrich
  • 94,744
  • 25
  • 252
  • 217
  • 2
    CoreData is not JUST about data persistence. As I said below, he could use an in-memory data store to simply receive the other benefits of CoreData, such as delta-saves, deletes, and undo/redo. If I make a change to my time sheet, and then want to back that change out, doing it with CoreData is incredibly easier than trying to write that logic yourself. – jmstone617 Apr 03 '12 at 12:39
  • Of course core data is more than persistence but my point is more about how and where the user interacts with the data. if you have web services for every edit/redo and you don't want to allow any edits the server cannot deal with, then every form of local data manipulation is a great overhead.. if it does make sense to operate on local data, core data makes sense (e.g. with RestKit). If you only want to "store" simple things for viewing them (no or little manipulation) then even core data itself is a overhead – Martin Ullrich Apr 03 '12 at 12:54
1

It's ideal for if you want to store data locally on the phone.

Seriously though, if you can't see a need for it for your timesheet app, then don't worry about it and don't use it.

Solving the sync problems that you would have with an "offline" mode would be detailed in your design of your app. For example - don't allow projects to be deleted. Why would you? Wouldn't you want to go back in time and look at previous data for particular projects? Instead just have a marker on the project to show it as inactive and a date/time that it was made inactive. If the data that is being synced from the device is for that project and is before the date/time that it was marked as inactive, then it's fine to sync. Otherwise display a message and the user will have to sort it.

Nick Bull
  • 4,276
  • 1
  • 18
  • 25
  • In the web app you can't delete projects that have timesheets associated with them but.. if they don't then you can .. edge case but still. – Derek Organ Apr 03 '12 at 12:23
  • Can you give me an example of when you used core data for an app and it was needed? – Derek Organ Apr 03 '12 at 12:24
  • 1
    Just change the server side so it doesn't delete them. What happens if you delete something on the web app and someone is entering data and they click the "save" just after someone has clicked the "delete" on the project? You will be handling that case anyway. What about using coredata for caching the projects and other data locally on the handset so you aren't constantly going back and forth to your server. Sounds to me like you are just wanting to write a wrapper around a webview to display your webapp. You need to think about the user experience on a mobile device native app. – Nick Bull Apr 03 '12 at 12:37
  • I've used core data in a game for storing the in-game statistics for calculating achievements. I've also used it for local caching of news and other data for another app. – Nick Bull Apr 03 '12 at 12:39
0

It depends purely on your application's design whether you need to store some data locally or not, if it is a real problem or a thin GUI client around your web service. Apart from "offline" mode the other reason to cache server data on client side might be to take traffic load from your server. Just think what does it mean for your server to send every time the whole timesheet data to the client, or just the changes. Yes, it means more implementation on both side, but in some cases it has serious advantages.

EDIT: example added

You have 1000 records per user in your timesheet application and one record is cca 1 kbyte. In this case every time a user starts your application, it has to fetch ~1Mbyte data from your server. If you cache the data locally, the server can tell you that let's say two records were updated since your last update, so you'll have to download only 2 kbyte. Now you should scale up this for several tens of thousands of user and you will immediately notice the difference of the server bandwidth and CPU usage.

MrTJ
  • 13,064
  • 4
  • 41
  • 63