Thursday, May 10, 2012

UIStoryBoard Power Drill, Batteries Included

I got a lot of great response and questions about my post with the UIStoryBoard. This means people are interested in using it, and I'm not good with explaining things.

I did combo this drill down with a sorta complex core data model and assumed this was setup before handing off objects to each subsequent class. I'm going to nix the core data in favor of a simple input, but we are going to keep music on the table!

Lets start here : GitHub-UIStoryboardExamples

This Xcode project will start you out with some plist data that is a nested list of music genre, artist, album, song. At the same time not to complicate the ViewControllers on how it handles these different tiers the data is only nested as a "NSString name" , "NSArray items" pair. This way we concentrate straight on the loopback of the table segue.

First take a look at the "Auto" side of this app, this table view controller uses the cells prototype push outlet to auto loopback to the controller again. Because this does not utilize the didSelectRowAtIndexPath: (or to be clear) this does call but, performs the segue regardless. This practice will make use of the sender value in the prepareForSegue: to identify which cell was clicked on. Realize we are not making a decision where to go next, thats already happening via the segue, we are only deciding what to take with us. We send some values to the next view controller that is another instance of this current one, but is not this exact one. And the view controller is then stacked in the navcontroller and is now only aware of the sub-array we handed down to it.
This auto drilling can be a little limited because of the way we always drill into the same view controller class type. But! if you want to explore here, I suggest you make another cell prototype with a different identifier and a different segue outlet, and use it at your desired tier.

The "Manual" side takes on calling segues from code and needs the fake UIBarButtonItem to create the loopback segue. This little trick will let you define segue identifiers and then let you decide what direction to take when you call performSegueWithIdentifier: The other important thing is to know what object you want to send along here as the sender. The cell is no longer the sender that is triggering the segue, didSelectRowAtIndexPath is and we could likewise send the UITableViewCell or filter it down to the object we are after. This is the place I test for the data nesting and chose to end the drill down. Calling the different segue will push over to the details view, but the stack of drills downs is still managed by the navcontroller.

Good luck and happy storyboarding.

9 comments:

  1. Thank you very much, Jason! I started using the concept widely and it works great!

    ReplyDelete
    Replies
    1. Let me know if you have other topics or things you're stumped on. This will help me decide on future posts.

      Delete
  2. This comment has been removed by the author.

    ReplyDelete
  3. this is freaking awesome sample app ! well done bro !

    ReplyDelete
  4. i love you man ! this is exactly what I was struggling to achieve ! you save my life. I wanna buy you beer !!

    ReplyDelete
  5. thank you! the link is dead, could you please update the link?

    ReplyDelete
    Replies
    1. Updated to use code now hosted at github, your all set.

      Delete
  6. Thank you so much. I want to add "search bar and search display controller" to rootview in xcode 5, but it say signal SIGABRT. How can i fix it?
    Best Regards

    ReplyDelete
    Replies
    1. If I had to wager a guess, where you may have implemented the search bar you are searching an old released pointer of an array. If you are using this Segue hand off concept from this tutorial, then you will want to make sure that any temp or sub array is being retained in the new view controller you are using it in. Any class that once housed the instance of a parent array or dictionary may deallocate that parent, therefore deallocating the sub array of items you've passed to the drilled down view. If you make sure the items are retained once handed into the drilled down controller you'll be safer off.

      Delete