Processing Queued Notifications at Wakeup Time

Processing Queued Notifications at Wakeup Time

An app in the suspended state must be ready to handle any queued notifications when it returns to a foreground or background execution state. A suspended app does not execute any code and therefore cannot process notifications related to orientation changes, time changes, preferences changes, and many others that would affect the app’s appearance or state. To make sure these changes are not lost, the system queues many relevant notifications and delivers them to the app as soon as it starts executing code again (either in the foreground or background). To prevent your app from becoming overloaded with notifications when it resumes, the system coalesces events and delivers a single notification (of each relevant type) that reflects the net change since your app was suspended.

Table 3-2 lists the notifications that can be coalesced and delivered to your app. Most of these notifications are delivered directly to the registered observers. Some, like those related to device orientation changes, are typically intercepted by a system framework and delivered to your app in another way.

Table 3-2  Notifications delivered to waking apps



An accessory is connected or disconnected.



The device orientation changes.


In addition to this notification, view controllers update their interface orientations automatically.

There is a significant time change.


The battery level or battery state changes.



The proximity state changes.


The status of protected files changes.



An external display is connected or disconnected.



The screen mode of a display changes.


Preferences that your app exposes through the Settings app changed.


The current language or locale settings changed.


The status of the user’s iCloud account changed.


Queued notifications are delivered on your app’s main run loop and are typically delivered before any touch events or other user input. Most apps should be able to handle these events quickly enough that they would not cause any noticeable lag when resumed. However, if your app appears sluggish when it returns from the background state, use Instruments to determine whether your notification handler code is causing the delay.

An app returning to the foreground also receives view-update notifications for any views that were marked dirty since the last update. An app running in the background can still call the setNeedsDisplay or setNeedsDisplayInRect: methods to request an update for its views. However, because the views are not visible, the system coalesces the requests and updates the views only after the app returns to the foreground.

xmpp extensions



XMPP is the Extensible Messaging and Presence Protocol, a set of open technologies for instant messaging, presence, multi-party chat, voice and video calls, collaboration, lightweight middleware, content syndication, and generalized routing of XML data.

The XMPP Standards Foundation (XSF) develops extensions to XMPP through a standards process centered around XMPP Extension Protocols (XEPs). The process is managed by the XMPP Extensions Editor and involves intensive discussion on the Standards mailing list, formal review and voting by the XMPP Council, and modification based on implementation experience and interoperability testing. All documents in the XEP series are available under a liberal IPR Policy for wide implementation. Submissions are welcome (see also the “inbox”). All XEPs and related files are under source control, old versions are available, and IETF-style XML reference files are provided. A compressed archive of all current XEPs can be downloaded [[[[[here]]]]]. 这里可以下载到所有XEP协议PDF版本的压缩包。

You can view and submit XEP-related bugs and feature requests at the issue tracker.

This page lists approved XMPP extensions as well as proposals that are under active consideration. A list of all XEPs (including retracted, rejected, deprecated, and obsolete XEPs) is also available. Good places for developers to start are the client compliance and server compliance definitions, as well as the technology overview pages.


First, call setProxyCandidates with an array of the possible servers that you might be able to use for proxying. The default is “”, and your server is not federated with, which is why you are getting the disco error back.

Next, in your delegate, implement the following methods:

- (void)turnSocket:(TURNSocket *)sender didSucceed:(GCDAsyncSocket *)socket;
- (void)turnSocketDidFail:(TURNSocket *)sender;
Then, in your didSucceed implementation, send data on the socket that was passed in, using:

- (void)writeData:(NSData *)data 
Finally, close the socket:

- (void)disconnectAfterWriting;

I figured this out by looking at the source for TURNSocket.m, looking for the hardcoded “”, then searching for [delegate to find the places the delegate was getting called. This took me back to TURNSocket.h, which had a protocol documented for the delegate to implement.