I have a offlineMapVC and a onlineMapVC for my application to support both online maps (using MapKit and Google Maps) and offline maps (using Route-Me).
I made my own mapVC to manage the switching of these mapVCs and be able to use the view controller as one separate view controller. Well I've done this by making the offlineMapVC and the onlineMapVC instance variables of the new mapVC witch I now use all over my application.
First off all things seem to work but. However while using this approach for a longer time I ran into some problems due my using of View Controllers in a hierarchy. I read this is the wrong way to go. What is the right way to manage the switching between two view controllers? My question seems fairly simple but I couldn't find a decent solution.
I put view controllers in view controllers, myself, and I have seen much better programmers than me doing the same thing. (See Rob Napier "iOS 5 Programming - Pushing the Limits". He mentions it frequently.) As long as you don't have more than one view controller directly controlling the same views and subviews, you should be okay with it.
Since Jonah Williams wrote that article, I think iOS 5 formalized the use of view controller hierarchy with custom content view controllers. You might consider your mapVC to be a custom content view controller and implement onlineMapVC and offlineMapVC as child view controllers.
(Apple documentation links tend to change frequenctly, so Google "Custom Content View Controller" for the documentation.)
If you can give some more context to what you mean by "switching between two view controllers" that would help answer your question. Generally, I have more than one view controller active at the same time. I don't switch between them. (I use navigation and tab bar controllers in the same applicaiton, but I assume you are aware of how those work and you're asking a different question. It's just not clear what the detials are in your case.)
Related
The app I am currently working on requires that I do not use ANY storyboards. Therefore I need to do everything programmatically. One thing I seem to be struggling with is switching between two UIViewControllers.
The issue is that every time I call the self.present() method; it creates a brand new instance of the class I would like to show. So when I go into Xcode's visual debugger, I see over 15 different views that are all stacked and are merely instantiations of one another. Ex: View1, View2, View1, View2, View1, View2, View1... This constant repetition of the views is significantly hurting the performance of my app. So my question:
Is there a way that I can switch between my two UIViewControllers without constantly creating a new instance of each one?
Again, I am doing all of this with ALL storyboards DELETED. So the solution I necessary needs to be implemented using ONLY code.
I think you should create main ViewController.
if you keep your two instance view controller, create two controller in mainViewController. Then keep that in main viewController.
And push view controller you want to present in navigation of main view controller
if you want to change second view controller pop navigation controller and push another, or just push other controller.
if you want keep your instance view controller i think it's best option for you
I think that it is really important to realize the fact that the view controller will show up multiple times in the debugger because that is something that can throw off the performance of the app. I really like the way you mention that in your comment. This is one of the main differences that can outstand you from another programmer in the same field. One of the most easiest and simple ways to fix this problem would be using the self.dismiss() method. Another way to dismiss this view controller would be to use a navigation controller to fix this problem. A navigation controller will push the main view controller out of the way and it will not create multiple instances of it. This will be the most efficient as it doesn't require a lot of code and a mere initialization of the UINavigationController class implemented in the UIKit. This is one of the most important tools and resources that you must make use of while coding in xcode and developing your skills in the swift ios field. Since this problem is not one of the most common to find on the internet, it is very beneficial for you to post it on this forum page and will really be helpful for some other programmers unaware of such methods and ways to code. One of the questions that I have for you is the fact that you don't want to use storyboards. Why don't you want to use storyboards and only make it proGrAMitcally? This is one of the very questions that manages to astound me. The storyboard is an implementation that makes it very easy for xcode and swift users to work around the tedious work that has to be done while working in the coding aspect. It only takes a few lines of code and you can get a seGu done very easily. The switch is very easily done and you can find this method on some youtube channels. For this type of work, I recommend VigneshSriniswami Patel and ShaniLakshmiVishnuJiSwami, these content creators will help guide you to becoming an xcode master.
Hope I helped!
I'm interested in building a slide out sidebar for a view controller, and I've done a lot of reading on how to implement it. This tutorial, as well as virtually all the others go over creating child view controllers, which seems like a great way to go about it. However, it's always done in code for examples.
This post goes over how to create container view controllers in the Storyboard, but it left me confused how exactly container views work in the Storyboard, and there seems to be little in the way of explanations online.
Finally, this post went over how to implement a slide out menu with container view controllers and a Storyboard. Sounds perfect right? Well, in reading it I was confused how the author seems to use multiple container views. I thought there was supposed to be one that encompassed all of the subviewcontrollers. Is it implemented correctly in that post?
Basically, I'd love an explanation on how to implement multiple view controllers using container view controllers via the Storyboard. It's my understanding from the first tutorial that you have the view controller that contains everything, and then add view controllers to that container and then they all work together via delegates. Achieving this in Storyboards is leaving me scratching my head.
Adding a container basically adds a child view controller and its view to the main controller. I think you are not clear on two things here. First, each container can be linked to only 1 controller/view pair. So, if you want to have more than one child controllers, you must have more than one containers. Secondly, communication between parent and child controllers is handled by 'embed segues', not by delegates.
I am exploring the design options for an iPAD application with multiple views on the different part of the main screen. I am going to have different ViewController for each of the view. UI is quite different from what any of the available view controllers (UISplitViewController, UINavigationController etc.) provide. I have been reading about the container extension api of UIViewController (especially addChildViewController):
http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/Reference/UIViewController_Class/Reference/Reference.html
(Look for "Implementing a Container View Controller")
However, it seems to me that this functionality is mainly designed for applications with UI that transition from one view to another (transitionFromViewController...). In my case, all of the views are visible at the same time. However, they do interact with each other. So my questions:
Am I missing something w.r.t. container extension of View Controller? I will still probably end up using this just to keep the list of child view controllers but don't see much value.
Can you recommend any other api/pattern that I should be using?
Thank you.
You can easy access to childViewController.
self.childViewControllers will return an array with all childs.
I asked similar question couple days ago: Maybe this will help you:
Get container VC instead of view
Take a look at http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/CreatingCustomContainerViewControllers/CreatingCustomContainerViewControllers.html.
Add your various view controllers to self.childViewControllers and add the views of the child controllers as subviews of self.view.
I'm just getting back into iOS development after a year or so away and am looking for a way to have a single view above or below a UITabViewController view. The idea is to have one ad view that is used throughout the app instead of one on each tab. The constant reinitializing of the ad view seems like it would be a lot of overhead so having one persist throughout would seem to be more effective.
I've searched for this but not found much of anything so even a useful link would be appreciated.
Thanks in advance,
Jason
I see several approaches here:
Since you are setting up your view hierarchy in your application's delegate, I'd suggest creating a separate UIViewController and managing it from your app delegate. That way you can show/hide it in the main UIWindow, without having to do much work.
You can subclass UITabBarController and show the ad in the visible view controller. This is more work, but your app architecture is arguably cleaner, because your app delegate doesn't get cluttered with ad-related code.
Another option is to look into a UIViewController category, where you can manage add related code. Not necessarily the cleanest, but it keeps the ads out of both your app delegate, and your tab bar controller. (You'd add the ad view as a category property via runtime level calls and associate objects, but that gets messy.)
I'd probably go with the first approach if it were me, but I could argue for either of the other two approaches, since an ad view doesn't really necessitate it's own view controller.
How about create a parent view controller and each view controller inherits from that parent view controller? Parent view controller has a ad view or table view, so every child view controller will has those two view as well.
Okay, after spending some time trying to create and manage a customer view controller for this I stumbled on the Container View Controller capability Apple added in iOS 5. I have no need to support iOS 4 or earlier so this works good for me. There's a good description of it here (unfortunately the author never wrote part 2 with a tutorial):
Container View Controller description
And a decent tutorial is available here:
Container View Controller tutorial
Between the two of these I was able to create a good setup with an AdViewController and BodyViewController (TabBarController) contained in a Container View Controller. This gives me all the capabilities I need (at least so far).
I've been working on an iPad application that has about 15 view controllers. Some of the view controllers are full screen, others are embedded inside the other view controllers (think split view controller).
On the iPhone navigation is very straight forward. Even if you have a ton of view controllers, you are using one of Apple's root view controllers (tab or navigation). The navigation is handled by the root view controllers and you are pretty much free to focus on your views.
On the ipad the split view and tab view controllers are not always useful, and for the app I'm working on they do not cut it. I have created separate navigation controller objects to handle hiding/show view controllers based on notifications that get posted when the user performs actions.
Anyone else have experience with solving the navigation problem on the iPad?
have you checked out MGSplitViewController by Matt Gemmell?
http://mattgemmell.com/2010/08/03/mgsplitviewcontroller-updated
I'm not claiming it'll solve all your navigation problems, but it's an interesting idea and may help you in finding more/better ways of handling view controllers.
With iOS 5 Apple has added the concept of Container View Controllers. This makes adding and removing children easy, allowing their methods for rotation/appear/disappear to be called automagically. Cool stuff!
Also, be careful using multiple view controllers for views which don't fill the full screen. Apple's documentation explicitly states that you shouldn't use view controllers for partial-screen views:
Note: You should not use view controllers to manage views that fill only a part of their window—that is, only part of the area defined by the application content rectangle. If you want to have an interface composed of several smaller views, embed them all in a single root view and manage that view with your view controller.
http://developer.apple.com/library/ios/#documentation/uikit/reference/UIViewController_Class/Reference/Reference.html
Although some things might work when you have multiple view controllers managing different sub-views, other things won't work. For example, only one of your view controllers will be informed when the device is rotated. Likewise, not all your view controllers will be sent 'viewWillAppear' 'viewDidUnload' etc messages that you might expect.