I am just wondering if there are any advantages and disadvantages such as performance when choosing between NSXMLStoreType and NSSqliteStoreType for Core Data persistent type?
I searched around, and only found NSXMLStoreType is not supported in iOS.
Not supported in OS X? That's news to me (and to the apps in which I used the type for development).
NSXMLStoreType is GREAT for development purposes because you can actually look into the persistent store with a text editor (XML == human-readable) while SQLite or Binary store types are not. SQLite, however, is fastest because it supports atomic updates (update individual records without writing the entire store back out for one little change). XMLStoreType, by contrast trades this speed for readability.
I use XML type for debugging but SQLite in deployed apps. Well, those in which I still use Core Data, that is. CD isn't a good fit for everything. In fact, it's a so-so or poor fit for many when a custom-designed system works just fine (especially where filtering or property setting speed is important).
Related
I am trying to write an application that will access, and change, entries in a user's calendars. The changes are driven by fairly complex rules, that the user can define.
My question, before I spend too much time developing, is whether I should go with core data. A lot of the model will be handled by core data, but I will need to access a lot of stored info and then change it. Would this be a problem with core data?
It would help if I had a better understanding of core data, but at this point I do not :( Could someone comment on the possibility to perform changes on the model data, when using core data? I'd hate to be a few months into the development, and discover I made the wrong choice!
The recently released WWDC media collection contains an audio presentation from 2005 when the Core Data framework was released as part of the OS X frameworks. The presentation covers Core Data's primary goals, design principles and architecture. It also discusses a set of sample applications (the recipy apps). The collection is available through iTunesU. It is worthwhile to listen to to grasp the framework's working principles.
I've been working with Core Data for a while now. I find it easy to work with, well integrated into Xcode, stable and so far has been a true contributor to my productivity. It offers various storage options for your data (binary, XML - very easy to work with during development - and SQLite), very decent tool support, easy model migration for small changes, complex migration available for major model changes with some extra effort.
You will have to be aware of the fact that Core Data is NOT a RDBMS nor a RDBMS mapping tool. It is an object graph and persistence framework, which is a different thing. If you ignore this fact, Core Data might give you performance penalties.
Making schema changes isn't harder with CoreData than with most other data frameworks. CoreData can handle many simple changes to your data model on its own. When it can't figure out the right thing to do, you can write custom migrations.
In my experience, CoreData usually makes data-intensive apps easier to write and maintain, with a very slight loss in flexibility that you usually won't miss.
We have a shoebox-style application that we want to make a first-class citizen in Lion. This means integrating Auto-Save & Versions among other things. Currently we don’t have a document-centric model and we just use a plain Core Data stack.
UIPersistentDocument provides a really easy way to integrate both Auto-Save & Versions and I see two options we could choose from to integrate with the new APIs:
“Abuse” NSPersistentDocument for our shoebox-style application. Technically it would be a document-based application, but the user interface would still be the same iPhoto-like library. This makes conceptually not a lot of sense, but we would get a lot of functionality for free.
Keep the current plain Core Data stack and implement Auto-Save & Versions manually.
I heard contradicting opinions from Apple representatives about the approach we should take and it would be great to clarify things before we start our implementation. While I think that 1. shouldn’t be used it’s also very tempting, because we get a lot for free. I couldn’t even find sufficient documentation on manually implementing Auto-Save & Versions in a Core Data application.
I would really tend to use 1. but I see some problems:
I’m worried about file-system-level conflicts when using versions and only one database-file. I couldn’t find any documentation regarding this topic.
I’m worried about performance issues in Versions when browsing through “space”.
We can’t enforce only one instance of the open database, since Versions has to open several instances. I’m worried about side-effects and concurrency issues.
Conceptually it looks like a hack and I don’t like hacks.
If we would only want to integrate iCloud sync I definitely wouldn’t think about using a document-centric model for our application, because Core Data supports it directly. I’m mostly worried about the developer overhead we would have if we would stick to our current non-document based paradigm.
Do you have any advice or ideas how shoebox applications should be integrated in the new Lion world?
I'm afraid you're forced into using the first option. Versions is implemented inside NSDocumentController *sic* and so you will have to use some kind of NSDocument to get anything out of versions. I think you also have to add your App's Window in a NSWindowController to that document in order to get the nice little popup menu at the top. The problem is that versions is more or less a completely opaque feature...
But there's a question you gotta answer yourself: What portions of your app would you want to put into version? Does it really make sense to have everything in a single file when it comes to restoring data? Version restore (other than copy&paste) happens on the file-system level. And thus, does it really make sense to always have everything restored at once? If your answer is no, you probably even have to slit up you model into multiple smaller files...
Don't expect improvement here until the next major release. That's what I guessed from the engineers comments...
I'm fairly new to Cocoa. I was talking to my brother, who's put together a few iPhone apps, and I said something about Interface Builder. He said that he doesn't use it - he builds his UIs programmatically. He said that this way, he doesn't have to worry about loading the NIB. I understand that using Interface Builder actually creates instances of view/window/button/etc objects that are serialized and have to be deserialized when you load the application, but is the deserialization that expensive? Granted, he's talking about iPhone and I'm developing on a MacBook Pro, but still.
I have yet to see an argument against using IB due to performance reasons, and having used both methods I havent seen any difference either way. For the more ui intense applications I usually end up not using IB only because it is difficult to build complex customized views with it. So really I tend to use IB for the more simple apps and go with the progammatic approach for the more complex apps. This approach obviously is performance optimizing as well.
Absolutely learn IB! It's worth it and will save you countless time over the long haul. Then use it when you can. When you cannot (high complexity) you always have the programatic approach but you'll find it FAR easier to maintain your nibs (IB) as your app grows and ages.
If both methods can be useful, I'd recommend going the Apple's way; i.e. using Interface Builder (IB). You'll get less code to write (and less code equals less bugs, less maintenance, less work ;) !), a better abstracted project, you'll be much more ready to inherit future goodies coming from Apple (remember Cocoa Bindings…), and soon you'll also be more productive.
Understanding what IB's doing for you (by going through your brother's method) is a very valuable knowledge too; so if you can do both on some li'l projects, do that. (As others said, for complex UIs, this will allow you to bypass it at times.) But still, in the end, I'd recommend using IB.
Although Interface Builder is an old piece of software, with its roots in NeXTSTEP development, it is still (IMO) an elegant way of creating the visual aspects of software.
In this interview with Aaron Hillegass, he says that "Experienced Cocoa programmers put a lot of the smarts of their application in the NIB file. As a result, their project has a lot less code."
And as we all know: "Less source code is better"
It depends a lot on the kind of application. ERP systems with a few hundred/thousand pages are not build with Interface Builder, as far as I'm aware.
Which method do you suggest to efficiently secure your embedded database in Delphi applications?
Here are the methods I've tested:
Using Molebox Pro
Pros - Fast, unpacking is not child's play, no additional task/coding
Cons - Database will be read-only, same drawbacks as exe compressors
Using DISQLite3
Pros - Overcome Molebox's read-only issue
Cons - 50% or more performance fall on encrypting
So I'd like to know if you have used anything like this in your projects and if you satisfied with speed and encryption etc. Please share your techniques.
The fact that Molebox Pro leaves your DB read-only while DISQLite3 does not seems to be the deciding factor. Likewise if the performance penalty on encrypting is the only con for DISQLite3, then it is irrelevant since Molebox Pro is read-only (thus no encrypting during operation). It really comes down to your requirements.
If you are looking for other options then I would suggest checking out ElevateDB or DBISAM from ElevateSoft. They are both embedded databases with built in encryption. I've used DBISAM, but ElevateDB is their newer and preferred database. Also check out Advantage DB from Sybase, which is less embedded but also has encryption.
If you have other requirements that may impact your choice let me know!
There might be applications that are not suited for Core Data - image manipulation programs like Photoshop or Gimp for example. But for applications that are suited for Core Data, say Address Book or iCal, what is the criteria to choose Core Data over a custom model?
I recently started a project where I decided to use Core Data for the first time in a real world application. My application is actually version 2.0 of an older app that uses a custom data model, so I spent a lot of time debating this question. Here are some of the things I asked myself.
The time to learn how Core Data works in a non-trivial application and fixing the little bugs and idiosyncrasies that pop up when you're learning a new technology. This may include a prototype or two, since you don't want to jump into using something like Core Data that will be responsible for such as large chunk of your application.
Whether or not Core Data will solve problems that are hard to address when using a custom data model, for example storing and holding in memory very large sets of data.
Whether or not you want to share code with a platform where Core Data is not available, for instance Cocoa Touch. Along the same lines, if you want the resulting data files to be compatible without having to build a separate exporter.
If learning Core Data will help improve yourself as a programmer, whether its making your more attractive to Mac development shops or just for your own use.
If your data model is simple enough that you don't really need things like undo manager support or relationships, the areas where core data really shines.
If you're using external libraries or other technologies such as Distributed Objects, where you might not want to use NSManagedObject.
Are you, for whatever reason, targeting a Mac OS X version before 10.4 as your minimum requirement? If so, no Core Data for you.
Are you going to allow the user to manually order things in a list? If so, no Core Data for you—it doesn't allow ordered relationships. (Supposedly you can create a numeric “sequence” property that you can order by, but keeping that consistent sounds like a tremendous hassle.)
Are you going to be working with a specific file format as your native format? (For example, TextEdit's native format is RTF.) If not, you won't be using Core Data for on-disk storage, so you may not want to use it at all. (You could, but I'm not sure there are enough other reasons.)
Kick :)
For me the biggest question you need to ask yourself is: Are you going to store critical data in there (user created content) or data that can easily be reproduced (content downloaded from internet). If you have the first (user created data) i would steer away from Core Data ASAP or make sure you have a backup plan in your app.
Once bugs start popping up (and trust me, there are) for instance when trying to migrate your data to a new version of your object model you are stuck, completely stuck! And telling your customer "I am sorry I cannot build a new version of your app, I am waiting on Apple to come up with a fix" will not cut it in the real world. There is no official way of accessing or understandig the underlying structures, so once it goes boom, you are on your own.
Been there done that, not going there again!
my 2 cents