Is this a bad idea?

I've been working on this problem for two days now. I'm working on an iPhone app that, at the开发者_开发技巧 moment, has "dual layer" view (see picture.) The semi-transparent orange panel covering the left third of the screen was created by simply resizing the sub-view (in IB) to take up less than half the screen so that, when that view loads, the original view is still exposed on the right. This would allow the left view to be a "menu view" allowing a user to select what he or she would like to appear in the main view window (which is actually a UIWebView...see screen shot.)

----- Click Here For Screen Shot-----

If I'm going to keep this setup (assuming it's not a structural sin), the left-view clearly needs a way to communicate with the main view. Can I invoke methods in the main-wiew ".m" file (WebViewController.m) like viewDidLoad and others from the "ETG" button on the orange subview? Or is this just a really bad idea? And if this isn't a bad idea or a sin against iPhone structure, how would you implement it? I'll thank you in advance for any helpful thoughts or suggestions you might have. Thanks!

If you're following the model-view-controller pattern, which you generally should, then your view should send messages to the controller or modify the model, not another view. Although it really depends on what you're doing. In your case you are using the panel as a control, so you should implement in a fashion that makes it independent of other views.

Usually the only time you have views directly manipulate other views is in layout, and that is normally in a top-down fashion.

Again, these are general rules and there are always exceptions.

What you are describing doesn't seem insane, but they way you go about talking to the main view might need a little work.

It seems like what you want to do is have the overlay view have a delegate that it can send messages to. Does that seem like it would work for you?

Umm, is the web view the main view?

Either way, I'd do this:

One view controller that contains two main areas. One is your UIWebView, and another is your layover. If you do this in Interface Builder, put the Layover on top of the UIWebView.

All you have to do is animate it in and out based on certain input. A bad idea is to say "hide menu" and make the UIWebView take up all the space, so you can't get it back.

Then use use one view controller for both.

The recommended method of communicating between view controllers, if that's subviewed, is to create properties in the view controller that you can pass. Eg: the web view needs to tell the main view what site it's on. So put an NSString in your main controller as a property, then pass it the string on viewWillDisappear or whatever that name is.

(Or, use viewWillAppear on the top level and have it grab that property from the 2nd view).

Essentially it's just a branching tree, and you have to pass data up one node to reach the others.

You "can" use the application's delegate itself/(the application) and from anywhere, call [UIApplication sharedApplication].property (after creating a property), and use it as a global, but that's not considered reusable code. Since you're used to basic, it might work for you.

Finally, C++ globals do work, and there are many examples on the web for using globals in an iPhone program with externs. (even less recommended).

Now, it sounds like you need to read the Views Programming Guide, even though it has severe grammar issues in areas (they may have corrected the homonyms in the 3rd paragraph of the intro by now, but other areas are totally confusing because of that), to get an understanding of how views respond to input, and what happens when input is ignored and bubbles up the tree. (that's basically what it does, lol... but layers and views have intricacies and it's good to understand them and how they function together).

No, it's not a bad idea. But without understanding layers, view animation, and design maybe it is, until you do.

NazCode

If I understand what you're trying to do, one approach is to use notifications. This way none of the objects involved need to have references to one another. Before I learned this approach, I had several awkward cases where I seemed to be working much too hard just to get two objects to talk to one another.

In your case, your orange layer can post notifications and the controller for the UIWebView can listen for them.

So when you tap the button in the orange layer, do something like this:

[[NSNotificationCenter defaultCenter] postNotificationName:@"etgTapped" object:self];

And in controller that looks after the webview add something like this to your viewDidLoad method:

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(etgTapped:) name: @"etgTappe" object:nil];

And then create an etgTapped: (NSNotifaction*) notification method in that class.

Finally, in viewDidUnload de-register with the notification centre:

[[NSNotificationCenter defaultCenter] removeObserver:self];