Does anyone know of a good way to start with a basic model but not use Core Data yet? I have a simple application that doesn't need to save any data (at the moment), but I don't think Core Data would be overkill for it.
I don't want to use the App Delegate to store data, nor do I want to store data in individual views. I was hoping to find some sort of "transitioning" type of solution that would let me switch over to Core Data in the future.
I've seen some simple examples, but they require storing an instance of the model within a particular view controller. I plan to have several views, so I want to find a better way.
The data model for an app can be as simple as a dictionary, or an array of dictionaries, or a plain old C-style array of characters for that matter. Or, to take it one step further, you might create a custom model class that not only stores the data but also knows how to manipulate it as necessary for your application.
How each controller gets access to the model is a different question. Some people like to use a singleton (I don't) so that they can access it globally. A (IMO) better approach is to instantiate the model in an object like the app delegate or root view controller, and then pass either a pointer to the entire model or a pointer to part of the model to view controllers as needed. An address book app might pass just a Person object to an address detail view controller, for example.
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.
Im developing an iOS application and I'm stuck on how to design the structure of it. Here is what I have so far:
The app is called "Time Clock" and it allows users to clock in and out. The app will generate time stamps when a user clocks in or out respectively. As far as data goes, I already have a large MySQL database that is already being used for a similar Windows desktop application. (I'm trying to cater to my company's iPhone users)
My question is, what should I do about the data structures in this app? Can Core Data retrieve the MySQL data (through a web service) and manage it? Should I use data controller classes to manage the data? I don't know the best way to handle the data.
Here are the data fields that need to be managed:
Store
Name
PIN
Timestamp In
Timestamp Out
All in all, what is the most efficient way to manage the data in an app such as this? If you could point me in the right direction i would be very thankful! :-)
Core data wont be able to retrieve anything from a webservice, you need to make a data access layer that will return that data to you via NSURLConnection and the like, there is a lot of information out there on how to do this... I would recommend modeling some classes that basically your data layer will fill for the rest of your application to work with. Also if your data is shared across many views i would suggest making some singleton class that will keep the data already retrieved, this way you can access it across different UIViewControllers in your application. Way I would structure this is
DataAccessLayer (layer that consumes your webservices, and fills the info into classes (your model)) -> Some Singleton class that keeps your objects from your webservices -> UIViewControllers (these will talk to your data access layer/ Singleton class for the data it needs which in turn uses it to fill your views ->VIEWS - > if changes occur to your model relay that to your webservices via the data access layer
... As far as core data, you can use that if you want to persist the data in your application, but its not necesary otherwise, i should point out that core data is not the only way to persist data in your application... This answer is a bit general but hope it can point you to the right direction..
Daniel
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
I am writing a Catalyst web application that presents some data that does not change in between requests. I want to load this data when the application starts and stick them somewhere so that the relevant controllers can use them. Where should I load this data and where should I store it? At first I tried to load it in the main App.pm file and put them into the application config. This works, but it’s ugly, since the App.pm file gets littered by a lot of loading subs that don’t really belong together:
__PACKAGE__->config(this => load_this());
__PACKAGE__->config(that => load_that());
# et cetera
Then I figured I could load some of the data in the controller that uses them and store them in the controller’s config hash. This is not perfect either, because some of the data is needed in more than one controller.
I also thought I could localize the data to the controller instead of sharing them. This feels nice, because I would have all the code that works with the data more or less on one place. The problem is that the controller would also have to render parts of the resulting page for other controllers – for example if the title page controller wanted to display a list of recent news, it would have to ask the news controller to render the list. This does not seem to be the preferred way of doing things in Catalyst.
How would you solve this?
(The nature of the data: This is a website of a music festival. There is a line-up, a list of sponsors and other simple data pulled from YAML files, because database would be overkill and hard to edit.)
Fundamentally, the data should belong to the Model, which is to say your YAML files should be represented by modules in your application's Model. That's one reason you separate the model from the controllers in the first place: All of your controllers can talk to the same models, without having to replicate their information within themselves.
There's no reason you can't cache the data persistently in these modules, using plain perl data structures or whatever caching technique you like.
I have an app that allows the user to view, manipulate and manage a collection of Schedule objects. Different parts of the app need access to this data. I've experimented with making the collection a singleton, but I didn't find that very clean.
I recently changed to storing the global data in the AppDelegate class and using:
MyAppDelegate *delegate = [[UIApplication sharedApplication] delegate];
[delegate.myGlobalData doSomething];
Which eliminates the need for my global data to be a singleton, but is really just taking advantage of the UIApplication singleton.
There really isn't just one primary view controller where it makes sense to store it in my case. So I was wondering what different strategies people use to address this.
If you've got a central data model that needs to be accessible to multiple controllers, there's nothing wrong with using a singleton to manage the data-- a "sharedManager" is exactly what the scenario demands. This is essentially what Apple does with their address book API for manipulating contacts. They use a C-style API but it involves getting a reference to the shared address book database and then using that in future calls.
Using the app delegate works too, but as you note it's really the same thing. You're designating the app delegate singleton as the owner of the data model, which is OK too.
NSUserDefaults can be abused in this way but that's really not its purpose. Aside from being kind of ugly, it also puts restrictions on the type of data you can store. Your own model can store whatever data you like, but NSUserDefaults is not quite so flexible.
Using SQLite or a property list or whatever to store the data to a file is really orthogonal to the question of how to manage it. From your description a singleton approach sounds reasonable, and that singleton can write to files in whatever way makes sense for the data you're working with.
Many people store everything in the AppDelegate and access the data through [[UIApplication sharedApplication] delegate].
If the data are supposed to be persisted, you could also use the NSUserDefaults singleton.
If the data are big, maybe you need SQLite.
This is for "global" data as you asked.
If your view controllers are organized in tree, a better way would be passing the required data from parent UIViewController to child UIViewController.