I'm trying to add Core Data to an app that loads news form of an RSS feed so I can store articles offline. I am using ASIHTTP to load the data off of the internet as XML.
I'd like to store the articles in Core Data so I have them the next time I start. My AppDelegate_shared already is set up for Core Data, based on the template, but I'm not sure where to add all the rest of the code.
I found a tutorial by Ray Wenderlich, but it only confuses me. His tutorial assumes that there is a single App Delegate file, not three, as created by the Universal App templates.
Where in my three AppDelegate files (the shared, iPhone and iPad specific) does my core data article entry code go?
Are there any tutorials that deal with Core Data with the newer app template setup (3 delegate files)?
How do I read out my Core Data into a UITableView?
The Core Data stack only needs to be created in one shared location at startup. You can still have three different application delegates, as long as all three call the same setup routine. This could be done by making all three application delegates you have be subclasses of one base application delegate which handles this setup.
Another way to approach this might be to create a singleton for managing your Core Data access. See this question for other potential configurations that people have used, as well as the reasons for them.
As far as how to populate a table view with data from a Core Data database, you'll want to use NSFetchedResultsController for that. It makes displaying and updating table views simple on iOS. Jeff LaMarche has some good template code for dealing with this, and the sample applications generated when creating a new navigation-based Core Data iPhone application show this in action.
Finally, I taught a class on Core Data last semester (and finished another one last night), for which the course notes are available here and the video can be downloaded from iTunes U.
the core-data stuff belongs to the shared appdelegate. because the other two appdelegates are just subclasses of the shared one.
why not create a new universal project with coredata and look how it's done? and to see how the data is feed into a tableview, you could create a navigation-based project with coredata and look how it's done in there.
Related
I am writing an application which needs data persistance. I am using CoreData as my framework for this. I am currently trying to design my data structures for the app, of which I am planning on having 2.
The main data in my app is a sheet of various information which is input in a wizard format. I wish to use a MutableArray to hold the form data.
Secondly, I wish to have an individual instance (singleton) of MyClass available at any time, which I will use as a temporary placeholder to accept data being input during the wizard. Once the user completes all the steps, it will create a new object in the array for it.
What I gather from CoreData is that I need to use the ManagedObjectContext as a bridge between my application and the disk on the iOS Device. My question is:
"Should I use one instance of this context in the app delegate and just reference to it from any view who needs to talk to the files, or do I make a new context on every ViewController."
Right now I am not fussed on memory efficiency, but I wish to be as efficient as I can before I release the app.
If you have a singleton Shared instance as an access layer, you could also make it to be the communicator to your core data context.
I recommend using a UIManagedDocument to setup the managed object context. It is a bit more work at the beginning but for example you could implement iCloud access more easily.
But you can of course also just hold a managedObjectContext (without managed document) in your singleton, or - as in the per designed core data app - in your app delegate (which you can access by the uiapplication shared instance from anywhere).
There is really not one right way, I think. You could look at the Stanford c193p lectures (available on iTunes) and watch the core data sessions to get to know the managedDocument approach.
I have several small utility apps for iOS. I want to combine these into one app with each utility accessed from a menu. I'm trying to figure out the best way to do this. The apps use Core Data which makes things slightly more complicated. Are there any standard ways of doing this or is just a matter of glueing pieces together until I get it to work?
Thanks
I recently worked on one such application. The design was as follows
-> Each sub application registers with the container app by providing the name of it's app delegate. I'd maintained a plist for this purpose which holds a mapping of the app name and the appDelegate class.
-> Whenever the user selects an app the container app will instantiate the app delegate and add the main view controller returned by it as the root view controller.
This design helps solve the logical part of the problem. You will still have a hard time before compiling all the source code as a single project.
As far as core data is concerned you must not have a hard time with it if each of your sub application uses a different object store.
I've looked around for this but haven't found what I'm looking for. I need some data to basically come pre-loaded in the app. I know that I could just put it all in on the first launch but would like to stay away from a long load time on the first launch and have it already loaded.
Is it possible to insert entities into core-data so that they are hard-coded in?
Yeah, you include a a pre-filled data store in your app bundle and copy it from the bundle to the documents directory as part of the app launch process - check if the data store exists and, if not, do the copy. You do this prior to accessing the Core Data stack for the first time.
There are a few ways you could do this. The lazy programmer way is to enter your default data into the app, either on the phone or in the simulator, grab the data store file, and include it in your Xcode project. The downside is it doesn't work well if you need to go back and edit the data model later.
The other option is to create an editor app on the Mac that uses the same Core Data model as your iPhone app (they're compatible) and edit the data in your Mac app. Jeff Lamarche talks a bit about this in one of his blog postings. I've done something similar, except I wrote a command line tool to download the latest data from a web site (in my case, XML data) and parse the XML into NSManagedObjects.
This StackOverflow post talks about a bit more complex option of having two data stores - one for your system data and one for your user data - and letting Core Data use both stores at runtime.
I was thinking of writing some UIViewControllers to display the data in my Core Data stores while developing and testing an app.
I was thinking of something like this: A view controller that allows the user to select parameters to be passed into a fetch request, then a table view controller to list the fetch results, and finally a view controller to display the data in a particular entry from the fetch results.
Does anyone know of some open source code already similar to this, or a different approach I should take for monitoring my data?
NOTE: To clarify, I'm talking about a generic solution that could be put into any app using CoreData with minimal configuration.
Not a direct answer to your question but there is a new app in the mac app store which allows you to view and manipulate Core Data Stores. While it doesn't integrate in with your own app (and its not the cheapest software out there) you might find it helpful. I stumbled across it a few moments ago and thought of your question here.
http://itunes.apple.com/us/app/core-data-editor/id403025957?mt=12
I am new to the iphone platform and am creating an app that retrievals a rss feed and displays it in a UITableView. I have gotten this working perfectly (or rather, the way I wanted). What I was thinking was I would store the current feed items on the phone so that it would initally load the old items it has stored while it got the new feed, then parse the new feed and add the new items and refresh the TableView. I was going to use Core Data to store it the old feed items because it would be a good way of learning Core Data and it would be an appropriate use of Core Data. However, I am having a difficult time learning how to use Core Data and connecting it with the Table/Array.
I have already googled and looked on stackoverflow for tutorials but have yet to find anything that explains it in a way I really understand. Any explanation of the overall steps that it takes to add Core Data to an existing app would be greatly appreciated. Full-blown detail are not necessary (but would also be useful). I'm just not very experienced with SQL or storing of data in such a manner and am having trouble wrapping my head around how the whole concept of Core Data works and how it connects to everything.
Also, any better method of doing what I'm trying to accomplish would also be appreciated.
There exist Xcode templates for Core Data-based applications; these are a great start to getting Core Data off the ground. However, it sounds like you want to integrate Core Data into your existing app, so you'll need to...
Add three main Core Data objects: the managed object context (MOC), the managed object model (MOM), and the persistent store coordinator (PSC). These need to be accessible wherever you want Core Data available, so either in your app delegate or, more preferably, in the controller or data source for your table view.
Create a MOM in Xcode. This will be a file of type .xcdatamodel, and it's an object graph that defines all the Core Data entities you want in your app.
Use NSFetchedResultsController (as suggested by Louis Gerbarg) to get data out of Core Data and display it into your table view.
Add code in your existing RSS-fetching-and-parsing routines to store new Core Data objects back into the store, when appropriate.
A good way to start is just to create a new Core Data application and play around with it a bit; you can also look at Apple's fantastic resources on the subject, like the Core Data Programming Guide and the sample apps Recipes and Locations. (Developer registration may be required.)
One last thing to note is that for the most part, a lot of the Core Data code you need to add can be ripped straight out of one of the Xcode template apps and pasted into your program (this holds especially true for the accessors for the three Core Data objects you need). Be careful not to use code you don't understand, though.
If you are using CoreData to populate a UITableView you really want to use NSFetchedResultsController as opposed to trying to populate and sync array yourself. The documentation for NSFetchedResultsController includes links to several CoreData tutorials, including onces that populate table views.
NSFetchedResultsController is still a bit buggy and requires fragile workarounds. I would start with the simpler iPhone Core Data "location" tutorial before moving on to the Books tutorial.
Also, any better method of doing what I'm trying to accomplish would also be appreciate
yes, it sounds like Core Data might be overkill for your application. Assuming your feed items are stored in a collection object you can easily use OSX's built in serializaition.
Been noted in other Stack-Overflow posts, but I can highly recommend the Prag Prog book "Core Data: Apple's API for Persisting Data on Mac OS X" - most is also relevant to iPhone Core Data apps; there is a whole chapter on creating an iPhone app too.
http://pragprog.com/titles/mzcd/core-data