So I started to work on an app, it has 5 tabs of which 3 shows UITableViewController with custom cells, but with different data.
Is it possible to link 3 tabs to same UITableViewController, but check which tab is selected, and according to that, load right data?
I tried putting in UITableViewController:
if (self.tabBarController.selectedIndex == 0)
//Load array1
else if (self.tabBarController.selectedIndex == 1)
//Load array2
else
//Load array3
But the indexes are not always the same (it depends in which order you select tabs?, and sometimes I get index that is very high number).
How would you do this?
Assuming you mean "Is it possible to link 3 tabs to same UITableViewController instance":
It is possible, but it's not a great idea. I believe (but couldn't point you at chapter and verse) that the assumption by Apple is that different tabs will have unique, different view controller instances in them. When you change tabs, the view controller instance about to hide has various 'about to be hidden' lifecycle methods called on it. Likewise, the view controller instance about to appear has various 'about to be shown' lifecycle methods shown on it. It's possible your single view controller instance may fall foul of the order of these lifecycle methods being shown.
The above point aside, it's also a waste of effort reloading a table each time just because the user changed a tab. Be kind and do things the way you're meant to do them. There's no reason you can't have a single view controller class that handles everything, but you create a different instance of it for each tab.
Note: your UIViewController being aware of which tab it is in counts as a 'code smell'. This usually means you're doing something in an undesirable fashion and hurting the re-usability of this code. That applies in this case.
To avoid this 'code smell', your view controller should be able to be given the data it is to show, without any knowledge of even being shown in a UITabBarController.
Leverage the UITabBarControllerDelegate to detect when the user switches tabs.
Upon tab switch:
assign the new array contents to a member variable used to display
the data in the table view (with a similar if/else block as you posted), and
call reloadData on your UITableView
to trigger a redraw with the data
Related
I'll try to explain this as best as i can, but i appologize if it gets too confusing - I've been stuck on this problem for many hours now.
In my application i have a search screen where the user will be able to select a bunch of criterias to perform the search by. Some of these criterias consists of fairly long lists of values to choose from and therefor i want a tableview on my searchscreen which have 4 rows - Each row representing a criteria that the user can set.
Once the user clicks on a row i want to push a new window in my navigationcontroller which consists of a new table containing the selectable values for that criteria - Once the user clicks on one of these rows on the new window, i want the selected value to be sent back to my main searchscreen and pop back to my search screen.
What would be the best way to do this?
Elaboration:
My searchscreen is called SearchViewController and is contained in a navigationController.
SearchViewController contains two sliders and a tableView with 4 rows called "Searchtype", "Property type", "Salestype", "Area" and a searchbutton. If the user clicks on "Searchtype" then i want a new view to be pushed in the navigationController which should contain a new tableView with a bunch of rows representing different possible values for the "Searchtype" criteria - The same goes for all 4 rows in SearchViewController.
When the user clicks on one of the value rows in the newly pushed tableView i want that tableView to be popped away and the selected value sent back to the SearchViewController allowing the user to either select more criterias or push the search button to actually perform a search based on the selected criterias.
But i can't figure out the best way to do this?
I really appreciate any help i can get - I'm going nuts trying to figure this out :)
Btw. i don't use Interface Builder - All UI elements are coded manually.
5 ways to do it here:
1) Let the Search View Controller be the delegate of action in the Search Type View Controller, so that when the user selects a search type, it will be informed. Use protocol for proper check at compile time if you want, and remember to use assign instead of retain for the delegate, to avoid circular reference.
2) Set the UINavigationController delegate to Search View Controller (or whatever class you want to control it), and listen to the event when the Search Type View Controller is popped out.
3) Implement a "refresh" function in viewWillAppear: as suggested above, but this is not recommended, because the implementation of viewWillAppear: sucks and not reliable at all. Maybe good for simple app, but when the structure of your app gets complicated, forget it.
4) Use NSNotificationCenter. Your Search View Controller will observe all changes to search criteria, and in each child view controller, when the user changes it, post a notification. This is more complicated, but much more powerful and flexible than all the methods above.
5) Similarly, you can use Core Data to store all search criteria in an object, and listen to changes in that object using KVO. This is a bit more advanced and may be overkill, but if you know KVO, it makes life much easier in Objective C, so probably worth taking a look anyway.
Btw: It's good to do all the UI by hand coding to understand the concepts at first, but try to move to Interface Builder whenever you can. It is a much recommended way to work (there are countless threads on this in Stackoverflow or on the web, with more elaborated discussions on why IB is better).
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.
Ok so basically I have a UITabBarController as my root view controller. I have three tabs that will all have UINavigationController objects nested in them, controlling three table views each.
Each mode will access the same database in the same way, but just sort by different variables. Very similar to the way the iPod app works - whether you narrow down your search by Artist or Genre, you end up at the same "detail view" (the song playing).
My question is, should I link all three tabs in Interface Builder to the same UINavigationController, but just populate the table depending on the selected tab? Or should I create completely independent objects for each tab, and copy and paste code?
The first way seems more efficient and flexible, but the second seems like it will be a little more explicit and easy to read!
Thanks for any help :)
I think clearing the navigation controller stack on every tab switch (assuming it is not hidden when the non-uppermost navigation child is shown) would be much more resource-consuming than having all three/four UINavigationControllers available all the time (mostly for quick tab-switching).
Further, if the owning UINavigationController is the only object that retained (owns) the UIViewControllers on the stack, then you will also deallocate your UIViewControllers should you decide to reset the navigation stack (1-Nav scenario). Assuming of course they are not "statically" present inside a NIB.
TL;DR version
I'd use a separate UINavigationController for each tab, in a low memory-footprint app it will increase the visual performance of your tabs.
I've Created a UITableViewController subclass. Do I only need one controller? Do I just instantiate multiple instances of that one subclass?
The iPhone App I'm building will start with a Table of a list of people. If the user taps a person, a new table will be pushed in with a list of Companies they've worked for. If the user then taps a company, they'll see a list of Job Positions. And if they tap a position they'll see a list of people holding those positions.
This could go on forever, and the user could always back up the list.
The App Delegate instantiates the Navigation Controller and the Table View Controller and then pushes it onto the Navigation Controller. But when a user taps a row, now the TVC is creating another TVC.
Is that right or should the
AppDelegate be instantiating all
TVC's? Or does it work out since
they all get pushed onto the Nav
Controller anyway?
Does each Table View instance
need to have a different name or can
they all be called 'mainTVC' or
something like that?
tableViewController *mainTVC = [[tableViewController alloc] init];
Won't I run out of memory? Do i
need to start dropping Table Views
when they're 2 or 3 levels away from
current, and then re-create it if
the user backs up to it?
No need to create multiple TableView's, what I've done in the past is simply re-bind to a different datasource. So keep one TableView and have a datasource for people, then companies, etc...
I'd create a view controller for each type. Presumably you'll want to have special display characteristics like a custom tableview cell to display job positions slightly differently then you would people names.
Other then that, #Ben Gottlieb's answer should work quite well. Use lots of view controllers and handle the didReceiveMemoryWarning: method.
One more thing, if the user drills down so far that you want to say they'll never go all the way back (sort of like having an undo stack) you can use the setViewControllers:animated: UINavigationController method to reset the stack to a certain size (say 15 to implement an 'undo buffer' of 15). With this method you can make sure that the first view controller is always your root view controller and the rest are all drilldown instances.
Option number (2) looks good. You can push quite a lot of view controllers onto the stack before memory becomes an issue. The system will clean up most of the heavyweight memory hogs (ie, the views) in the didReceiveMemoryWarning: method. If you're creating a lot of in-memory structures, you may want to clean them up in that method (be sure to call the inherited method).
To answer your third question, as long as you don't have huge data stores in memory, memory shouldn't be an issue. You SHOULD NOT under any circumstances "drop" tableviews - this would lead to crashes(and there's no way to do non-FILO additions/removals to the navigation stack anyway). Under memory pressure, you should only free "nonessential" items like caches. However, this shouldn't be an issue.
Also, if you have more than 3 or so levels, chances are you need to rethink your UI. If users are drilling down 10 levels, it will be tedious to navigate the stack back.
I have a view that contains a UITableView and a UILabel which works perfectly as far as I can tell. I really don't want to manage the UIView and UITableView with the same controller as the UITableViewController handles a lot of housekeeping and according to the documentation:
If the view to be managed is a
composite view in which a table view
is one of multiple subviews, you must
use a custom subclass of
UIViewController to manage the table
view (and other views). Do not use a
UITableViewController object because
this controller class sizes the table
view to fill the screen between the
navigation bar and the tab bar (if
either are present).
Why does Apple warn against using it and what will happen if I ignore this warning?
Update: Originally I quoted the following from the Apple Documentation:
You should not use view
controllers to manage views that fill
only a part of their window—that is,
only part of the area defined by the
application content rectangle. If you
want to have an interface composed of
several smaller views, embed them all
in a single root view and manage that
view with your view controller.
While this issue is probably related to why UITableViewController was designed to be fullscreen, it isn't exactly the same issue.
The major practical reason to use only one view controller per screen is because that is the only way to manage navigation.
For example, suppose you have screen that has two separate view controllers and you load it with the navigation controller. Which of the two view controllers do you push and how do you load and reference the second one? (Not to mention the overhead of coordinating the two separate controllers simultaneously.)
I don't think using a single custom controller is a big of a hassle as you think.
Remember, there is no need for the TableviewDataSource and the TableViewDelegate to be in the actual controller. The Apple templates just do that for convenience. You can put the methods implementing both protocol in one class or separate them each into there own class. Then you simply link them up with the table in your custom controller. That way, all the custom controller has to do is manage the frame of tableview itself. All the configuration and data management will be in separate and self-contained objects. The custom control can easily message them if you need data from the other UI elements.
This kind of flexibility, customization and encapsulation is why the delegate design pattern is used in the first place. You can customize the heck out of anything without having to create one monster class that does everything. Instead, you just pop in a delegate module and go.
Edit01: Response to comment
If I understand your layout correctly, your problem is that the UITableViewController is hardwired to set the table to fill the available view. Most of the time the tableview is the top view itself and that works. The main function of the UITableViewController is to position the table so if you're using a non-standard layout, you don't need it. You can just use a generic view controller and let the nib set the table's frame (or do it programmatically). Like I said, its easy to think that the delegate and datasource methods have to be in the controller but they don't. You should just get rid of the tableViewController all together because it serves no purpose in your particular design.
To me, the important detail in Apple's documentation is that they advise you not to use "view controllers [i.e., instances of UIViewController or its subclasses] to manage views that fill only a part of their window". There is nothing wrong with using several (custom) controllers for non-fullscreen views, they just should not be UIViewController objects.
UIViewController expects that its view takes up the entire screen and if it doesn't, you might get strange results. The view controller resizes the view to fit the window (minus navigation bars and toolbars) when it appears, it manages device orientation (which is hard to apply correctly if its view does not take up the entire screen) etc. So given how UIViewController works, I think there is merit to Apple's advice.
However, that doesn't mean that you can't write your own controller classes to manage your subviews. Besides the things I mentioned above, interacting with tab bar and navigation controllers, and receiving memory warnings, there isn't really much that UIViewController does. You could just write your custom controller class (subclassed from NSObject), instantiate it in your "normal" fullscreen view controller and let it handle the interaction with your view.
The only problem I see is the responder chain. A view controller is part of the responder chain so that touch events that your views don't handle get forwarded to the view controller. As I see it, there is no easy way to place your custom controller in the responder chain. I don't know if this is relevant for you. If you can manage interaction with your view with the target-action mechanism, it wouldn't matter.
I have an application where I did use 2 separate UIViewController subclasses below another view controller to manage a table view and a toolbar. It 'kind of' works, but I got myself into a massive pickle as a result and now realize that I should not be using UIViewController subclasses for the sub controllers because they contain behavior that I don't need and that gets in the way.
The sort of things that went wrong, tended to be:
Strange resizing of the views when coming back from sub navigation and geometry calculations being different between viewWillLoad and viewDidLoad etc.
Difficulty in handling low memory warnings when I freed the subview controllers when I shouldn't have done.
Its the expectation that UIViewController subclasses won't be used like this, and the way they handle events, using the navigation controller etc that made trying to use more than one UIViewController subclass for the same page tricky because you end up spending more time circumventing their behaviour in this context.
In my opinion, The Apple Way is to provide you the "one" solution. This served the end-users very well. No choice, no headache.
We are programmers and we want to and need to customize. However, in some cases, Apple still doesn't want us to do too many changes. For example, the height of tab bar, tool bar and nav bar, some default sizes of the UI components(table view), some default behaviors, etc.. And when designing a framework and a suite of APIs, they need to nail down some decisions. Even if it's a very good and flexible design, there is always one programmer in the world wants to do something different and find it difficult to achieve against the design.
In short, you want a table view and a label on the same screen, but they don't think so. :)