I have a rather simple iPhone app consisting of numerous views containing a single, grouped table view. These views are held together in navigation controllers which are grouped in a tab bar. Simple stuff.
My table views do little more than list text (like "Dog", "Cat" and "Weasel") and this data is being served from a collection of plists. It's perhaps worth mentioning too that these tables are 'static' in the sense that their data is pre-determined and will only ever be amended—and if so, very rarely indeed—by the developer (in this case, moi).
This rudimentary approach has reached its limits though, and I think I'm going to need something a bit more relational. I have worked a tad with Core Data in the past, but only with apps whose data is determined by user input.
I have four closely related questions:
Is Core Data overkill for an app consisting mainly of a selection of simple table views?
Do you recommend using Core Data to manage data which is predetermine and extremely unlikely to ever change?
Can one lock Core Data down so that its data can't change, thereby relinquishing my responsibility as the developer to handle the editing and saving of the managed object context?
How do I go about giving Core Data my predetermined data, and in a format I know that it can work with?
Thanks a bunch guys.
The answer is simple. If you do not need to persistent to an out of date format (like MSWord, etc.) then you should be using Core Data. Raw SQLite is a headache that is not worth the effort 99.999% of the time.
Core Data is more efficient than plists and allows greater flexibility if the project ever evolves.
It is also very easy to pre-populate a Core Data sqlite file using a OS X machine; you know, the machine you are using to develop your application in the first place :)
NNW's use case is a singular exception to this rule that, if I were a betting man, I would bet has the Core Data team's attention and will be corrected in a future update. An update, by the way, that you will get for free if you use Core Data.
You might consider using the SQLite API directly, rather than Core Data, as it may be easier to pre-populate a database that way. You can create and modify a SQLite database on any platform (Mac, Windows, Linux), and just copy it to your application's bundle as a resource.
You can find tutorials/examples that will create a user's database by copying a SQLite database out of the application bundle. In your case, you can just use the one in the bundle. Just be sure to open it read-only.
I would recommend sticking with plists since your data will rarely change and when it does it will be developer-driven.
Core Data is very powerful, but there will be a moderate amount of plumbing and infrastructure you'll need to set up to make it work.
Core Data places its store outside of your app bundle (as it must to run on the iPhone), so all new installations will need to load data into the store on the first run. This data will probably have to be stored as resource plists anyway, so you aren't saving yourself the trouble of generating those plists. Turns out that wasn't true and you can store read-only parts of the persistent store in the App bundle.
Since I don't know exactly what kinds of limitations you're running in too, Core Data may be the solution, but I'm guessing it won't be. If object relationships are the biggest difficulty you're dealing with, you should read up on object archiving as a way to store your entire object tree in a form that can easily be saved as a resource in your bundle and recreated when necessary.
You should read why NetNewsWire switched
The two main takeaways from that post:
I bet Core Data is the right way to go 95% of the time. Or more. It’s easy to work with. It’s fast (in most cases).
And:
(Rule: always work at the highest level possible.)
I recommend using plain SQLite. It is simpler, easier to maintain and you can build the database on non-mac systems, using many popular GUI editors. For me, using Core data is still a pain. Code to populate your tableviews from a static SQlite database is simple, straightforward, and transparent, while Core Data needs more boilerplate code which you don't even understand completely at first and overall has a lot of hidden complexity which you don't really need.
Related
i'd like to make some application that store data in device.
so i want to use some storage. but there are two ways i can store my data.
first one is saving them to file system by XML structure, and the other one is by using sqlLite library. but i have no idea. because i don't know the strength and weakness each of them. for example location of stored data, and which one is faster to get the data i want. i just store text data. so please recommand which one is better.
sorry for my english skill. thank you!
SQLite !!! No doubt about that.
For easy maintenance, querying capability and lot more.
SQLite has the basic features of a database engine, it's lightweight. Specially designed for mobile platform. So some features like regex in database etc is not included.
File and Database. Always preference goes to database.
DATABASE ALWAYS...
As you said SQLite is one option, and you can use SQLite directly with iOS. But I hope you have heard about Core data, which is a higher level wrapper to make Database easier.
But there is no comparison between Database and files
This would be Perfect answer for your question and for iOS I would suggest SQLite will be the best one as it has everything in one file,
performance loss is lower than XML as cache gets bigger.
It depends on the amount of data (and its structure and complexity) that you are going to store. For rather small amounts, not more than a handfull of records or two, I would use an NSDictionary and the load and save methods that come with it. Those persistant storage will be in XML, btw.
For more data or rather complex data, especially when you do not need to load all the data at the same time, then you should go for a database solution. That chould be sqlite. Or you may opt for core data which (per default) is based on sqlite.
I would suggest core data (unless you aim for portability such as android). You will have to invest in learning core data. Which may appear to be confusing from start. But once you have started with that you will certainly find core data quite convenient. It takes a lot of work from you that you have to care for manually when using native sqlite.
Now this might look like a duplicate thread, but my question is that I have read a lot of questions like.. Core Data vs SQLite 3 and others but these are 2-3 years old. I have also read that FMDB was developed as core data was not supported on iOS, So it should not be used any more. And on the other hand I have read that one should not use core data as a database.
So I am seriously confused,whether I should use core data for object storage or not. I mean on what basis I should decide which to use? Are there any guidelines provided by apple or someone else.. or is it something that will come to me with time.?
Ankit,
Here's the tl;dr skinny: use Core Data.
Here's the long form:
While you could use many criteria to choose between Core Data, an ORM (FMDB) or direct sqlite calls, the real cost of this choice comes from your time to use it, Apple's support and leverage from other projects. (RESTKit, which maps REST services on to Core Data, is popular these days.)
Hence, a large percentage of the time, say 90+% (a made up stat), the answer on iOS will be to use Core Data. Why? Once you get the hang of it and build out a few little helper methods, Core Data keeps you in a consistent computing world -- the Objective-C object graph. Core Data will teach you things about how to use a dynamic language that will help every other aspect of your iOS programming. Hence, you are more productive. Don't fight the framework.
If you are bringing over a large, complex SQLite database & schema from another app, it then might be cost effective to use either FMDB or SQLite. But I doubt it. Your time writing a simple Mac-based command line app to migrate the DB to a Core Data DB is a finite and simple task. You are almost guaranteed to have to rewrite most of the business logic in Objective-C. (Yes, C++ and Objective-C++ are both good technologies. Has your database business logic really been tuned to work on a memory limited device? I didn't think so.)
Core Data gets a bum rap on performance. It is really quite fast. You just have to use it differently than you use a DB. In particular, you almost always over-fetch data from the store and then refine it using predicates directly on the various sets and arrays. On iOS devices, where the flash is surprisingly slow, this over-fetch strategy is particularly effective. You actually have a lot of RAM on these devices, use it to gain performance. (Yes, I know this is an apparent contradiction to my above knock on portable business logic. But really, code ported from a desktop or server environment has so many implicit assumptions about the speed of the disk, the amount of memory and the reality of a VM with a backing store, it just will not work well on a battery powered, memory limited device with a funky memory model. [It won't work very well on Android devices either.]) You will also denormalize your data to simplify displaying it in various iOS and Mac OS X UI widgets. There are a few applications where Core Data will be slower than an equivalent SQLite DB. Those have been detailed elsewhere. The one major claim is that tasks where IDs are defined by upstream databases hits Core Data's performance is true. But it can be somewhat mitigated by judicious indexing and over-fetching.
The thing to remember about mobile devices too is that the database size, because these are mobile devices on the leaves of the internet, is generally of modest size. Hence, performance is easier to attain. Many lessons from the world of servers may not apply to this mobile, battery powered world.
In other words, you've had to go "all in" to use Objective-C on iOS/Mac OS X, you will gain some important productivity benefits from using Core Data too.
Andrew
I recently embarked on this journey myself, and ended up trying out all three. Here's what I learned:
Raw sqlite3
Low-level, full access to database. No abstractions. Very verbose - it takes a good deal of code to do very simple things.
Core Data
Very high-level, built on abstractions, MUST use Apple's generated database. Useful for iCloud synchronization and simple iOS-only data management. Difficult and dangerous to directly access database, and should not be used for cross-platform databases. Still takes a fair amount of code to do simple things.
FMDB
High-level, very abstraction friendly but not forced. Still get full access to database if you need it. Provides an NSDictionary of the result with each item automatically typecasted to the mutable variant of the proper datatype (e.g., text columns are returned as NSMutableString). I ended up building a very simple wrapper class around it to abstract it even more, so I have a helper class with static functions like selectAllFrom:(NSString *)table where:(NSDictionary *)conditions, which returns an NSArray of NSDictionary objects. It's fantastic to be able to do things like NSArray *usersNamedJoe = [DBHelper selectAllFrom:#"user" where:#{#"name": #"Joe"}];.
Basically, while Core Data may be useful for simple iOS-only apps, anyone who's interested in using cross-platform databases should stay far, far away from it - Apple has no interest in making that easy, and it shows.
TL;DR:
Don't use raw sqlite3 unless you're doing something extremely trivial.
Core Data is fine for simple iOS-only data, if you're comfortable with being locked into it.
If you want full control over the database and you're not doing something trivial, or you're building your app for multiple platforms, FMDB is definitely the way to go.
I use FMDB for all my projects that have heavy usage of "INSERTs" and FMDB is not out of date. The last commit on Github was at last November. If you go with SQL I recommend you to use FMDB.
Core Data fits to 95% of all projects, but if it comes to optimization to run to a wall. If you want the benefits of Core Data (OOP, ...) then use it. If you have a lot of insert an deletes with "WHERE" user Sqlite (FMDB)
This POST explain the off and top site for Core Date vs. Sqlite (FMDB)
CoreData is not just an abstraction of an SQL database. CoreData is also does object graph management. CoreData can do things that FMDB simply can't do.
As always: It really depends on your use case. But in 99% of cases CoreData is the right choice.
If performance is critical, you still have to understand how a database works. But CoreData can deliver that performance if you use it the right way. But it takes some time to learn. There are many things that are trivial to do in CoreData that would be very complex to do in FMDB.
As a new SQL guy, I'm going to throw in my two cents:
In Core Data, you have a bit of "boilerplate" code that you need to put in before you can actually use your database. Your app needs at least one of these:
A persistent store coordinator
A managed object context
A managed object. This correlates to an entity, which correlates to a table if you use an SQLite database.
To take full advantage of the framework, you need to understand what role these objects play in the management of your data.
On the other hand, we have SQLite, which - in my opinion - is much easier to understand. To start, you'll need:
A database
A table or more (depending on your data)
Knowledge of SQL - a flexible language with a simplistic syntax (SELECT queries do more than what you might originally think they do)
An object through which your app communicates with SQLite.
Core Data is only an object abstractization of the SQLite3 database. That means you'll have persistant objects easy to manage for standard database operations. You can also work in an transactional mode and design your core data database structure in XCode by creating models.
If you don't whant to create manually your SQLite3 database or persistant methods use Core Data.
I'm a novice iphone developer, and just completed my first iphone app.
After provisioning my iphone for development, I noticed that the app used way too much memory, and that several memory leaks that were issuing from the app accessing the sqlite database in the app caused the app to crash often. After running instruments, I have decided that CORE DATA sounds like a better way to go: of course I still need to use the sqlite database that I have.
so my question is this: how easy would it be to adapt an already existing app to run on core data? My app basically shows 17,000 different mapView annotations in small amounts by county, though my database is very simple, just one giant spreadsheet basically.
in the App delegate, my app opens the Sqlite database, puts some of the data into a locations object with four attributes, and then makes an array of those objects.
the first view controller lets the user decide which county ( one of twelve or so) the user wishes to view, and then the last view controller uses a loop to add the selected locations to a mapView.
How should I modify my app in the previous paragraph so that it uses CoreData? Can you point me to any resources that I can use to achieve this (preferably not the Dev Center's CoreData tutorial; overly confusing and more complicated than i need right now)? or do I have to make an entirely new project in xcode and start from scratch?
Apologies for the indirect pontification, but ...
First, I'd say your assertion, "After running instruments, I have decided that CORE DATA sounds like a better way to go..." is flawed. Finding bugs and performance issues in your app doesn't automatically mean a different approach is better - it may only mean you need to fix your memory leaks and/or adjust your approach based on what your profiling shows.
The fact you say you still need to use an existing SQLite database doesn't automatically preclude using Core Data, but it does make your end solution significantly more complicated. If you can possibly get away with using either Core Data or SQLite entirely, that would by far be your best bet.
Also, Core Data is not a beginner (or, I'd argue, even an intermediate) Cocoa technology. It requires significant prerequisite knowledge to do anything more than very basic stuff without becoming hopelessly lost when the inevitable problem arrises. If you're too pressed to take the time to read the documentation and research the technology for now, you're probably better off just fixing the problems with your existing solution.
... and there's nothing wrong with your existing solution (using SQLite directly) at its most basic. The better question(s) to ask is (are) about the specific problems you're having with your current approach.
That said, if you want to adapt an existing iOS-based solution to use Core Data, you'll likely have an easier time of it than if you were targeting Mac OS. Create a basic Core-Data-Based iPhone app project and look at the code. The code to build the Core Data stack is in plain sight. The only other thing to remember is to add an xcdatamodel file like the one found in the empty project. If you've gotten far enough to interface with the SQLite library, you should have enough experience to see clearly how Core Data is used in a standard iOS app.
The steps you need to go to convert to Core Data:
- Develop data model (maybe graphically in xcode)
- Adopt your code to use core data instead, i.e. rewrite that module
- Read your old data and put it into core data
If you have it already running with sqllite, I'd stick with it. If it uses much too many memory, it's probably a bug on your part, or bad partitioning of the data you load into memory, and you want to address this one way or the other - although Core Data makes it maybe a bit easier to get it right.
This is a more a philosophical question about Apple's design decisions than a question about Core Data.
Why in the world is it useful to have a model system that is so difficult to prepopulate? What are the advantages? I know you can have your program generate the sqlite file and edit it manually, but as far as I can tell, you can't do that if you have any relationships at all.
I compare this to the MVC paradigm used in rails, which seems to make way more sense. Models in rails provide a similar level of abstraction to Core Data (from what I can tell) but they also allow you to enter whatever you want into your database manually (or through a script).
The problem I have with Core Data is that: since rails seems to prove (to me) that you can have an excellent model abstraction from the database while retaining several convenient methods to prepopulate it, what possible advantages does removing that ability offer? Is Core Data somehow more efficient? Is the difficulty involved in prepopulation merely a side-effect of other design choices, and if so, why wasn't prepopulation taken into consideration?
(A disclaimer that I'm genuinely interested in the reasoning behind these choices, and though my post might suggest it, I'm not really looking for a "Models in Rails vs. Core Data" debate.)
Because Core Data is NOT a database. It is an object graph that happens to persist to disk and one of those persistence formats is a database. This means you need to look at it in a reverse PoV.
Core Data is designed to be as fast as possible in retrieving objects from that persistent store and saving them back out. One side effect of this is that the persistent format is focused on making that goal faster and being compatible with anything else is secondary at best. Thus the internal structure of the SQLite file is aimed at performance, not at compatibility.
My opinion about pre-population is that Core Data is designed as a closed loop system. You can use Core Data to populate the data file easily. It is no harder to populate a Core Data SQLite file than it is to write a script to translate your Oracle data to CSV format.
If you stay within Cocoa and Core Data then it is not difficult at all. You write a command line app or editing app and import the data. From the PoV of a Cocoa programmer, that is a trivial task that takes just a few minutes.
In the development of my first serious iPhone application (Meaning I'd like to actually get it out on the AppStore), I needed a good way to represent my data. Instead of going with core data, I (stupidly, I think) decided to use classes to represent my data.
I created three classes, MMDot, MMShowMovement, and MMShow. The MMShowMovement holds instances of the MMDot class in an array, as the MMShow holds instances of MMShowMovement. Sounded like a nice way to do it, each class has a lot of logic that has to go with it, so I thought that classes seemed like a good way to go about representing all this data.
My question is, is there an easy way to save the instances of these classes so I can restore the data after the application is reopened? I have made applications on OS X using a NSKeyedArchiver, would it be similar on the iPhone? Would it be easier to start again using Core Data instead (These objects are very complex, especially MMDot with about 15 instance variables, now that I look at it, maybe not THAT complex)?
I'm really at a loss here.
You can absolutely use NSKeyedArchiver to persist your objects. I'm a fan of either method, the decision mostly lies with your application needs. I don't think it will be much work to re-model your objects in CoreData. Without knowing anything about your application I'd say if you are doing simple persistence with a simple model you may not need Core Data, if you have complex relationships and will be reading/persisting data frequently during an application session Core Data is probably the way to go.
If you have a lot of object instances, you are probably better off using Core Data - it will help cache things, help you with queries to get specific sets of objects, and so on. KeyArchiving is really a lot more useful if you are saving off a handful of instances, but have some downsides - in particular it's harder to track down memory leaks from Unarchived objects.
Core Data can also do paging of results for you too, so that you aren't fetching in the entre contents of a large array if you do not need it.
I was looking into serializing my classes the other day and went with using NSUserDefaults. I just give all the internals of my objects a unique key based on the object. Seemed to work fast for me.
Wrote a blog about it here: http://technolojiadev.blogspot.com/2009/12/serialize-this.html