Communicating with External Accessories IPHONE APPS

In iPhone OS 3.0 and later, the External Accessory framework (External Accessory. framework) provides a conduit for communicating with accessories attached to an iPhone or iPod touch device. Application developers can use this conduit to integrate accessory-level features into their applications.

To use the features of the External Accessory framework, you must add External Accessory.framework to your Xcode project and link against it in any relevant targets. To access the classes and headers of the framework, include an #import<External Accessory/ External Accessory.h> statement at the top of any relevant source files. For more information on how to add frameworks to your project, see Files in Projects in Xcode Project Management Guide.

Accessory Basics

Communicating with an external accessory requires you to work closely with the accessory manufacturer to understand the services provided by that accessory. Manufacturers must build explicit support into their accessory hardware for communicating with iPhone OS. As part of this support, an accessory must support at least one command protocol, which is a custom scheme for sending data back and forth between the accessory and an attached application. Apple does not maintain a registry of protocols; it is up to the manufacturer to decide which protocols to support and whether to use custom protocols or standard protocols supported by other manufacturers.

As part of your communication with the accessory manufacturer, you must find out what protocols a given accessory supports. To prevent namespace conflicts, protocol names are specified as reverse-DNS strings of the form This allows each manufacturer to define as many protocols as needed to support their line of accessories.

Applications communicate with an accessory by opening a session to that accessory using a specific protocol. You open a session by creating an instance of the EA Session class, which contains NS Input Stream and NS Output Stream objects for communicating with the accessory. Your application uses these stream objects to send raw data packets to the accessory and to receive similar packets in return. Therefore, you must understand the expected format of each data packet based on the protocol you want to support.

Declaring the Protocols Your Application Supports

Applications that are able to communicate with an external accessory should declare the protocols they support in their Info.plist file. Declaring support for specific protocols lets the system know that your application can be launched when that accessory is connected. If no application supports the connected accessory, the system may choose to launch the App Store and point out applications that do.

To declare the protocols your application supports, you must include the UI Supported External Accessory Protocols key in your application’s Info.plist file. This key contains an array of strings that identify the communications protocols that your application supports. Your application can include any number of protocols in this list and the protocols can be in any order. The system does not use this list to determine which protocol your application should choose; it uses it only to determine if your application is capable of communicating with the accessory. It is up to your code to choose an appropriate communications protocol when it begins talking to the accessory.

Connecting to an Accessory at Runtime

Accessory are not visible through the External Accessory framework until they have been connected by the system and made ready for use. When an accessory does become visible, your application can get the appropriate accessory object and open a session using one or more of the protocols supported by the accessory.

The shared EA Accessory Manager object provides the main entry point for applications looking to communicate with accessories. This class contains an array of already connected accessory objects that you can enumerate to see if there is one your application supports. Most of the information in an EA Accessory object (such as the name, manufacturer, and model information) is intended for display purposes only. To determine whether your application can connect to an accessory, you must look at the accessory’s protocols and see if there is one your application supports.

For a given accessory object, only one session at a time is allowed for a specific protocol. The protocol Strings property of each EA Accessory object contains a dictionary whose keys are the supported protocols. If you attempt to create a session using a protocol that is already in use, the External Accessory framework generates an error.

Listing shows a method that checks the list of connected accessories and grabs the first one that the application supports. It creates a session for the designated protocol and configures the input and output streams of the session. By the time this method returns the session object, it is connected to the accessory and ready to begin sending and receiving data.

Creating a communications session for an accessory

After the input and output streams are configured, the final step is to process the stream-related data. Listing shows the fundamental structure of a delegate’s stream processing code. This method responds to events from both input and output streams of the accessory. As the accessory sends data to your application an event arrives indicating there are bytes available to be read. Similarly, when the accessory is ready to receive data from your application, events arrive indicating that fact. (Of course, your application does not always have to wait for an event to arrive before it can write bytes to the stream. It can also call the stream’s has Bytes Available method to see if the accessory is still able to receive data.)

Processing stream events

Monitoring Accessory-Related Events

The External Accessory framework is capable of sending notifications whenever a hardware accessory is connected or disconnected. Although it is capable, it does not do so automatically. Your application must specifically request that notifications be generated by calling the register For Local Notifications method of the EA Accessory Manager class. When an accessory is connected, authenticated, and ready to interact with your application, the framework sends an EA Accessory Did Connect Notification notification. When an accessory is disconnected, it sends an EA Accessory Did Disconnect Notification notification. You can register to receive these notifications using the default NS Notification Center, and both notifications include information about which accessory was affected.

In addition to receiving notifications through the default notification center, an application that is currently interacting with an accessory can assign a delegate to the corresponding EA Accessory object and be notified of changes. Delegate objects must conform to the EA Accessory Delegate protocol, which currently contains the optional accessory Did Disconnect: method. You can use this method to receive disconnection notices without first setting up a notification observer

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status