I'm at a point in the development of the app I'm working on where in order to complete the assignments given to me, it seems like the best way to accomplish what I need is to combine a UINavigationController with a UITabBarController.
Structurally, the app has a home page, and the rest of the app is navigated through the UITabBarController. This is a sound design for the original, but when I took over the development process of this, I had to make a lot of additions to the app, and there's technically supposed to be a "second" section which adds extra "features" if you will that aren't necessarily related to the main functionality of the app itself.
Basically, since everything begins at the Overview, the user is supposed to have a choice between just diving into the app itself, or using some of these extra features. I'm thinking the Navigation Controller would be fitting for the extra features, but I'm not sure how I can add to it.
What I need to know is - is this solution to the problem sound? If so, what's a good way to accomplish this? Is it ok to have a separate UIWindow class to link the Navigation Controller up with the TabBar Controller?
Granted, this app has used a lot of nib files, and every time I've tried to do something programmatically, it just hasn't worked. Thus, if someone could point out a NIB method of achieving this, I'd appreciate it.
According to Apple recommendation, UITabBarController should always be the root view controller of your app. So basically your main view is just one tab of your tab view controller, and so you just need to embed your main view controller in a navigation controller. This way you can navigate to whatever page you wish within that tab using the navigation controller, or you can go to other tabs using the tabbar controller.
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.
I'm new to iOS programming and was wondering, should you only use a navigation controller if your entire app will be embedded in it? I've embedded view controllers for login/signup screens and was wondering for the actual game play controllers, is it bad practice to navigate to an entirely new view controller? Or should I push to another screen in the navigation controller to start a new game etc...
Any advice will be greatly appreciated. Thank you.
I think that the best practice to use UINavigationController is to use them whenever you want to able the user to go back, and/or if you want to add bar buttons to it (For example to add new items, to perform a search, to open settings, and so on).
You can even work with several navigation controllers in the same application according to your needs. You want to understand first the flow that your application will have.
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 looking to create a subview that looks like a banner drop down view from the Navigation Bar.
or like this
I feel like I see this effect all the time but have been struggling for a while to recreate this. I have it working on single view applications but I would like it to stay in place as I navigate from view to view. Right now I have the view setup in the storyboard and would like use this because I had issues attempting this programatically.
To create this "drop down banner view" and have it stay in place (until the user dismisses it) as a user navigates from screen to screen I see two solutions, each of which I have stumped myself on.
Create my own master view as the window.rootViewController
I see this as the cleaner solution in the end, but a bit harder to implement. Would it be possible to create a blank UIView as the rootViewController and whenever the app needs to drop down an alertBanner it could tell the rootController to do so? The view hierarchy would be something like
window -> masterViewController -> alertBannerController -> Navigation Controller -> otherViewControllers
but I cannot seem to have this set up the proper way.
Create an instance of my AlertBannerView from a subclass of the UINavigationController
Instead of calling the method to create a dropDownBanner from the rootViewController another option I see is subclassing the navigationController to be able to drop down this subview. This way it could still persist as the user navigates around views.
Once again I am having problems setting this up properly to work with the existing NavigationControllers
Conclusion
I do not know what is the best approach here.
This is different than the Apple Push Notifications drop down screen because I would like to customize it for the apps UI
Any tips on how to properly set up a custom view as the rootViewController would be great (where do I do this? what methods do I need to call?)
The problem to solve here is to have the alert banner view remain in the window until the user dismisses it even if they are navigating from screen to screen.
Thanks!
Depending on which version of iOS you're working with, yeah there are a lot of possibilities and ways of doing this. In fact, there are a lot of people who already have.
Best place for getting some ideas on how to attack this problem, to me, is by looking at an existing solution. CocoaControls is a great place for this.
For instance, here is a relatively recent one: https://www.cocoacontrols.com/controls/mpgnotification
And here is a list of a bunch of them ( they aren't sorted in any particular order unfortunately though ) : https://www.cocoacontrols.com/search?utf8=%E2%9C%93&q=notification
I'm just getting back into iOS development after a year or so away and am looking for a way to have a single view above or below a UITabViewController view. The idea is to have one ad view that is used throughout the app instead of one on each tab. The constant reinitializing of the ad view seems like it would be a lot of overhead so having one persist throughout would seem to be more effective.
I've searched for this but not found much of anything so even a useful link would be appreciated.
Thanks in advance,
Jason
I see several approaches here:
Since you are setting up your view hierarchy in your application's delegate, I'd suggest creating a separate UIViewController and managing it from your app delegate. That way you can show/hide it in the main UIWindow, without having to do much work.
You can subclass UITabBarController and show the ad in the visible view controller. This is more work, but your app architecture is arguably cleaner, because your app delegate doesn't get cluttered with ad-related code.
Another option is to look into a UIViewController category, where you can manage add related code. Not necessarily the cleanest, but it keeps the ads out of both your app delegate, and your tab bar controller. (You'd add the ad view as a category property via runtime level calls and associate objects, but that gets messy.)
I'd probably go with the first approach if it were me, but I could argue for either of the other two approaches, since an ad view doesn't really necessitate it's own view controller.
How about create a parent view controller and each view controller inherits from that parent view controller? Parent view controller has a ad view or table view, so every child view controller will has those two view as well.
Okay, after spending some time trying to create and manage a customer view controller for this I stumbled on the Container View Controller capability Apple added in iOS 5. I have no need to support iOS 4 or earlier so this works good for me. There's a good description of it here (unfortunately the author never wrote part 2 with a tutorial):
Container View Controller description
And a decent tutorial is available here:
Container View Controller tutorial
Between the two of these I was able to create a good setup with an AdViewController and BodyViewController (TabBarController) contained in a Container View Controller. This gives me all the capabilities I need (at least so far).