I have a ViewController (with navigation) that needs to show 7 different content layouts. I want to keep the same background and nav, the only thing that needs to change is the central UIView.
If I have 7 different UIViews on the same xib/storyboard, can I hide the ones I'm not using or will that ding performance?
Using segues won't work either because they make a mess out of my custom navigation and animations.
Is there a better way to accomplish what I am trying to do? Thanks for suggestions
solution
My design is too custom for using view controller containment so I decided to mimic the idea with a custom UIViewController and two UIViews. It's not too bad and it works rather quickly.
You should look into using view controller containment, then you can load your views from separate nib files and still provide your custom navigation and animations from your container view controller.
Note: This is only really supported from iOS 5.
Generally, it's a good idea to unload views that aren't visible, however, if your views aren't using too much memory (and/or cpu time) hiding them when they're not in use should work fine.
View controller containment is probably what you should be doing if each view has its own unique functionality (i.e. view 1 is a map, view 2 shows some about text, view 3 is an image gallery). UITabBar might be useful, but it depends on your app.
The performance hit would depend on your views' contents. If you haven't done so already, invest some time into learning how to use Instruments (apple's diagnostic tool). Watching the video titled "Optimizing App Performance with Instruments" in the developer resources would be a good start.
My design is too custom for using view controller containment so I decided to mimic the idea with a custom UIViewController and two UIViews. It's not too bad and it works rather quickly.
Related
Is it a good practise to creates views in xcode and hide them and when required show them?
I am asking that because I prefer to create views visually and not in code.
If the view is to complex(a lot of subviews) should I create a new view controller to it?
I know there isn't a specify question here but I really need a clarification on this matter.
Regards
One of my first iOS applications had a tab bar and views that the user could switch between. Originally it was done by hiding and showing the right views depending on what the user pressed on the tab bar. This ended up being a complex disaster.
I then rewrote the app so that each tab bar view had its own UIViewController with its own set of views. That turned out to be so much easier to manage. (I also changed from using Interface Builder to straight code for creating the views, but that's beside the point and you can continue to use IB if you want.)
As for me, I prefer folowing practice:
Usually, a use storyboards,where views are placed, but if a view is complex, I create a separate XIB file, arrange all subviews there, and then in storyboard drag an UIView subclass and connect my XIB view with it.It helps to avoid mess in storyboard.
As for hiding views, I also don't recommend such practice as it can become very complex to understand your code and all those views are allocated when XIB is loaded, so the mobile developing rule "do as lazy as u can" is not met. We should try to spend as less memory as it's possible.
UIView is the best way to create iOS app, esp. if you want to reuse the code.
For example if you have same view to present in iPad n iPhone then using UIView can result in lots of similar code in View-controller
In another case if your view might need to have multiple table view it can be quite complex to handle each with delegates in ViewController. But separate view will solve this problem.
I have made my 1st open source code after learning how to use View
https://github.com/bishalg/BGRadioList
which I had learned from
http://www.raywenderlich.com/1768/uiview-tutorial-for-ios-how-to-make-a-custom-uiview-in-ios-5-a-5-star-rating-view
About the hiding view - I have used lots of hide and show view codes in my apps but believe me at one point it will become complex and unmanageable if you have lots of views.
I'm writing an app that has two sections like this:
The idea is that on the top half I'm creating a request, and on the bottom I'm displaying the results. As my UIViewController subclass grows and grows I thought it might be a good idea to split that into two UIViewControllers. (So what I'm trying to do is something like a UISplitViewController).
Although I know it's possible programmatically I'd like to put both UIViewControllers in the screen from the Interface Builder so I can manage autolayouts and design there. Dragging and dropping doesn't work there.
Is that possible? And more important - is that a good design or should I stick to the rule "One view controller for one screen"?
You can use a custom container view controller to achieve what you want. See:
WWDC 2011 #102 on UIViewController Containment (Apple developer ID required)
the containment section of the View Controller Programming Guide
the containment section of the UIViewController Reference document
In short, since iOS 5, you no longer have to have a single view controller. Just make sure you call the necessary containment related calls. And iOS 6 makes it easier to design the storyboards for custom containers with the "container view" object.
Apple have stated (WWDC 2012, Evolution of View Controllers, I think) that the "screenful" is no longer appropriate. A view controller should manage a self-contained chunk of functionality.
As of iOS5 you can compose an interface of multiple view controllers using view controller containment (addChildViewController: and so forth). As of iOS6 you can do this in interface builder using containers and containment segues.
You will of course need a view controller to hold your two child view controllers - this will hold a screenful of content, and will usually perform any coordination between the two children.
I am a beginner at best when it comes to xcode, iOS, and objective-c. I have been working on a project that has had me looking up information a lot. I have already been learning a lot, but I realized lately that I have forming some bad practices.
I have used Storyboard to lay out the abstract view of the app. The first thing I noticed I was doing dealt with popover views for iPad. I did not know how to dismiss them via button press, so I was creating a new modal segue from the popover button back to the main view.
I realized that this was creating a new view and placing it over my existing view. This would start to chain until the program eventually crashed. Last night I learned the importance of delegates and how they can help me gracefully dismiss the popover view.
Based on the documentation I have read for modal views, it appears that I need to be dismissing those types of views as well.
My question regards to proper practice when building an app. What if I have a ViewController that has 10 buttons, each of which will spawn a popover that is similar yet features slightly different content. Is it OK to create 10 new views in storyboard and drag and drop the UI elements on there? This means that the main view controller is going to have 10 delegates, one for each.
OR would it be best to create one general view, load the content dynamically, and only worry about one delegate in the presenting view controller?
EDIT: As far as the differences between them, they each have a list of labels (questions) and a UISegmentedControl to match the label. This will allow the user to fill out a survey. There are currently 10 views because I have 10 sets of questions that I feel deserve different views. At the bottom of each view there are 4 buttons. Every view must include these 4 buttons.
It's "ok" but not practical to have those 10+ delegates. If these ViewControllers only differ slightly - have you considered creating a "base" view controller and then adding/updating some of the differences programmatically depending on the content? I think it all depends on what you want to display and how much these differ. I would definitely not recommend 10+ delegates all delegating back to the same controller.
Basically, I'm saying yes to your "OR" question.
For an iPad app, I realize that having a UISplitViewController allows you to embed childViewControllers inside a parentViewController and the childViewControllers are able to control each of the left and right subviews. However, I was wondering if there is any intrinsic advantage to doing that versus just using a UIViewController that acts as the ViewController for the left and right subviews?
The main advantage to writing your own instead of using UISplitViewController is that you can customize it however you need. The built-in UISplitViewController can't be used as a child view controller, which may be a requirement depending on your app.
Keep in mind that if you don't need anything special, you should stick with what Apple has already provided. The less code you have to maintain, the better. Having said that, it actually doesn't take that much code to roll your own. My custom implementation is about 250 lines and features all the same delegate methods and even the presentation gestures (swipe right to show, swipe left/tap detail to hide).
However, I was wondering if there is any intrinsic advantage to doing that versus just using a UIViewController that acts as the ViewController for the left and right subviews?
You won't have to rewrite all the boilerplate code.
It's probably better designed and has less bugs than a quick hack whipped up manually.
The biggest advantage is going to be relying on a framework that has already been written and will probably be improved on in the future.
The split view controller went through a big upgrade between iOS5 and iOS6 with how the navigation side was displayed while the device is in portrait and if you used their framework its an automatic upgrade.
With that said if you wanted some custom look or functionality then it can be worth writing your own although breaking common behavior can be confusing to users depending on what you do.
I would like to develop an application for iPad, using a layout like that shown in this link:
https://skitch.com/sparkoletto/g13ck/ipad-views-layout
As you can see in the image on one page I would like to insert a UITableView (B), two UIScrollView (one vertical (D) and one horizontal (A)) and a simple UIView (C).
What is the best way to develop such interfaces?
It 'best to use a single ViewController that manages all the views that I need, or create a ViewController for each view, and then combine them all together in another UIViewController?
Thanks
I disagree with #TomSwift. When these things get complicated, it's very helpful to break them out into their own view controllers. You'll create a view controller of the correct type and then [self.view addSubview:vc.view] at some point.
The problem with making one complicated view controller is that it becomes delegate and datasource for too many things that are internal details of individual subviews. Your delegate methods now need to check which tableview is talking to them, for instance.
Splitting them up also makes it much easier to manage rotation, particularly if you want a different set of views displayed in each orientation. This is good for memory management as well, since the VCs can automatically unload the views you aren't using anymore.
Breaking things up too small is of course also a problem. There is a cost to having separate view controllers, especially if they interact with each other. Having a good feel for when is the right time is the mark of an experienced developer. But for the view you showed, I would almost certainly break it up. Your situation looks very much like UISplitViewController.
Likely a single view controller, IMO, unless you plan to reuse some of these panes in other places. In which case you could implement a "container view controller" with a single view to handle the layout of the child view controllers.
Typically view controllers manage "full screen" (or nearly full screen) views. The exceptions are fairly rare - UISplitViewController is one.