i m new to ios app development.i m currently learning to work with navigation controller.Can anyone plz explain how to call -(UIInterfaceOrientation)navigationControllerPreferredInterfaceOrientationForPresentation: have implemented it in my code ,but it is not executing at all.
thankz in advance.
You don't call it, it's a delegate method that will be called by the navigation controller. You need to make whatever class you have the implementation of that method in, the delegate of the navigation controller.
The first method you mention is just a method which is called by the framework (if necessary) to get the "preferred Interface Orientation". For the system use this method you have to set more than one accepted interface orientation in your project setting and plist file.
The second method ´navigationController´ is inherited from ´UIViewController´ and gives a reference to the UINavigationController in which the UIViewController is embedded (means if there is no NavigationController it's nil). So it's a getter.
Now I think some more clarification in what you want to do with these methods would be useful, I mean you must have a reason why you ask, nobody just asks "why is there that method?"^^
Related
I wonder if dealloc is always called when you close a ViewController in Objective-C for iOS. I've done some tests and it seems like it. Except I don't get any logs when I swipe close the application. I figured that maybe XCode doesn't log things if you fully close the app like that.
The reason I wonder this is because I'm sending analytic data when one of the ViewControllers closes and I kinda need to know if dealloc is always called or if there's any better way doing this.
If you want to get notified when app is killed via Swiping , you can use applicationWillTerminate method and in this method , you can check for current view controller in navigation stack and send analytical data for that View controller .
It's not defined when dealloc will be called for a view controller (or pretty much any class), therefore don't use it for sending analytics.
Use viewDidDisappear instead, which you can rely on to be called when the view controller has been removed.
I have 3 view controllers that I'm navigating between. When I open my app, I start at Controller1, which I can then use to navigate to Controller2 or Controller3. I can navigate to each of them fine individually, however, after I go to Controller3, return to Controller1, then try to navigate to Controller2, I get an EXC_BAD_ACCESS with code = 1. There is no exception or error message given at all, it just takes me to my AppDelegate file and gives me that error code.
I don't know what the issue is, but something that seems relevant is that I'm setting Controller3 as the navigation controller's delegate. I have a fourth navigation controller that also is set as a delegate as well, and causes the same behavior when I from 1->4->1->2, just like with 1->3->1->2. I have no issue going from 1->4->1->3 or 1->3->1->4, only when 2 is involved. I'm not sure if the issue is the delegates, and the fact that 2 isn't being set as one. Once again, I can navigate to it fine by itself, but not after navigating to one of the other 2 sub-view controllers.
If you set Controller3 or Controller4 as the navigation controller delegate then you need to clear it in the viewWillDisappear function of those classes otherwise you will end up with an invalid reference and that is what is causing your crash
I ran into this same kind of crash, so I will share what the issue was for me:
I had created a subclass of UIWebView.
In my storyboard, I dragged a UIWebView onto the canvas and changed it's class to be my subclass.
That was all working. The app had already passed through our QA team, was "accepted" by the business owner, and we were ready to push it to the app store.
Then I was told, "You can't use UIWebView. You must use WKWebView."
Fine, I changed my subclass to inherit from WKWebView, tweaked my internal class logic, and....splat. Trying to segue to that view controller would crash just as noted by the OP.
The problem was my storyboard: Because it was trying to instantiate my subclass, it was basically attempting to create a WKWebView which is NOT necessarily supported in Interface Builder (my friend says it might be ok in later versions, but I didn't verify).
TL;DR
The moral of the story is that if you have a subclassed object on your story board whose ancestor can't be dragged from the toolbox, then you will probably crash when you segue.
I need some hints or suggestions on an issue.
What I want to do is to 'Minimize' a UIViewController like the 'message circles' in old facebook messages. So that the user can continue using the app and just move the circle to anywhere on the screen and then tap it to open it up and continue working from there.
The minimized UIViewController is suppose to be a UIWebView and I want the user to be able to continue working from whatever state the webpage was in.
I know one is suppose to add code here but I more want some pointers on where to start and how to think or possibly some suggested codesnippets or links.
Hope someone can help me out.
Thanks
edit: Thanks Moti. Ok so I will Not be using storyboard but do do everything programmatically.
I will have it not fully hidden but 'minimized' as an ontop circle to be accessed to just by tapping it anywhere from in the app.
Trick14, I will have a check. tnx
Make a Base View Controller which is inherited by every ViewController in your app. Declare the functions in it. And you can directly access these functions in any of your base class. Or simply hide or show your view anywhere in your app.
If its part of navigation controller you can keep strong reference to it somewhere, so when you pop it out it will stay alive. And when you need it you can push it again.
If you can describe some more details regarding how you show/hide and if its part of storyboard or built in runtime, the community will be able to be more specific regarding solutions.
If you look into UIViewController you will see
addChildViewController:
removeFromParentViewController
willMoveToParentViewController:
didMoveToParentViewController:
You can play around with those to achieve what you need, for example when you detect that the "overlay" controller removed from parent view controller you could push it back in the method didMoveToParentViewController: of the the other controller.
Yes, there is some management to be done, but it is possible.
I will try to make some working example with dummy views.
I have an app that has similar layout where a new ViewController will pop up when the button was clicked.
When the user clicks on one of the table cell, I would like to return this result to the main controller's function, please help.
There are different ways to do this.
- By using delegates.
- By implementing Notifications.
- Pass main view controller reference to the view controller and set some property or call method.
Now its up to you what way you will use. But according to my point of view implementing delegates will be the best way for this.
Following are some links from where you can understand how to pass data:
- http://www.raywenderlich.com/forums/viewtopic.php?f=10&t=3265
- http://www.tutorialspoint.com/ios/ios_delegates.htm
2nd link will take you to the delegates tutorial.
You might want to read about 'delegates'. Here is link to good SO discussion: What is a "delegate" in Objective C's iPhone development?
I've been looking at view controllers for a few days now (searching xcode help, google and stack overflow), and I think I have some understanding of it, but not a lot.
I have some code, that I have trouble understanding.
So here I have the following code I found in the book I'm reading, and I'm not sure If I understand it correctly.
-(void)prepareForSegue(UIStoryboardsegue *)segue sender:(id)sender{
((ViewController2 *)segue.destinationViewController).delegate = self;
}
First, I have no idea why we typecast to our second view controller(viewController2) here.
I think I get the rest though, we take the method's segue parameter (which holds information about the view controllers involved in the segue), and we access the destinationViewController(meaning that we want to access the view controller that we are going to). We then set the delegate property of the destination view controller to self. I believe we set the delegate property to self, because we want to send messages to a delegate in the view controller we're going to.
Heres the last one I don't get:
In the header file:
#property (weak, nonatomic)id delegate;
In the implementation file: (the controllerVisisble property is a boolean, and is changed to YES when the user hits a button to perform a manual segue to the second view controller, which is this one)
-(void)viewWillDisappear:(BOOL)animated{
[super viewWillDisappear:animated];
((ViewController *)self.delegate).controllerrVisisble=NO;
}
Heres what I think this does: the viewWillDisappear method is called when a view is closing/removed.
I'm not quite sure about [super viewWillDisappear:animated], but I'm guessing that it gives an animation when the view disappears?However, I remove that line, and my dismissViewControllerAnimated method still gives an animation when the view controller is dismissed.
Here's the part that really confuses me. We need to access the first view controllers dateChooserVisible property somehow, to set it to NO, so we can access the second view controller again through our button. But, I don't understand why we have to typecast (viewController *), and type in self.delegate. Nor, do I understand why we created a property called delegate in the header file, to use here.
A lot of these questions are more generic than just within the context of view controllers.
[super methodName] calls the superclasses implementation of the method named methodName. In your case, Apple has written some code (that we don't have access to) in UIViewController's viewWillDisappear: method. ALWAYS call super when overriding a method from a superclass.
Note that viewWillDisappear: is just callback triggered whenever the view is set to disappear. My guess is that the super implementation of this method forwards this callback down to child view controllers, especially in the case of standard container classes like UINavigationController and UITabBarController.
The type casting really doesn't seem necessary, you can always call methods without compiler errors/warnings if the receiver is either type id or provides a declaration for the called method in its #interface.
As far as the delegates go, protocols and delegation are a major part of Objective-C, and widely used in Apple's APIs. This link might help you understand how they work; it helped me immensely.