Be careful about using Core Data for iOS memory management…
Over the last few months I’ve been migrating away some of our current apps to use Core Data which is an object graph and persistence framework provided by Apple in the Mac OS X and iOS operating systems.
These projects have given me great exposure to Core Data from Apple while I’ve been developing apps recently using plugins such as FMDatabase.
During the exposure to using Core Data I thought it would be good to write upon my experiences for other developers out there starting to look into a solution for database management in iOS…
App with FMDatabase
One of the minor requirements was to allow a user to create and save the event of their choice. The task was to apply CRUD operations to empty sqlite file. The advantage was that we could create the data file, and make the changes when required.
Now this was useful especially when we needed to add new features into the mobile app. Obviously we needed to define each operation to data manager class which did bring a bit of frustration.
Next time I would definitely use Core Data to this kind of project and here is why:
App with Core Data
The project specification for the mobile app required that users were required to save some of their operations, however, we also had to store the data provided by the client. So the task was to load the data to the app and also apply CRUD operations. I decided to use Core Data in order to test it but also for its “object like” approach to manage the data. It is a great choice if you want an optimised cache of the data to be fetched and then bind it to the interface.
When it comes to pre-loaded data, I realised that using Core Data as a file format was a real pain. I was impressed how easy we could build our data model and visibly define all objects and its relations. We checked how the data file that was created and integrated the clients data.
The issue came when the client came back and changed the data model. I quickly realised there is no way of changing the data file outside the CoreData, unless you want to do some minor changes in the text. That could be easily achieved with CoreData Editor but even this well promising app is limited to few operations. CoreData Editor only imports a CSV file and it is imported out of the order so setting up the relations was like a “Sisyphean task”. Manually building code to handle the migration between model versions was not an option. CoreData columns are not public file format and even after figuring out the mysterious letter “Z” still it isn’t a deal.
After all the struggles we still managed to finish the project with the huge lesson for the future. CoreData is not ready to handle pre-loaded data unless you really have a passion. Thou, its a great option for any other apps and you will really benefit in time, great memory management (it only load the objects you currently need) and your product structure (you only have to change the objects in your model, not the entire data set). Everything is treated as objects so forget about NSDictionary.
So, what have I learned? CoreData is not for all projects we work on. Wisely plan your project and your data handling, if your project needs smart data manger with low memory use and no data pre-loaded use CoreData, but if your project does require the data pre-loaded I strongly recommend to use one of the available libraries that does treat the data as a user-visible file.
Further Useful Links
Core Data Tutorial for iOS: Getting Started