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
Related
Is it possible to pass a button between two views?
I mean, when the button is clicked it has to call another view and stay while the view behind it pushesToSegue away.
Are you trying to reuse the same button in multiple view controllers? That is not really how things are done normally in iOS.
I suppose you want to pass some data attached to the Button (i.e. its label or tag) to the next view controller. In that case, you would want to pass the data as properties (e.g. NSString, ...etc.). In your next view controller, create the same button in the same position in the storyboard. Then you can set its label from the data you have passed in.
Now if you really want to pass a UIButton to the next view controller, you can still pass it as a property. However, when someone taps the button, the action method that is called is still the one in your first view controller. You could remap it to another action method in the next view controller, but going down this path is against the general rule of thumb.
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.
The first view controller has number of textfield along with three button where each button is pushed to different view controller. The case is same for the other view controllers too. I want to retain the textfield values entered remains same, irrespective of navigating from one view controller to others in all view ?
Be careful. You have to know when your controllers are deallocated. After deallocation you cannot restore the values, but if you stored the values in i.e. in NSUserDefaults, when the controller deallocates, then you can restore.
Normally, if another viewController is pushed, the last one is hold in memory, to get back smoothly. Forward pushing is always initializing a new controller, for which you have to think about how to store the old values (i.e. NSUserDefaults or implementing nscoding)
Store the buttons (or NSStrings containing the text) as ivars (instance variables) within your first controller. As long as you aren't getting rid of that controller and recreating it, they should persist.
I have a basic modal view system.
My app loads the UI base in which there are 2 buttons presenting 2 other views.
In those views, a dismiss button.
Everything works fine.
BUT, in one of the 2 modal views, I have a bunch of UISlider & UISwitch.
I want them to retain their values but the dismiss loses them: as soon as I trigger the button to show the view containing the UI elements, this view is shown with all values for all elements as I put initially in the xib.
should I store all values in variables, then in viewWillAppear I could "recall" them ?
would you advice me another strategy ?
Yes, your proposed approach is exactly the right sort of thing. But be careful; viewWillAppear can be called for many reasons; make sure you're only doing this when the view controller is coming into existence and showing the view for the first time.
NSUserDefaults can be an excellent place to store globally needed info like this. In viewWillDisappear, store the desired state info (values of the sliders and switches) in defaults. Then retrieve them the next time the view is about to appear.
When you create the modal view you are creating a new instance of the modalViewController an the modalView. This new instance knows nothing about any other instance. There are a few ways you can retain the information from previous iterations of these modal view controllers.
How I would do it:
Set up place holders in your main view and pass the values that the user selects back to the main view via a protocol and delegate setup. Then when you segue to the modal view you can load those variables in before displaying the modal view.
So let's say you have a dictionary with all of the values: {slider = YES, someValue=10,...} Create that dictionary in the main view controller, the first one that opens, and place some default values in it.
In your modal view controllers create the same dictionary as a property.
Create a protocol in your modal view controller with a method that is something like
- (void) doneEditing:(NSDictionary *)values
Set up your first view as the delegate for the modal view controller and in the implementation of doneEditing copy the values to the dictionary that is present in the first view before popping the modal view.
When the first view is ready to present the modal view again, copy the values to the dictionary property of the modal view before presenting it.
I hope this gets you headed in the right direction. It's important to remember that each time you segue or create and present a modal view you are creating a brand new instance of that view, it knows nothing about the previous instance at all unless you tell it something about it.
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?