Is it possible to make an advanced UI, such as the twitter app for iPad, using storyboards? I am new to them and all the reading I have done on storyboards make them seem rather simplistic. Can you do most everything you could with nibs with a storyboard?
A storyboard isn't much different from a group of .xibs. The advantage they provide is that you can see the relationship between the different view controllers. So sure -- anything you can do with a .xib you can also do with a storyboard.
Related
What are the advantages of using segues vs managing view controllers and subviews like we did pre-iOS 5.
Pre iOS 5 I might:
Build XIB files for my various Views then do something like [myVC.view addSubView:newVC.view];
vs Segues
You get the advantage of working with storyboards and the functionality of passing data between view controllers (which was easily accomplished pre iOS 5 in multiple ways).
So to me it looks like the only advantage of using segues is that you can use storyboards and pass data between VCs.
Is that right? Or are there other advantages?
one of the down sides that can be added to Kunai Balani's answer is that it makes working with a team with version control more difficult if many people are working on the same storyboard. my svn gets really confused when 2 people make an edit on the storyboard.
if you are not working with a team then you can disregard this disadvantage
There are several advantages :
1) Communication. Storyboard (and thus use of segues) is makes it easy to understand the flow of your application. This gives other developers an ease of understanding of the structure of view controllers without looking through any code or debugging.
2) You save time by using segues. Just imagine doing push and pop everywhere all around your application. If you need to change transition (lets say modal transition animation style) for all your view-controllers you have to go and search for each and every view controller then modify it. With storyboard all of them are at one place. It's easy to modify their transition style with just modifying one attribute.
3) Ease of debugging. Lets say your application crashed during a push in navigation controllers. With story board you get the identifier for your segue which caused this. No need to follow stack trace across your UINavigation Controller.
I've been tasked with creating an app, but I have zero experience with iOS development. I have general programming knowledge, particularly with Java, JavaScript and PHP (I'm more a web developer than a programmer). I have dabbled with C, Xcode and various other languages and IDEs in the past, but I remember very little.
I've been following Apple's Developer Library tutorials, and I'm at around the Language stage, where I'm come to a grinding halt. While I slowly progress through learning the basics of Objective-C, there are a few things I'm very confused about regarding development in Xcode that various tutorials seem to completely skip over or just imply that you know what to do, or some just stop right before the part I'm having trouble with.
1) Storyboard - yes or no?
Is it better to start with an empty application and work with the
files or create a template (in my case a tabbed application) and work
with the storyboard?
2) If using a storyboard, do I still need to have a .xib?
Are the User Interfaces more like global templates that the view controllers implement?
If I wanted a different layout for each tab of my app, would I create a .xib for each tab, or just edit the controllers in the storyboard? Am I correct in understanding that the storyboard can have multiple instances/relationships of the same controller, in which case having .xib's would make more sense?
3) If using storyboard, where do the implementation and source files come from?
This is probably a stupid question. I know you can just add them via File -> New, but I don't know how to associate those files with a view controller. Is there a way to have the files created automatically when adding a controller into the storyboard?
Since you're just starting, you should use Storyboards because it lets you link different view controllers(pages on your app, essentially) visually and outside of code. For example, you can link your UITabbedViewController (the part that manages the content of the other tabs) to the pages that represent the content of the different tabs. Basically, your storyboard would have the tabbed view controller in a parent-child relationship with the sub-controllers. You would have one instance of each -- the tabbed view controller, managing an instance of each of the tabs' content and controller. This is the same regardless of Storyboard or xib, but you can connect this more easily in the storyboard.
You can still use a .xib(nib) file for stuff like Custom Table cells or in cases where you want to separate a view element or controller from a storyboard where there are other constraints.
In the storyboard, you subclass the controller class on the sidebar in the visual editor by entering your subclass of say UITabbedViewController in 'Custom Class'. In your file associated with 'MyTabbedController', you implement your stuff.
Great book:
http://www.barnesandnoble.com/w/beginning-ios-6-development-david-mark/1113216077?ean=9781430245124
Good luck!
Storyboards can be appropriate for small applications, where you have ten or twenty screens. When your app contains more than that, you will just get lost in storyboard schema, where all your view controllers will visually look the same.
I prefer not to use storyboard, just separate xib files for each controller.
If you use storyboard, you can create xib files for other parts of application that is not related to SB, and view controllers that is involved in SB has their interface stored in SB, meaning you will have to design them in there, in this one huge storyboard file. I find this very uncomfortable.
As you are new to IB, I would like recommend you to take a look at Auto layout. There is no magic anymore :)
To answer on a point-by-point basis:
I typically use the "Single View" template. It provides everything you need for your first view and can take it from there. It's a clean slate but it already has that first view which will be exactly the same code in 99% of the applications you make.
No, the storyboard file is your xib. You used to have to make a new xib for each new layout, but then Apple introduced storyboards. A storyboard is basically all of your xib's in one file. Rather than make a new xib, drag a new ViewController object onto the document. You typically only have 1 storyboard file or 2 if you want to support both iPhone and iPad layouts.
I don't think you can have it create your source files automatically, but its fairly easy to connect them manually.
Select the ViewController that you want to connect to your source files by clicking on that black bar beneath it. Then go to the bar on the side and go to this panel:
There you enter the name of your custom ViewController subclass where I have put "MyViewController". Hope that helps!
I have an application with a navigation controller and a few views, but now I need to add master-detail view mechanism to one of my view controllers. I am using storyboards. How can I implememt such functionality without reinventing the wheel? I've searched the web but all I've found was examples with creating apps as master-detail apps from scratch, I haven't found an example of adding it to an already existing app.
Thank you,
Can.
I want to create an iPhone (not iPad) app with a split screen view that shows two view controllers on the same screen, one on the left and one on the right of the screen (landscape only).
Is there a way to make UISplitViewController work for iPhone, or is there an open source library i can use to achieve this look?
As said, you can not use a split view controller. However, I dont think you need it anyway. Its a little cumbersome and restrictive.
You can achieve the effect of the split view controller easily using subviews. (Try to avoid using multiple view controllers as this is generally bad practice).
Create two custom views and ad them as sub views to the main view. Look at their auto resizing properties. Try to use interface builder. Show / hide you side view when the user rotates.
UISplitViewControllers aren't that useful - you can mimic their effectes easily.
There is no way you can achieve this using the UISplitViewController class. If you take a look at the Apple reference documents it clearly states that the UISplitViewController is an iPad-specific viewcontroller.
Note this point
If you are developing a universal application, though, be sure not to create and use these controllers when your application is running on an iPhone or iPod touch.
I am new to iPhone development... trying to figure out the best design for 70+ views. Do I have 1 Navcontroller and 70 views or what?
I originally thought I would have about 10 XIBs each with their own NavController and views, but I haven't found anyone that seems to think this is correct or not.
I think I understand the iPhone does not handle the memory dealloc by itself so I am assuming that will be a bit choice on how to make this work.
If you are going to implement 70+ views means you have to use both the navigation controller as well as tabbar controller. Then only the user can easily access all the views. If you are using 1 navigation controller and 70+ views means it is very difficult for the user to view all the views.
If you would like to design your views graphically using Interface Builder (built into Xcode4 or separate app for Xcode 3 and prior), I would just have a UINavigationController in your first xib (one with the UIWindow). You can then design each of your other views separately, in their own xib file and load them and push them onto the navigation stack as necessary.
Your understanding is correct; iOS does not support automatic garbage collection, although there is a pretty established paradigm of how to allocate and release memory as needed to avoid memory leaks. 70 views in an iPhone app is quite a bit, but it should be fine in theory, although I can see there being issues if the user has to drill down quite a ways in the hierarchy and each successive view eating up more memory.