With the introduction of storyboard, I wouldn't select to create a .xib/.nib when I create a subclass of UIViewController, because I can just drag out a viewcontroller in interface builder and assign it to the new class.
So, with storyboard, when would i need to use the .xib/.nib file?
Thank you.
Storyboards don't completely remove the need for NIB files. One common example is when creating subviews to go inside a UIScrollView. You can't create the subviews separately in a storyboard; instead you have to create separate NIB(s) for the subviews and attach them to the scroll view programatically.
In fact, on almost any occasion where you have a need for subviews which change at runtime you'll want to use separate NIBs.
Storyboards are great for certain kinds of apps, but for anything even remotely complicated the old way works very well still. An additional benefit is that they co-exist nicely. You can put placeholder views in your storyboard and fill them programatically with NIB-defined views later on.
I guess, storyboard contains the .xib/.nib files for all your views. It present relationships between them and helps you to avoid confusion if you have a LOT of views. Also it saves your time and nerves when writing code.
I have tried out storyboarding lately and I do have mixed feelings about its use:
Pro's
Convenience: You might have to write much less code. So you can for example show a static view without having to write any code.
Overview: You can quickly see how the ViewControllers relate to each other
Efficiency: For the simple use cases I find the Storyboarding much more efficient than "the old way".
Example 1: Editor > Embed In > Navigation Controller and voilà, no more instantiating and configuring is required.
Example 2: You can make "Prototype Cells" for TableView which speeds up the creation of static table views dramatically. AFAIK this is not possible with nib files
It's cool :-)
Con's
I find that the re-usability somehow suffers with storyboards. Although I can segue to a given ViewController from multiple points, it is still limited since in one case I might use the VC as a Popover and in another as a Master-ViewController.
Assuming that you are working in a big team and different people are changing different parts of your application, having one monolithic storyboard which you then have to merge might pose a big problem team-work-wise.
I really would like to have some mechanism to include or reference existing nib files into the storyboard which is currently not possible.
So considering these points I still find storyboarding very appealing but it makes sense to combine both approaches which is not really a big deal. Additionally, this technology it is still quite new so it might improve in the (near) future.
If you use storyboards, you generally won't need to create separate .xib files. You can still use a .xib file if you want to -- it might be useful e.g. if you have a particularly complex view that you'd like to configure by itself. Most of the time, though, there won't be a need to do that.
Related
The output of this tableview not appearing correctly.what is the reason to come like that
So the tableView that you just drag into a view will have default properties associated with it. When you run it on a phone/sim it doesn't actually have the 'Table View' heading (that's just there to make it easier to design the storyboard), it'll have a white background with no rows and will look like there's nothing on the screen. Furthermore it may not even be at the location you placed it at depending on how the constraints default when rendering the scene.
It seems like you have a little to learn about how this works. When creating a new storyboard, generally speaking you associate a ViewController class to it. Assuming you have dynamic data to display on the table, you connect references to the tableView to the class, then you need to assign a delegate to the table and then implement the protocols. Then if you have custom cells, it adds a little more to do. Theres several great tutorials from Apple itself on how to do all this in swift.
If you just want to see how the table would look; in the storyboard itself you can create prototype cells in the table and design it out that way.
Either way, make sure you read about constraints and how to make it look right when rendering on a phone. Just dragging things onto the story board does not mean that when you finally run it, it will look exactly as you designed it. You need to specify how components align relative to each other, which is essentially what constraints do.
I am using xib-s for my UITableViewCells on iPhone. Now I need to convert my app to universal app. Do I have to create new xib-s (looking exactly the same way) for the iPad version? My current problem is that I am using grouped UITableViews. As the left and right margins on both devices differ, some of the controls on iPad are partly "out of the cells".
In case I need new xib-s (looking exactly the same way), do I need separate properties for the controls in the ViewController? For example, for a label named myLabel, do I need a second property myLabelIpad or is there a better way to handle that?
Cheers
My suggestion is to create new xib. But if there are small changes , then you can maintain one xib. However it depends on how different your iPhone / iPad versions are. For example, if the iPad version is just a bigger version of the iPhone one with a few extra buttons, etc, it's easier to use one UIView and just set the frames of the subviews appropriately.
First understand what you are up to. How do you want your iPad app to look like? How does it navigate. Ceratinly you want to leverage from the lager screen of the ipad. When ever you do that and the auto-resizing mechanism is not sufficient (which it rarely is) then go for a separated xib file.
Second - for each XIB which hosts the same number and types of UIView and UIConrol subclasses, you should be able to use the same view controller for two separate XIBs. Just link all conrols within both XIB to the related IBOutlet properties and IBAction methods alike.
However, when you take leveraging from iPad capabilites seriously then you are like to end up with a different set of view controllers. That is when you can combine the controls of several iPad views wihin one single iPad view and similar cases.
Nevertheless, think of using popups. The content of a popup could nicely correlate to what is a full screen on the iPhone. In that case you can use the same view controller again within that popup container.
Does this sort of answer your question? If not, then please be more specific.
Actually you can retain the same Table cell xib files. You just have to get the Auto resizing masks of the cell and its subviews right.
I have made a pretty little UI on storyboard but I'm quite new to XCode and Objective C (coming over from Java) and I'm having some trouble adding functionality. I know that I should make a subclass of UITableViewController (storeTableViewController) and set the class of the storyboard controller to that. The problem is that when I do that all my hard work in the storyboard is erased, and I can see where the code is conflicting with the showing of my UI (for instance, the tableView:numberOfRowsInSection returns 0 always), and I think that with enough time and patience I could program the UI, but is there any way that I can use all this work that I've done on the storyboard and still be able to add functionality? I want to set a text box at the top to be the first responder as well as be able to change an image and labels on command programmatically.
You should probably use IBOutlets. Connect the StoryBoard UI Object to IBOutlets and you can modify the properties of the UI objects from the code
You can declare IBOutlet link this
IBOutlet type variableName
Check this tutorial video which will help you a lot.
Video Link
I use the storyboard as a canvas. I plug in the outlets that I want and all the little details and then I go around and built the classes. That being said, you need to declare a urtext field outlet (depending to what you want it to do) then add the delegates necessary and allow it to perform on selector. Then you can declare the function. Linking it in storyboard is easy by control and drag.as far the image you can use an uiimage and declare its function and how it changes depending to what the changes are the code varies. My suggestion is to take screen shot of your storyboard and post it with your question so I/ we can help you with the code. But as far as your question goes I hope this answer satisfies you. Happy coding.:)
I have 1 main Master screen (MVC) and 4 other screens that share ~80% of graphic objects. They differ in some label texts, a button with action and some other 20% graphics. Thinking in terms of clean object oriented code architecture, I have started to implement those screens as separate UIViewControllers. But I didn't like having pointers to those 4 MVCs and a duplication of some methods, so I rewrited the code into one UIViewController. Most of graphic objects are UIImageViews that I put on with Interface Builder. So, now the xib file of that "unified" UIViewController is a little bit bloated with overlapping objects from those 4 screens. I also need to have those methods like showScreen1, hideScreen2, showScreen2, hideScreen2, and other methods, so I'm not very happy with this architecture too. I understand that I should not mix those 4 MVCs (screens) and both the code, and xib files would be cleaner but I'm also thing about performance, saving memory loads and etc. What would be your opinions on that? How much memory resources takes the loading of separate UIViewController? Maybe the amount of saved memory is not worth when compared to code cleanness? Again, having 4 separate MVC's would force me to have 4 pointers both to my Master MVCs and 4 pointers to those separate MVCs from my Master MVC, because I need to communicate and navigate between those screens. Another option would to use notifications instead of pointers but it doesn't change the amount of required relations. So please share your thoughts and insights :)
For user interface controls that share the same design perhaps you could use categories, this is what I'm doing in a project. I've added a category to UINavigationBar to show a texture on the bar, added a category to UIBarButtonItem / UIButton for a back & cancel button and since my ViewControllers all share the same background image I've created a UIViewController subclass that contains the default background image - every view controller used in my app inherits from this default view controller.
I would stick with 1 view controller per screen.
Apple doesn't recommend creating giant nibs, this is especially visible in the WWDC 2011 video on storyboarding (check this video out if you're a registered Apple developer). Giant nibs are bad in terms of performance, it takes a lot of time to load all objects and all the objects from the nib stay in memory all the time, even if the objects are on a screen that's currently not being displayed. It's a better approach to have a separate nib per screen.
I need to represent a linear process (think wizard) in an iPad app.
In principle I could use a UINavigationController and just keep pushing new controllers for each step of the process. But this seems rather inefficient since the process I'm modeling has no notion of navigating backwards so all previous views would pointlessly stay around and use up resources.
At the moment I keep adding and removing a subview to one "master" viewcontroller and basically swapping out the contents. This works but feels rather clunky and I hope there is some nicer way to achieve this.
Additionally there needs to be an animated transition between the views. (I have this working at the moment via beginAnimations / commitAnimations)
UPDATE:
To clarify my question: I'm aware that wizards usually have a back button. That's not what I'm building here.
The process that has to be shown possibly has a lot of steps (up to around 30-40 in some cases probably) so I really don't want to have 39 obsolete view controllers taking up ram.
Could you set the backBarButtonItem of each view controller's navigationItem to nil so that you don't show a back button?
You can extend uinavigationcontrollerdelegate and check every push event the current stack size. Then you can replace with a new reduced array that contains only the desired view controllers. By the way, if you implement a good memory management and release every resource on viewDidDisappear, i'm quite sure that it's not a matter for the os to manage a huge number of "empty" view controllers.
Hope it helps