I want to get notified when my application is in background with :
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(calendarChanged:) name:EKEventStoreChangedNotification object:nil];
I tried to implement it but (calendarChanged:) never get called ?!
You should specify the EKEventStore object when registering the notification observer
Your method is not going to be called while in background, it will be called once your app comes to foreground.
Taken from this question, the search option doesn't hurt.
Related
I'm trying to integrate the GCController framework into my project. I'm not so familiar with Objective-C, so please excuse my ignorance around how this is supposed to work.
I have a class that extends NSOpenGLView, which registers observer methods for the various controller notifications, like so:
-(void)awakeFromNib
{
// Do some stuff
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(controllerStateChanged) name:GCControllerDidConnectNotification object:nil];
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(controllerStateChanged) name:GCControllerDidDisconnectNotification object:nil];
}
and I've defined a super simple handler as such:
- (void)controllerStateChanged {
NSLog (#"something happened, let's check it out\n");
}
Problem is, these events/notifications never seem to fire - and when I inspect [GCController controllers], it's entirely empty.
Of course, it stands to reason that if there are no controllers, there will be no events - so maybe I'm doing something wrong?
Or perhaps, for whatever reason - my controller simply fails to generate the required events (I'm using a PS4 controller which is registered with the OS, be it wirelessly or via USB, so I'm not sure what I'm missing here).
Is there some other place I need to enable these notifications? Do I need to somehow initialise the GCController framework?
So it turns out that the GCController framework only supports MFi (Made For iPod, Made For iPhone, Made For iPad) controller products.
For anyone looking to support non-MFi controllers, you'll need to interface with the HID via IOKit. Or use the rather excellent DDHIDLib instead
In my 'viewDidLoad'in ViewController.m, I am registering to the NSNotificationCenter defaultCenter with 'EAAccessoryDidConnectNotification' and 'EAAccessoryDidDisconnectNotification'
When my app is active in foreground, I get the notification, and respond in accessoryDidConnect. all works OK.
But, when app is in background, how can I get such notification?
('EAAccessoryDidConnectNotification' and 'EAAccessoryDidDisconnectNotification')
[Code below]
Thanks a lot.
Dan
(void)viewDidLoad
{
[super viewDidLoad];
[[NSNotificationCenter defaultCenter] addObserver:self
selector:#selector(accessoryDidConnect:)
name:EAAccessoryDidConnectNotification
object:nil];
[[NSNotificationCenter defaultCenter] addObserver:self
selector:#selector(accessoryDidDisconnect:)
name:EAAccessoryDidDisconnectNotification
object:nil];
[[EAAccessoryManager sharedAccessoryManager] registerForLocalNotifications];
}
According to the documentation, it's not possible:
If your app is suspended in the background when an accessory
notification arrives, that notification is put in a queue. When your
app begins running again (either in the foreground or background),
notifications in the queue are delivered to your app. Notifications
are also coalesced and filtered wherever possible to eliminate any
irrelevant events. For example, if an accessory was connected and
subsequently disconnected while your app was suspended, your app would
ultimately not receive any indication that such events took place.
But it would be interesting if someone proved me wrong.
in iOS 12.1.4, plug in the relay cable with iPhone and DSLR Camera when app is in foreground, then switch app into background mode, unplug the relay cable and switch app back into foreground, you will receive the accessoryDidDisconnect notify via EAAccessory's delegate methods.
I have started listening to global keyDown events. Is there a way to get information from which application that event came?
A handler receives NSNotification instance and NSEvent is part of it. Can I somehow extract that information from those objects?
Listening snippet:
[NSEvent addGlobalMonitorForEventsMatchingMask:NSKeyDownMask handler:^(NSEvent *event){
NSLog(#"global keyDown %#", event);
[[NSNotificationCenter defaultCenter] postNotificationName:kKeyPressed
object:event];
}];
Observer:
[[NSNotificationCenter defaultCenter] addObserver:self
selector:#selector(keyEventHandler:)
name:kKeyPressed
object:nil];
UPDATE
Global key downs are not send from any particular application. What I actually needed is to check for currently active application at event handler:
[[NSWorkspace sharedWorkspace] activeApplication]
This returns NSDictionary with information I needed.
You're not posting a distributed notification, or using a distributed notification center. This means you know that the notification came from the current application.
Meanwhile, you're generating the notifications yourself, so if you did need to know the application, you could just add that in.
Finally, the events you're embedding are global key events, which do not have an associated application. Except in special cases, they're not generated by any application, they're generated by the user typing on the keyboard.
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.
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.