Advantage of UISplitView over handmade containers [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

Improve this question

I have an app originally made for iPhone. In one storyboard scene, there are two container views that embed two different view controllers that display a model in different ways. The user can switch between showing either of these with some toggle button.

Now I want to make the ready for iPad, where it is possible to show both embedded views at the same time. The initial intuition is to use a UISplitView, but trying that felt like more hassle than needed:

• I can't easily reuse logic from the controller in the original iPhone version, for instance because of lack of multiple inheritance I can't inherit both that controller and UISplitViewController.
• The split view controller can't be pushed in a navigation view controller.

So, now I think: why not just keep (almost) everything the same and put the container views side by side, simulating a split view, and just keep the same old controller and logic (except that there is no need for a toggle button).

Still, split views must be there for a reason, so my question is: is this a good approach? What built in functionality and features of a split view may I be missing out on? My specific app is meant to be landscape only, so a split view automatically being nicer in portrait is not relevant for me.

Answer 1

At the time UISplitViewController was invented (iOS 3.2) it was illegal to create your own container view controller, i.e. a view controller whose view contained the views of other view controllers. You had to use only the container view controllers supplied by Apple. So what UISplitViewController was doing couldn't be done any other way.

In iOS 5, custom container view controllers were introduced and UISplitViewController immediately became unnecessary; it became legal to write your own alternative. I even wrote one (warning, this is iOS 5 code):

https://github.com/mattneub/Programming-iOS-Book-Examples/blob/master/iOS5bookExamples/ch22p667splitViewNoPopover/p560p575splitViewNoPopover/MySplitViewController.m

So my advice is, as long as you understand how custom container view controllers work, do what you like!

Answer 2

Uisplitviewcontroller are mere containers with delegation( that majorly controls the show hide behaviours of the master view. ) For simple use like in your case , that is just for one orientation i think uisplitviewcontroller is a better option than the handmade one.

Pro: Simple to use On orientation change it gives you the reference of the master view in case you are hiding it and you can present it via popover (preferred to save screen in portrait mode)

Con: Uisplitviewcontroller will always be the rootview controller of you application. (Hacks are there for this too,but still). So if tour application uses login screen you would need to show that modally . This means your main application view will appear before the login itself(though hidden by modally , but in lifecycle it will be loaded before the login screen. I have found uisplitviewcontrol a less mature. Here is the example, my app uses the swipe to dismiss/show the master view, once i had the need to present a screen modally from details view when the masterview was visible. The modal screen was layered between the master and detail views. Though i solved this by presenting the view from the master itself but still i considered uisplitview control as a unified control and it was weird.