HYPStateObserver

@abstract Notification issued when Hype services start.

@discussion This notification is issued upon a successful call to -startWithOptions on the Hype singleton instance. When this notification is triggered, Hype services are actively being advertised on the network and device matches can occur at any time.

@abstract Notification issued when Hype services stop.

@discussion This notification is issued when the Hype services are requested to stop, or otherwise forced to do so. If the services were forced to stop (such as the adapter being turned of) the error instance will indicate the cause of failure. If this is being triggered due to a successful call to -stop, then the error will be set to nil.

@abstract Notification issued when Hype services fail starting.

@discussion This notification is issued in response to a failed start request. This means that the device is not actively participating on the network with any transport nor trying to recover from the failure. If, at some point, the framework finds indications that recovery is possible, a -hypeDidBecomeReady: notification is issued. Hype services will not start unless explicitly told to.

@abstract Notification issued when Hype services become ready after failing.

@discussion This notification is issued after a failed start request (that is, after -startWithOptions: resulting in -hypeDidFailStarting:error:) and the framework identifying that the cause of failure might not apply anymore. Attempting to start the framework’s services is not guaranteed to succeed as other causes for failure might exist, but they are likely to do so. It’s up to the receiver to decide whether the services should be started. This event is only triggered once and Hype stops listening to adapter state events.

@abstract Notification issued when the HYP instance changes state.

@discussion This notification is issued whenever the Hype instance changes state. This method could be used as an alternative to -hypeDidStart: and -hypeDidStop:error:, as it indicates when Hype enters into HYPStateRunning and HYPStateIdle states, but also HYPStateStarting and HYPStateStopping. Whether to use this method or the other specific notifications is a design call, as both types of notification are guaranteed to always be triggered when state changes occur. However, the more specific onStart(Hype) and onStop(Hype, Error) are preferable. Notice, for instance, that this method does not provide error information in case of stoppage.