I'm hoping someone can tell me if it's possible to put a separate navigation stack on the detail view for a split view controller. I've been banging my head against this problem for a while and now am wondering if it's even possible.
I'm developing a universal application that allows users to browse a conference schedule. On the iphone this is simply a a table view where users:
-->selects a session topic from a list of topics (plain table)
---->selects a session title from a list of topics(plain table)
------>sees details about the session including papers to be presented and can selected a individual table (grouped table)
-------->sees details about the paper (grouped table)
What I'd like to do for the ipad version is something like this:
-->selects a session topic from a list of topics (root controller, plain table)
---->selects a session title from a list of topics(root controller, plain table)
------>sees details about the session including papers to be presented and can selected a individual table (detail controller, grouped table)
-------->sees details about the paper (detail controller, grouped table)
That's the goal, but everything I've tried in terms of getting the detail controller to have a separate navigation stack has screwed up the split view controller. I can get everything up to the last step working fine. But as soon as I push a the details about the paper onto the detail controller stack, the splitview controller goes crazy.
Has anyone accomplished something like what I'm describing above?
I could simply replace the session details controller with the papers detail controller instead of trying to push it onto the stack. But then I lose all the benefits of the nav stack, lose all the free transition animations, and have to maintain a substantially altered version of the same table for the iPhone and iPad.
Thanks in advance for any suggestions.
I swear, sometimes I think stack overflows greatest benefit is how often publicly posting a problem spurs me to solve it myself.
So what I describe is definitely possible. Simply look at the settings app. It does exactly what I describe.
The problem I had was that some of my detail view controllers, because they were inherietend from the iPhone version, did not implement "shouldAutoRotate". Once I added that, everything fell into place.
If anyone else if facing a similar problem, I might also suggest you start with Matt Long's walkthrough of adding a navigation stack to the splitViewController here:http://www.cimgf.com/2010/05/24/fixing-the-uisplitviewcontroller-template/
Related
I am building an Onboarding/Welcome screen for my app, but the problem is that my app has a tab bar, so my Onboarding somehow interferes with that and doesn't look like a seamless interface. My solution is to put the Onboarding thing on a separate view controller and once a user is done with that screen, it presents the navigation controller and all of ITS views. I have done some research on this, but I'm still lost. If you have any other ideas, or have solutions, please let me know, thanks.
Here is what I want to achieve:
In order to do this in a way that looks nice and works well you should not be pushing or presenting the tab bar but updating the root view controller of the whole window.
I can’t provide a code example right now but there will be several online sources for this.
You should be changing the view controller so it essentially toggles the app between “logged in” and “logged out”.
That way you don’t have to worry about how to get from one to the other. They act separately just dealing with their own stuff.
Users of my app can continually load new instances of the same view controller with different pieces of information. Is there a maximum amount of view controllers that can be in the navigation stack?
Edit:
This particular view controller shows postings made by other users and I put a section that shows users related postings, so when they go to tap one one they see another set of related postings and so on. I've seen many apps like this in the past. Do their developers do anything to prevent memory crashes or do they just assume users won't tap on enough of them to make the app crash?
I’m working on an app which combines a tab bar controller with a number of split views, so that each tab item shows a different master-detail view. I want the tab to be visible at all times so the user can switch directly between master-detail views.
I can achieve this by having a separate split view for each tab, but I'm not sure whether this is approved by Apple. The view controller catalogue for iOS says "A split view controller must always be the root of any interface you create." However the UISplitViewController API reference says "Although it is possible to install a split view controller as a child in some other container view controllers, doing is not recommended in most cases."
As an alternative approach, I can have a split view as the root, with a tab controller on the primary. This means though that the tab is hidden on compact width devices when the detail view is shown. The user has to navigate back to the master view to switch tabs. This is not the behaviour I want and is not what happens with the Apple Music app for example.
So, a couple of questions:
Would Apple reject the app if it has a tab as the root and multiple split views?
Is there another way of achieving what I want?
Many thanks.
Your quote says "not recommended", not "your app will be rejected".
The only wishes you have expressed are "I want the tab to be visible at all times so the user can switch directly between master-detail views". That doesn't really leave room for alternatives. Also, you haven't described your app. It might be that your design choice is not suitable for its use cases.
It sounds like you want us — a third party — to speculate about whether Apple would reject your app. This is not the right forum to ask for that, but I say try, and you'll get a definite answer.
I'm trying to build an app that has lots of similarities to the Facebook App in terms of the "Storyboard". I'm tempted to do everything in code as I know best but I'd really like to figure out how to storyboard these more complicated UI's.
The Facebook App starts with a login view. When you log in, you get a tab view. In the main tab view, you have a table view. Within each table view are a user, post, and comment buttons which push to a new view.
So the way I am understanding it is we have UINavigationController with the .navigationBarHidden set to false. The first view controller here is the loginViewController. When the login button is pressed and the user is logged in, we performSegueWithIdentifier to a UITabBarController. The first tab is a UINavigationController with a UITableViewController as the first view controller. Clicking user, post, or comment pushes the appropriate view controller onto the NavigationController.
This all begins to seems a bit more complicated than just writing this all out in code. I'm also not even sure this implementation is correct with all these nested view controllers. I'm not sure this is all possible with storyboard as well: for example a navigation controller for pushing to comment, user, or post views doesn't seem possible with storyboard.
I'd like to know the correct way of implementing this kind of UI design. And should / could this be implemented using Storyboards?
Your design team may layout the app using a "storyboard" (physical objects -- not the digital version). Large apps are hard to piece all the little things together on a storyboard. Just too many wires going every which way.
Look at the FB app without internet access and you can see their basic building blocks easier. Its built in units (post at a time) that are added to a scrolled view. Search bar and menus at the top and buttons at the bottom with the scrolled view in the middle. The posts probably have some common base class with various types derived from it (picture, video, links, etc).
There is some sort of background process monitoring the position of the scroll view to dynamically load new stories if you get down within 1/3 of the way to the bottom. Within each post you can see the components if you look closely and think about what sort of block that is.
The IMDB app for iPhone seems to allow infinite drill downs and explorations from a movie detail page to a detail page of an actor who was in that movie, to that actor's first movie to that movie's director, etc.
What is the best way to build this in Xcode?
Be sure to check out Apple's UINavigationController documentation/sample code here. You can learn a lot about iOS development from looking at the sample apps.
The "infinite drill down" you're referring to is the act of "pushing" a controller onto the current stack of controllers. As you go back, you "pop" a controller off the stack to get back to the previous controller. If implemented properly, UINavigationController will handle things like making sure the Back button contains the title of the previous screen, keeping the screens in order, and the sliding motion.
Good luck!
You can create by using a UINavigationController and push the view one by one as you want.