I am new to iOS development. I am having a weird situation, not every time but very often. My textfield is getting cleared automatically when I come back to the same screen using back button. Code as:
self.navigationController?.popViewControllerAnimated(true)
Problem happens in both simulator and device.
It happens because the content view is refreshed everytime when you navigate app to previous viewController this make refresh to all ui components as well. What you need to do here just save the textfields value temporally to any persistent storage like local db or using userDefaults then assign the value again using viewWillAppear() method because this method executes everytime when you navigate back your app to vc.
viewWillAppear(): Called just before the view controller’s content view is added to the app’s view hierarchy. Use this method to trigger any operations that need to occur before the content view is presented onscreen. Despite the name, just because the system calls this method, it does not guarantee that the content view will become visible. The view may be obscured by other views or hidden. This method simply indicates that the content view is about to be added to the app’s view hierarchy.
Related
I am trying to create a simple app and here is how it works:
When the user clicks the button "Picking", it'll show a tableview. And when the user selects a row in the table view, it will show the first view and display the data on the label.
I have 2 problems:
Every time I click the button "Picking", a new instance of the table view controller gets created; but does not reuse the existing one. How can I make it reuse the old one?
I want to pass the selected data to the root view. I tried by creating a segue to show the root view when user selects a cell and then passing the data on prepareForSegue method. But, I faced the above problem of memory leak. How do I pass the data between screens without leaking memory?
It sounds like you may be making a circular view hierarchy. When you tap on the cell in the table view, if you're pushing a new instance of the first VC, that is the wrong way to do it IMO.
Instead, you should pass the data back to the first VC then dismiss the second VC. Then, when you tap on the "Picking" button again, it's a new instance of the table view but your previous instance has already been removed from memory.
This allows for the smallest amount of memory to be used at any given time. When the table view controller isn't on the screen, it doesn't need to be in memory.
IMO, the best way to pass data up a navigation stack is to use a protocol and delegate. It's similar to how Objective-C protocols and delegates worked if you're familiar with that. Here is Apple's documentation on both. The delegate section is about 1/3 the way down the page.
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Protocols.html
So I have an iPhone app. It has a simple structure, all based on a UINavigationController.
I have a storyboard that has one view, a segue to another view, etc. Now this other view has a UITextView that I do not want to edit on this screen - if the user taps this, I want it instead to fly over to a second screen which basically has the same text view, but this one is full-screen, and the user will edit the text on that screen before returning to the previous screen.
So I capture the textViewShouldBeginEditing method. I previously, in the storyboard editor, manually created a push segue from the previous view controller to this new view controller, and named it so that I can call it by it's identity, which I do with:
- (BOOL)textViewShouldBeginEditing:(UITextView *)textView
{
// This is called when the user clicks into the textView as if to edit it.
// Instead of editing it, go to this other view here:
[self performSegueWithIdentifier:#"editMemoSegue" sender:self];
// Return NO, as I don't actually want to edit the text on this screen:
return NO;
}
Seems reasonable. And it works. Sorta. It does in fact shoot me over to that other view. That other view's events fire up, I set it's text view to become first responder, I edit the text on that screen. Everyone's happy.
Until I want to use the back button to return to the previous view.
Then I quickly find out - my navigation stack is foobared. Most of the time, I have, for some reason, TWO instances of my new editing controller on the stack, so the first time I hit the back button I get the same stuff over again. Then, oddly, occasionally, it will work as intended, and I will see my previous controller with only one back click.
I started reading the log, and I found this:
2012-12-09 09:41:03.463 APP[8368:c07] nested push animation can result in corrupted navigation bar
2012-12-09 09:41:03.818 APP[8368:c07] Finishing up a navigation transition in an unexpected state. Navigation Bar subview tree might get corrupted.
2012-12-09 09:41:03.819 APP[8368:c07] Unbalanced calls to begin/end appearance transitions for <SecondController: 0x83881d0>.
So obviously, I'm doing something incorrectly here. The question is, what? And how do I do what I want in the way that correctly appeases the tiki gods of the iPhone framework?
Check to see if the textViewShouldBeginEditing is being called twice. I've noticed that these kinds of delegate calls sometimes are.
How is your #"editMemoSegue" being created on the storyboard? is it created from the textView? if it is then you should recreate it directly from the view controller or from the top status bar on the view controller that way it wont be called twice when you touch the trigger object and when you call it programmatically.
What I am asking may be impossible and sound weird, but here it goes.
Here is similar to what I want to achieve:
A user opens the app for the first time, there are two tab bars, in the first one (he has not tapped the second one yet) he presses a button that should initiate a progress view and text view changes and other view changes EVEN THOUGH the user has not loaded the other view controller by clicking the second tab bar.
So, is there a way to generally load a view controller before the user manually loads it himself, I know calling viewDidLoad manually will not help, any suggestions? Pretty confusing, it is like modifying a view but the controller has not loaded yet...
Thanks!
Make the changes in the other view controller and then let the controller configure its own view when it does its natural loading.
I have an app which plays music files. The UI has two tab views. TabOne plays the song while TabTwo displays information about the song. I have a button which sets a global variable that identifies the song to be played. The song does play but the information displayed in TabTwo does not update.
How do I ensure that both tabs update in sync when the button is tapped?
Thanks,
Ritesh
You can't force another view to update by an action that occurs in another view. Instead, you have to setup the view controller to check for some data just before it's view appears.
Whenever a view is not visible on screen, you can think of it as being asleep. In the case of a tabbar, the tabbar controller only activates the view controller for the view of the tab being currently displayed. Therefore, even if you send information to a view controller when it is not active, it will not update its own interface automatically.
Instead, you have to manual setup the view controller to check for new data. Most often this is down in viewWillAppear which is called whenever the controller's view is about to be displayed (such as when its tab is selected.)
In your specific case, you need a global variable that identifies both the song and the songs data. When you press the button, the action method should set that global variable to the appropriate song. The song info tabview does nothing until the user selects its tab. At that point, the view controllers looks at the global variable and loads the information into the user interface elements before the view actually appears. From the user's perspective, the song and song info tabs appear synchronized.
I can't provide more detail without seeing your actual code or your broader app design.
I'm starting to go a little crazy with this one.
I have an iphone application with a somewhat complex view structure it is a tabbed application with either a view controller or a navigation controller on each tab.
The main controller for one tab uses the viewDidAppear callback to reload any data that has been modified since the last time it was displayed and this behaves fine in most cases. The issue I have run into is that when I navigate in subviews(within the same tab) using the standard navigation controller push/pop mechanism the viewWillAppear and viewDidAppear on the main view always fire when I navigate back to it.
However if I load a modal view controller and then dismiss it, the viewWillAppear continues to fire but the viewDidAppear stops firing.
I am almost certain that this is tied to the need to manually call these callbacks on the modal controller but I cannot find the reference info on how to do this correctly. (I only see this viewDidAppear bug on the hardware, in the simulator it works as I'd expect)
If you need further clarification let me know and thanks for any input.
Yes, this is how it works. You are better off switching to using viewWillAppear.
This has the added advantage of updating the data before the screen is redrawn.
viewDidLoad should be used for one-time setup operations:
Setting titles
Instantiating subviews, content arrays
Anything else related to the infrastructure of the view in question
After that, use viewWillAppear: to do anything related to refreshing data. You shouldn't have to call any of the viewDid/viewWill methods manually – that's handled by the innards of UIView. viewDidLoad won't fire after you dismiss a modal view controller because, more than likely, the view never unloaded. viewDidLoad fires fine when you're navigating the a view controller stack since the new views need memory, requiring other views to unload, then be reloaded when they reappear.