I have a situation here which I am trying to resolve, but it seams I am missing something.
My architecture of the application is as following:
AppDelegate (TabBarController)
Navigation Controller
Viewcontroller one
Viewcontroller two
Viewcontroller three
Viewcontroller
Since I have lot of text validations and scrolling enabled, I am using a custom uiscrollview for viewcontroller one, two and three. In the custom uiscollview I am utilizing the code from Apple which causes scrollview to scroll if the textfield is being hidden behind the keyboard. The problem which I am occuring at this point is that I have the viewcontroller one working fine, but when it comes to viewcontroller two and three, it does see's that custom view controller after debugging, and reaches the point of "setContentOffSet" but not animating the scrollview, but just displaying the keyboard.
If anyone had this issue before, I would like to see what might I be missing here?
I have a navigation controller that works with two UITableViewControllers. The first UITableViewController shows the user a list of their picture libraries, and when they tap a cell, the second UITableViewController gets pushed on the stack and displays the pictures in the library (much like a UIImagePicker). What I want to do is, when a user selects a photo library on the initial UITableViewController, I want the navigation title to not animate, while the transition of UITableViews does animate. Is there a way to accomplish this, or do I need to implement a UIViewController that swaps in two UITableViews (upon then I'm not sure if I'd be able to edit the back button after the second UITableView gets swapped in?).
I'm pretty sure that the easiest way would be to add two UITableViews into a UINavigationController's view and just animate them with [UIView beginAnimation] in a didselectrowatindexpath. You should also have a flag to save a view state - either a library picker view is shown to user or an image picker. Then you'll be able to handle this properly in a back button selector.
That's the easiest way IMO.
I'd recommend one UIViewController and animating the frames of the table views to transition between them.
I have a UINavigationController App. I want to add a small bar just below the UINavigationBar, around 20px height. y application is almost finished, so I want to rebuild as less code as possible. For example, if I wanted to add a button in the bottom of every view of my application, I can do that by extending UIViewController with a category, and adding a UIButton as a subview of the current controller view, maybe in the viewDidLoad method.
This approach works fine, and so I can add my UILabel to all my views at the top of them. The problem is that it does not TAKE SPACE. It is always on top of my previous views (UITableView...). What is the best way (or just one way) to accomplish such a thing without having to create for example a view with 2 frames, and having all my main views extending it?
I thought of changing UINavigationBar height, but that is definitely not an option.The prompt property of UINabivationBar is just to big (around 30px).
I also tried to create a new view in the viewWillAppear method of every UIViewController, adding to that view my breadcrumb subview, and the original view, but it is not working.
Any ideas on this?
Thank you!
If I were you, I'd make a new UIView subclass to represent this thing, and embed it on the views of the individual UIViewControllers. They can get at the navigation stack by looking at the UINavigationController's .navigationControllers array, walk that and get view titles, etc.
In my app , i have UIScrollView in bottom of the page where it contains list of UIViews. i want display the same UITableView with same contents on all the views. Can any one help me out of this?
What you need in fact is the opposite : having one viewController managing your table AND a list of sub viewControllers managing your views. The the main controller load subView depending on the row selected (a bit like the tabviewcontroller does).
I have always sort of wondered when to use a UIView vs. a UIViewController on the iPhone.
I understand that you shouldn't use a UIViewController unless it's a full-screen view, but what other guidelines are there?
For example, I want to build a modal overlay - a screen that will slide into place over the current screen. If this modal overlay is full-screen, should it be a UIViewController? The last time I built something like this, I subclassed UIViewController, but now I wonder if that was correct.
From Apple's View Controller Programming Guide for iOS:
"The most important role of a view controller is to manage a hierarchy of views. Every view controller has a single root view that encloses all of the view controller’s content. To that root view, you add the views you need to display your content."
Also:
"There are two types of view controllers:
Content view controllers manage a discrete piece of your app’s content and are the main type of view controller that you create.
Container view controllers collect information from other view controllers (known as child view controllers) and present it in a way that facilitates navigation or presents the content of those view controllers differently.
Most apps are a mixture of both types of view controllers."
This is a great question.
My basic rule of thumb. Is that every major 'page' of an application gets it's own view controller. What I mean by that is that during the wire framing stage of application design, everything that exists as its own entity will eventually be managed by its own View Controller. If there is a modal screen that slides over an existing screen, I will consider that to be a separate 'page' and give it its own view controller. If there is a view that overlays and existing page (such as a loading screen or help popup.) I would treat those differently, implement them as UIView subclasses and keep the logic in that 'pages' view controller. It the popup has behavior I will communicate back to that pages View Controller using the delegate pattern.
I hope this helps. It is very much a philosophical and architectural question and much could be written about it.
I use UIViewController whenever a view is full screen and either has outlets/actions and/or subviews.
Put everything on a screen into a UIViewController until the view controller starts to have too much code, then break out the screen into multiple UIViewControllers contained by one master view controller...
To put that into context of your answer, make a view controller for that modal overlay. It will have one anyway if you are using a nav controller to present it (and you probably should).
I have a somewhat different approach:
Override UIView if you plan to do custom drawing in drawRect. Otherwise, subclass UIViewController and use [self.view addSubview: blah] to add the components of the page.
There are a few other special cases, but that handles about 95% of the situations.
(You still will often need a UIViewController with a custom UIView. But it's common to have a custom UIViewController with no corresponding custom UIView.)
Is the thing that slides in a self contained screen? I mean, does it directly interact with the parent? If so, make it a UIView, if not, probably recommend a UIViewController.
A UIView is part of the UIViewController see the view property of UIViewController for this. As you pointed out correctly UIViewController manages a complete screen and there should be only one visible UIViewController at a time. But in most cases you will have more UIViews or subclasses of UIView visible on the screen.
The example you gave would be a correct use in most cases. As you may have noticed you will get a lot of functionality when subclassing the UIViewController. Animating the appearance and dismissal of the UIViewController would be one of them.
As marcc pointed out if the thing you want to slide in is not a self contained screen you would be better off using a UIView.
As a conclusion I would say that if you want to use the functionality that comes with subclassing UIViewController than go for it make it a UIViewController. Otherwise a UIView might be better.
The itunes U Standford class has a great lecture on UIViewControllers I would recommend watching it, because it has a lot of information regarding UIViewControllers in general.
If you are familiar with the MVC pattern, then you should be able to understand the difference between UIVIew and UIViewController. To make a simple statement, UIView is for rendering UI elements on screen. UIView is the superclass of pretty much all Cocoa Touch UI elements. Those elements do not know what information they are supposed to display, what they should do when a user clicks a button, what happens when an async network request is completed and so on. UIViewController is for all that and more. The view controller is responsible for placing the UI elements in the correct locations on screen, setting the contents of the UI elements, handling button presses and other user inputs, updating the model when needed etc.
Conceptually, a single UIViewController controls the contents of the whole screen in an iPhone App and that is why it is often easy to think of things in terms of view controllers. If you need a view where the user can select ingredients for a food recipe, you'll need a UIViewController for that. I made this distinction for myself because coming from a Java background I wasn't used to the framework enforcing MVC. I would think of things in terms of UIViews, and start implementing them that way and then run into all sorts of trouble because of that. If you are going to stick to UIKit for your App, then the workflow Apple has made for you is: for each separate view in your App, create a UIViewController subclass and then use Interface Builder to place the UI elements and to create connections for buttons etc. It works wonders, saves a ton of time and lets you concentrate on making your App function well.
I use UIViewController for showing View on full Screen.
For better control on custom view I prefer subclass of UIViewController instead of UIView, earlier I was using UIView for making custom sub class.