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];
Related
I have a TabBar Application with 2 tabs saving/fetching data to and from CoreData. The problem that I am having is that when the form has been filled and the user has touched the save button the view is not re-loaded or re-initialised. All I want is for the view to be ready for the user to repeat the process with the next set of information. I am probably not thinking about this in the correct way so a pointer in the right direction would be very much appreciated...
Do I need to manually set everything including the managedObjectContext etc. to nil? Or is there something that I can do with methods like viewWillDisappear that will elegantly help me to "re-initialise" that specific tab?
I ave read up the Apple docs on view hierarchies, and life cycles but I just seem to have confused myself...
Thanks in advance for any suggestions, referrals to code or even recommendations on relevant reading material.
It sounds like what you want to do is reload any data to their default states when the user taps a button. Unfortunately, you'll have to do this manually, setting each IBOutlet's value to a meaningful default (probably the empty string).
There are two ways I can think of that would help make this more elegant:
Use an IBOutletCollection and fast enumeration to loop over all the IBOutlets and not have a bunch of code to do each one individually.
If you're switching tabs in between these events, you can something neat and use your app delegate as your UITabBarControllerDelegate for the tabBarController:didSelectViewController: to call the clearing-out method for you instead of relying on viewDidAppear.
Any help would be appreciated.
I am looking for a way to programatically notified that a view is loaded from outside of that viewController.
Lets say my main view has 5 buttons, after the view is loaded and the buttons appeared I want to be notified in another file (outside of that viewContrller) that it is loaded. How/Where can I check this and be notified?
Do I need to do some Aspect Oriented Programming?
Use NSNotificationCenter. You can communicate between classes.
NSNotificationCenter or a delegate method is the most appropriate way to accomplish this.
Listen for a custom NSNotification inside your other object. Have your view controller post that notification during whichever part of its life cycle makes most sense (viewDidLoad, viewDidAppear ...).
If you can't post a notification, then observing a keyPath might be the way to go. For example, you can put something like this in your control object and then implement observeValueForKeyPath::
[viewController addObserver:self
forKeyPath:#"view"
options:NSKeyValueObservingOptionNew
context:NULL];
While you can do this with notifications as others have suggested or KVO, this strongly suggests a design problem. You should never be accessing a view controller's internal views directly. So the deeper question is: why do you want to know?
The most likely cause in my experience is that you're letting some other object set the titles or modify enabled. This breaks MVC and leads to the kind of problems you're probably trying to fix. The correct way to handle this is to put the data into a model object that is shared between the various view controllers. The current view controller can then observe changes on the model and update its UI elements appropriately.
I have had about 6 hours trying to work out custom application delegates. even following tutorials i end up with errors!
I need a simple way of allowing one object to talk to another.
I have a root view. then another view which then pushes onto the stack with a list of options. then another view showing the relevant options based on the previous selection.
So basically 3 views, and i need view 3 to pass data back to view 1 when i popBackToRootViewController.... This is becoming a huge headache, for something that in theory should be so simple. I have previously just thrown data into nsuserdefaults but using protocols in the way apple suggest to do it.
Please can someone help me understand :)
There a different ways to solve that problem. First of all, you could pass the first View over and over to the View you are making changes on and then call a method of view 1. I won't recommend that.
Another, much easier way is to use Notifications. Just register your first View in the notification center [[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(somethingChanged) name:#"aStringWichIsUniqeForCallingSomethingChanged" object:nil];. You have to provide and implement a callback method (somethingChanged in my case). In your subwiew where the things happen, you have to post a notification by doing [[NSNotificationCenter defaultCenter] postNotificationName:#"aStringWichIsUniqeForCallingSomethingChanged" object:nil];. And don't forget to remove the view from the notificationcenter if they are not needed anymore!
[[NSNotificationCenter defaultCenter] removeObserver:self];
A third possibility is to use a singelton (like the app delegate) which contains all views that should communicate. Simple make all views as ivars & properties for them in this singleton and implement in each of them methods which should be called if something changes. Then call [[singelton sharedInstance] view1] somethingChanged].
If i say View, i mean viewController, but i'm to lazy to write that. ;)
Hope, that helps!
Protocols and delegation formalize a concept which works even if you don't follow the formal rules: It's about declaring a way for objects to talk to each other about the same thing, especially in those cases where you either don't have or don't want control about one of the objects, or in cases where things get complex and you want everything nice and tidy so it's easier to reuse the code.
In those cases however where a rather small, well known set of information is to be passed back and forth between two (or more) well known objects which are unlikely to be reused, informality is quite ok.
This means you could:
provide the sending object with a property of the type of the receiving object
implement a method in the receiving object which will take the information to be sent as an argument
at some point, for example in your case when the root controller pushes the child which becomes the sending object, the receiving object will set itself as the value of the sending object
if the sending object has information to send, it uses the reference to the receiving object to send it a message calling the earlier mentioned method, passing the information as an argument
As I mentioned before, this makes sense for glue code. You shouldn't be doing it this way though, if:
you're working in a team and you're working on one object and a teammate is working on the other
it's obvious you may be able to use the same functionality in a future project. In this case, think about having an intermediate subclass between your original superclass and your app-specific subclass, one that encapsulates the core functionality and offers a formal protocol to interface with it
the exchange of information involves objects of different classes within the same app
the exchange of information itself is rather complex and one (or two) glue methods wouldn't cover it
I have been using Objective-C for a while and pretty much understand most of its features. However, the concept of delegates eludes me. Can someone please give a succinct and easy to comprehend explanation of what delegates are, how they are used in the iPhone SDK, and how I can best make use of them in my own code?
Thank you!
There are a couple main reasons to use delegates in Objective-C, which are subtly different:
Enhancing the base functionality of a framework class. For example, a UITableView is pretty boring on its own, so you can give it a delegate to handle the interesting bits (creating table cells, adding text to section headers, what have you). This way, UITableView never changes, but different table views can look and act very differently.
Communicating to parent objects in your dependency hierarchy. For example, you may have a view with a button that the user may push to do something that affects other views. The view will have to send a message to its parent view, or perhaps the view controller, so that it can create or destroy or modify other views. To do this you'd pass the parent object into your view, most likely through a protocol, as a weak reference (in Objective-C, an assign property). The view could then send any message declared in the protocol to the parent, or delegate, object.
This approach need not involve views. For example NSURLConnection passes event back to its delegate, which may be the object that created it, using this mechanism.
Essentially, all a delegate is, is an object that accepts feedback from another object. Put simply, when stuff happens to an object, it tells its delegate (assuming it has one).
For instance, lets say I have a UIViewController with a UITextView placed in the middle of the view. I set up my UIViewController to be the delegate of the UITextView. Then, when certain actions are performed on the text view (begin editing, text changes, end editing, etc), it tells it's delegate so it can do whatever logic it needs to do, like spell checking every time characters change, or dismissing the keyboard when it receives a return key press.
Delegate methods perform a similar function to callback functions in C.
Hope that makes sense :)
Best and simple concept I got from a Lynda.com Tutorial was: When you set a Delegate it means you have been given work to do. So, if you want to use methods that are written in a protocol method, you must implement them by searching in the Delegate Class Reference and using them. I hope it helped.
By the way, Delegates are excellents. They are your friends. They have been made to make your life as a programmer much easier.
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.