I use programmatic way to create design parts and I won't use storyboard for design. But at some design I feel it will be easy with storyboard, is it possible to do design in both storyboard and programmatic in one project simultaneously. If so please tell me the process.
You can. Everything you can do in the designer you can do in code (though not vice versa).
You can instantiate the storyboard using the "UIStoryboard FromName" methods. From the storyboard object you can then use "InstantiateInitialViewController" to get the initial view controller of the storyboard. From this point on the storyboard segues will perform as expected.
If you want to jump to a certain part of the storyboard, you simply use the other method on UIStoryboard which takes an Identifier.vc.
Once you are done with your storyboard view controllers you can then get rid of it programmatically as expected (use pop/dismiss depending on how it was presented).
It is similar to the technique used for splitting large storyboards into smaller ones. If you google "splitting large storyboards" you will be able to find a lot of articles which will help you.
Absolutely. Most (if not all) of the objects you see in storyboard are part of the UIKit, which you'll see is imported at the top of every View Controller Xcode makes for you. You can add UI Objects, like a UILabel, to a View using addSubview, for instance.
Technically, you don't need to use the Interface Builder at all (and there was a time when you couldn't), it just makes things incredibly faster to produce.
Related
I have seen many examples where a view-controller is initialized using its storyboard-ID in Main.storyboard:
UIPageViewController *myPageViewController = [storyboard instantiateViewControllerWithIdentifier:#"PageViewControllerID"];
Are there any particular advantages of doing it like this instead of just doing the old alloc-init?
If you choose to use a storyboard then you either request the initial view controller (or allow the system to do it), request the view controller by identifier or trigger a segue. The advantage of requesting by identifier is that you can do whatever you want with the controller. Segues are much more powerful than they used to be and basically everything can now be done directly, but there could be some conditional logic you'd rather run (which could trigger a number of segues...).
You don't need to use a storyboard though. If you want you can create everything in code or you can continue to use NIB files. Storyboards help when you're using auto-layout and want to take advantage of the layout guides. 99% of the time using a storyboard will save you time over using just code and perhaps 50% of the time over using a NIB.
New to iOS, just wondering if someone could explain the point of the storyboard.
If i create a view controller and programmatically add to it, what do i need a storyboard for?
Is it only for custom views? custom tables? etc
Thanks.
Long story short, my understanding of storyboard purpose is as follows:
Less code -> less bugs
Visual representation of UI layout simplifies UI creation (views hierarchy, autolayout constraints)
Extremely simple way to set objects' properties (e.g. delegates, gesture recognizers) just by control-drag
From Apple's Document:
Storyboards
Storyboards are the recommended way to design your app’s user interface. Storyboards let you design your entire user interface in one place so that you can see all of your views and view controllers and understand how they work together. An important part of storyboards is the ability to define segues, which are transitions from one view controller to another. These transitions allow you to capture the flow of your user interface in addition to the content. You can define these transitions visually, in Xcode, or initiate them programmatically.
You can use a single storyboard file to store all of your app’s view
controllers and views, or you can use multiple view storyboards to
organize portions of your interface. At build time, Xcode takes the
contents of the storyboard file and divides it into discrete pieces
that can be loaded individually for better performance. Your app never
needs to manipulate these pieces directly. The UIKit framework
provides convenience classes for accessing the contents of a
storyboard from your code.
For more information about using storyboards to design your interface,
see Xcode Overview . For information about how to access storyboards
from your code, see the UIStoryboard Class Reference .
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.
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 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.