[cstone]

"The UIView hierarchy itself is undocumented. The ordering of the contents is undefined, may change at any future date, and can not be relied upon."

This is exactly what I said above. If you expect a certain structure, your app will almost certainly blow up, and is defective. However, you can rely on the fact that the UIView hierarchy can always be modified, with public methods, regardless of what's inside (or not inside) it. Because that fact is documented.

[ankhmoop]

This is exactly what I said above. If you expect a certain structure, your app will almost certainly, and is defective. However, you can rely on the fact that the UIView hierarchy can always be modified, regardless of what's inside (or not inside) it. Because that fact is documented.

No, you can not rely on that undocumented assumption:

1) You can not know what to modify in an opaque set of views, because the contents of that opaque view hierarchy is undocumented.

2) You can not know that it is safe to modify the opaque view hierarchy, as doing so may break the undocumented invariants of the opaque view hierarchy.

3) You can not assume that the members of the view hierarchy meet your assumptions regarding structure, subclass, or nature, as the view hierarchy is opaque and not subject to declared API invariants.

If it's not documented, it is not a defined invariant, and it can not be assumed.

To claim otherwise is to simply fail to understand the purpose of defined invariants. Software development is no place to rely upon empirically-derived knowledge.

[cstone]

You can empirically determine exactly what's in an opaque set of anything (NSArray's various public access methods) and exactly what part of the area of a view is covered by a subview. Then you can call the public removeFromSubview method on that view, and it will remove it from its subview. Then you can attach your own. Apple doesn't say you can in the documentation, but they say that UIImagePickerController is a UINavigationController, and you can do that to any UINavigationController.

You can do this at run time for any UIView, even those which are part of so-called opaque types. Those methods are documented, and you can read about them above. I'm done trying to tell you that.

I can't imagine how frustrating your iphone app development experience must be if you rule out experimentation of all types. How did you ever get past the code-signing step?

[ankhmoop]

You can empirically determine exactly what's in an opaque set of anything (NSArray's various public access methods) and exactly what part of the area of a view is covered by a subview.

The facilities necessary to modify the hierarchy are defined.

The content of that hierarchy is undocumented and may change at any time. The behavior of modifying the opaque view hierarchy is undefined.

You can do this at run time for any UIView, even those which are part of so-called opaque types. Those methods are documented, and you can read about them above. I'm done trying to tell you that.

The contents are undocumented. You can not assume any behavior whatsoever if you modify the contents of the entirely undocumented view hierarchy.

Having been in the position of dealing with customers foolishly relying on internal implementation details, you honestly make me want to beat my head against the wall. It's one thing to make the mistake, it's another to proudly celebrate it.

I can't imagine how frustrating your iphone app development experience must be if you rule out experimentation of all types. How did you ever get past the code-signing step?

You still misunderstand. It's simple: you can not firmly rely upon undocumented, empirically-derived knowledge without a vendor documented invariant.

The contents of an opaque view hierarchy -- and its behavior if modified -- are entirely undocumented.

My capacity for civil dialog is exceeded, and I'll stop here.