title: Two UIViews, one UIViewController (in one UINavigationController)
body: <p>Given an iPhone app with a <strong>UITableViewController</strong> pushed onto a <strong>UINavigationController</strong>, I would like to add a right bar button item to toggle between the table view and an "alternate" view of the same data. Let's also say that this other view uses the same data but is <em>not</em> a <strong>UITableView</strong>.</p>
  
  <p>Now, I know variations on this question already exist on Stack Overflow. However, in this case, that alternate view would <em>not</em> be pushed onto the <strong>UINavigationController</strong>. It would be visually akin to flipping the current <strong>UIViewController</strong>'s table view over and revealing the other view, then being able to flip back. In other words, it's intended to take up a single spot in the <strong>UINavigationController</strong> hierarchy.</p>
  
  <p>Moreover, whatever selection you ultimately make from within either view will push a common <strong>UIViewController</strong> onto the <strong>UINavigationController</strong> stack.</p>
  
  <p>Still more info: We don't want to use a separate <strong>UINavigationController</strong> just to handle this pair of views, and we don't want to split these apart via a <strong>UITabBarController</strong> either. Visually and contextually, the UX is meant to show two sides of the same coin. It's just that those two sides happen to involve their own View Controllers in normal practice.</p>
  
  <p>Now … it turns out I have already gone and quickly set this up to see how it might work! However, upon stepping back to examine it, I get the distinct impression that I went about it in a rather non-MVC way, which of course concerns me a bit.</p>
  
  <p>Here's what I did at a high level.</p>
  
  <p>Right now, I have a <strong>UIViewController</strong> (<em>not</em> a <strong>UITableViewController</strong>) that handles all commonalities between the two views, such as fetching the raw data. I also have two NIBs, one for each view, and two <strong>UIView</strong> objects to go along with them. (One of them is a <strong>UITableView</strong>, which is a kind of <strong>UIView</strong>.)</p>
  
  <p>I switch between the views using animation (easy enough). Also, in an effort to keep things encapsulated, the now-split-apart <strong>UITableView</strong> (not the <strong>UIViewController</strong>!) acts as its own delegate and data source, fetching data from the VC. The VC is set up as a weak, non-retained object in the table view. In parallel, the alternate view gets at the raw data from the VC in the exact same way.</p>
  
  <p>So, there are a few things that smell funny here. The weak linking from child to parent, while polite, seems like it might be wrong. Making a <strong>UITableView</strong> the table's data source and delegate also seems odd to me, thinking that a view controller is where you want to put that per Apple's MVC diagrams. As it stands now, it would appear as if the view knows about the model, which isn't good. Loading up both views in advance also seems odd, because lazy loading is no longer in effect. Losing the benefits of a <strong>UITableViewController</strong> (like auto-scrolling to cells with text fields) is also a bit frustrating, and I'd rather not reinvent the wheel to work around that as well.</p>
  
  <p>Given all of the above, and given we want that "flip effect" in the context of a single spot on a single <strong>UINavigationController</strong>, and given that both views are two sides of the same coin, is there a better, more obvious way to design this that I'm just happening to miss completely? Clues appreciated!</p>