All of the examples I can find of setting up a notification look like this:
[nc addObserver:self selector:#selector(keyboardWillShow:) name: UIKeyboardWillShowNotification object:nil];
where object is always being set to nil. object is the notificationSender, which is defined thusly in the documentation:
"The object whose notifications the observer wants to receive; that is, only notifications sent by this sender are delivered to the observer. When nil, the notification center doesn’t use a notification’s sender to decide whether to deliver it to the observer."
I want to receive the keyboard notification only for one particular text view, so I want to tell addObserver that, but I don't know what to give it for the object. I tried the outlet variable that's bound to the text view I'm interested in, but that just resulted in my getting no notifications at all.
Any suggestions?
The UIKeyboardWillShowNotification is coming from your window instance, and for all intents and purposes is a "system" notification. The keyboard is either showing or not showing, it's not really something that is tied to a specific control.
If you want to do something when a user enters a specific text field, you should probably control that in the text field's delegate instead.
In this case you can not get the notification only for one particular text view, as the docu for UIKeyboardWillShowNotification says "The notification object is nil.".
You have to check in your keyboardWillShow impl if your particular text view isFirstResponder.
I had two competing needs - I had to use the keyboard notification because I needed to get the keyboard height, which appears to be only available that way, but I also needed to know which text view I was in, which meant also using the textViewDidBeginEditing delegate. After much messing around I finally resorted to getting the keyboard height in the notification method and storing it in an instance variable, which was then available to use in the delegate method (I need to scroll the view up so the bottom text view is not mostly hidden under they keyboard when they start typing). A bit inelegant, but it works.
Thanks for the pointers!
Related
Hi I want to make custom local notification so that whenever popover is visible it will handle by that notification.
so that as multiple time the popover is visible it will handle by that notification
Currently i have partially done this but problem is that if i want to run notification's selector method multiple times i have to post that notification wherever i want.
used this link to implement it
i want to send some notifications to observers when some event occurs. and i also want to know how observer catch/handle/receive that notification?
Can i make notification like, once i postNotification in viewDidLoad it will handle as many times that event occurs?
Note-See the answer posted by me
Use this
line before presenting popover
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(dissmissPop:) name:#"popOver" object:popOver.contentViewController];//popOver is your name of popover
-(void)dissmissPop:(id)sender{
//method to be called
}
To call notification from popover use this
[[NSNotificationCenter defaultCenter] postNotificationName:#"popOver" object:self];
Notifications are same as broadcast receivers. If we register as broadcast receiver whenever new email arrives. But do you actually post the event notification? No. Someone else does. Similarly when keyboard is shown the notification is posted by the system. Send you only get notified.
The system posts whenever the keyboard is gonna appear. This should make it clear that if you want to post custom notifications you have to post it every time there's need for it to.
So if you make custom notification you have to postNotification when ever you want to post it.
I'm trying to make an application that uses the event's when the volume up/down buttons are pressed. I'm using the event like this:
[[NSNotificationCenter defaultCenter] addObserver:self
selector:#selector(volumeChanged:)
name:#"AVSystemController_SystemVolumeDidChangeNotification"
object:nil];
when one of the volume button is pressed, the function "volumeChanged:" is called.
my problem is that when one of the volume buttons is pressed, I also get the default notification that shows the current volume bar status. I want to hide this message, so nothing will appear when I press the volume buttons. is anyone know how to do so?
p.s. I don't care about the volume itself. all I care about is the buttons events and the message that pops out when one of them is pressed.
thanks.
Edit:
Now I understand. Check out this answer and its comments.
Documentation is your friend, take a look at MPVolumeView class reference.
As of 4.2 you can manage visibility of controls with two new properties: showsVolumeSlider and showsRouteButton.
P.S. Welcome to StackOverflow :) Remember to use search box and accept answers that solved your problems ;)
I have an app with a navigation controller as the root view. There are many views that can be pushed in.
The user has to create an account to use the app. The user can then log into this account from other devices, but only one device can be logged onto the same account at a time. So if multiple devices try to log into an account, only the latest device will be logged in and the other devices are logged off (a push is sent to the devices).
Since there are multiple views that the device could be showing before it was logged off, I call popToRootViewControllerAnimated: to get back to the root view. This is because when the user logs in the next time I only want the root view to be shown (the new account might not have access to the previously shown view).
If the user has an alert view or action sheet presented (which uses the current view as its delegate) before the push is received, the view will still be shown after the popToRootViewControllerAnimate: method is called. If the user then taps on a button for the alert view or action sheet, it will send a message to the dealloc'd view and crash the app.
An example:
myViewController is being shown to the user.
myViewController create an action sheet prompting the user for a decision.
The push is received for the device to log out.
The navigation controller pops all the views controllers and now shows myRootViewController.
Since the view controllers are popped, myViewController is now dealloc'd.
The action sheet from myViewController is still shown.
When the user selects an option form the action sheet, a message is sent to myViewController, and since it is already dealloc'd, a crash will occur.
Is there any way to prevent this?
One solution I have considered would be to keep track of all the objects that uses a specific view controller as its delegate. Then when that view controller dealloc's it will also set all the object's delegates to nil. This requires me to manually take care of every view controller when they create an object that uses itself as the delegate, since I cannot think of a way to automatically create and update this list.
Any better solution (or improvement to mine) would be appreciated!
Edit: The alert view and action sheet are only examples of some objects that I would use myViewController as a delegate. I am also using a number of other classes (and third-party libraries) that implements this delegate pattern.
A few ideas:
you can encapsulate the alert/action sheet view and delegate in a single class. Then when you need an alert view, create MyAlertView instead, which will also be its own delegate and will do [self release] after the user taps a button.
make your App Delegate the only delegate for all your alert views and action sheets. App Delegate is always around while the application is running, so there won't be a problem with a released delegate.
The problem with both solutions is that if you need your application to know what happened in the alert view/action sheet, you somehow need to tell the interested class of the user's choice.
You can do that by either using delegates of your own - which would mean you're back to square one - or use notifications: when the alert view/action sheet delegate is called, it would post a notification ([[NSNotificationCenter defaultCenter] postNotificationName:NotificationName object:self userInfo:userInfo];), while the interested object would look for that notification ([[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(onNotification:) name:NotificationName object:nil];) and perform whatever tasks necessary in onNotification:(NSNotification*)aNotification method.
You'll be able to agree with yourself on what type of information is passed in those notifications (I would think the button number in a NSNumber class would be enough, or perhaps pass the button text, too). And you won't have to keep track of all alert views - just don't forget to remove the observer ([[NSNotificationCenter defaultCenter] removeObserver:self name:postNotificationName object:nil];) in the views' dealloc.
Edit:
"This requires me to manually take care of every view controller when they create an object that uses itself as the delegate, since I cannot think of a way to automatically create and update this list."
Actually you probably can do this in a semi-automated way: make a singleton object with a method like
-(id)delegate:(id)delegate for:(id)forWhom
And then instead of
someThingy.delegate = self;
you'd do
someThingy.delegate = [[DelegateLocker defaultLocker] delegate:self for:someThingy];
Inside the DelegateLocker you'd have a MutableDictionary with delegate class as a key and a MutableArray of someThingies as a value. Then in your view controllers' deallocs you'd call
[[DelegateLocker defaultLocker] delegateIsDying:self];
which would go through the thingies and assign delegate = nil for each
The drawback of course is that you'll be retaining all the thingies for an indefinite period of time instead of releasing them immediately.
So the ViewController that presented the action sheet iand set itself as the delegate right? So why dont you keep a reference to the ActionSheet in the ViewController, in the dealloc method of the view controller, you can check if the action sheet is visible, if it is then set the delegate of the action sheet to nil,and dismiss it...
so
-(void)dealloc
{
if(myActionSheet && [myActionSheet visible])
{
[myActionSheet setDelegate: nil];
//dismiss
}
}
Hope that helps
If you want automated solution, I think you can make a function to iterate through Ivars of your view controller to see if any Ivar has delegate property and set it to nil.
I have a view with multiple text fields and I want to do the same effect that the Contacts application does when you click on a text field would otherwise be hidden by the keyboard when it comes up. When I dismiss the keyboard I plan on moving the view back down properly.
I suspect that I do this by changing the Frame value, but I need this to be animated so that it isn't jarring to the user.
Advice? Examples?
Wrapping your view in a UIScrollView is indeed the way to go. As well as on the textFieldDidEndEditing delegate, you could instead subscribe to the UIKeyboardDidHideNotification and UIKeyboardDidShowNotification and when you receive a notification that the keyboard did hide/show then scroll your view appropriately. I can post code examples for the keyboard notifications if you need it : )
Edit
Figured I'd post the code anyway - someone might find it helpful:
You need to declare listeners for the notifications:
NSObject hideObj = NSNotificationCenter.DefaultCenter.AddObserver(UIKeyboard.DidHideNotification, HandleKeyboardDidHide);
NSObject showObj = NSNotificationCenter.DefaultCenter.AddObserver(UIKeyboard.DidShowNotification, HandleKeyboardDidShow);
then your Action methods would look something like:
void HandleKeyboardDidShow(NSNotification notification)
{
scrollView.ScrollRectToVisible(textfield.Frame, true);
}
void HandleKeyboardDidHide(NSNotification notification)
{
// scroll back to normal
}
Edit 2
So if you'd like to remove the Observers when the view is destroyed, first you need to ensure you assign NSObjects when adding the observers then use the following code to remove them:
NSNotificationCenter.DefaultCenter.RemoveObserver(showObj);
NSNotificationCenter.DefaultCenter.RemoveObserver(hideObj);
Hope that helps.
I just did this on an application. I used a scrollview to wrap my entire view, and then used scrollToRectVisible on the textFieldDidEndEditing-delegate method. It worked perfectly!
The Apple documentation on about the keyboard management topic is pretty good and contains code (at the bottom) for most situations that that you can copy/paste right into your app.
Best of luck.
In many situations, such as making the keyboard go away when the use clicks done, there are two options: set the text field's delegate to self, and adopt the UITextFieldDelegate protocol, and then use the method
- (BOOL)textFieldShouldReturn:(UITextField *)textField;
to resignFirstResponder and return YES. But you can also
addTarget:self
action:#selector(myMethod:)
forControlEvent:UIControlEventDidEndOnExit];
or something like that, using the did end on exit event, and then in the method, [sender resignFirstResponder]. So what is the best option in situations like these: the delegate, or the event?
The quick rule of thumb is that delegates are supposed to answer the question of "should I?" on behalf of the object they are a delegate for. Events, on the other hand, are broadcast afterward to let listeners know that something has happened.
In your case, while you could call [sender resignFirstResponder] in response to the event, you're mixing metaphors by doing this. Your delegate should have already made the decision to hide the keyboard (or not) and the event being broadcast is merely to let all the other components know that they keyboard hid.
If you are going to be paired with one other class, where the real type of that class may vary, then it makes a lot of sense to formalize that pairing into a protocol and a delegate arrangement.
If the information you want to send is targeted at a broader set of objects, then it starts to make more sense to use notifications - though now you have somewhat obscured what information is being passed by the notification as there's no central definition for what to expect.
Both are about an equal load to work with - with a delegate you have to set yourself and then remember to unset yourself before you are deallocated. You have to do the same thing with notifications, remember to start listening and then unsubscribe before you are deallocated.
Also, you should try as much as possible to make sure you send notifications out on the main thread as the notices get sent on the same thread they started from. Same goes for delegate methods, it's not very kind to call a delegate method from some other mystery thread!
The delegate makes your objects more reusable they are an adapter that lets any object interact with the defined behaviors of that object and use the object. I would say delegates should be adopted by the object responsible for keeping the state of and defining behavior to actions that will occur in the object that it is using. Events should be used for any other objects that are intersted in particular action that the object that has the protocol does (so objects not responsible for keeping the state of the object that defines the protocol).
For example: A view controller using a textfield will adopt its protocol to dismiss the keyboard and any other behaviors that can occur for a textfield, maybe another controller will do some animation when the keyboard is dismissed, so it will register to the textfield as an event in order to receieve the event of the keyboard being dismissed.