toxicsoftware.com - Latest Comments

Re: UIStoryboard Issues

Wayne Hartman — Sat, 07 Jan 2012 19:13:42 -0000

Great post. I've been using storyboards for over a month now and have run into the same issues. However, I did discover some even more rotten ones:

1) You can't just use segue.destinationController if you are using a VC that is wrapped in a navigation controller. You must dig into the controller hierarchy and find it. For example:

       UIViewController* viewController = nil;

        if ([[segue destinationViewController] isKindOfClass:[UINavigationController class]]) {
            UINavigationController* navController = [segue destinationViewController];
            viewController = (UIViewController*)[navController topViewController];
        } else {
            viewController = (UIViewController*)segue.destinationViewController;
        }

This is very troublesome to me and just doesn't smell right.

2) There is no automatic prepareForSegue for an accessory view action on a table view cell. You have to implement this yourself. So much code...

3) There is a reproducible flaw I discovered with an overrelease on a UISearchViewController if you create one as part of your storyboard and a low memory situation occurs. So much for ARC.    If you'd like an example project on this, fell free to hit me up.

4) If you are doing a Universal app, you must keep the segues in sync. If you change a segue name in the iPhone version, you must make a corresponding change in the iPad version, else use branching logic. Having to duplicate or keep these sorts of things in sync really rubs me the wrong way. The problem is that I can't think of a good alternative.

5) Popovers on iPad are the worst.
        a) You cannot programmatically set the anchorView nor the anchorRect without using a private API.
                i) This is important to be able to do when you may not create everything through IB.
        b) The expected order of operations in a popover differ from other segue transitions:
               ii) The view is loaded first, then the prepareForSegue call is made.
               ii) In other segue transitions, prepareForSegue is called first, then the view is loaded.
               iii)This is detrimental to the design of your ViewControllers because some UI modifications may have been expected to be made based on models you set in prepareForSegue, thus causing you to write more code to overcome the difference in behavior...

Re: UIStoryboard Issues

Matt — Thu, 22 Dec 2011 21:05:26 -0000

Enjoyed this post a lot.

The bloated prepareForSegue is a bad smell, in the Refactoring sense. And I would have expected that the solution would be the same as in Refactoring: multiple UIStoryboardSegue subclasses. Unfortunately the inventors of storyboards didn't think of that, so prepareForSegue is sent to the source view controller and we end up with spaghetti.And string identifiers - could anything be less maintainable, more error-prone? And they didn't even think to show the identifier in big letters in the canvas part of the storyboard editor?Plus, the whole prepareForSegue architecture is just wrong; instead of letting the destination view controller specify its own designated initializer, so that it must be given the right data in order to be instantiated and can then do with that data what it likes, the source view controller winds up having to know the inner mechanisms of the destination view controller and set its properties or call its methods. That is not correct OOP design.
Storyboards feel like a sop to beginners who don't understand view controllers, but I don't think they actually make life better for them or for anyone else. I do understand view controllers and I'm very nimble with them; storyboards just get in my way.Nevertheless, the basic idea is intriguing, especially the insight that the whole repertoire of things that must happen as a view transition takes place can be clumped into an object (a segue).

Re: UIStoryboard Issues

Drew McKinney — Sun, 18 Dec 2011 11:02:08 -0000

I'm happy you posted this. I'm struggling with Storyboards from a fundamentals standpoint. I'm used to being able to access objects like the TabBar as an outlet without interference, but with Storyboards I am forced to grab the rootViewController from the window and trust that it's correct. Granted, this happens without storyboards, but it adds a new level of confusion by not allowing me to connect some things to code but not others. Granted, I'm doing this to perform a more advanced interface action, but it's nothing out of question for an developer creating any kind of quality App.

Storyboards seem suited for those new to cocoa, allowing them to focus on the ViewController actions and not have to bother with the particulars of App delegate up front. Also, I've used Storyboards with designers to visually place interface elements, allowing them partial exposure to the development process. But as you mentioned, these are simply too inflexible for any kind of advanced use.

Re: UIStoryboard Issues

Peter — Sat, 17 Dec 2011 00:41:18 -0000

I cannot be more agree with you. Storyboards suck.

Re: UIStoryboard Issues

kra — Thu, 15 Dec 2011 00:26:20 -0000

Definitely agree with you.
I'm getting super weird behaviour on viewdidload/unload with container VCs. Bsically, the initial VC is a container VC, we have the children in the storyboard, loaded with instantiateVCWithIdentifier on demand.
When a child VC is "off screen" (ie after removeFromParentVC), a memory warning does drop the views and outlets, as expected.
But when it comes back (ie addChildVC), it loads only whatever is wired to the main view, the NSobject outlets not directly under the VC's main view are just not loaded. Not even init'd. And even worse, wiring views into those nsobjects just crashes the app. Works fine if i move the children to a regular nib (one per nib).

Re: UIStoryboard Issues

schwa — Wed, 14 Dec 2011 14:06:04 -0000

Madness! Madness I say.

There's nothing intrinsically wrong with UIStoryboard. I think _if_ Apple improves upon it , it could be really useful. I just don't think the current version of it is ready.

Re: UIStoryboard Issues

Maxim Zaks — Wed, 14 Dec 2011 13:07:36 -0000

Quantity defines the poison!
IMHO story board is for prototyping and small Apps.
It is madness to do monolithic storyboard for over 20 view controllers.

Re: UIStoryboard Issues

schwa — Tue, 13 Dec 2011 23:29:04 -0000

In a NIB based app I tend to pass the data needed by a VC as the VC is created (see my "initWithFoo:" example in the post.) This sprinkles the set up code amongst the VCs that need the data.

In a storyboard based app the code for instantiation tends to get centralised in the source view controller.

On top of that because the destination view controller often is _not_ the view controller that needs the data (often there is a UINavigationController in the way) you need to get from the source view controller to the actual view controller that needs the data.

Look at the code example I posted in the body. And that just shows a prepareForSegue: for a single (destination) view controller - imagine if the source view controller had more segues. 3 segues in a source view controller isn't uncommon.

And yes, thank you for pointing out how to file a bug with Apple. I was expecting Tim Cook to read my blog and make sure these features were implemented.

Re: UIStoryboard Issues

Thomas Alvarez — Tue, 13 Dec 2011 21:32:33 -0000

"My root view controller has become a source view controller for lot of segues and therefore its prepareForSegue: has become a stupidly large method"

I understand your complaint about the size of the method if you have a lot of segues (outgoing) one view controller. Could you explain how if you have a "root" view controller that has a lot of outgoing segues to other view controllers, how you don't have a lot of code in it with presentViewController calls doing the same thing when you're not using Storyboards?

Btw, writing "feature request" in a blog post isn't going to get you anything. File bug reports on Radar (https://bugreport.apple.com).

Re: UIStoryboard Issues

schwa — Tue, 13 Dec 2011 19:37:14 -0000

There's that. I haven't encountered it myself (for most of this project I was the sole developer). Was hoping it would merge cleanly though.

Re: UIStoryboard Issues

Jean-Denis Muys — Tue, 13 Dec 2011 19:34:45 -0000

One other thing I dislike about storyboard is that it makes it more difficult to work with other developers on the same app with source control. With separate nibs, you can split work responsibility more easily with little need to resolve conflict at pull/push time. Storyboards are just too monolithic.

Re: UIStoryboard Issues

Charles Choi — Tue, 13 Dec 2011 17:59:41 -0000

FWIW, my first impression of working with UIStoryboard was inflexible control flow, particularly when interleaving visual and code implementations of that flow. If it's of any consolation, the problem with efficiently describing control flow in visual languages has long been noted in CS and it seems that it still has yet to be solved here.

Re: UIStoryboard Issues

schwa — Tue, 13 Dec 2011 17:53:07 -0000

(Thanks for copying the comment from the gist - you raise a good point so am very glad you did)

The trouble with breaking up your UI into multiple storyboards is that it buys you very little over multiple NIBs. And you still have all those problems discussed above. You can't easily link between individual VCs spanning multiple storyboards so you're back to writing a lot of code (again).I do plan on using Storyboards still - like you mention it's the only way for the new UITableView features (I have to assume that's a bug on Apple's part). And I may keep storyboards for some simpler parts of the app (e.g. new user signup/login). But I definitely won't try to make the entire app use storyboards again.

I'll happily re-visit the technology again once improvements have been made. I have faith it can be made a lot better.

Re: UIStoryboard Issues

BJ Homer — Tue, 13 Dec 2011 17:50:45 -0000

Attempting to cram the entire interface of an app into a single storyboard is often a bad idea. In the same way that we use classes to implement separation of concerns, you can use storyboards to separate various "modules" of your app. You might have a "Settings" storyboard, a storyboard for each tab, etc. There's no need to shove everything into a single storyboard.

The ability to use static cells and design prototype cells in tableviews is, in my mind, the killer feature for storyboards. I have a number of storyboards with only a single view controller in them, but I use a storyboard instead of a xib simply because I can design my tableview cells inline.

Re: Calling a Turd a Turd

Jonathan M. Sterling — Wed, 15 Jun 2011 17:24:00 -0000

Thank you for writing this. Zarra's post irritated me somewhat.

Re: Calling a Turd a Turd

schwa — Mon, 06 Jun 2011 09:38:06 -0000

Who was trashing the people? The people behind it were unknown.

Yes it's unfair to immediately blame the devs when something sucks. But at the end of the day they wrote the app.

Re: 90% of Everything is Crap

Guest — Mon, 06 Jun 2011 09:02:19 -0000

I'm trying to figure out which 10% of this post isn't crap. ;-)

Re: Calling a Turd a Turd

samh — Mon, 06 Jun 2011 07:25:22 -0000

The thing is, there is a difference in criticizing code or an app as crap, and another in assuming the developers who wrote said crap were incompetent. If you don't know the circumstances, refraining from attacks on other developers is a wise course of action. You can be respectful of what went into the development of a product while still giving the necessary criticism. It's just harder to do.

Seems like that's what the original post at CocoaIsMyGirlfriend was getting at. Why trash the people?

Re: Calling a Turd a Turd

Pedant — Sun, 05 Jun 2011 23:26:45 -0000

W. Somerset Maugham said it already.

People ask for criticism, but they only want praise

http://www.quotationspage.com/...

Re: Calling a Turd a Turd

Preston Sumner — Sun, 05 Jun 2011 17:13:28 -0000

"at the end of the day owned by a psychopath who makes Bond villains look huggable"

Apple or The Daily?

Re: 90% of Everything is Crap

Viswakarma — Sat, 04 Jun 2011 15:39:48 -0000

I fully agree with you!!! That is how engineers and designers who create take critique of their work. It is called peer review.

Re: 90% of Everything is Crap

schwa — Sat, 04 Jun 2011 11:27:38 -0000

Having worked on literally dozens of products as a contractor I can definitely agree with you. Often you're considered "just the contractor" and never get any control over the quality of the final product. As a sub-contractor (a position I've preferred to avoid) it is even worse.

But totally blaming the client on the other hand isn't fair either. Contractors often blame the "crazy client" for everything - that's a cop out that is pretty common amongst contractors. I've certainly used "my hands were tied" line as an excuse for bad work. Maybe I could have made that product better on my own.

I think the key to what I tried (and probably failed) to get over in this blog post is that lack of criticism is worse than too much. With out criticism everything is "awesome" and all developers are "rock stars". No product is mediocre. Everything is amazing.

That's all a lie. 50% of everything is below average and 90% of everything is shit. We all know that. Pretending otherwise encourages mediocrity.

I'd rather my peers were overly critical of me and heck snarky with it than let me wallow in crapness.

Re: 90% of Everything is Crap

Rich Wardwell — Sat, 04 Jun 2011 11:13:50 -0000

When you build something high profile - something that is advertised during the fricking Super Bowl, it better be good. When you have a website that looks like this: http://www.chaoticmoon.com/ it better be good. When it isn't, the criticism is going to flow, and you better be prepared for it.

I think Marcus's mistake (and even some of the folks criticizing - such as Loren Brichter's carousel) was to take / or put the blame squarely on the backs of the coders. There were a lot of people responsible for the issues of the Daily, and much of it probably did not lie on the head of those actually doing the development. Or rather, the developers were certainly not in control of the final product.

Re: 90% of Everything is Crap

Jonathan Wight — Sat, 04 Jun 2011 11:01:46 -0000

But see, everyone hates a grammar nazi.

Although in this case backing up your criticism with a little rule to help you avoid the mistake in the future is very handy

Re: 90% of Everything is Crap

trashbat — Sat, 04 Jun 2011 05:49:26 -0000

The problem with corporations/businesses setting requirements is that they are often over-ambitious at what they can do given the time, or money, available.

Often, this is because they've seen the same functionality elsewhere, and - with good reason - have no real way to distinguish between which things are easy to implement, and which ones aren't.

Having seen Flash based carousels on ebay, Amazon, et al, and Coverflow, I can imagine it would be easy for a non-technical person to think it was something easy to do.

On the other hand, I think if there is one thing that defines the Mac software community - and even Apple to a degree - is that software or hardware may be missing features - but what is there, should work.

And perhaps that points to where the big change is - the Mac Dev blogging community is largely made up of independents. (This differentiates it from, say, the Java Dev community, where 'enterprise' development dominates). Independents set their own destiny - they can cut features or slip timescales as required.

But the rise of iOS - and increasing popularity of the Mac - means a big increase in third parties setting the agenda. And if you start with a date and a list of features that must be in there, there's only two factors that can give, cost and quality - and we know which one it often is.

(There's also a vicious circle where previous experience means people have low expectations of V1 - and that it's OK to ship, because that's what software is like. Oddly, before it was easy to update software with patches, and it was shipped on physical media, it was a lot less buggy).