Classes

@abstract Hype domestic instance.

@discussion This class is the main entry point for the Hype SDK. It provides facade access to the Hype service running on the background. This class wraps the domestic instance created for the host device. Each app can only create a single instance, which is why class is a singleton. This class allows users to listen to events on the created instance by subscribing observers, as well as starting and stopping the Hype services.

@abstract Hype network instance.

@discussion Instances map to devices participating on the network. Instances are advertised on the network and, when found, a notification is issued indicating that the instance is available for communication purposes. Usually, there’s no need to instantiate objects of this type at all, as the framework handles that automatically. Hype uses 96 bit identifiers (which added with the realm adds up to 128 bits). 64 of those, 96 bits can be used for a custom identifier, which is called the vendor identifier. Vendor identifiers can be set when starting Hype’s services with HYPOptionIdentifierKey, and are queried back using -vendorIdentifier on each instance. This should be useful to help map instances with some useful entity, such as users. The -identifier property returns the instance’s full identifier, including the bytes generated by the SDK.

@abstract Represents a message sent over the network.

@discussion Messages are abstract entities that help keeping track of data as it is sent over the network, by holding a unique identifier. The identifier is actually held by the underlying HYPMessageInfo instance (-info), but the HYPMessage class provides dynamic access to that attribute. This is mostly motivated by the fact that Hype does not keep messages for memory purposes. As such, it’s up to the developer to hold or discard the data as needed. Instead, HYPMessageInfo instances are used to keep track of the state of any given HYPMessage.

@abstract Message metadata.

@discussion This class is used to hold message metadata. At this point, it only includes the message identifier, but this will change with future releases. It’s mostly useful to associate messages with the metadata, as Hype notifications usually use instances of this class and not HYPMessage. This is motivated by the fact that HYPMessage holds the message’s payload, which would consume more memory.