3 ms·

I jumped into iOS dev after storyboards so, I fear nibs... I've never used one. If I started with a storyboard, should I throw in nibs every now and then for ce

I jumped into iOS dev after storyboards so, I fear nibs... I've never used one. If I started with a storyboard, should I throw in nibs every now and then for certain tasks??

danilocampos 13y ago
Here's the haphazard way I'm using this stuff these days: 1. Non-view controller views. These typically go in nibs. Custom tableview cells, tableview headers used across multiple views, custom buttons, nibs are all fine for this. (And the UITableView API accepts nibs for setting up reusable cells.) You can certainly do custom tableview cells in Storyboards, but it's weird because I don't know how you can re-use those cells across multiple tableviews. 2. View Controllers. These I'm often using Storyboards to build. Since they're great for static tableviews, Storyboards end up having a decent chunk of stuff built in them lately. It can be nice to look at two views side by side. I seem to be grouping related view controllers together in single storyboards. Nibs have performance penalties if they're packed down with too many objects, as every single one has to be loaded into memory. My understanding with Storyboards is that they don't have this drawback, so that's helpful.
bennyg 13y ago
I like to think of Nibs like classes. A lot of times I'll have a certain design I want reused throughout the app, and this works perfectly. For instance, in an app I'm working on now, I have a few different views that have scroll-views inside of them, with each object of the scroll-view being a view itself. In the last of the chain of views, I use a nib because there's a solid amount of data there, and visually designing it in IB is easier to iterate and make it look exactly like I want it to. I have a .m/.h attached to the view (just a subclassed UIView) with a custom init method, returning what is basically a custom object (that happens to be that .xib). It's super efficient to make changes and keep things looking good when the data or the feature-set needs to change.
- BHSPitMonkey 13y ago
  Keep in mind, this scenario is just as good a candidate (maybe even better) for doing the layout in code rather than a nib.
  - bennyg 13y ago
    Here's why I say no it isn't: The end product, what my nib is for, has 12 labels, three UIView border bars (1px thick), two UIViews just for a differing background color in a couple spots, and a UIImage. Now you're right, I could set all those in code, alloc all those labels and adjust their sizes and positions relative to the ones that came before and all of that jazz, and that's all fine and dandy. Until I realize that my design needs tweaking. So, instead of selecting all elements on the nib and pressing up twice for a two pixel shift, I'm sitting there editing 20 different things in a CGRect call... way more work. So instead of doing it all in code, the way I went about was creating a subclass of UIView with a .xib file attached to it. The .xib has everything where I want it visually and it's connected to the header via properties of everything that needs to be dynamic. Then I made a custom init method that just takes in my object and returns a UIView object that is the totality of that nib loaded with the data I need it to be. All in all, instead of bloat, every time I need to return an instance of that custom subclass I effectively call something like this: UIView *newView = [CustomClass createCustomViewWithObject:(id)object]; And that's it - I'm free to put it wherever I want up the chain in my subsequent views.

I jumped into iOS dev after storyboards so, I fear nibs... I've never used one. If I started with a storyboard, should I throw in nibs every now and then for certain tasks??

danilocampos 13y ago

Here's the haphazard way I'm using this stuff these days: 1. Non-view controller views. These typically go in nibs. Custom tableview cells, tableview headers used across multiple views, custom buttons, nibs are all fine for this. (And the UITableView API accepts nibs for setting up reusable cells.) You can certainly do custom tableview cells in Storyboards, but it's weird because I don't know how you can re-use those cells across multiple tableviews. 2. View Controllers. These I'm often using Storyboards to build. Since they're great for static tableviews, Storyboards end up having a decent chunk of stuff built in them lately. It can be nice to look at two views side by side. I seem to be grouping related view controllers together in single storyboards. Nibs have performance penalties if they're packed down with too many objects, as every single one has to be loaded into memory. My understanding with Storyboards is that they don't have this drawback, so that's helpful.

bennyg 13y ago

I like to think of Nibs like classes. A lot of times I'll have a certain design I want reused throughout the app, and this works perfectly. For instance, in an app I'm working on now, I have a few different views that have scroll-views inside of them, with each object of the scroll-view being a view itself. In the last of the chain of views, I use a nib because there's a solid amount of data there, and visually designing it in IB is easier to iterate and make it look exactly like I want it to. I have a .m/.h attached to the view (just a subclassed UIView) with a custom init method, returning what is basically a custom object (that happens to be that .xib). It's super efficient to make changes and keep things looking good when the data or the feature-set needs to change.

BHSPitMonkey 13y ago
Keep in mind, this scenario is just as good a candidate (maybe even better) for doing the layout in code rather than a nib.
- bennyg 13y ago
  Here's why I say no it isn't: The end product, what my nib is for, has 12 labels, three UIView border bars (1px thick), two UIViews just for a differing background color in a couple spots, and a UIImage. Now you're right, I could set all those in code, alloc all those labels and adjust their sizes and positions relative to the ones that came before and all of that jazz, and that's all fine and dandy. Until I realize that my design needs tweaking. So, instead of selecting all elements on the nib and pressing up twice for a two pixel shift, I'm sitting there editing 20 different things in a CGRect call... way more work. So instead of doing it all in code, the way I went about was creating a subclass of UIView with a .xib file attached to it. The .xib has everything where I want it visually and it's connected to the header via properties of everything that needs to be dynamic. Then I made a custom init method that just takes in my object and returns a UIView object that is the totality of that nib loaded with the data I need it to be. All in all, instead of bloat, every time I need to return an instance of that custom subclass I effectively call something like this: UIView *newView = [CustomClass createCustomViewWithObject:(id)object]; And that's it - I'm free to put it wherever I want up the chain in my subsequent views.