I'm a new iPhone dev and I integrated a team of iOS developper, in the domain of education. First, I thank you for your help.
Here is my question : The lead developper told that for the project (iOS 5), they will not use Core Data to deal with the database of the app, but they will use their own SQLite libraries.
I have been told by the lead dev that Core Data will not fit in that project, because of the data they are dealing with... No more details
Since Core Data uses SQLite, (and so will the library they created), do you have any ideas why Core Data could be a problem (in general)
I really thank you if you have any clue.
EDIT :
I've just learnt that the lead is creating an sqlite database and we are going to use it in the app. And the fields contains a lot of html (a lot of special characters like \ or & or <), and we are going to display it in some UIWebViews. Is he right when he says that those special characters can turn wrong with core data ?
The only reason I can think of is cross-platform portability. If you use a manually-generated schema, and perhaps even provide common library code, then that database schema/library can be used on non-Apple platforms.
It's hard to guess at other people's reasons but.... The purpose of Core Data is object persistence. The fact that it can use a database as a storage mechanism is an implementation detail. For problems that are specifically object-oriented in nature, it works very well.
If you are dealing with a problem that is more suited to solutions that are about rows, columns, and tables, it isn't necessarily a good fit.
I like using objects and have a lot of experience with Object/Relational mapping in other systems, so I tend to be pro-Core Data. People with a database-only background probably have a different view.
Related
This question is different from questions here, because of the app being mostly in the background.
It is a requirement for our application that we keep the data store encrypted.
Our current implementation is using SQLite using SQLCipher. The plan is to move to Core Data.
I'm looking for a solution to keep the data encrypted, while still accessible in the background and is not restricting in terms of queries-NSPredicates and migration (schema change).
Below are all the options I've been looking into:
NSFileProtectionComplete - will not allow file access in the background
encrypted-core-data - This library does appear to be kept up-to-date. However, I've had second thoughts about using it in production after seeing the list of known issues. Has anyone used this recently?
NSIncrementalStore - This was the way that Apple engineers recommended that we follow. encrypted-core-data is using this method.
Transformable Attributes in core data - is this solution scalable for larger data sets?
Does anyone have a recommendation that meets all of the criteria and can be used in production apps?
I ran some proof-of-concept apps using each of the above options. I ran numbers and bench-maked it against our existing solution (SQLCipher).
Looks like using core data with incremental store (encrypted-core-data) came out to be the best.
After analyzing runtime performance times for read, write and search on DB with small and large sizes, encrypted-core-data turned out to be the most efficient and simpler to implement.
I'm making a statistical analysis app which needs to store large amounts of data locally. To give you an idea of what I'm talking about, I've made this illustration (not exactly the right information, but very similar):
The app will keep track of several thousand destinations, with the destinations population, temperature, number of cars etc. These numbers will be represented in a graph so that you can look at the numbers "development" over time. This will go over a long period of time, in other words: thousand of dates for each data-type for each thousands of cities.
To achieve this I need to save large amounts of data, and it is preferred to be done locally (is that crazy?). I'm stuck between digging deep into the foundation of Core data, or using my already decent skills in SQLite.
If you suggest I should use SQLite, could you refer to how you would implement this into your app (some code perhaps?).
If you suggest I should use core data (mainly for performance), please show me how you would implement this type of data model with entities, attributes, relationships etc. I can imagine using dictionaries saved in the core data would be a good solution?
Thank you in advance.
If you're going with SQLite with Swift - I highly recommend using this project. I am using it in my current project and it is absolutely fantastic and works perfectly (I'm not affliated in any way with the project or author). You actually drag that project into your project and it becomes a subproject, then you just set it up as 1. target dependency, 2. framework to link with, 3. copy framework (build phases), and it just works. Then you can handle your database with brilliantly constructed Swift interfaces rather than ugly cumbersome libsqlite calls.
I have used it for modest amounts of data. A few databases and multiple tables. Clean and intuitive. So far I haven't found a single bug of any kind. And Stephen Celis, the author, was responsive when I asked a question about a feature that wasn't documented (but actually is present and works, it turns out). It's a prodigious effort.
Its so clean and tightly integrated with Swift that, if I didn't know better, I'd think Apple itself added SQLite support to the Swift language.
https://github.com/stephencelis/SQLite.swift
Core Data is an object persistence model-- and there's your answer really, because every object has a little overhead, so having thousands of objects in memory at one time is problematic. If you already know SQL then that's another plus.
(Discussion of overall merits of core data is outside the scope of this question. The "music" app pulls it off using core data with thousands of items, I think, but because it only needs to display a subset of items. Map Kit drops down to C, and quite handles itself impressively with tens of thousands of single-digit byte items, which you can see running instruments with a Map Kit app.)
I've used SQLite in iOS and it's not a problem, being C-based and Objective C being a strict superset of C. There are various "wrappers" but look at these carefully, in case they take you back to every-row-an-object. I didn't use one and found the SQLite C setup to be tricky but fine. EDIT: I used this tutorial, which is dated now for the Objective C but a clear overview of how to integrate SQLite.
The only catch is the bundle/documents distinction in iOS will catch you if you ship with large amounts of data and want to save to that database: you can't modify files in the bundle, so you need to create or copy an SQL database to the documents folder 1 time, maybe on first app launch, to use it. Since you can't delete from the bundle, now you have your database twice. A problem inherent to the way iOS is set up.
I'm planning a way to persist data for an iOS (swift) app. From reading a bunch of articles about persistance on iOS, it seems Core Data is a really well supported way to do that. A bunch of libraries/tools are built around it, one popular combination seems to be MoGenerator + MagicalRecord + Core Data.
As MagicalRecord provides some kind of Active Record functionality, it seems it could be "easy" to accidentally break things. I've been told it could happen that users would have to reinstall their app to recover from such failures.
So question: is it feasible to use just plain Core Data instead of MoGenerator + MagicalRecord + Core Data? Or is this so low level, that it only makes to use raw Core Data for big teams? Can the pros/cons be compared to those of plain SQL vs ORM?
I would strongly recommend to NOT use MR or Mogenerator until you know enough about Core Data to know WHY to use them.
Magical Record really can seem like magic if you don't understand what it is doing under the hood. And to use Core Data without a good understanding of the basic framework is to invite problems that you will never get to the bottom of. There are Core Data traps that you are going to need to understand, whatever tool you use.
CD is not really low-level compared with MR: but is more verbose (MR is saving you a lot of boilerplate). However I would recommend spending a bit of time with a decent book like Learning Core Data for iOS by Tim Roadley. When you have worked through that, you may find - as codeFi suggests - that you have built yourself a core data engine that does enough for you so that the addition of Magical Record unnecessary.
Another problem with going for MR is that the stable release, 2.2, is two years old. V2.3 is still in beta, and going forwards the focus is on 3.0. If you use the stable release, and find issues with it, they won't get fixed. If/when v3.0 is ready, the interface may be completely different anyway.
What the best way and how to work with multiples tables in iOS project and does FMDB supports relationships between tables?
Should I use Coredata or the FMDB wrapper?
Whatever you want to do, you can use either Core Data or FMDB + SQLite.
Basically, if one of the follow is true, I suggest using SQLite.
Performance is really important
You already have a huge SQLite database from elsewhere
You plan on making the database cross-platform somehow
Have a look at this blog post to read about the difference between SQLite and Core Data.
However, in most cases Core Data is a better way to go. Core Data is a great framework that helps you keep your consistency (using object graphs) and is really quite easy to use. It has received a bad rep for its performance, but it is actually not that bad. For instance, over-fetching is a common thing that is used to improve performance. This means fetching lots of data and then filtering out the data you actually want. This works great in iOS devices since their RAM is actually really good these days. Use it!
Also, if you plan on using Core Data, you should understand that it is NOT a wrapper for SQLite. You should not be thinking about tables like you normally would. In Core Data you have an object graph with entities instead of tables.
Conclusion:
Use Core Data unless you already have a SQLite database form elsewhere OR performance matters a lot (and I mean a lot).
There is no one good question for this. It's depends on project.
In my opinion if you have already some data which you want to import to the application, and you will facing huge amount of data in your database, you should go for pure sqlite (and maybe FMDB).
If you are connecting to REST, want to use TableViews, starting from empty database CoreData will right answer for you.
FMDB is only a wrapper on sqlite so it will have relations, because sqlite has.
I have a new iPad application that is data driven (read, delete, create, update) and requires data persistence on iPad devices that are installed the application. There are about 10 tables for that application; those 10 tables are relational in some ways (one to many; many to many; and stand alone). I am new to data driven application with iPad.
I do not know whether I should follow the Core Data approach or SQLite approach. Which approach is the better and real-world oriented? Please advise. Thank you very much.
My advice is try both; sketch out two simple versions of your app, one with each implementation. Of course Core Data uses SQLite as storage behind the scenes, but it is much more than that. In my view it's a very complex, clunky beast to wrangle, but it is about modeling and persisting objects that have attributes, it can help a lot with consistency when you delete an object that's involved in a relationship, and the NSFetchedResultsController is helpful for populating a UITableView in a memory-efficient way. With SQLite it's just a database and that's all it is; you have to do all the work, but there are nice Objective-C front ends, and you are completely in control rather than having to do everything in Core Data's very strange way.
There's a short section of my book that demonstrates a tiny Core Data app, and even though it's tiny you can see I spend a lot of time banging my head against the wall of Core Data's special way of doing things:
http://www.apeth.com/iOSBook/ch36.html#_core_data
The previous section has a few lines showing how simple it is to fetch data from a SQLite database with a nice Objective-C front end:
http://www.apeth.com/iOSBook/ch36.html#_sqlite
I recommend that you read a book about Core Data before you commit yourself to it. There are several good ones. I'm not saying it's bad, but it is not at all a beginner technology and you really need to know what you're in for.
You are on the right track with Core Data in my opinion, what you need to ask yourself is how your data is being used against the benefits of each approach. Core data lets you update and write data using data types like NSDictionaries which do not require any outside of the box techniques to handle and write data like SQLite does. SQLite does work and can work how you want it to, but in my opinion using a third party wrapper is just one more step to take to achieve something that is already native.