iOS and accessories to communicate [turn]

and accessories for communication

On the iphone OS 3.0 and beyond, the External accessory Framework (Externalaccessory.framework) provides a plumbing mechanism that allows applications to be used with the iphone or ipod Touch the accessories of the equipment to communicate. With this pipeline, application developers can integrate component-level functionality into their programs.

Please note: The following sections will show you how iphone applications connect accessories. If you are interested in becoming an iphone or ipod Touch accessory developer, you can find the appropriate information on the Http://developer.apple.com website.

In order to use the interface of the external accessory framework, you must add externalaccessory.framework to the Xcode project and connect to the corresponding target. In addition, you need to include a #import <ExternalAccessory/ExternalAccessory.h> statement at the top of the corresponding source code file to access the framework's class and header files. For more information about how to add a framework to your project, see the Documentation section of the project in the Xcode Engineering Management Guide, and for general information about the classes in the external accessory framework, see external Accessory framework reference. parts of the foundation

Prior to communicating with the accessories, we need to work closely with the manufacturer of the accessories to understand the service provided by the accessories. The manufacturer must include explicit support in the hardware of the accessories to communicate with the iphone OS. As part of this support, accessories must support at least one command protocol , which is to support a custom mode of communication that allows data transfer between accessories and applications. Apple does not maintain the registry of an agreement, what protocols are supported, and whether custom or standard agreements supported by other manufacturers are to be determined by the manufacturer.

As part of the communication with the accessory manufacturer, you must find out what agreement the given accessory supports. To avoid conflicting namespaces, the name of the protocol is specified by a reverse DNS string, in the form of Com.apple.myProtocol. This allows each accessory manufacturer to define the agreement according to its own needs to support different product lines for accessories.

The application communicates with the accessories by opening a session that uses the specified protocol. The way to open a session is to create an instance of the Easession class that contains Nsinputstream and Nsoutputstream objects that can communicate with the accessories. Through these streaming objects, the application can send raw packets to the accessories and receive similar packets from the accessories. Therefore, you must follow the desired protocol to understand the format of each packet. declaring protocols supported by applications

Applications that can communicate with accessories should declare the supported protocol in their Info.plist file to enable the system to know that the application can be started when the appropriate accessories are connected. If no applications are currently available to support an access accessory, the system can choose to start the App Store and point to the application that supports the device.

In order to declare a supported protocol, you must include the Uisupportedexternalaccessoryprotocols key in the application's Info.plist file. The key contains an array of strings that identify the communication protocols that the application supports. Your application can include any number of protocols in any order in this list. The system does not use this list to determine which protocol the application should choose, but to use it to determine whether the application can communicate with the appropriate accessories. Your code needs to choose the appropriate communication protocol at the start of the conversation with the accessories. Connecting accessories at run time

The accessories can not be seen through the external accessory framework before the accessory access system is ready for communication. When the accessories become visible, your application can get the appropriate accessories object and then open the session with one or more of its supported protocols.

The shared Eaaccessorymanager object provides the main entry point for the application to find the accessories to communicate with. This class contains an array of connected accessory objects that you can enumerate to see if there is an application-supported accessory. The vast majority of information in the Eaaccessory object, such as name, manufacturer, and model information, is used only for display. If you want to determine whether an application can connect an accessory, you must look at the accessories protocol and verify that the application supports one of these protocols.

Please note: It is possible for multiple accessory objects to support the same protocol. If this happens, your code must be responsible for choosing which accessory object to use.

For a given accessory object, there can be only one session of the specified protocol at a time. The Eaaccessory object's Protocolstrings property contains a dictionary, and the dictionary key is an accessory-supported protocol. If you attempt to create a session with a protocol that is already in use, the External accessory framework generates an error.

Listing 8-1 shows how to check the list of access accessories and get the first accessories from the application support. It creates a session for the specified protocol and configures the input and output streams for the session. When this method returns the Session object, it completes the connection with the component and can begin sending and receiving data.

Program Listings 8-1 Create and accessories communication sessions

After configuring the input output stream, the best step is to process the data associated with the stream. Listing 8-2 shows the basic code structure that handles flow events in the delegate method. The methods in the checklist can respond to events from the input and output streams of accessories. When an accessory sends data to the application, the event occurs to indicate that there is data to read; Similarly, when the accessory is ready to receive application data, it is represented by events (of course, you don't have to wait until this event occurs to write data to the stream, The application can also invoke the Hasbytesavailable method of the stream to confirm that the accessory is still able to receive data. For more information about the flow and how to handle flow events, see the Cocoa Flow Programming Guide.

Program Listings 8-2 handling Flow Events

td>