I've been able to incorporate all of Apple's code, delegation, etc related to iAds, in simple view based applications.
Tab bar type applications seem more difficult, perhaps I don't understand the overall architecture of those apps. It seems that, say, if there are 3 tabs and views corresponding to those tabs that the other tabs sort of inherit or are attached to the first tab.
When working in interface builder, it seems that dragging an adbanner into the windows actually replaces everything that is there and building some kind of view container to put the "tab infrastructure and associated views" and an iad doesn't seem to fly.
I'm able to code by hand the pop of an ad in my code, which shows up when running the app under the first tab, but it doesn't show on the subsequent tabs, I was doing this in viewDidLoad. It seems the tab bar apps want to sort of own the entire screen realestate to some extent. Any thoughts? There's a UIWindow and the TabBarController, the window seems largely "blank" and otherwise purposeless.
What I would do is create a separate custom view, which you push onto your enclosed view in each tab just as part of the viewDidLoad process.
Related
I have a tab bar app that I want to add a banner ad to. I have read another answer about how to add the ad, but it didn't talk about where. It seems the most obvious position would be between the tab bar and my content, but it seems a little disruptive to put the ad between two parts of my interface. I could also put it at the top of the screen, but there are reasons why I don't prefer to do that.
Is there a way I can move the tab bar up to make space for the ad?
Changing the frame of a tabbar controller's view is really painful.
I once considered doing it for some reason and found Adam's answer to Subclass UITabBarController to adjust it's frame very helpful.
But keep in mind that UITabBarController is doing a lot of magic behind (like resizing itself and its view controllers' views at different times) and that it may change with future versions of the OS.
Changing the default behavior of Apple's UI components can also be ground to AppStore rejections (so far I've never seen iAd banners put below the tab bar.)
I've yet to find an example that does this. A client wants a navigation-based app where two sections (one nav-screen each) need to have a few views, controlled by a tab bar. I'm having difficulty setting up the logic of connecting all of the elements and making sure the flow makes sense (ex. hitting the nav-bar's back button on any of the tabbed views will lead back to the same screen).
I answered a similiar question not long ago (if I understand your question right). This will add a tabbar as a rootcontroller and each tab has its own navigationcontroller.
Right design pattern for tabbed navigation views?
EDIT
From UITabBarController documentation
Because the UITabBarController class inherits from the
UIViewController class, tab bar controllers have their own view that
is accessible through the view property. When deploying a tab bar
interface, you must install this view as the root of your window.
Unlike other view controllers, a tab bar interface should never be
installed as a child of another view controller.
As #Jolly good has mentioned, Apple HIG suggests not to do such implementations.
The only other way I can suggest is to try implementing a custom view controller that looks/behaves like a tabbarcontroller and make use of that.
Another hack I can think of, not sure if it'll work or if its possible, create a tabbarcontrller the usual way and then set the hideBottomBar property, and make the bottom bar visible only when you want it to be visible.
It is possible, despite the documentation that #Jolly good cited.
As a real world example, let me describe a game of mine. It consists of a UITabBarController (UITBC) and UINavigationController (UINC). The "main" window of the game is the Root view of the UINC, and when the game is active, it hides both the tab bar and nav bar to maximize screen real estate (not as necessary for iPad, but still...).
When the game is idle (paused, between rounds, etc.), it pushes the UITBC onto the nav bar. It also tells the UITBC to make a particular VC selected. That allows access to the additional screens (About, Scores, Instructions, Settings, etc.), and the player can navigate using the tab bar. In addition to the additional views on the tab bar is the game controller that simply pops the UITBC from the nav bar to revert to the game view to un-pause, go to next round, etc. (Obviously, the UITBC is cached within the game VC so it can be pushed back when necessary.)
Using this sort of logic, it is possible to mix and match tab bar and nav bar controllers for complex navigation. You can get away with this for games; just make sure that any non-game app follows Apple's HIG so as not to confuse the user.
I hope this helps.
I'm building an iPhone app and I'm sort of confused about which approach should I choose for views and controllers.
I would like to have a tabbar at the bottom with three options. I would also like to have a main view displayed when the app shows (along with the tabbar) but I don't want this view to be part of the tabbar options.
So, when the app begins, the tabbar has no option selected but the main view displayed. When a tabbar options is selected, in its top bar it should display a back button to the main view. When the back button is pressed, the main view display again with no tabbar option selected.
Which approach should I choose?
Hope it makes sense.
Thanks.
I understand what you're trying to do, but you shouldn't do that. I don't like that design at all. You should have one navigation controller for each tab.
You should probably read Apple's Human Interface Guidelines as it's possible they would reject your App if they thought such an implementation with a TabBarController was confusing.
As an alternative, you could possibly have the "main view" as you call it accessible with a button in the Navigation bar at the top and then add that to all three tabs. Not necessarily a better design but you probably wouldn't be breaking the guidelines.
A better alternative might be to use a UIToolBar at the bottom instead of the Tab bar which has the three buttons spawning your views modally which can then be dismissed as you suggest.
Remember though, your App's users have built up a knowledge of how App's are generally supposed to navigate, feel and control so you should think carefully before deciding to go against that.
Firstly, I think you should reconsider giving your Main View it's own tab. That way it's a no-brainer for the user to return to that screen. BUT, if you STILL don't like that idea, read on...
The UITabBarController has the unfortunate side effect of not being able to be removed once created (even if you delay it's creation by instantiating it programmatically).
SO...
Option 1: Make your MainView a modalPresentation sub-view, displaying it ON TOP of one of the views in your tab bar (hiding the tabs until you're ready to show them again).
Option 2: Give a subview of your first tab a...
mySubViewController.hidesBottomBarWhenPushed=YES;
This will make the UITabBarController disappear temporarily (just on that view, until you're ready to show the tabs again).
Both options seem kinda messy to me, but they are possible. Depends on how well you execute them, I suppose.
Hope this helps!
You could add the main view as another tab.
OR
You present the main view modally when the app starts over the tab bar views.
The first option would be used more if the view holds the same kind of content as the tabs, for example if the app was an online store, the tabs would be Categories, Search and Recently Added, with what you call the "main view" being the Home page (showing offers or something). (So all the views/tabs would be showing products on the store)
The second option would be more if the content of the main view is different to the tabs.
Keeping with the online store example, if the tabs were Categories, Search and Recently added and what you call the "main view" being a login/logout screen. (so the tabs would be showing products, but the modal view ("main view") being more admin related, and it's main purpose not being to display products.
XCode: "This template provides a starting point for an application that uses a single view. It provides a view controller to manage the view, and a nib file that contains the view."
What does that even mean? (ie what does Single view actually mean)
1) This means that your application will only have a single view screen that is active
2) This means that your application will be able to have as many screens as you like using a single view controller.
Ok now what if your application has multiple screens? not a single view screen, is still suitable under a view based application template?
Example
Screen1(main): on this screen you have 3 buttons, "Open Form1", "Open Form2", "Open Form3"
When the button is clicked it opens up the associated screen,
Press the "Open Form1" button opens up "Form1" screen2
Press the "Open Form2" button opens up "Form2" screen3
Press the "Open Form3" button opens up "Form3" screen4
When the user completes the form and submits it, a thank you screen is displayed
therefore in this example there would be a total of 5 screens.
Each form screen contains is different, textfield inputs, and information, is this considered as a view based application?
View-based app is just a template to say that your app will be view-based. That means that you can have any number of views you want, as this template comes with a view controller (that, as the name says, can be used to control the views... show/hide them with animation, for example).
The template starts with ONE VIEW that is added to the app view controller. You can add any number of views to that controller.
So, yes to your questions. You can use this to create the app you mention, where any of the "screens" you mention would be a view, for example and you can show each one using, for instance, the app view controller to animate each view showing or hiding.
That means the template will create one view and corresponding view controller along with app delegate, main window. That will also do the necessary things to add this view to main windows, and load when app runs. This is just a template. Then you can crate any number of views and view controllers as you want.
This means that the template you are starting the project with provides a single ViewController, and associated XIB for the View. As the first answer says you could use this template to build the application mentioned.
HOWEVER you may wish to think about how the user is going to interact with your app. Will you allow stepping back and forwards through the screens, in which case you may want to consider the Navigation Based app where you push/pop screens onto a stack to allow easy movement between then.
You might also have a concept of allowing the user to jump at will between each of the screen pages in which case you might want to implement a TabBar application.
Or you could just implement it all yourself. At the end of the day it will be your application design, and the template is only a starting point to get you going. I would suggest that if you are starting out with iOS development however to go with 1 ViewController matched a XIB for each screen you wish to implement to keep things simple.
I have a fairly simple iPhone application that I want to have run on both the iPhone and the iPad. I'd like to just have the iPad version be a bigger version of the iPhone version, scaled up or not -- I'm working on an iPad-specific version of the app that makes better use of the interface, but wanted to make sure my existing customers have something in the meantime.
The app is a simple tab-based application, and within each tab is a navigation controller that presents a table view, each of which can drill down a couple of layers. Everything mostly works -- I have a couple of instances of views not filling the space available, but I can fix that. My biggest problem right now is that the navigation controllers universally break when I try using them. Once I drill down a level or two, I suddenly won't be able to come back up again.
Let me try to explain in more detail:
One tab starts off with a "year" table view, showing all years that have entries; if you tap a year, it pushes another table view with all months in that year that have entries; if you tap a month, it pushes another table view that shows the individual entries; if you tap an entry, it pushes a view (a UIWebView, with some extra widgets) that shows an entry's details.
Each push is done with [self.navigationController pushViewController: foo animated: YES]. The three table view controllers I mentioned above are all created from the same nib (in fact, everything pushed onto a navigation controller in any tab is loaded from the same nib). Since I know there are only up to three levels of navigation, I just allocated three identical view controllers and use one, two, or three depending on how many entries there are.
Popping these controllers off using the "back" button seems to universally mess up the state of the view controller. So, if I drill down to the third view -- showing everything in a single month -- I won't be able to pop all the way back up to the first view: the back button stops working if I pop up one level.
Another example in another tab: it's one table view that you can tap any entry on, and a new view controller will be pushed that shows the details of that entry. If I tap an entry, tap the back button, then tap the entry again, no back button appears, or sometimes, the text that would go inside the back button appears, but no button appears!
This behavior happens if I try running the iPhone app in scaled mode (built with base SDK 4.0, supporting OS 3.2) or in native mode (built with base SDK 3.2). It runs without problems on the iPhone. I'm kind of at a loss here, because this stuff always "just worked" out of the box, mostly from the defaults that were set up back when I first created the project.
My programmer's instincts are telling me that I'm doing something very wrong in my view navigation, and that the iPad is just exposing it, but I can't figure out what it is.
Has anyone run into an issue like this, or suggest something it might be or some better way to debug what's going on?
The issue was that I had a category on NSMutableArray, which added stack-like methods push and pop. Removing this category class fixed this issue.
WTF, though.