Is it appropriate for my app to have several managed object contexts? I was going this route, (passing along my MOC from one instance of a UIViewController subclass to the next,) but I'm starting to run into EXC_BAD_ACCESS errors and I'm wondering if it could be related.
So, when do I want to use multiple ManagedObjectContexts, and (when) should I only use one?
Edit:
In my UISplitViewController based app, when deleting a row on my Master view, only after presenting a second view inside the main detail view, my detail view controller crashes on respondsToSelector, which I don't call ever.
Edit 2:
Basically, I have a master view and a detail view. In the detail view, the user presses a button. The button brings up a "new transaction" view. Instead of presenting the view modally, I manually add it to the detail view. If the user makes a change to the managed object context in this new view and then tries to delete the row in the master view, it causes a crash. If I present the same view modally, everything works just fine.
Furthermore, NSZombieEnabled says that a respondsToSelector method is being called on the (parent) detail view. I don't call that anywhere in my app. Could this be a memory issue? A threading issue? I don't explicitly create any new threads, but I don't know if there are any threads being created behind the scenes.
What might be the problem?
EDIT3:
This problem seems to get better. In my detail view, I also have a table, which, like the master view, uses an NSFetchedResults controller. When I delete the cell, I also hide the detail view, which causes it to be released. Releasing the detail view causes the app to crash. If I don't delete the detail view, the transactions in the detail view's table are deleted. (This is because I have Core Data set to cascade when an account is deleted.)
So, perhaps I have too many NSFetchResultsController objects? I believe that what is happening is follows:
When I delete a row, the NSFetchResultsController value changes and so it tries to fire the delegate method. However, the detail view has been removed and it's view controller deallocated. So, the delegate system fires a controllerDidChange method and crashes when trying to deliver the notification to the detail view.
How can I fix this?
Generally speaking you should use just one, unless you need to access data from multiple threads, in which case you'll need one per thread.
You certainly shouldn't need to create one per UIViewController.
You might also want to re-think whether you should pass the whole managed object context to a UIViewController anyway - how about just passing it the model objects it needs to do it's job?
Related
I have two view controller. On the Second controller I have a button which cause a UILabel to change from "larry" to the string "happy". If I press back, which take me to first view controller, and then forward, which take me to the second view controller (from the first view controller). I found that the UILabel change back to default, "larry". How do I make it so that when I change view controller, the changes and data doesn't get clear away.
Recap: How to make it so that every change in a view controller doesn't change back to default after changing to another view controller.
This doesn't only happen with UILable, it also happen with
self.loadPage.hidden = YES;
I also found out what I made to turn 'hidden' also appear back after I pressed back and forward.
Thank
The problem that you are facing is due to the fact that when you press the button a new instance of the second viewcontroller is created and that old one is destroyed.
If you want to persist the data while pressing the buttons, you need some way to store the information somewhere
there are some methods to got about it
You can use instance variables in both the classes to store the data temporarily and display them. You need to know the concept of protocols and delegates for this as well.
You can store the information in NSUserDefaults for some moment so that you can access it later on.
The issue is each time when you goes from first view controller to second, you are initialising a new instance of second view controller which brings back every values you changed to default values.
You need to save the values elsewhere and assign those values whenever control is switched from one view controller to another
I have two view controllers, one that shows some content in a list and one that renders a map. I give users the option to switch between the two by tapping a button. I'm currently using a segue for the button to switch between the two views, but because of the nature of segues I end up re-initializing the view controller each time, generating unnecessary network traffic.
I'm looking for a way to transition between these two views in such a way that the controllers are only initialized once, the first time they're invoked. Subsequent invocations of these controllers would just use whatever instance was already loaded in memory.
Is this achievable? If so, what do I use? pushViewController also ends up calling viewDidLoad on the controller being pushed onto the stack
I have a side menu controller that is part of the rootViewControllerI never remove it from there and when it slides off screen - its just an animation that updates its frame details.
Is it possible to update this view, while it is not displayed on scene? I have a UiTableView in there and I would like to reload it while it is off screen - so when the user slides out the screen, its already populated with new content.
My first approach was a delegate - however, the delegate method doesn't get fired and I believe this is due to it being off screen. But, I somehow think side its in UIWindow it is never really deallocated like a normal view when it leaves the screen?
Edit
I am using this Github project for the menu.
The view I want to update is in a UINavigation controller, one level deep. I can get the current instance of it - however, the delegate method doesn't trigger.
It seems to me that you are going with something like this. Even if not, look at the example. Here RootViewController is always alive and you move one viewcontroller to parent view controller and remove other one.
I have two ways to fix it:
If you are removing first view from parent view controller. Don't remove it. So the controller is still live and use delegates to trigger the event.
Remove first view controller then use Root view controller to get the updates and once the previous view controller loads back take updates from root view controller and update this one.
Hope it can atleast give you an idea.
I am pushing and popping from one view to the other within my App. The view is being retained in the memory so when you hit the "Back" button after pushing a view, the same screen that was before you pushed the view is retained.
For some reason, I will need to reload the parent view after popping from a child view. I need to display different content based on the actions the user taken when they were redirected to the child view.
I am using UINavigationController to navigate from one view to the other. I need it so I can easily go back and forth within the different views of the App.
The correct way to do this would be to perform your actions in viewDidAppear. Initialisation code that you write in viewDidLoad is called only once. But in viewDidAppear you can refresh your view's content every time the view is added to the window. The controller is retained in the memory for performance reasons. Removing it would hamper that factor.
Here is a stack overflow post that explains the different view* callbacks in good detail.
I've been learning coredata by making a lot of simple test apps based on the xcode Navigation controller template with "use coredata" checked.
The awakeFromNib method in the App delegate has been a source of problems for me, because I'm adding other views to the controller and changing the load sequence, so that RootViewController may be a second or third choice.
I've figured out what awakeFromNib is doing, and I've removed it so the app delegate is no longer tied to any particular view. (So when I do want to load RootViewController, I'll load it as a regular view, and use its own viewDidLoad to initialize the managedObjectContext for the view).
My question: are there performance gains or other benefits by using awakeFromNIb in the AppDelegate? or is it just another way of doing the same thing as I'm doing from the viewDidLoad method?
All the methods fire at different times and different circumstances.
awakeFromNib is called when the nib file associated with a class is loaded from disk. Any class that can own a nib can use it. viewDidLoad is used only by view controllers. It is usually called when loading from nib as well but it can also be called by a view created in memory (very rare circumstance.)
In either case, you only put functionality in either that you only want to run once when the instance is first loaded. E.g. a common nubie mistake is to put code in viewDidLoad that needs to run every time the view appears. Say as with master view that opens a detail view and then reappears when the detail view is dismissed. If the code for the master view is in viewDidLoad it will only run the first time the master view is loaded but not any of the subsequent times the master view disappears and reappears.
You generally don't initialize any other views or do much of anything in the app delegate's awake from nib. That is usually performed in applicationDidFinishLaunching.