Re: How is one supposed to use a UIPageViewController in a storyboard?
Re: How is one supposed to use a UIPageViewController in a storyboard?
- Subject: Re: How is one supposed to use a UIPageViewController in a storyboard?
- From: Fritz Anderson <email@hidden>
- Date: Tue, 24 Sep 2013 19:14:33 -0500
On 24 Sep 2013, at 1:42 PM, Rick Mann <email@hidden> wrote:
> On Sep 24, 2013, at 10:38 , Fritz Anderson <email@hidden> wrote:
>
>> On 24 Sep 2013, at 3:03 AM, Rick Mann <email@hidden> wrote:
>>
>>> UIPageViewController seems very clunky. On the surface, it looks similar to UITableViewController, but in fact, it behaves very differently. There's no view associated with it, nor can you add a view to it (in the storyboard editor).
>>
>> That is correct. The data source for the page-view controller must feed view controllers to the page controller on demand. The page-view controller does not know, and does not care, what kind of view controller it gets from any one request. You may have different view controllers that go into pages. The design has to allow for this.
>
>> Create XIBs or Storyboard scenes with your page-layout views. That's the best you can do.
>
> I think you're missing what I meant. Of course it's different, in the sense that it provides view controllers instead of views. But it's incredibly cumbersome to use as a first-class citizen in a storyboard. In my case, it's a child of a tab view controller. But there's no way in IB to specify anything about the fixed view hierarchy if you instantiate it in IB (that I can see).
I often do miss what people mean; I have almost no common sense. Let's see if I misunderstand you further…
We've done this, but with only one per-page view controller, and without an outer wrapping container like a nav or tab controller. I don't think the principles are different for the purposes of this discussion.
In a split view, the detail view's root scene belongs to an unexciting UIViewController. The view contains a toolbar, and a container view that embeds a page-view controller.
Split view
Master (nav controller)
Detail (view controller)
Toolbar (owned by the vc)
Container (embed segue to page-view controller)
Page-view controller (detail view controller is data source)
... and that's where the hierarchy dead-ends. You can't put anything inside the page-view controller's scene, because so far as application developers are concerned, page-view controllers _don't have any views_ of their own.
We do the layout for the pages in orphan scenes in the same storyboard. No link to the page-view scene is possible.
(continuing the above hierarchy:)
TextPageViewController
IllustrationPageViewController
...
As I understand it, you're unhappy that you can't drag anything into the page-view scene as some kind of default controller managing a default content view. Am I right?
It's an interesting idea, and maybe someone can think of a way around my objection: The page-view controller is a scene. The (proposed-default) page-content controller is also a scene. You then have two controllers, with two scenes, in one place. I don't see how to disentangle it, and developers who want more than one possible page type will still have to add orphan scenes for the more-than-one controllers.
> Perhaps you might think to create a UIViewController that you subclass. Okay, now let's put a container view into it, and then embed a UIPageViewController in that.
>
> Well, container views are fairly useless in IB, because there's no outlet for the embedded view in the containing view controller. You'd have to iterate the children to find a UIPageViewController, but what if you have more than one? Cumbersome. And there's no way to wire the dataSource and delegate back to the containing view controller.
Put an identifier on the embed segue, and listen for it in the parent controller's prepareForSegue:sender:. The segue that comes into the method will get you the contained controller.
> I'm having trouble seeing the utility of putting a UIPageViewController in a storyboard for anything but a quick demo app, and then only if you can subclass it (which the docs say you can do in 7 but imply you can't do in 6). Now we're even more like a UITableViewController, except you can't have a view hierarchy in the UIPageViewController.
We agree: you cannot have a view hierarchy in a UIPageViewController. That's not a quirk of Interface Builder; it reflects the fact that there is no such thing as a view hierarchy in a UIPageViewController. For consistency's sake, its scene looks like a view, but it isn't.
I'm surprised it's subclassable; my memory was that it wasn't, and I beat up on a junior programmer for doing it. But he was using the page-view controller as its own data source, and besides he needed a beating on general principles.
— F
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden