This is more of a requirement than a problem.
There is a tab bar controller, in one of the controllers of the tab bar controller there is a nav controller. Below it there is a segment control, I have to display some data(which I'll get thru URL connections) in table view. On changing of segment from the segment control the content of the table will change. And the segment control changes the type of data being displayed in the table and even there UITableViewCells are different. All the three segments will display data in the table.
One possible solution is to change the data and reload the table when the segment is changed.
Other solution is to change the views (will have three different view controllers) on changing the segments and these view controllers will implement there own table delegates and will have independent table views.
First one is more efficient I suppose. Second one will keep everything(code) separate of the different segments. There are some issues though, the navigation controller is not accessible in the inner view controllers.
Can any one suggest me the best possible solution for the same?
Thanks in adv.
I looked into this quite a lot and eventually plumped for changing the data source of a single TableView. I only had two segments, cell types, fetchedResultsControllers etc. and it still made for a pretty heavy custom TableViewController. Lazy loading images, if you need to do that, is also a bit of a pain.
I didn't need to have a handle on the navigation controller for the individual table views but if that's important to you, perhaps the second approach is best. Despite the above, the first approach works pretty well having got it down. Interested in hearing any better patterns for though.
Related
I wanted to know if I have to create a new ViewController for each view I have. Let's say I have 3 views do I need 3 viewControllers or does 1 ViewController can manage all 3 views?
Edit: Views are Objects that I create with .xib file so following the description given me by Xcode 4.3.3: represents a rectangular region in which it draws and receive events.
My situation : What I want is the main View showing 3 buttons, each button leads to a new View. That's about it each of the 3 views will have about the same thing, a tableView to display data parsed from an XML.
Thanks again!
EndEdit
Thanks
Both are possible, depends on your needs. View controllers can easily manage more than one (sub)view (e.g. every UI control subclasses UIView and you can have many in a single view controller). Sometimes it's more convenient to put views in different view controllers, sometimes it's not.
Depends on your situation and what you want to present to the user. If those 3 view controllers have very similar functions and only minor differences, then you could use the same class and have an instance variable to indicate which mode you're in. For instance if you have a list of Songs, Playlists or Videos, those could be the same class, with an enum variable to differentiate between the 3 modes. If your views are significantly different however (like a Song list and a Video player) then you should usually have separate classes for them.
For iOS, general best practice has been for a single view controller to manage a single "screen (or "window", but of course there is only one of these on an iOS device). This view controller may support a variable number of view objects (certainly not a ratio of 1:1 views/view controller).
As of iOS 5, nesting multiple view controllers managing multiple views in single window is now technically supported, but I still consider it a practice best avoided.
One window = one view controller = multiple views.
In one view controller you can manage any number of views.
It is preferable to use a viewcontroller per view. the advantages of the approch is as follows:
Any time you can convert the Template of the application. (eg. from table view to tabview or split view can make quick change)
with each view controller you follow the MVC architecture.
if you have n controller than try to manage n MVC model so that you can shift any model any where easily.
Memory management will be easy (Push and Pop manage memory automatically.)
if we have sigle view controller and n number of view than it will be quite difficult to manage memory.
Also we need to keep the screen ID for each view and need to mantain also their switching.
there are N number of advantages if you use N numbers of viewcontroller over N number of views.
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 have a User Filter section of my iPad app. There is a segmented bar with 5 buttons for 5 types of filters.
Clicking each of the buttons will load up the respective view..
My question is.. would the best way to handle the UI of each filter to have several views in this nib and load/unload accordingly.. or would best practice be to create the information in a scrollable view?
below is the setup..
http://imgur.com/iuufU.png
Thanks in advance...
Generally, go with separate views. The Scrollable view is an approximation of what you're trying to achieve (by the looks of things), whereas the separate-views more closely reflect your aims.
Some typical dvantages:
if you change your UI design, e.g. if one of those filters has to go in a different page, but 4 stay here ... then it's easy to move the whole View without changing the eixsting ones.
you can put each view in a separate NIB file (if they're different), or loaded from a separate ViewController instance (if they're the same), and you get some of the advantages of Apple's automatica memory management of VC's / NIBs.
Usually, people start with the same view for each filter, using a single VC class (instantiated multiple times, once per tab).
Then, as the app evolves, they find that one tab needs a different layout, so they add another VC class, and only need to update the alloc/init line for that one tab.
I'm building my second app, and I'm trying to learn from the places I stubbed my toes on the first one.
Just as in the last app, I have sections of my app that feature a view with buttons along the bottom (basically a custom tab bar) that trigger the switching of the contents of the main, big area of the screen. One is a map view, one is a table view, one is a grid view, looking at the same objects in three different ways.
In my last app, I had each of the content options be a separate view, managed by separate ViewControllers. That worked, but there were places it was awkward. Passing data among those VCs was a little tricky (especially passing back upstream), and I was totally confused by my nested view controllers not having access to self.navigationController, for instance. It could be argued that I now know how to work with that scheme (and I do), but I'm interested in a Better Way.
I'm now thinking, maybe that whole thing should be ONE view controller, and it should have separate top-level UIView objects that it swaps in and out when the tabs at the bottom are clicked.
Problem is, two of my nested views have tables on them. So I'd need to either write REALLY complex UITableViewDelegate methods to figure out which table I'm talking about, or create separate UITableViewController subclasses to manage my table data. Either way, this just eliminated most of the simplicity I was hoping to achieve by keeping it all in one View Controller.
The other thing is, having those content views be UIViews inside the same view controller has some ramifications. There's no load time to swap views, but I'm burning memory I don't need to, if the user never visits one or more of those view alternatives.
Thoughts?
Problem is, two of my nested views have tables on them. So I'd need to either write REALLY complex UITableViewDelegate methods to figure out which table I'm talking about, or create separate UITableViewController subclasses to manage my table data.
A table view datasource/delegate does not need to be a view controller, it can be any object. So you could write two custom classes that acts as datasource/delegate for the table views.
The other thing is, having those content views be UIViews inside the same view controller has some ramifications. There's no load time to swap views, but I'm burning memory I don't need to, if the user never visits one or more of those view alternatives.
You should load the views lazily in that case, i.e. do not load anything before is is needed. And release stuff that is not needed at the moment when you receive a memory warning.
I've spent too much time walking down dead ends on this project, so it's time to query the hive mind:
I am making a simple iPad game consisting of three locations which the user navigates between when an area of the screen is touched. These locations are represented by fullscreen images and there are a lot of different animations and stuff going on which makes it logical to divide each location into its own UIViewController.
The question is this: Which components should I use for handling the navigation between the locations/controllers?
UITabbarController: After finally managing to hide it away without a white bar at the bottom, I could not get selectedIndex to work in order to swap between view controllers.
UINavigationController: Does not permit more than one view controller inside, and I have three which I want to use. Is it possible to hide it away and still use it?
I could of course cram all my logic into a single UIViewController, but this seems plain wrong. Any advice or solutions for a newbie struggling towards journeymanhood would be greatly appreciated indeed!
If I well understand, everything happens like if you had three view to manage separately. If this is the case, you definitely should have three view controller. Communication between these controllers should then take place in the model. View controllers can be made aware of changes in the model through delegate in this case. If those interaction become too heavy, I suggest you create a super controller (application controller) managing the model and the three controllers.