I'd like my controller to subscribe to notifications from view. However, before doing that, I'd like to confirm if it is OK for a view to know the instance of its controller?
Let me offer you a more specific example of what I have in mind.
My controller creates the view and informs it that it is its controller
self.gameView = [[GameView alloc] initWithController:self];
Once done, it subscribes for notifications from this view
[[NSNotificationCenter defaultCenter] addObserver:self
selector:#selector(saySomething:)
name:#"SaySomethingClever" object:nil];
Meanwhile the view does its thing, but when the right time comes, it posts a notification
[[NSNotificationCenter defaultCenter] postNotificationName:
#"SaySomethingClever" object:gvc];
In order for it to do it, the view needs to know the recipient of the notification (gvc).
I'd like to use this opportunity and as you whether the following is ok:
When initWithController is called, the view
-(id) initWithController: (GameViewController* )g {
gvc = g;
return [self initWithFrame:CGRectMake(0, 0, 480, 300)];
}
where initWithFrame:CGRectMake is a private method that handles specific view stuff.
Everything works fine, however, i wonder whether this approach is morally acceptable
It's not strictly a problem if the view has a reference to its controller, but it looks like your real problem is a misunderstanding of the notification posting method.
The object argument isn't the receiver. Indeed, if it were -- if the poster of a notification had to know the object that was going to get the notification -- that would defeat the entire purpose of the notification. You could just call the appropriate method! The point of notifications is that the poster doesn't need to know the other objects which are listening.
The object argument is actually used by the receiver to distinguish which notifications it should care about. Most frequently, the argument is the poster itself:
[[NSNotificationCenter defaultCenter] postNotificationName:IDidSomethingInteresting
object:self];
but it can in fact be any object.
When registering for notifications, you can specify a particular instance whose notifications you're interested in. This is the object argument to addObserver:... The notification center will then only pass on those notifications whose name and object match what was specified.
Even if you pass nil for the object in addObserver:..., you can check the object of a received notification and only act if the poster was one that you are interested in.
For example, there might be several windows in you application, and you may be interested in knowing when one of them is resized, but you don't care what happens to the rest of them. You would pass just that window instance as the object for addObserver:...
To sum up, your view in this case doesn't need that reference to its controller in order to for the controller to receive notifications posted by the view.
See also: "Posting Notifications"
While the concept is OK, it's not needed in your case:
[[NSNotificationCenter defaultCenter] postNotificationName:#"SaySomethingClever"
object:self];
The object referenced by an NSNotification is usually the object which posts a notification. The whole notification idea is that posters don't need to know about observers.
I would focus on controllers calling other controllers (or ideally model methods).
Allow each view to work with it's main resource and allow the controller for that view to make additional calls.
Related
I have a simple setup.
I have a 'TripService' and a 'TripViewController'. When something changes in the trip service, such as the distance it should fire a notification, so that anyone interested should be notified, in this case the view controller.
Problem happens when I trigger the notification tied to an object, so i put:
[NSNotification notificationWithName:TRIPSERVICEDISTANCECHANGE
object:self
userInfo:distanceInfo];
and listen for it with
[notificationCenter addObserver:self
selector:#selector(distanceChanged:)
name:TRIPSERVICEDISTANCECHANGE
object:self.tripRecorder];
In this case I trigger it but nothing distanceChanged never gets fired.
If I replace both 'object' values with nil then this works.
The strange thing is this works Fine if I run the app in debug mode and step through the code.
In the code:
[notificationCenter addObserver:self
selector:#selector(distanceChanged:)
name:TRIPSERVICEDISTANCECHANGE
object:self.tripRecorder];
the argument:
object:self.tripRecorder tells the notification center to only deliver TRIPSERVICEDISTANCECHANGE notifications to self that are sent from self.tripRecorder. If the notifications are being delivered when object: is set to nil, that tells me that self.tripRecorder may not be the object sending the notification. However, you also say that the code works if you step through the program with the debugger. That sounds like an object-lifetime issue (The notification object is being destroyed before the notification center can process/deliver the notification). notificationWithName: returns an autoreleased object, is it possible this object is being released at the end of the method in which it is created?
I am developing an iOS application where need to do some stuff when I have Internet connection and other, when I haven't. If I haven't at some point I will show a message to the user to give me internet and come back. The question it is how to detect the following situation:
the user press the Home button twice, goes to multitasking , Settings and will connect to internet
the user comes back with multitasking to my app, but doesn't press anything
I know I will get callbacks to the AppDelegate:
- (void)applicationDidEnterBackground:(UIApplication *)application
- (void) applicationDidBecomeActive:(UIApplication *)application
but the code ( it is not started by me) it is very big, and I don't want to handle there the UIViewController needs, if there is any alternative.
My UIViewController's - (void)viewDidAppear:(BOOL)animated it isn't called when the user came back.
The breakpoint it is not hited for sure!
Any usable ideas, except in AppDelegate?
You can use the notification center to listen to applicationDidEnterBackground within the view controller:
[[NSNotificationCenter defaultCenter] addObserver: self
selector: #selector(handleEnteredBackground:)
name: UIApplicationDidEnterBackgroundNotification
object: nil];
Do this in viewDidLoad. Similarily for applicationDidBecomeActive.
Don't forget to remove yourself as an observer in viewDidUnload.
The application delegate is the correct place to be handling application state changes, but just because that is the case, it doesn't mean you must put all the logic that is triggered by the application state change in there.
Put the logic where it belongs. If it's networking code, that's not in the application delegate and it's not in the view controller, it's in a separate class. Then look into ways of tying the different parts of your application together. In most cases, notifications, KVO and the shared instance pattern are good approaches to take.
I have a class that synchronizes data in the background every once in a while. The user can be anywhere in the app's navigation tree and no matter where the user is I need to be able to update the view controllers with whatever new data I just synchronized.
I put the object in charge of the background thread sync as a property of the SharedAppDelegate.
In a way I need to implement something like the Observer pattern and every time I instantiate a view controller set it to listen to some event on the background sync object so that after every sync I can execute a method in the view controllers that are listening.
I'm not sure what the correct way to do this in Objective-C is or if there is even a better or recommended way.
Use a NSNotification with NSNotificationCenter, which fits precisely your purpose :
in your AppDelegate, when the sync ends, call
[[NSNotificationCenter defaultCenter] postNotificationName:#"SyncEnded" object:mySyncObject]
in every view controller you display, call
_myObserver = [[NSNotificationCenter defaultCenter] addObserverForName:#"SyncEnded" object:nil queue:[NSOperationQueue mainQueue] usingBlock:^(NSNotification *note){ ...your UI refresh code... }
also do not forget to remove the observer when it's not needed anymore (view controller deallocated / unloaded / not visible, up to you ), or the NSNotificationCenter will end up crashing :
[[NSNotificationCenter defaultCenter] removeObserver:_myObserver];
A few notes :
This example uses the block-based API to perform the UI refresh work on the main operation queue (implying on the main thread), because you must not perform UIKit operations on any other thread than the main thread. This is likely that your background sync will send its notification on an other thread, so switching to the main thread is necessary. If you want to use the selector-based API, be sure to send the notification on the main thread.
You can register as many observers on the notification as you want, so this matches perfectly your pattern (NSNotifications are usually the best way to notify different app components of an app-wide event like sync end).
The object parameter passed when posting the notification allows you to access the sync object in the observer block using note.object if you need it.
So far I have been using NSNotificationCenter with the method postNotification:aString object:anyObjectOfInterestForTheReceiver. But recently I read in the documentation that the object field should only be passed self. Is there any terrible side effect I am unaware of that should convince me to only pass self in the future, or is it OK to pass any object?
Thank you!
You can pass any object as the object of a notification, but the convention is that the object is the "thing that is doing the notifying" (and you put other relevant state in the userInfo dictionary).
The reason why it's mostly self is because usually the object doing the notifying usually wants to reference itself. That way, for example, if you had many Foo objects, and one of them completed a task and sent a notification, anyone observing the notification could just look at object to see which Foo was the one in question. The observer can also choose to observe only notifications from a particular Foo when you follow this scheme.
It's also reasonable (though less common) to use something besides "self" when posting a notification-- let's say you're sending a notification "on behalf of" another object. For example, you could be a singleton controller object that completes a Bar task, and you could send the notification with a reference to the particular Bar as the object. That makes more sense than using the singleton as the object, since there'd be no interesting variance there.
Again, this is a (useful) convention only. When you make up your own notification, you get to define the "contract" of the notification, which is the name, what kind of object is used as the object, and what's in the userInfo.
Yes, there is a side effect I can think of. Let me explain it.
The method you talk about was actually defined in NSNotification.h as below:
(void)postNotificationName:(NSString *)notificationName object:(id)notificationSender
The first parameter notificationName stands for the name of the notification.
The second parameter notificationSender stands for the object posting the notification.
Yes, any object can be a notification sender, even nil can be.
In terms of observering the notification(to became a observer of a specific notification), we got to know another method defined in NSNotification:
(void)addObserver:(id)notificationObserver selector:(SEL)notificationSelector name:(NSString *)notificationName object:(id)notificationSender
As you can see, the last parameter is notificationSender(the object whose notifications the observer wants to receive).
So right now, the side effect is apparently. Let me explain it in detail. There are three controllers A, B, C.for example. The controller A post a notification helloEveryone. The controller B also post a notification helloEveryone.
In C controller, if you place a statement like below:
[[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(helloEveryOne) name:#"helloEveryone" object:nil]
Then you will receive two helloEveryone from controller A and controller B.
if you place a statement like this:
[[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(helloEveryOne) name:#"helloEveryone" object:controllerA]
Then you will receive only one helloEveryone from controller A.
The self surely is not a nil notification sender as long as it can post a notification, but use another object as a notification sender, may be it is a nil object. And the observer's behave is different in terms of that whether notification sender is nil or not.
It is crucial if the events really have sender.
When you register an observer, you can specify the sender that you want to observe. If you are letting other people using your message, so it is crucial to pass sender correctly or the observer that bound to specific sender will not get your message.
I've been thinking about this and have read through another stackoverflow question regarding the best recommended way to communicate between view controllers. However, the question/answer for that doesn't seem to address the best approach for the reverse behavior.
i.e. to pass data from ParentController to its ModalController, we could initialize ModalController like initWithDataToProcess:.
But what if we want to do the reverse? How would I notify the previous controller about a new data?
e.g. User clicks on 'new person' button on the ParentController. I initiate a new ModalController and present the user with a person editor view via presentModalViewController:. User clicks on 'done' to add a new person. I dismissModalViewController: and UI returns to the ParentController's view.
Using a global field reference in a singleton object (app delegate or other) is bad. delegation (via formal protocol) and notifications (via NSNotificationCenter) seems overkill. Any suggestions?
It is generally cleaner to use notifications. Just add your observer like this....
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(somethingHappened:) name:#"MyNotification" object:nil];
and elsewhere in your code you'd post the notification whenever you need to.
[[NSNotificationCenter defaultCenter] postNotificationName:#"MyNotification" object:self];
In the example I'm passing self but you can pass any object you wish really and it will be fed to your somethingHappened: function
The important thing is to keep the #"MyNotification" very descriptive and unique. Adding your project name to the beginning is a good way to keep things unique...eg. #"ProjAXViewHasGotData"
A delegate is pretty much the minimum you can do. If you think it is too much of a hassle to declare a new protocol for this, just pass in the parent view controller and have the modal one call a method on it.