Im new to iOS development, and Im developing an app the uses a lot of UITableViews. I am having a hard time wrapping my head around how Im going to accomplish this app.
I am going to have the user be able to add cells to a table view, and for each cell, I need a UIViewController (this view controller will look the EXACTLY same for every cell) that will save data.
So my question is how can i write the code to create a view that only cooperates with one cell, but has the same interface for all the other cells? (The view im talking about is when the user drills down on a cell, it allows them to input some data).
Every "drilled down view" is the same, but they all must work uniquely with the cells of the table! I am having such a difficult time with this one, and any help would be greatly appreciated, if anyone knows of a tutorial I can check out, that'd be great! Thanks again!
Generally you would, if at all possible, have two view controllers, your table view controller and your detail view controller. You'll often hear this described as a "master-detail" (the table view controller being the "master"). Your table view controller will, when someone selects an item from the tableview, trigger a detail view controller, passing it the necessary information.
You would only consider different detail view controllers (what you call the "drilled down view") if the nature of the view is structurally different from each other. Thus, you would have one detail view controller for each "type" of detail view, and you'd just pass it the necessary information to present the appropriate details. You haven't provided enough detail in your question to let us ascertain whether one detail view controller would be sufficient, whether you'd need a few, or whether you really need unique detail view controllers.
For more information on view controllers, I'd suggest you go through the ViewController Programming Guide as a more detailed discussion of how to construct master-detail apps is probably beyond the scope of this forum. You can probably also google "iOS master detail tutorial" and get tons of hits.
Related
I have a very large form to build in my ipad application and I'm note sure which approach( between create multiple views in or multiple viewcontrollers ) to follow. Well, I have decided to split may form in logical sections, so I want use a splitviewcontroller with a root( a tableviewcontroller with the sections) and multipleviecontrollers for each sections. When the user select a row in tableview I will show the correspondent viewcontroller. I'm saving a reference for each viewcontroller in my app_delegate and the app_delegate also is the responsible for change the viewcontrollers. Is this the best approach? There is other approach to follow? About the multiple view I was thinking to put multiple view in the same xib file and then choose based in tag as the use tap the row in rootviewcontroller's tableview.
Thanks in advance. And sorry for my bad english.. Learning!
I will say this on the subject: currently, having multiple view controllers on the screen at the same time can be problematic if you're not using one of Apple's existing classes, such as a UISplitViewController.
The main issue is that important events your view controllers will want to respond to (rotation events, etc) won't be passed down to them. It's not a huge pain, it's just something to need to take into account - you'd typically create your own parent view controller that could pass these events down to its children.
Now, you are using a split view controller, so alls well on that front. There is no provided way for detail and master controllers in a split view controller to communicate with each other, but Apple recommend you employ a standard delegation pattern. If your application is fairly simple this could certainly happen in your app delegate as you do now.
If you're targeting iOS 5 only there are some changes that are relevant regarding multiple controllers on the screen at the same time, but I can't discuss them on here because of the NDA. You should go to Apple's developer forums (devforums.apple.com) to learnmore.
Sounds like I'm trying to do the same thing as you (large insurance forms here, how about your project?) Unfortunately I can't help out as you're a bit ahead of me. I've been able to flip back and forth between 8 detail views by tapping on the 8 rows in my UITableViewController, without keeping a reference to either the current or previous one anywhere. The data I enter into various TextFields stays where it should.
I currently have a xxxViewController.h/.m and corresponding .xib file for each detail view. That's an awful lot of code, but I couldn't see any other way to do it. Now I'm having a problem getting my button pressed handlers to fire. Also I've still got to put a database behind these screens.
Were you able to overcome your issue?
Thanks,
Jeff in Alabama
I want to hear developers opinions on the best way to swap views on the iphone.
For example, I have a tab bar and one of its tabs defaults to a login view. When The user logs in the view changes to a logged in view.
I was going to just use one view controller and have all the content in one xib hiding and showing content as needed but this seems in no way elegant.
Secondly I was considering having one viewcontroller and simply swapping the xib. I'm a litle reluctant to try this as I've read in an article or 2 that it can lead to memory leaks.
Finally I was considering using 2 view controllers with with 2 seperate xibs. My gut tells me this would probably be the "proper" solution but I so far have failed to hunt down any sample code on the correct way to do it.
Can you offer advice on the best way to solve this problem?
Is there a technique that I have not listed?
Thanks.
I would keep the logic for which view to show in the view controller. The XIB is the view itself, and should have no objects in it that are transient or not always visible for that particular view.
Your second approach (of swapping the views) seems to be the right approach to me, and is always something I, personally, do in these situations. I am not aware of any memory issues if you do it right (remove from superview, followed by loading the new view as a subview of the controller's view). You could perform any custom initialization once the new XIB has been loaded and before showing it to the user.
Multiple view controllers just seems superfluous as then you would ideally require another top level controller to manage the two view controllers.
I'm in the process of learning and designing an app for our company. At its heart, it has a list of "alarms" which when clicked on, goes to a more detailed view with a toolbar to perform tasks upon that "alarm".
I'm having a devil of a time working out how to structure this application. I have something that works currently (i'll explain it in a sec), but now I'm about to hook up the data source for the table and I'm getting myself lost.
At the main screen, there is to be a list of "alarms". This list should be able to be filtered with 3 categories (All, Category 1, Category 2) where the categories are subsets of all the "alarms". I've implemented this using a TabBarController.
Within each tab, I've got a NavigationController (to handle the navigation of between the list and the details) and it's main view is a custom UITableViewController that contains the custom table view.
As described, when you click a item, it navigates to a detailed view. This is all currently working but I'm concerned about the structure.
It's pretty obvious that I have a fair bit of duplication with the 3 different NavigationControllers, but I've read that subclassing the NavigationController is not recommened.
My questions are:
Is there a better way to structure this application? Is there a better filtering method (thats quick and easy) instead of a TabBar?
Where should the tableview datasource go? Most examples I've seen have it being created in the AppDelegate and then passed directly to the tableviewcontroller. My custom tabelviewcontroller is a couple of levels down the controller chain, how do I pass the datasource to it, or can I make the datasource "static"?
I hope that all made sense
Sounds as though you want one navigation controller and table view controller with a segmented control at the top to switch between the different data views. For an example of this kind of layout have a look at how the App Store app works when you select the Featured tab - it has a segmented control to switch between New, What's Hot and Genius.
I am trying to wrap my head around controllers in Cocoa Touch. The main problem is that I would like to have more than one controller “on screen” at once – I want to have a large view (with controller A) composed of smaller views controlled by their own controllers (say B). I’d like to have it this way because the division makes the code much cleaner. What’s bad is that the additional controllers (of type B) are not “first-class citizens” on the screen, for example they do not receive the autorotation queries and notifications. (And cannot easily display modal controllers, they have to send the presentModal… message to their parent controller.)
What is the difference between the A and B controllers from Cocoa viewpoint? Does the system keep some kind of pointer to the “frontmost controller”, a privileged one to which it sends notifications and such stuff? Why don’t the other controllers receive them, even though their views are on the screen? Is having multiple controllers “on screen” considered a hack? Or is it supported and I am just missing some point? Thank you.
More about the problem I am trying to solve: I am writing a simple photo browser. Photos are displayed in full screen, user can swipe left or right to change photos. The A controller takes care of the scrolling part and the B controllers take care of each photo itself.
Isolating B seemed like a good idea, since the photos are loaded from network and there is a lot that can happen, like the network might be down et cetera. In the B controller the code is fairly simple, since B only works with one particular photo. If I moved the code to the A controller, things would get messy.
The only thing I don’t like about the current solution is that I have to manually work around B not being a “first-class” controller. I have to pass some calls manually through A to B and when B wants to display a modal dialog, it has to send the presentModal… to A. Which is ugly.
There is now a first-class support for this scenario since iOS 5, it’s called controller containment.
swift controller containment
objc controller containment.
It's not closely related to the original question but important. Apple clearly states in View Controller Programming Guide that a view controller is responsible for controlling exactly one screen's content:
"Each custom view controller object you create is responsible for managing exactly one screen’s worth of content. The one-to-one correspondence between a view controller and a screen is a very important consideration in the design of your application. You should not use multiple custom view controllers to manage different portions of the same screen. Similarly, you should not use a single custom view controller object to manage multiple screens worth of content.
Note: If you want to divide a single screen into multiple areas and manage each one separately, use generic controller objects (custom objects descending from NSObject) instead of view controller objects to manage each subsection of the screen. Then use a single view controller object to manage the generic controller objects. The view controller coordinates the overall screen interactions but forwards messages as needed to the generic controller objects it manages."
However in iPad Programming Guide they also say that there may be container view controllers:
"A view controller is responsible for a single view. Most of the time, a view controller’s view is expected to fill the entire span of the application window. In some cases, though, a view controller may be embedded inside another view controller (known as a container view controller) and presented along with other content. Navigation and tab bar controllers are examples of container view controllers."
Up to my current knowledge I would not use sub-view controllers in a view controller but try to subclass NSObject and send messages to them from my main view controller.
Also check this thread:
MGSplitViewController discussion
First, and this is important, view controllers don't get "on screen" -- views do. Your "top level" controller can certainly pass along the kinds of messages you're describing to its "sub-view-controllers". In fact, this is how most apps work. Consider an app that has a tab bar, and where the views use navigation controllers. You actually have several view controllers "running" at the same time, each with its own view on screen at once -- your "root" view controller will be an instance (or subclass) of UITabBarController, which then has several nested UINavigationControllers, each which will display nested view controllers (like an instance or a subclass of UITableViewController).
You might want to read up a bit on how responder chains work. Consider a touch event. It will be generated for the view closest to the top of the stack, that can receive events, which is also underneath the tap. If that view can't handle it, it gets passed up the view hierarchy food chain until something deals with it (and then eats it).
As to the specifics of your question, on the whole, I'm not sure exactly what the strategy you describe is really doing to benefit you in terms of complexity. It depends on how exactly you're implementing things, but having separate view controllers for each little subview may require more bookkeeping code than just having one view controller that knows about all its sub-view components.
This is a pretty old question, but since I guess there are people who might face the same problem today I'd like to share my solution.
I was writing this application that had this one screen with a lot of information, pagination, controls etc. Since according to Apple's MVC documentation on the role of ViewControllers, you should not implement the logic in view itself, or access the data model directly from it, I had to choose between having a Massive ViewController with a few thousand lines of code which was both hard to maintain and debug(even with unit tests) or find a new way.
My solution was to use UIContainerView like below:
this way, you can implement each part's logic in it's own ViewController, and the parent view controller takes care of constraints and sizing of the views.
Note: This answer is just a guide to show the way, you can find a good and detailed explanation on how it works and how to implement it HERE
Actually you can make it work earlier than iOS 5, since most of us are targeting 4.x and 5.x at the same time. I've created a solution that works in both, and it works great, few apps in appstore use it :) Read my article about this or just download and use a simple class that I've created for this purpose.
Can someone explain to me the advantages of a UITableViewController over a UITableView? Generally, I use the controller but the basic table view seems a lot more flexible.
I always use UITableView. I never use UITableViewController.
Using UITableViewController is confusing. Each controller is supposed to do one screen except container controllers.
Well, UITableViewController is a controller and most of the time, a tableView is simply not the only thing there.
If you look at documentation:
http://developer.apple.com/library/ios/#documentation/uikit/reference/UITableViewController_Class/Reference/Reference.html
UITableViewController provide very little new interface compared to UITableView. None of which is essential.
– initWithStyle:
(duh? I initiate my tableView in nib and I customized a lot anyway)
Getting the Table View
tableView property
(the original tableView)
Configuring the Table Behavior
clearsSelectionOnViewWillAppear property
(okay, just put some code on ViewWillAppear)
Refreshing the Table View
refreshControl property
[tableView reload]?
So you see,
So unless you want your code to look neater (and not much more), there is no reason to use UITableViewController, that I know of.
I don't think you understand your own question.
The UITableViewController is a controller.
The UITableView is a view.
One isn't better than the other, they're completely different objects, used for completely different things.
I'd spend some time learning the Model-View-Controller pattern so prevalent throuought Cocoa and the iPhone SDK.
The Model-View-Controller Design Pattern
The idea is that ViewControllers hold a tree of subviews (and sub viewcontrollers) and manages dispatching events to/from its subviews. For example, you might have a view that holds an image, and that view lives in a view controller that handles orientation changes and memory warnings, etc.
This is one thing I find very confusing about Cocoa: Apple's implementation of MVC (or at least the terminology they use) is questionable. In Cocoa, most views are themselves actually acting in some capacity as controllers insofar as the MVC pattern defines them (just look at UITableView--most of its methods are actually controller methods). Therefore you have Apple's additional concept of a view controller on top of what is already to some extent a controller. The fact that you don't even need to use UITableViewController at all (even with data binding) basically proves that the view is acting as its own controller. In MVC, you can't have a view bound to a model without a controller (that's the whole point of the controller in MVC).
It appears to Apple's developers, that a "view controller" (e.g. UITableViewController) is really more of a slightly higher-level helper/manager class that manages the more low-level UITableView class and enables a few key additional capabilities that pertain more to how the table view interfaces with the general UI of the app.
Additionally, it appears that Apple intends for a view controller to actually be more of a screen controller, recommending only one view controller per screen (presumably meaning you can't nest view controllers). I maintain that calling this concept a view controller is a misnomer.
Please don't hesitate to correct me on this anyone, I'm still very new to Obj-C/Cocoa myself.
UITableView is a view and UITableViewController is a controller that has UITableView as its root view.
So, by using UITableViewController:
You have one root view that is UITableView itself. So it takes less memory than UITableView with a UIView as parent view in its controller.
It provides you with a ready-to-use template, if you needed a controller and a UITableView as its main display view.
Static table views are only valid when embedded in UITableViewController instances.
The link above returns a "Page Not Found." For some reason, even the corrected link returns a "Page Not Found" when hyperlinked (perhaps Apple doesn't allow linking into their developer site).
To find the relevant information, go to Apple's Developer Connection (http://developer.apple.com/index.html) and search on "cocoa model-view-controller design pattern".
In the table of results, select the "Cocoa Fundamentals Guide: Cocoa Design Patterns." On that page scroll down the Table of Contents on the left side until you see the item "The Model-View-Controller Design Pattern." Select that item to read more details about that particular design pattern.