On 24 Sep 2013, at 1:42 PM, Rick Mann <rm...@latencyzero.com> wrote:
> On Sep 24, 2013, at 10:38 , Fritz Anderson <fri...@manoverboard.org> wrote:
>
>> On 24 Sep 2013, at 3:03 AM, Rick Mann <rm...@latencyzero.com> 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 (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
