I could use some clarification regarding where these references come from. As an experiment, I set up a split view controller in my application. When the delegate methods are called, they reference what appears to be a valid UIButtonBarItem and a valid UIPopoverController. I say "apparently" because both of these have non-nil values and resolve to the appropriate class (UIButtonBarItem and UIPopoverController). I did not allocate or initialize either one. Am I supposed to?
I don't see anything in the reference documentation that requires that I initialize these programmatically or says how it should be done. I also don't see where the toolbar that contains the UIButtonBarItem is referred to. I haven't found any examples of tutorials that address this detail more than superficially. If someone can explain or provide a reference to an explanation, that would be helpful.
I am working out how to switch from split view to popover view when going into the portrait orientation. I want simply link an existing button to code that does what the UIButtonBarItem would do. I have a small banner view of my own that serves as a toolbar, and I would rather adapt the button in that to work with the split view controller, if I can.
The UISplitViewController creates both of these for you and you can do with them what you want. Just add the button that it provides you to your toolbar and store a reference to the popover (so that you can dismiss it, etc.).
Note that when you go back into landscape mode you need to set your popover variable to nil and remove your button since they are no longer valid.
Related
This is my first app using storyboards/segues, and I'm pretty sure the answer to this is easy, but I'll be as thorough as possible in describing my issue.
I am making a simple app which has a Tab Bar Controller scene and two View Controllers.
My app launches by being sent a URL from another app. The application:openURL:sourceApplication:annotation: method in the app delegate performs some work to determine
which tab to display first, and
what information to display on it.
My goal is to use the performSegueWithIdentifier method (I'm open to alternatives though) from within the AppDelegate to select the tab, and also find a way to send a method to the instance of the view controller created by the storyboard.
Issue #1 is that I can't set an identifier. When I select the tab "relationship" there are no choices available in the Attributes Inspector (it says "Not Applicable"). How do I set a name for this segue? Can I? Or is there some rule under which UITabBarController segues can't be trigger programmatically?
Issue #2 is that I can't find a way to have a pointer to the view controller. Pre-Storyboard I would alloc and init a new view controller and then set it up, but here if I do that, it does not get displayed when my app launches (I think this is because Storyboard is displaying a different instance of the same view controller.)
I know this post is long, but I feel like I'm missing something simple. What is it?
Sounds like you need to have your AppDelegate set the entry point to your storybard.
Just as a disclaimer, I am an iOS beginner, in a pretty unique position. I'm an intern learning on the job, with a hard deadline for a test app, with specific specs. So I unfortunately don't have the luxury of learning all that I should about xCode and objective C.
Anyways, I am trying to create a navigation menu similar to the iPad's slide out menu. I've looked at plenty of sample code given in response to questions like this in the past. It all works perfectly fine, but I can't understand all of what they're doing. I think this results from being fairly bewildered by view controllers and delegates. And, since I'm supposed to be writing this all by myself, I can't just build off of their existing code.
My plan for this working is to have one main view controller, containing the navigation menu in a table view. This is hidden behind a normal UIView, until a button is pressed, at which point the normal UIView slides offscreen enough to reveal the menu. Upon selection of a menu item, the normal UIView would slide back to its original position, and be replaced by the relevant UIView, controlled by its view controller. In other words, clicking on the menu item relating to "Home" would load the homeViewController.xib, controlled by the homeViewController. This would be loaded in that normal UIView subview, on top of the tableView.
I'm able to load a view in that normal UIView as a result of a button press.
homeViewController *_homeViewController = [[homeViewController alloc]initWithNibName:#"homeViewController"];
[self frontView] = _homeViewController.view;
There may be some syntax errors in that code, since its from memory. I'm not able to access the computer with my code on it at the moment, but that's the general gist. Basically, that places the home view nib on the frontView (that normal UIView that's over the table view), but its not connected to homeViewController. Or at least I think that's the issue, when I press a button, that's correctly connected between the nib and the homeViewController.h, and only set to NSLog in the .m file, the application crashes.
Any idea how to connect this nib to its viewController when displayed in this way? Or, to create the nib in IB, without the associated .h and .m files, and use the main view controller as the homeViewController as well? Or, if my logic is inherently flawed, what SHOULD I do? Something with NavigationControllers?
EDIT:
I also tried a new approach- changing homeViewController's file owner to viewController, and connecting the button on homeViewController's action to viewController. This too caused a crash upon pressing the button. I really think the issue is with having multiple view controllers acting on screen at once, or having multiple views from separate nibs, controlled by one view controller on screen at once.
I suspect that your immediate problem is that _homeViewController is being freed as soon as you leave whatever method that code is in. To fix this, create a strong property in this class that holds the _homeViewController for as long as its view is needed and allocate it to that property rather than a local variable. That way, buttons (or whatever) that are part of that view still have a valid controller object backing them.
In the long run, pushing or presenting view controllers when you need the screen to change is a much better strategy but, as I said, the immediate problem.... :)
I'm trying to put an iAd banner in an app that is based on a UINavigationController (it's not the standard nav-base app proposed by xcode, cause I don't need the table view).
I'd like to place an ADBanner on its bottom, to be always visible, no matter how the user pops and pushes views.
I studied the iAdSuite example in the apple sample code, but, though it's reported among the "best practices", I don't think it's the best practice for what I need. It basically declares an ADBannerView in the app delegate class and then implements the ADBannerViewDelegate methods for every single view the app needs. That means implementing the ADBannerViewDelegate methods over and over again on every view controller class you need! It doesn't seem too smart... :(
I'd rather prefer to have an approach more similar to what Apple itself does in the tab bar based app, where you have a part of the window always occupied by the tab controller and all the views switching above without affecting the tab bar view below.
You can't directly put an ADBannerView along with the nav controller in the app delegate, because ADBanner needs to be placed in a view controller (you get a runtime error otherwise).
I tried to subclass from UIViewController, implementing the ADBannerViewDelegate in this class, and place it in the rootViewController along with a UINavigationController but I'm not having good luck with this approach...
Has anybody found a good, simple way to to this? Any hint?
Thank you for any help...
You can have just one class for ADBannerViewDelegate, and just one instance of ADBanner itself. When the currently active view changes, remove ADBanner from the old view, add it as a subview to the new view.
EDIT:
to clarify, you don't need each view implement the ADBannerViewDelegate. You only should have one class implement it (that class doesn't have to be a view controller for that matter).
You would also need to maintain a somewhere a property that would point to the currently active view (e.g. you can update that property in your Navigation Controller's navigationController:didShowViewController:animated:, or come up with your own protocol for that if your views appear in a more complex way).
Then in your ADBannerViewDelegate you'd just resize the view currently pointed to by that current view property. The actual view doesn't even have to know it has an ad in it ;)
Specifically, I have something like a game, with a menu screen made out of standard components. I want a button to switch to another view controller that the user will interact with for a while, then return to the menu screen. It seems like having the menu controller present the 'game' mode as a modal view controller is the most straightforward solution, but is this the best way to essentially replace the entire view? Is the whole menu (which may later become a deep nav or split controller) kept in memory as long as the modal controller is in front, and is this something I should bother to worry about?
There are really two parts to this question:
Which method of transitioning from one view to the next in an iPad application provides the best experience to the user?
Which method of transitioning from one view to the next is easiest to implement and best handles memory management?
I'm not going to try to address the first part of this question other than to point you to Apple's 'iPad Human Interface Guidelines' which says (among other things):
Reduce Full-Screen Transitions
Closely associate visual transitions with the content that’s changing. Instead of swapping in a whole new screen when some embedded information changes, try to update only the areas of the user interface that need it. As a general rule, prefer transitioning individual views and objects, not the screen. In most cases, flipping the entire screen is not recommended.
When you perform fewer full-screen transitions, your application has greater visual stability, which helps people keep track of where they are in their task. You can use UI elements such as split view and popover to lessen the need for full-screen transitions.
http://developer.apple.com/library/ios/prerelease/#documentation/General/Conceptual/iPadHIG/DesignGuidelines/DesignGuidelines.html
However, in your case I'd have thought a full-screen transition is entirely appropriate (but then I'm not a user experience expert).
In answer to the second part, yes displaying a new view controller modally seems like a good approach to take.
By default both the objects used by the menu view and those used by the modal view will be kept in memory - but the great thing about using UIViewController sub-classes is that they've got some default memory management built-in. If your application receives a memory warning whilst the modal view is being presented in full-screen mode, the menu view controller's views will be removed and it's 'viewDidUnload' method will be called. So in your implementation of this method you should release any objects you don't need and then recreate them as needed in the menu view controller's viewDidLoad method (which will be called again before the menu view is shown).
This is explained in more detail in the UIViewController class reference:
When a low-memory warning occurs, the UIViewController class purges its views if it knows it can reload or recreate them again later. If this happens, it also calls the viewDidUnload method to give your code a chance to relinquish ownership of any objects that are associated with your view hierarchy, including objects loaded with the nib file, objects created in your viewDidLoad method, and objects created lazily at runtime and added to the view hierarchy. Typically, if your view controller contains outlets (properties or raw variables that contain the IBOutlet keyword), you should use the viewDidUnload method to relinquish ownership of those outlets or any other view-related data that you no longer need.
http://developer.apple.com/library/ios/#documentation/uikit/reference/UIViewController_Class/Reference/Reference.html
Sample:
I've created a minimal set of files that highlight the issue here: http://uploads.omega.org.uk/Foo3.zip
If viewDidLoad/viewInitWithNibName are called, a message box is displayed. The message box is not displayed, therefore, the methods are not being called.
Details:
I have an application that is attempting to use a UITabBarController to switch between multiple views.
The views are linked up to the UITabBarController using interface builder (select the tab page, open Attributes (Option-1), and fill in the NIB Name field), and so are displayed "automatically" with no extra code-behind to make them appear.
Is it intended behaviour that views loaded like this do not have their viewDidLoad method executed? If not, how am I doing it wrong, and what do I need to change.
If it is intended behaviour, I can think of a few work-arounds, but any suggestions are appreciated:
Scrap the UITabBarController and implement the view switching myself (using initWithNibName and add/insert/push/Subview).
Call each of the children's viewDidLoad method manually in the UITabBarController's own viewDidLoad method.
Thank you in advance for any help you can offer.
OK, I've managed to solve this.
Linking the NIB to the TabBarController isn't enough - you also need to link the code beind file, it is not implicitly linked by the NIB even if you set the file owner correctly.
Open IB, and select the relevent page. Click in the middle to select the view controller. Enter the NIB name of the sub view, then go to the last page (option 4). In 'class identity', enter the name of the code-behind file for the sub-view NIB.
Everything will now work nicely.
I've uploaded a correct version of the sample code: http://uploads.omega.org.uk/Foo3-Correct.zip
You're not instantiating ImportedView anywhere in your project, so it's not calling either initXXX or viewDidAnything. If you put your alert code in -[FirstViewController viewDidLoad], it'll fire as expected.