Re: Segue


Alex Zavatone
 

Please pardon this little sidetrack from this storyboard discussion.

One thing I absolutely love (read the view controller header, folks - line 100 to 102) is simply using a storyboard as a skeleton and deleting the top level view. 

Why?

Well, the UIViewController header comments of course.

If you
  invoke this method with a nil nib name, then this class' -loadView method will attempt to load a NIB whose
  name is the same as your view controller's class. 

This means that the storyboard can exist as a visual representation of your app and its screen flow and you can use XIBs for each screen and they will automatically take the place of your scene’s top level view if you simply delete the top level view of your scene.

It is (was) that simple.  In fact, IIRC, this has been that way since at least 2008.

This means that on larger teams, there are no storyboard merge conflicts at all if each developer keeps to their own XIB.  Just set the top level class of the scene to the class in the storyboard and do the same in the XIB.  Everything just loads and works.  Let multiple developers work in multiple XIBs.  

Now, this changed somewhat in Swift and the Swift implementation looks very close to Objective-C, so it shouldn’t be too hard to see if a similar approach works in Swift.

It’s much much easier just using the storyboards as skeletons and keeping all the top level views in individual XIBs.  

Segues work as they are expected to, everything else works just as it is expected to.  

It’s nice.

Hope this helps someone else.

Cheers,
Alex


On Oct 3, 2018, at 10:58 AM, Fritz Anderson <anderson.fritz@...> wrote:

I can't answer for your habits of thought. A constellation of XIBs plus code to coordinate them could possibly reproduce the user's experience of an application built with storyboards. (I'm sure I'm forgetting something, don't hit me, I wear glasses.) My thoughts in no good order:

It's cognitively easier to coordinate the appearance and flow of an application in a single window. If the design is too big for a single view, you can link to another storyboard.

Not every controller transition fits the model of a simple segue, but most do. Those transitions are so routine you may not even realize they're in your app. You can create them by hand, but drawing and configuring a line is five minutes, not thirty (> O(n)), and easier to maintain.

Most remaining potential segues (such as jumps between branches of a hierarchy) aren't that hard to subclass, and again you have a picture.

I don't want even to think about handmade unwind segues.

I don't want to think hard about managing potentially-broad nav hierarchies that might change during development, without segues, so yes my concerns about segues are relevant to good (reliable, maintainable) practice.

Embedded controllers, one example: A static-cell UITableView must be run by UITableViewController, which can't include auxiliary controls like Cancel/Save. Embed it in a wrapper controller with a toolbar. The scene for the table controller follows the size of the embedding view.

Scene layout. If a controller is stacked in a nav controller within a tab controller, you get the correct aperture for free, even if you change the wrapper controllers. Also, the root views of children of tab controllers include the icon and label of the corresponding tab. This is orthogonal to whether you use Auto Layout.

This is dangerously close to an insult — I don't intend one, this is for the archive — but make sure it's not just a matter of sentiment. You still run into people who won't use Instruments (except at release minus one week) or even a debugger, because they feel moment-to-moment pressure telling them they don't have time to learn.

I'm not saying storyboards solve every problem or obviate every XIB.

   — F

On Oct 3, 2018, at 8:55 AM, Dave <dave@...> wrote:

I’ve been looking over the pro and cons of using storyboards and for the life of me I can’t see what is gained by using them? I thought it would make development quicker but actually I don’t think that do you save time using a Storyboard. IMO, using old old fashioned NIB and code is the same or quicker than using a NIB that the while thing is so much more maintainable and reliable. Unless I’m missing something……




Join cocoa@apple-dev.groups.io to automatically receive all group messages.