I know already:
Core Data, SQLite3, Property List Serialization, NSCoding with NSCoder (encode / decode)... what else?
Another framework is BNRPersistence, which uses Tokyo Cabinet (I haven't tried it, so I don't know how good it is). Other than that, you can do pretty much anything you want--JSON or custom XML come to mind, but you can also use pretty much any C-based library.
You listed the standard ones. Of course you've got access to a file system, so you can pretty much do anything. What are you looking for?
Related
I've been looking around for a way to store an NSArray containing lots of NSDictionaries. So far I've come across a few different ways of doing it, the most popular of these seems to be the NSUserDefaults approach. That said, it just doesn't seem right to me. In my mind the NSUserDefaults should only really be used for storing the settings a user has selected.
Please can someone help me out with the best way to approach this problem? I'm certain that there must be some standard approach, however I can't seem to pin it down!
Apple does has a framework that provides generalized and automated solutions to common tasks associated with object life-cycle and object graph management, including persistence. ;-)
Seriously though, Core Data should be your first port of call, since it is optimised for the platform, and will scale too. Once you get your head around how it works, it's really fairly straightforward. Also, it's likely to perform better than any roll-your-own solution you come up with.
Please read Archives and Serializations Programming Guide. The top two choices will be to save the array as a property list, or to create an archive using NSKeyedArchiver.
Before I begin looking into this myself, I wanted to check if anyone had leads on projects that already integrate CoreData into the three20 MVC model.
I didn't find anything when I looked online so just throwing this out there too.
You should avoid the three20 code base. It is not the best example of Objective-C out there and is generally more headache than it is worth.
Likewise, because if its unusual internal structure it is not going to work with Core Data without a lot of re-writing. I have done it and I can honestly say that it was not worth the effort and will not be doing it again.
I haven't really heard of any tight integration, but it shouldn't be that hard to do. All you need to do is have a TTModel subclass provide the data from your CoreData context. Then just wire up the communication for reloading, etc. if needed.
Three20 has a template for you to work with Core Data, have a look at it first. Personally in my application, I have used a complex Core Data object model with nearly ten objects and relationships. So, be confident that it already worked for other people.
Are there any other database engines that could be used on the iPhone, besides sqlite3? Something like textDb is for PHP, single-file and no server.
There are a slew of alternatives to SQLite, but there is little point to using them as others have pointed out.
Before pointing out some alternatives, some points:
First, SQLite is an excellent single-file, non-client-server, small-footprint SQL database. The performance is excellent, it is a relatively tiny runtime, and it is thoroughly fast. There isn't an embeddable SQL-interpreting alternative that is either all around technically superior or anywhere near as popular.
Secondly, if you are doing persistency in an iPhone application, you should very likely be using CoreData. There are certainly reasons not to, but they are pretty uncommon. Beyond being a higher level mapping to a relational store that is quite adeptly integrated with Cocoa Touch, Core Data solves a number of very difficult problems above and beyond persistency; object graph management, efficient memory use (i.e. push stuff out of memory when no longer needed), and undo support, to name a few.
Finally, if you do decide to use some other database persistency layer, keep in mind that the iPhone 3G and prior is an extremely memory constrained runtime environment. The very presence of any kind of additional library can significantly reduce the working memory available to your app. Whatever solution you choose, make sure it is optimized to use as little memory as possible.
So, seriously, if you are looking to not use SQLite or CoreData it is either because you have a very rare case where they aren't appropriate or because you are being curious. If curious, well... good for you!
If you are looking for alternatives, the SQLite documentation includes a set of links to similar products.
Pretty sparse list and it isn't because the author is hiding anything. There simply isn't a lot of motivation in the industry to try and re-invent this particular wheel because SQLite does a really good job. There is a reason why Google, Adobe, GE, FireFox, Microsoft, Sun, REALBasic, Skype, Symbian, Apple, and others have pretty much standardized on SQLite to solve their non-client/server relational persistency needs; it just works.
If you're looking for an alternative, I would say Core Data.
I had the same question for a long time and even used SQLite in some projects. After speaking with an Apple Engineer though, he pointed out that Core Data could do everything that I was using SQLite for (mainly just storing information and accessing it in a few different ways).
I would start with the with Core Data Programming Guide and see how it works for what you're looking to do.
I think your problem is that you are thinking of a software library more like a software product. People want choice between Internet browsers for all sorts of reasons. But when you have a software library, it's pretty much set up for one purpose. If it doesn't fulfill that purpose well enough, it shouldn't be a library.
Do you not like NSObject? Do you not like the Core Foundation library? Then write your own. However, to drag up an unfortunately overused analogy, don't reinvent the wheel, unless your job is making new and innovative wheels.
SQLite does perform acceptably, and so it is supplied as a library on the iPhone platform. SQLite works for what I need it to do. If it doesn't work for you, then maybe you have some reason you'd like to share?
Freedom of choice is fine if you want to choose between Internet browsers, but I would think that as a programmer, one should have a very specific reason for going out of their way, spending valuable time to fix something that already works. Even with my choice of Internet browser, I have specific reasons I choose one over another.
No. Everyone seems to be happy with SQLite.
I've seen several approaches, and each seem to have significant plusses and minuses. I'm learning iPhone development, I'm building a relatively simple app, which, at it's core, is really not much more than CRUD operations on 3 or four related entities.
I'm used to ActiveRecord-type object persistence. The implementations for Cocoa Touch that I read about online are commonly referred to as extremely slow.
Most of the examples I see online (specifically the Pragmatic Programmers screencasts) have SQL hardcoded into the controller class, which doesn't seem... right to me. Seems very old school (but maybe old school is best in this case).
I know we can't discuss SDK 3.0 here, but it's common knowledge that CoreData is coming for the iPhone, that would of course limit my audience (I'm not sure I really care about that this much. It will be an app for sale, but I'm not planning on it replacing my career)
I have not tried Gus Mueller's FMDB yet, but I have read good things.
What are some of your experiences, what works, and what doesn't. Where would you recommend that a (still pretty novice) iPhone programmer invest their time?
Right now there's a lot of semi-raw SQL encoded in apps because there's no built-in system for higher level work. FMDB is a nice way to do this but it just wraps the SQLite calls into something more Objective-C like. It's great for some situations but obviously not for everything.
If you're familiar with ActiveRecord then SQLite Persistent Objects may be useful to you, because it's intended to be similar to ActiveRecord. I haven't used either so I couldn't tell you how similar it actually is. If that doesn't seem right for some reason, it's probably best at this point to target 3.0 and make use of Core Data.
Coming from a non-SQL background, I've been having a hard time absorbing SQLite3 for the past few days. Has anyone had any good results using any of the SQLite3 wrapper APIs out there? Do they work reliably? Which is best? I am also hearing buzz about Core Data coming to the iPhone. Not sure whether that info is trustworthy or not but maybe some of you know: will there be a Core Data for the iPhone at some point?
FMDB is easy to use and abstracts some of the SQLite nastiness away from you, but still exposes the SQL.
I have used it in a project, but subclassed it to add my own partially-OO layer. The advantage of this approach is that if I need more speed or something I did not foresee (triggers for example), I can make it happen. With Core Data, there is no "bypassing" available and I have to rely on Core Data's optimizations, memory use, etc.
Another difference is the Core Data will allow your app to remain fully OO. With FMDB or other database solution, you're always tied closely to the organization of the database. It's a design decision, and not one you can change later.
If you're only just starting now, I would use Core Data.
I spent some time last year looking at the various wrappers at the time. I didn't use any of them in the end.
I think the NDA was still in place when I was looking so I may have missed the best ones, but I found that most were very thin wrappers. For my purposes this meant that it added an external dependency, didn't save much typing and I would probably still have had to dive down to using sqlite function calls sometimes anyway. Just didn't seem worth it.
Why not target CoreData using the 3.0 SDK?
If for some reason you need to support 2.x, you should look at SQLitePersistentObject. It's slow and has some bugs but it is VERY easy to use. Sadly it is no longer under active development by the author.
Additionally:
Some time ago, with a small sample project (2.x) I used fmdb. As far as I remember it was pretty easy to use. However, it required SQL knowledge.