Comment by wallflower | Hacker News Reader

Comment by wallflower | Hacker News Reader

Parent Full thread

Re: CoreData

Every iOS developer has to go through that learning curve. It is part of the initiation process, unless you want to stick with straight SQLite. CoreData becomes a merit badge of honor. Every developer has their war stories about NSPersistentStoreCoordinator, PSCs on multiple threads, threading, performance, sorting, etc.

Quick note on performance in CoreData. If you need to cache objects that you use frequently, make your own in-memory cache. CoreData is not optimized for caching objects.

But really, CoreData, is something most people who move from iOS dearly miss. Not everyone wants fine grained SQL-level control over persisting data. There is no equivalent in Android. Nada. OrmLite and some other libraries have tried. Where most of the Android OR persistence libraries break down is either m:n relationships or performance or both.

However, times may be a'changing - maybe CoreData and some of its pain can be abstracted itself - if I were to advise a new iOS developer - assuming their requirements for persistence weren't too complicated - I'd tell them to go with Parse for managing backend persistence or http://helios.io from Matt Thompson (of AFNetworking).

    >if I were to advise a new iOS developer - assuming their requirements for persistence weren't too complicated - I'd tell them to go with Parse for managing backend persistence or http://helios.io

As I start to get into mobile development I've been trying to figure out using backend services like Parse or Azure Mobile Services are feasible for about 99.9% of the apps out there over the long term.

Skipping native storage in favor of a cloud provider ties you to a recurring cost (albeit probably small) and if your app fails to monetize, assume free with in app purchases, at the level required in which to sustain the costs of the overall cloud costs incurred by the apps' users then at some point down the road everybody may get cut off if the developer decides to stop paying for the cloud infrastructure.

This has made me feel like single purchase apps with a cloud based back end data piece are ultimately a ponzi scheme as the recurring costs for the early adopters are consuming the revenue from later purchasers.

Could there be a possible Parse-pocalypse in the not too distant future?

I'm still working on my first app so my concerns maybe totally off base, I'd love to hear from more experienced developers.

At this point, unless I'm going to be dealing with large (n>5000) data sets, I just use NSKeyedArchiver and serialize/deserialize all my objects to a file.

Might not be as fast as CoreData, but is sure a lot easier to code and it's fast enough that the user never even notices.

I was able to pick up SQLite much faster than CoreData. It just made more sense to me.

I was building the iOS and Android versions side by side, so a solution that was similar in both platforms was important.

Core Data, as someone said earlier, has a much steeper learning curve than straight SQLite, but it pays off in the long run, saving you from writing enormous amounts of repeating, mindless code. I dread having to maintain my older non-Core Data-using apps, and am in the process of migrating them where I can.

I'm in the process of writing the same repetitive database code for an Android app at the moment and would love a (high quality, I've tried a few bad 3rd party libraries) Core Data equivalent to use.

I was able to pick up SQLite much faster than CoreData.

This is what we did, but then we ran into growing pains of stale objects etc... with SQLite and moved to CD. CD is so much nicer to use and it's something I miss when working on the Android version of our app.

While there is a license for commercial use, db4o[1] might be a good alternative on Android. I'm not sure what CoreData is personally (sounds ORMie), but this tool is an embedded object database. Fairly quick. The con is it will increase your app install size.

1 - http://www.db4o.com/android/

There are a few open source libraries for managing CoreData from a higher level now (like NSOperation for GCD).

This post by Mattt Thompson (of course) on NSHipster has links to wrappers, adapters, synchronizers and utilities for working with CoreData: http://nshipster.com/core-data-libraries-and-utilities/

I highly recommend reading that before starting any CoreData project, and reading over that whole site in general to add new tools/concepts to the Objective-C and iOS Framework toolbelt.

How do you feel about MagicalRecord for alleviating CoreData pain?

I love MagicalRecord. Not only it makes working with Core Data much easier, it makes writing Core Data unit tests a joy.

For those who don't know Magical Record, here's basic a tutorial:

http://ablfx.com/blog/article/2

It's worth checking mogenerator as well:

https://github.com/rentzsch/mogenerator

http://raptureinvenice.com/getting-started-with-mogenerator/

I love the helpers for fetching and creating records that MagicalRecord gives you. But MagicalRecord also has ideas about how you should structure your ManagedObjectContext hierarchy. In the older versions (which we're still using) it was simple with just a separate context per thread which is connected directly to your persistent store. But the latest version (at least last time I checked) is much more complex with multiple child contexts rolling up to your persistent store.

I would prefer to just use the helpers and setup my MOCs and persistent store myself.

Reply on news.ycombinator.com