My application is for studying. It will have three screens, one for studying (reading), one for reviewing, and one which acts as the main menu (for managing documents and selecting study or review). The main menu will be the first screen when the app is loaded.
I am trying to decide on the best approach with regards to what view controllers and views I need.
Approach A:
(4 x View Controllers - root, menu, study, review)
This approach has a root view controller with no on-screen controls. It will always contain one of the other view controllers as a subview. For some reason I am attracted to this approach but I have seen no other examples of this so maybe I am being stupid. I am wondering if there is a reason why this is inherently wrong.
Approach B:
(3 x View controllers - root (menu), study, review)
In this approach the menu IS the root controller and the other controllers load in subviews of the menu. I think this is more of a standard way of doing things.
I would be grateful to hear any thoughts on which approach is best. I am a newbie to software development. I have worked through a number of books on iOS software development and messed around for a bit and now I am starting my first app for iPad.
Whenever you're determining how to layout your views and controllers, they're very often based on the application flow (from an end user's standpoint). So from your original question I'm not sure I exactly understand the flow- is the user forced to start at the main menu, and then from there is able to toggle between two mutually exclusive views (study & review)? If that's the case, I would recommend using a tab bar controller for the 'Study' and 'Review' views, as it allows for saving states of the views and switching between them without you having to do any extra work (from both of the approaches you described it sounds like you'd largely be recreating this behavior yourself). Then, for the main menu (which I assume is displayed when the app first starts?) You can simply open it modally (note you don't have to animate the opening, so it can instantly appear instead of sliding up from the bottom, and the user will never be the wiser). Once the user selects what they need to select in the main menu, dismiss the modal view and you're ready to go with your 2-tab controller.
Related
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.
I am a beginner at best when it comes to xcode, iOS, and objective-c. I have been working on a project that has had me looking up information a lot. I have already been learning a lot, but I realized lately that I have forming some bad practices.
I have used Storyboard to lay out the abstract view of the app. The first thing I noticed I was doing dealt with popover views for iPad. I did not know how to dismiss them via button press, so I was creating a new modal segue from the popover button back to the main view.
I realized that this was creating a new view and placing it over my existing view. This would start to chain until the program eventually crashed. Last night I learned the importance of delegates and how they can help me gracefully dismiss the popover view.
Based on the documentation I have read for modal views, it appears that I need to be dismissing those types of views as well.
My question regards to proper practice when building an app. What if I have a ViewController that has 10 buttons, each of which will spawn a popover that is similar yet features slightly different content. Is it OK to create 10 new views in storyboard and drag and drop the UI elements on there? This means that the main view controller is going to have 10 delegates, one for each.
OR would it be best to create one general view, load the content dynamically, and only worry about one delegate in the presenting view controller?
EDIT: As far as the differences between them, they each have a list of labels (questions) and a UISegmentedControl to match the label. This will allow the user to fill out a survey. There are currently 10 views because I have 10 sets of questions that I feel deserve different views. At the bottom of each view there are 4 buttons. Every view must include these 4 buttons.
It's "ok" but not practical to have those 10+ delegates. If these ViewControllers only differ slightly - have you considered creating a "base" view controller and then adding/updating some of the differences programmatically depending on the content? I think it all depends on what you want to display and how much these differ. I would definitely not recommend 10+ delegates all delegating back to the same controller.
Basically, I'm saying yes to your "OR" question.
I am trying to have the ability to switch views in and out. The screens are generated on the fly and there may be anywhere from 30-100 of them that will be presented sequentially. A NavigationController may work, but I may be creating a hundred or so screens so I am worried it will run out of memory if I push that many views. Maybe this could work if I only ever added one screen at a time to the NavigationController, and when a new one is added remove all screens and then add the new one. But this may cause strange animations.
I tried creating a custom View Switcher that could load each of the views on the fly following the chapter 6 example in the apress book. The problem is that on rotations the events do not make it to the View Controller for the currently visible view. So it ends up doing weird things on screen rotations.
Another approach that I am thinking may work is to use a tab bar controller and make the tabs invisible. Then I can just use tabs 1 and 2 to hold the current view, and the last view and ping pong back and forth. Then memory is not as much of an issue as using a NavigationController.
Does anyone have any other ideas? I feel like there should be an easier way to do this that I am just not seeing.
How about creating a singleton "ScreenManager" that loads, adds and removes your views on your root view controller? This way you can make sure that the view hierarchy isn't convoluted and out of your control. It's also a good idea design-wise and should be very easy and efficient with memory management.
The Flow of my application is
Application Starts -> TopMenuViewController ( Which Contains Several Buttons & navigation controller ) -> When particular button is clicked -> Load Split View Controller.
The user can go back to TopViewController. In short I want to load UISplitViewController on button click. How to do this? Thanx in advance.
In my experience, there's no good way to load a UISplitViewController on demand like that. It has to be the root of your entire user interface, or you will pull your hair out trying to make things work.
I've reworked several app designs to fit into this requirement, and it's generally not been difficult at all to come up with something functional and attractive which fits into the split-view-at-all-times paradigm. You can freely swap the views loaded into each side of the split with login panels, empty placeholders, etc. to make your flow work with the splitview.
There are third-party split view controllers that mimic Apple's and allow later loading (as well as master pane visibility in portrait, and other features). One is Matt Gemmell's MGSplitViewController. You could also come up with a different presentation altogether for your master-detail hierarchy.