I have understood the basic concepts of core data and how to create schemas or data model in xcode. However I am struggling to create database and import it xcode.
I don't have any experience with creating databases before.
Can somebody guide me here.
Thanks in advance!
If your application is document based, the database is the document. You create it in code when you create the document.
If it's not document based and will use just one single database, then you generally create it in code the first time the application is run (or, more likely, whenever the application is started and it cannot find an already existing database).
In either case if the database can start empty, that's all you need. If an empty database would be invalid and you do need some minimal data when you initialize it, you will have to populate it upon creation.
Depending on how much data your minimal database needs to have you can either hardcode the initialization or use a static resource (that is, a file) in your application bundle containing the initialization data in some form that you know how to read and use that to populate the database.
Using SqlLite is more attractive to me as I import the database without any modifications to the android version.
And I made some generic class to handle any database for android and iPhone but I cannot share it here.
Class DBWRAPPER
{
initDB();
ExecuteScalar()
ExecuteDicionary();
Close();
}
To follow-up on the AnalogFile answer, in case your application is not document base, you probably want to use core data with a preexisting SQLite DB. You could feed your DB with a scripting language like Python. e.g. I think it is a better approach than populating your DB programmatically in XCode. Check this tutorial for more info about this approach.
Related
I am developing iPhone app for a web application currently running online. Current web application is big and complex and uses SQL to store vital information like member details, login credentials etx. Other stuffs like info about several sections, groups, sub groups and other information related to each are saved in txt. Current system uses its own standard to keep data in files and also made custom algorithm to read and write data in it. Each txt file is below 1 mb size. There are lot of data manipulations going on.
Custom algorithm created just read those files and put all data in cache as records (same as in core data managedobjectcontext) and whenever there is a change in data the whole file is overwritten.
So while implementing the same what I want to choose for iPhone app? In apple website they said that 'SQLite is perfect for low-level relational database work' https://developer.apple.com/technologies/ios/data-management.html But in my case it is high level.
So please help me to make a decision. Do I want to manage data in files or sqlite database using core data?
I would also like to know whether it is possible to import those classes and algorithms currently in webserver to iOS, so I don't want to rewrite the same algorithm for iOS? Current server codes are in C#
In the rare case that you need to do low-level relational database work use SQLite. In the 99% other cases use Core Data. Don't ever store relational stuff into txt files. It'll just be a pain.
Your use case sounds like a good match for Core Data.
Often misunderstood, Core Data is an object store that happens to use sqlite for persistence. You don't manipulate the sqlite underneath it, Core Data manage the sqlite for you. You do not write SQL. The closest match to it in .NET is EDM and the Entity Framework in ADO.NET.
Assuming the classes and algorithm you want to import in the webserver is in C#, sadly those needed to be ported to Obj-C.
I have used extensively core data in my applications. Generally I need to submit the applications using a pre-populated database.
I generally create zillions of lines of code to populate the database, then I extract it from the applications directory and include it on the bundle. Is there a easy way to do that? Is there any way to populate a core data database created on Xcode using, for example, a CSV file and an external app?
thanks.
The usual way is to create the entries at the first launch.
If you want to import data from a CSV file, then you need a parser.
I can recommend this one: https://github.com/davedelong/CHCSVParser
You don't have any easy way to do that with Xcode.
Basically what I do in this kind of case: I build a second target dedicate to pool the database and create object with a fixed persistent store url relative to the workspace in the filesystem.
I'm diving in to iPhone development and I'm building an iPhone app that uses the Core Data framework and my first task will be to get the model setup with a view that will display it. Thus far, I have the model defined and my Managed Object Files created, but I don't have a database with any sample data.
What's a quick way to create a DB that conforms to my schema?
Are there any tools that can generate a sample DB using my schemas? Or do I have to create this sample data by hand?
Once the DB is created, are there any good tools I can use to directly manipulate the data in DB for testing purposes?
Thanks in advance for your help! I'm going to continue researching this question right now.
This is very close to the question "Provide Base Data for Core Data Application?" Additionally, my answer to this question describes how you can quickly build a Mac application that lets you create or edit a Core Data database that is compatible with your iPhone application's data model.
Beyond that, you can use the application Core Data Editor to do what its name describes.
I assume you've already created a working app that uses sqlite as persistent storage for your data model.
Have a look into the AppDelegate.m file to search for the sqlite database name and location, then run your app in the iPhone Simulator.
Use Spotlight to search for the SQLite database created by the app in the simulator, usually this is /Users/<Username>/Library/Application Support/iPhone Simulator/User/Application/<Application GUID>/Documents/<database name.sqlite>
Now you only have to copy that file to a working folder, open it using sqlite3 (www.sqlite.org), then type .schema to retrieve the database schema.
Now populate it, either by hand or using a python/ruby/whatever script!
Unfortunately, i'm not aware of any tool that will populate a db by simply feeding them the schema.
For directly manipulating the data, sqlite3 provides you with a command line utility that's really handy for that purpose.
When you're finished, add the file with sample data to your App project.
I would like to begin work on an iPhone app that does little more than display a books content for reading. The book content is available online, and is fully open source, but I would like to make the content available locally. With apps that I have worked on previously, namely with iPhone OS 2.X, creating (or finding) an .sql database and then just making queries for data from within the app worked really well. With the advent of Core Data (which I am not that familiar with) the older sql method may not be ideal. So my question is: What is the best way for me to go from online web content to locally stored iPhone readable content? Regardless of which approach I take, I am going to need a db (right?), so should I get the brunt of it out of the way and start with importing the web content into a db with all of the correct tables and columns? I guess with this question, I am just looking for a point in the right direction. If there were any suggestions about the best method for me to get rolling on this, it would be greatly appreciated. Thanks!
Core Data is good if you have "objects" that you want to make persistent. In the case of having just a lot of data to read/write, plain old SQLite may be simpler.
Sorry that I can't give any more specific advice, but it comes down to how complicated your app's data model and object models are. I'd recommend looking at Core Data, but don't use it just because everybody tells you how cool it is.
If you go with Core Data, you won't define your own SQL database schema, so don't start down that path until you've made the decision.
I actually would go with the Core Data route. Core Data is just an API provided by Apple to manage persistent data no matter the data backend (wether it is a flat plist file, an XML file, or a full sqlite database file).
In the case of a book, you can break down the entities as follows.
Book Entity
Title which is a String Attribute
Author which is a String Attribute
chapters which is a has many relationship of Chapter Entities
Chapter Entity
Title which is a String Attribute
pages which is a has many relationship of Page Entities
Page Entity
PageText which is a String Attribute
Then you can access all the values as if they are objects using Core Data without having to worry about the SQL backend code, and writing all the code to translate the SQLite datatypes to Cocoa objects that your view controllers can display.
I'm doing an iPhone application. In this app, I just want to have a database to be used as a looked up table for values in my app. The only thing the database will do was to supply me the values I needed depending on the query of the program. It won't do any addition or deletion in the database. My question was how do I initialize a default data on the application using CoreData. So that when the program starts It already had all the values needed.
If you have other suggestions of what is better do or what are other alternatives, please tell me.
Thanks.
I would create a simple Mac application, starting from the template for a Core Data document-based application. Copy your existing .xcdatamodel over the default one in the project (or add the new data model and be sure to rename anywhere that refers to the default model). Open up the XIB file for the document window in Interface Builder and drag the Core Data Entity item into it from the Interface Builder library inspector. From the resulting dialog, choose an entity to display and select an interface to display it in.
What this will do is create a fully functional interface for adding, removing, or editing the properties of that entity type. Everything should be hooked up via Cocoa Bindings so that you don't need to write a line of code for this to work. You can add interfaces for each entity type in your model this way.
This will let you quickly enter and edit data within a Core Data document, which you can then save out to disk and add as a resource to your iPhone application. The SQLite database structures are fully compatible between the desktop and iPhone Core Data implementations, so I've found that this is a quick and easy way of testing your iPhone Core Data code.
Please refer to the Core Data Programming Guide, or see below (copy from the PG):
"
How do I initialize a store with default data?
There are two issues here: creating the data, and ensuring the data is imported only once.
There are several ways to create the data.
You can create a separate persistent store that contains the default
data and include the store as an application resource. When you want
to use it, you must either copy the whole store to a suitable
location, or copy the objects from the defaults store to an existing
store. For small datasets, you can create the managed objects
directly in code.
You can create a property list—or some other file-based
representation—of the data, and store it as an application resource.
When you want to use it, you must open the file and parse the
representation to create managed objects.
You should not use this technique on iOS, and only if absolutely necessary on Mac OS X. Parsing a file to create a store incurs unnecessary overhead. It is much better to create a Core Data store yourself offline and use it directly in your application.
There are also several ways to ensure that the defaults are imported only once:
If you are using iOS or creating a non-document-based application for
Mac OS X, you can add a check on application launch to determine
whether a file exists at the location you specify for the
application’s store. If it doesn't, you need to import the data. For
an iOS-based example, see CoreDataBooks .
If you are creating a document-based application using NSPersistentDocument, you initialize
the defaults in initWithType:error:.
If there is a possibility that the store (hence file) might be
created but the data not imported, then you can add a metadata flag
to the store. You can check the metadata (using
metadataForPersistentStoreWithURL:error:) more efficiently than
executing a fetch (and it does not require you to hard code any
default data values).
"
As mentioned above, generally we need to create a pre-populated default store with code, then use it as a
resource file, and copy it from resource bundle to document directory if the coredata file is missing. Please search the CoreDataBooks code example in your Xcode Organizer (or Apple Developer Center), and look at the - (NSPersistentStoreCoordinator *)persistentStoreCoordinator method.
I racked my brain for hours attempting to solve this. What I came up with was simply not to save the database. That way, it will be initialized each time the app is opened. If you save it, it will continue to duplicate.
I would write a tool that populates a database with the data you want in it, generate the db at build time and stuff it in your resources folder. If you are not going to write to it you can just leave it there and access it directly, if you ever did want to write to it you would need to copy it somewhere you are allowed to write (like the documents folder).