Dear All, I am trying to build a navigation based iPhone application where I want to use Core Data modal at 3rd level view of navigation. The 1st and 2nd level view of this application are just simple tableViews. I have looked at the Apple CoreDataBooks application but there it used the methods for Core Data in the AppDelegate and RootViewController while I want to use these methods somewhere else. It is possible? Can somebody refer me to some tutorial for that?
Thank you very much.
You can
Have your view controller create the Core Data stack.
Use [[UIApplication sharedApplication] delegate] to find the app delegate from anywhere, and ask it for a context.
Pass your context as an argument down through the view controllers.
It's a choice only you can make, based on the ways you expect your application to change in the future.
Related
Is it possible to communicate with a viewcontroller after a segue switched to another viewcontroller?
I want to know, because I need data from a viewcontroller passed on to the next viewcontroller,
but I just can't figure out how to get data from one viewcontroller to another, as they have no unique names or something which I can use to communicate with.
So can someone tell me:
If it is possible to communicate between viewcontrollers, and if possible, how?
Usually you do it the other way around, pushing values from the source to the destination. If you implement prepareForSegue in the view controller that is going to be segue'd out, you can use
[segue destinationViewController]
to get a reference to the destination view controller.
Then you can set any values in that controller that are needed using properties on that controller before it segues in.
I have searched for tutorials about making a MVC based iPhone app, but without success
Goto ITunesU and look for Paul Hegartys "iPad and iPhone Application DEvelopment" from stanford university
very good!
try the views presentingViewController property.
A typical OOP pattern is to create yet another object, a Model object (MVC paradigm), connect all the view controllers that need to communicate with this Model object, and pass any shared state or variables by setting and getting properties in this Model object. A common shortcut for very small apps is to use the App Delegate as a Model object, as any other controller can get a reference to the app delegate. But this shortcut is not very extensible to larger or reusable code.
Now,I gonna Develop an App ,which wants to switch from many different Views irregularly,also the views need to load large resources,AKA,it's hard to manage memory.Are there any good solustion?
PS：I created a ViewController as RootViewController,and When a button was Touch,run the code as
"ViewController=newController"
.The problem came,The new View loaded wrong way,it rotate so that couldn't show in a correct way.
I google for the solution,some one said ,I should replace the rootViewController,just like that,
[UIApplication sharedApplication].delegate.window.rootViewController=newController;
But I can't get/set the rootViewController in other class though it's a singleton.
Why not having a class that handles all the view switches ?
This article describes an architecture that might be helpfull: http://www.mikeziray.com/2010/01/27/handling-your-initial-view-controllers-for-iphone/comment-page-1/#comment-607
I am pretty new to iPhone programming.
I have a navBar with three views. I need to control audio from all of the views. I only want one audio stream to play at a time. I was thinking that it would be smart to let my AppDelegate have an instance of my audioplaying class and let the three other views use that instance to control the audio. My problem is that I don´t know how my views can use the audioplaying class in my AppDelegate.
Is this the best approach and if so, how? Is there a better way?
The cleanest way would probably be to implement a singleton that you could access from all your view controllers (e.g. [[MYAudioController sharedController] theAudio]). It's also possible to access it in your app delegate (e.g. [(MYAppDelegate *)[[UIApplication sharedApplication] delegate] theAudio], but I tend to think it's a bad idea to make view controllers dependent on the app delegate.
I'm still a little fuzzy on understanding iPhone/Cocoa in general so this is probably a simple question.
I have a CoreData Window-Based App for the iPhone. The rootController is a UITabBarController. The first tab view has a UINavigationController attached to it with a table in it's main view.
When the App starts the objectContext is set up, which makes sense to have the App do that once. But now I have the managedObjectContext in the main Controller but I want to get that passed down to the Controller of the View inside the navcontroller, inside the first item in the TabBarController's tab list. How do I do this?
Would naming the one of the fields in the UI Inspector Tool allow me to do something like:
tabcontroller.navcontroller.manageObjectContext = self.managedObjectContext;
Would this only work if the controller was instantiated and 'live'. (Do the controllers not get instantiated until they are needed?) What if this was in a view that was for the most part hidden?
Anyway this is probably a simple thing I'm just not understanding things properly yet.
What is the general right way to share the manageObjectContext that is created and setup in the rootController to the many sub-controllers in the app?
I'm guessing this is the preferred method assuming the core-data initialization is done in the AppDelegate:
[[[UIApplication sharedApplication] delegate] managedObjectContext]
I usually give controllers a - (id)initWithManagedObjectContext:(NSManagedObjectContext *)context init method and a corresponding variable.
If a controller creates another controller in turn, it will, if needed, pass the NSManagedObjectContext to that controller in the same manner.
If you don't want to create an extra init method, just give the controllers a property for the NSManagedObjectContext and set that property directly after creating them.
I usually try to limit the number of controllers that directly deal with and "know about" Core Data though.
The answers to this question provide several means of accessing the Core Data stack deep within your application. As I indicate in one of the comments, I prefer to use a singleton DatabaseController that can be accessed from wherever, similar to how the NSUserDefaults' standardUserDefaults works.
I have an NavigationController based app where the data model is stored in the appDelegate after being fetched using CoreData. The views that display the data all have a pointer to appDelegate so that they can query the model for the required data. They then call methods in the appDelegate in response to user selections.
My question is, doesn't the MVC pattern optimally hide the data from the view? Would it be best practice for the appDelegate (in this case serving as model and controller) to supply the data to the view, and for the view to simply send a notification when there is user input? That would eliminate the need for the view to maintain a pointer to the appDelegate.
You're correct to worry about AppDelegate taking on this role. AppDelegate is an easy place to dump stuff, and it quickly becomes overwhelmed with roles. As you note, it's playing data model, data controller and application delegate. If you're getting to the AppDelegate using [[[UIApplication sharedApplication] delegate], it's especially a problem because it makes it very hard to reuse the view in other programs. It's less of a problem if your view has a delegate ivar that just happens to point to the AppDelegate, but could easily point to some other object.
The view often should have a delegate that it passes UI events to. See UITextField and UITextFieldDelegate for a good example pattern. Views generally don't post NSNotification for this kind of stuff. Conversely, model classes typically work best without delegates in my experience.
I am a huge believer in NSNotification. My programs use them for almost all data that moves up from the model layer. But for actions that move down from the view layer, delegation and direct method calls typically work best.
Its not your view that accesses the data. The controller should be the link between the data and the view. If by view you mean the controller, then that's perfectly fine and basically what MVC is all about.