iOS Struggling with a design concept

[RonC]

Hi everyone.

I'm struggling with how to do the following:

I want a window that is logically split into 3 areas:

• A top area that is always present, and contains various items that update based on what happens in other portions of the window, but the top area doesn't change (size, color, location) ever.
• A middle area that depends on a selection in the third area
• A set of "middle area descriptions" that control what is seen in the middle area.

Those last two feel like a "tab view controller" with various view controllers, so doing that is straightforward EXCEPT for the top part of the window that doesn't change.

Anyone have an idea how to do this or even where to get started? Right now I'm faking it - I have a tab view controller and each of the subviews explicitly contains the same view in the same place for the top part of the view. That approach feels both like a total hack AND extremely fragile.

 

[robbieduncan]

Instead of making the permanent view part of the tab view can you not add a UIView as the root view of the UIWindow then add the permanent view and the tab view (resized to make space for the permanent view) as subviews?

 

[seepel]

Instead of making the permanent view part of the tab view can you not add a UIView as the root view of the UIWindow then add the permanent view and the tab view (resized to make space for the permanent view) as subviews?

I believe tab views have problems if they aren't the root view. The somewhat unsatisfactory solution that I have used is to subclass UITabBarController, loop through it's view knowing that it has one view that is a UITabBar and another that is the content. I grab the content view, resize it and add my permanent view to the UITabBarController's view. While this doesn't strictly use undocumented APIs it does use an undocumented subview which is kind of a no-no, if Apple decides to change UITabBarController it could well break.

I suppose a better way to do this could be to have a UIView that your AppDelegate hangs onto. And have each of the UIViewControllers that you insert into the UITabBarController ask the AppDelegate for this view when they are displayed, and add it to the view from there. If all of the UIViewControllers are of the same type (e.g. all UINavigationControllers) you could probably subclass that so you don't have to repeated code, and if not you might be able to do something clever with a category.

 

[robbieduncan]

I believe tab views have problems if they aren't the root view.

I'm not 100% sure on that. The documentation says:

Unlike other view controllers, a tab bar interface should never be installed as a child of another view controller.

Installing the UITabViewControllers view as a subview is not the same as installing it as a child of another view controller...

 

[multinode]

Instead of making the permanent view part of the tab view can you not add a UIView as the root view of the UIWindow then add the permanent view and the tab view (resized to make space for the permanent view) as subviews?

I had the same thought, but I don't even see the need for a tab view. I think that something selected in one of his areas could push or pop views in the view stack of another area. I think a tab view is only necessary as a self commenting mechanism to persistently indicate choices. If the choices and the consequences thereof are obvious, then KISS.

My app is similar, I need two separate TableView areas independently scrollable and the contents i.e. data source for the second one depends upon a selection in the first.