Customizing UITabBarController's moreNavigationController - iphone

I'm in the process of customizing the 'More' view in my app's UITabBarController.
From what I see in the docs there is precious little support for customizing it. There is only a read-only property of the UITabBarController called 'moreNavigationController' that points to a UINavigationController.
This allows us at least to customize it's UINavigationBar. Customizing the table view it presents in the first view controller is a little trickier.
On other questions here on SO and elsewhere, I've seen that all talk revolves around messing with the internal structure of the moreNavigationController (for example observing that the first view controller in the stack is a UITableViewController, swapping out it's data controller, etc.). Problem is all these methods make assumptions about how undocumented code in the API behaves, assumptions that are hardly future-proof.
The only alternative I see here is to roll my own custom "more controller" (optionally ditching the edit functionality to keep the implementation fairly simple) and using it as the fifth view controller in the tab. Of course care must be taken to assign the subsequent view controllers to the custom "more controller" not to the UITabBarController directly (subclassing the UITabBarController may be required to enforce this rule).
Which approach would you choose? What other solutions would you suggest?

UIViewController *tbMore =
((UIViewController*)
[self.moreNavigationController.viewControllers objectAtIndex:0]);
int nRows = [((UITableView *)tbMore.view) numberOfRowsInSection:0];
for (int i = 0; i < nRows; i++)
{
UITableViewCell *c =
[((UITableView *)tbMore.view)
cellForRowAtIndexPath:[NSIndexPath indexPathForRow:i inSection:0]];
// Do any additional customization here!
}

I would choose to roll my own custom controller for 3 reasons:
moreViewController is controlled by UIKit. Externally, it is very hard to customize some views and control them directly. There will be unpredictable methods and layer definitions in moreViewController. It can't be basic UITableViewController. I think customizing classes that have delegates is more efficient.
If you customize moreViewController, you may have to release a new version of your app each time Apple releases new iOS. The developers of moreViewController at Apple may change entire class to something else. So your application will stop responding.
My own class, my own home. I can do whatever I want.

Related

Showing the same UIView instance in different UIViewControllers

Is it possible to somehow store a UIView instance in such a way that it can be accessed from other view controllers? I know this is probably bordering on "globals" which they say are bad, but I digress. All I know is I have a couple UITabBar tabs that need to reference the same instance of a view that was instantiated in one tab and needs to be displayed again in another tab. What's the best approach for doing something like that?
Sure. You just need to store a retained reference to the UIView object in a persistent object. For example, you can add a retained property to your UIApplicationDelegate subclass. You can have that delegate instantiate the view, and all the controllers would just ask the app delegate for the view. If you have a root view controller that is always available, you could retain it there.
Maybe thinking through the overall structure of your app can help find the "right" place to store the UIView. Below I present an app structure I frequently use, not necessarily as advice on how you should structure your app, but as an example to expand the options you can consider to help you with thinking about the best structure for you app.
I write a lot of brochure like apps for our clients. In these apps I need to present a number of views, each somewhat analogous to pages in a brochure. Some of these views will have user interaction, and need to retain their state when off screen, or share the state data with other views.
To manage these apps I create a presentation manager object. This object will retain the overall state of the app, including views that must persist when not displayed. I use one master UIViewController that owns the presentation manager and is responsible for all common view control operations. The specific logic for individual views will go in UIView subclasses for each view. These individual views are created by the presentation manager, and can ask that manager for what it knows, including any persistent views.
You can just use dependency injection, to inject the same view instance to the view controllers like this:
UIView *myView = [UIView new];
UIViewController *controller1 = [UIViewController new];
UIViewController *controller2 = [UIViewController new];
controller1.view = myView;
controller2.view = myView;
[myView release];
B/c you use UITabBar I would suggest to add your custom view to the window in the app delegate. Then you don't have to store it, just hide it. You can use either NSNotificationCenter to send notifications to show the view or you can call your appDelegate and show the view manually.

iPhone App Dev - Loading View From View Controller

I have a questionnaire viewcontroller class. This instantiates several questionviewcontrollers (each questionviewcontroller has an associated view).
How do I get the questionnaire to load these question views associated with their questionviewcontrollers....
EDIT:
-(void) setQuestions{
for (NSDictionary *q in self.questions) {
/* Create our Question object and populate it */
QuestionViewController *question = [[QuestionViewController alloc]init];
[question setQuestionId:[q objectForKey:#"questionId"] withTitle:[q objectForKey:#"question"] number:[q objectForKey:#"questionNumber"] section:[q objectForKey:#"sectionId"]];
/* Add it to our question (mutable) array */
[questionArray addObject:question];
[question release];
}
}
The above method is called in the viewDidLoad method of the QuestionnaireViewController and is where the QuestionViewControllers are created. Each one has an associated view with a next button.
It's not clear from your question what you mean when you say, "How do I get the questionnaire to load these question views".
Are you just asking how to display a QuestionViewController when a question is selected? If so, this sounds like a navigation based application. You would typically use a UINavigationController as your top level view controller in your app delegate, setting your QuestionaireViewController as the rootViewController of your UINavigationController. Then, when the user selects a question in your QuestionaireViewController, you can display its controller using:
[self.navigationController pushViewController:questionViewController animated:YES];
If instead you're asking how you can display the views for these QuestionViewControllers as subviews of your QuestionaireViewController, the short answer is don't do it (at least not under iOS 4.x). Apple's view controller framework is not designed to support using nested view controllers to manage multiple subviews simultaneously. The documentation states that each view controller should correspond to one full-screen view on iPhone. iPad changes these rules slightly for things like split views and popovers, but it's still not designed to let you nest view controllers within your own custom view controllers.
(In truth it is technically possible to use multiple view controllers to manage different subviews on a single screen, but doing so properly requires expert knowledge of how the view controller framework is designed so that you can properly delegate all the various UIViewController methods and properties like viewWillAppear:, navigationController, tabBarController, etc. You're generally better off following Apple's advice and using one view controller per screen.)

The ultimate guide for writing parent view controllers

Short version
If I'm writing my own custom split view controller, what do I need to do to make the child view controllers work as expected?
For instance: to send viewWillAppear: and so on.
Long version
Background
A while back I answered the following question:
Switch between UIViewControllers using UISegmentedControl
With the following answer:
The right way to do it is to have the controller handling the UISegmentedControl add the views of the controllers as subviews.
[self.view addSubview:controller.view];
It's your responsibility to send viewWillAppear: and so on.
However, tc. pointed out that this is not as trivial as it sounds:
No. View controllers are not meant to be used like that - controller will miss out on a lot of the UIViewController magic that's taken for granted (namely -view{Will,Did}{Appear,Disappear}: and -shouldRotateToViewOritentation:).
By "magic", I'm referring to everything UIKit does behind the scenes. You also forgot -parentViewController (which is important for things like modal view controllers). Additionally, somewhere in the depths of UIKit, it automatically calls -viewSomethingSomething: for you, so you might get -viewDidDisappear: twice! (I can't remember the exact details, but there's another user reporting that all you need to do is call -viewWillAppear: and the other three methods happen automatically.) The key issue is that Apple doesn't document the "magic" or how it changes between OS updates.
Since then I've been thinking that one should compile a guide for what needs to be present in the parent view controller in order for the child view controllers to work as expected. Apple's documentation doesn't cover this and Google didn't help much either, so now I'm hoping to find this knowledge within the stackoverflow community.
I've written several controllers like this and they all seem to work, but I can't help but wonder if I'm missing out on important view controller magic.
I think the best solution is "don't do that". Instead of hoping that you can duplicate all of UIViewController's behavior without being rejected for using private API calls why not create non-UIViewController controller objects to manage your subviews? A "controller" is not necessarily a UIViewController.
At a minimum you would need to override or mix in replacement getters for parentViewController, splitViewController, navigationController, tabBarController, and interfaceOrientation (and probably also modalViewController). For each property you would need to make sure that any private setter called by UIKit still works as expected and any changes to those values made by modifying UIViewController ivars directly are also correctly reflected in your implementations.
You're also going to need to figure out how UIKit determines which UIViewController is currently active and should receive view controller lifecycle methods because you need to make sure that these are sent to your container view controller and not only to one of it's children.
You will also have to hope that you haven't just constructed a situation which isn't supported by any of Apple's view controller classes. For example will any of them break if they have a parentViewController but their navigationController, tabBarController, and splitViewController are all nil?
Finally you'll need to keep up with any changes to these private implementation details with every iOS release.

What's the right way to add a ToolBar to a UITableView?

I'm writing a Navigation-Based iPhone app, and I'd like to have a UIToolBar docked at the bottom of my screen, with a UITableView scrolling between the tool bar and the navigation bar.
I've seen a couple of forums where it's been suggested that the View Controller handling this view should be a standard UIViewController rather than a UITableViewController. The view controller would have to implement the UITableView delegate and data source methods in addition to all of the standard UIViewController overrides. What (if any) built-in functionality do I need to recreate in this view controller subclass other than the aforementioned protocols to have it act like a UITableViewController? Is there anything I'm losing by going this route?
Or would it be better to nest a UITableViewController inside of a standard UIViewController?
As of OS 3.0 the Navigation Controller has a tool bar built in. To make it appear:
[self.navigationController setToolbarHidden:NO];
By implmenting:
- (void)setToolbarItems:(NSArray *)toolbarItems animated:(BOOL)animated
in your view controller, you can configure the items of the tool bar.
So you no longer have to worry about where the tool bar is located in your hierarchy.
(corrected typo)
Corey Floyd is mostly correct, except that
[self.navigationController setToolBarHidden:NO];
should be
[self.navigationController setToolbarHidden:NO];
That is, the "b" in "setToolbarHidden" must be lowercase. Also, method name listed in the iPhone OS Reference is actually
- (void)setToolbarHidden:(BOOL)hidden animated:(BOOL)animated
though it seems that omitting the animated parameter works too.
//Tool bar
[self.navigationController setToolbarHidden:NO];
UIBarButtonItem *buttonItem = [[ UIBarButtonItem alloc ] initWithTitle: #"Select All"
style: UIBarButtonItemStyleBordered
target: self
action: #selector(selectAll:) ];
UIBarButtonItem *buttonNext = [[UIBarButtonItem alloc]initWithTitle:#"Next" style:UIBarButtonItemStyleBordered target:self action:#selector(goNext:)];
self.toolbarItems = [ NSArray arrayWithObjects: buttonItem, buttonNext, nil ];
[ buttonItem release ];
[buttonNext release];
All you need do is implement the UITableViewDelegate and UITableViewDatasource methods required for the level of table view functionality you require. These methods can be in any class(es) though said classes should conform to the relevant protocols. The delegate and datasource should be set on the UITableView instance - either programatically or with Interface Builder. According to the docs you will lose some functionality - see the overview section.
Personally I find that many developers seem to be obsessed with providing all of this functionality in a single monolithic view controller class, and that because they have a table view in their view then a subclass of UITableViewController must be used. However, I like to consider the Single Responsibility Principle and will often break the datasource and delegate into separate classes when the complexity is anything other than simple. The code is also then not tied to a specific UIViewController implementation.
In situations where I have separate datasource/delegate classes I often construct and wire them up to the table view using Interface Builder and not in code. This approach (to me at least) is in the spirit of Dependency Injection and saves writing some boiler-plate code, and provides some level of decoupling.
These choices of course are influenced by the complexity of the functionality that you are trying to achieve - for simple implementations I might find myself using UITableViewController.
Try out this:
self.navigationController.toolbarHidden = NO;
Hope it helps you.

UITableViewController.view crash

So I'm trying to use a UITableViewController (let's call it homeView) in my iPhone application to display a simple table with only a few rows of text which are loaded from an NSArray in the controller. I want to display the table in the grouped style in a subview of a subview (let's call it subSubView) of my main controller. When I try the following: [subSubView addSubview:homeView.view], my app crashes on launch. However, when I allocate the object without adding it to any views, it launches fine.
What's the best way (or rather a working way) to display the table generated by my UITableViewController?
There isn't enough to tell for sure what is going on, but if I had to guess I would think that you probably aren't retaining homeView. Normally I would say that as a comment to your question, since it is not really an answer, but I have a completely separate answer:
Just use a UITableView, not a UITableViewController. Instead of trying to embed a controller within a controller (which is quite difficult since Apple doesn't expose the necessary tools to actually modify the view controller hierarchy), just make the VC you are writing support the appropriate delegate/dataSource methods and directly create the view.
While it might make some logical sense to try to embed VCs inside of each other, with the exception of the builtin container VCs (UINavigationController, UITabBarController) it Really Doesn't Work™. The technical reason for this is that internally some of the event routing and messaging depends on parentViewController being correct, but since you can't set it (setParentViewController: is private) tons of latent bugs in UIKit start rearing their head. The internal collection classes can set the parentViewController correctly, so everything works right.
Also, one last thing. In your question you named your view controller homeView. Please, please on't do that. A view controller and a view are separate things, call it homeViewController. Aside from the fact that a lot of new iPhone developers get confused about what the distinction is, there is nothing more aggravating then tracing through someone else's code and realizing that something you are assuming is one type is another.