Cognex Mobile Barcode SDK for iOS

It is important to recognize that there are several fundamental differences in the capabilities of smartphones (and tablets) as barcode scanning devices. These differences result in a user experience different from purpose-built scanners, impacting the design of the mobile barcode scanning application.

These differences and the general impact they have on your application are the following:

• A smartphone does not have a dedicated hardware trigger. Without a hardware trigger, the application program itself is generally responsible for initiating the scanning process, which results in accessing the built-in camera, displaying a preview screen if required, and analyzing captured frames from the video stream for barcodes.
• A smartphone (unless otherwise configured) does not have an aimer. Generally, the application program provides a live-stream camera preview on the mobile device screen, thereby allowing the user to see what the camera sees and can then position the device over the barcode.
• Mobile device orientation may need to be considered. Most users hold and use a mobile device primarily in a portrait orientation and for barcode scanning. Having the camera in this orientation is generally sufficient. However, most mobile device cameras have a higher resolution along their landscape orientation. When scanning very long or dense barcodes, reorienting the device to landscape can be beneficial and even necessary to decode these barcodes.
• Image analysis and barcode decoding is performed in software on the mobile device which can be a CPU intensive task. For this reason (and others discussed later), it is highly recommended to only enable the symbologies and features of the SDK your application will need, not everything the cmbSDK is capable of.

The cmbSDK has been specifically engineered to make these differences as transparent as possible to the application developer and the user. By following a few simple guidelines, it is possible to develop applications that work and behave the same, whether using an MX-1000 mobile terminal, or just the built-in camera of the device.

Without a hardware trigger, mobile devices must use alternative methods to initiate barcode scanning. There are three common paradigms used: 

• Application or workflow driven trigger: In this paradigm, it is the application code itself, or the business logic/workflow of the application that starts the scanning process. In other words, the user of the application has reached a point where a barcode needs to be scanned, so the application invokes the scanning module. In simple programming terms, this is akin to calling a function like "startScanner()". 
• Virtual trigger: This is where the application program provides a button on the screen whereby the user can use to start/stop the scanning process. Depending on the application design, the user may be required to press and hold the virtual button to keep the scanner running. This method is similar to the workflow driven method as the button from the user interface is merely being used to invoke the scanning module. 
• Simulated trigger: For this method, one of the buttons on the mobile device, typically the volume-down button, is used to simulate a hardware trigger. When the user presses and holds this button, the scanner starts/stops just like when a trigger is pulled on a purpose-built scanner. This method is not commonly used as users find it non- intuitive and inconvenient to use the volume key in this fashion. 

The cmbSDK supports all three of these methods, any one of which (or multiple) can be used in an application.  

As previously discussed, unlike like purpose-built scanners, mobile devices do not have a built-in aimer. Barcode aimingis generally accomplished by providing a live-stream preview from the camera on the mobile device display: the user can then reposition the device until the barcode presents in the field of view and is decoded.This task is greatly simplified with the cmbSDK as it provides a built-in preview control that can be displayed full-screen,partial screen, and in either portrait or landscape orientation.The cmbSDK also supports "passive" aimers: devices that attach to the mobile device or mobile device case that use theLED flash of the device as a light source to project an aiming/targeting pattern. The advantage to these types of aimers isthat an on-screen preview is no longer required (since the mobile device can now project an aimer pattern similar to apurpose-built scanner). One limitation of passive aimers, though, is that since the mobile device flash is being used forthe aimer, using the LED flash for general scanning illumination is not available.

Mobile devices support developing applications for either portrait orientation, landscape orientation, or auto-rotation between the two. The cmbSDK fully supports all three options for both the presentation of the barcode preview as well as the scan direction. As mentioned previously, most barcodes can be scanned by a mobile device regardless of the orientation of the application and/or mobile device.

In some circumstances, though, using landscape orientation may be advantageous or even necessary. Mobile cameras have a higher resolution along the "height" of the image in portrait mode. For example, a common resolution used is 1280x720. When scanning barcodes in portrait mode, this means that 720 pixels of data are available for barcode decoding along the horizontal axis. If scanning a particularly long or dense barcode (e.g. a large PDF417), using the landscape orientation provides 1280 pixels on the horizontal scan line. Orientation makes little to no difference when scanning "square" barcodes like QR, Data Matrix, and MaxiCode. 

Today's smartphones and tablets have significant computing power. With multi-core CPUs and even dedicated image processors, they provide an ideal platform for cost-effective and efficient barcode decoding. As powerful as these devices are, developers are still advised to consider optimizing their barcode scanning applications. While the SDK has been optimized specifically for mobile environments, image analysis and barcode decoding is still a CPU intensive activity: and since these processes must share the mobile device CPU with the operating system, services, and other applications, developers should limit their applications to only using the features of the SDK that satisfy their needs.

Application optimizations include the following: 

• Only enable decoding for the barcode types the application needs to scan.The cmbSDK supports the decoding of almost 40 different barcode types and subtypes, and while you can enable all of these, it can negatively impact performance as well as introduce unwanted side effects: 
•  The more symbologies enabled, the slower the performance. This can lead to sluggish decoding and the degradation of the overall performance of the mobile device, leaving the user with an inaccurate impression of the SDK’s capabilitie.
•  False reads are possible. This is particularly possible when some of the weaker symbologies, like Code 25, are enabled without proper consideration and configuration of other, more advanced features like minimum code length and barcode location. These features help mitigate false reads with the weak symbologies, but at a cost of degraded performance (and again, are not intended to all be turned on and used at the same time). 
• Using an optimal camera resolution. By default, the cmbSDK uses HD images (typically 1280x720 ) for barcode decoding. This resolution is sufficient for all but the very smallest or dense of barcodes. As the application developer, you can use a higher resolution (full HD), but keep in mind that these images are significantly larger, so they will require more time to analyze and decode.  
• Using an appropriate decoder effort level. The SDK has a user-configurable effort-level that control show aggressively the SDK performs image analysis. Like most other settings, the SDK uses a default value (level 2) that is sufficient for almost all barcodes. Using a higher level can result in better decoding of poorer quality barcodes, but at the price of slower performance. 

For these reasons, when the cmbSDK is initialized for use with the built-in camera of the mobile device, no barcode symbologies are enabled by default: the application must explicitly enable the symbologies it needs. As most barcode scanning applications only truly need to scan a handful of symbologies, this behavior steers the developer to using the SDK in an efficient manner.

Enabling symbologies is a very simple process, which is explained later in this document. 

Perform the following steps to install the iOS cmbSDK:

1. Download the latest XCode for iOS Development.

2. Download the Cognex Mobile Barcode SDK for iOS. 

Perform the following steps to set up your application to use the iOS cmbSDK:

1. Open XCode and start a new project.

2. Add the following lib and frameworks to your project: 

* SystemConfiguration.framework * AVFoundation.framework
* CoreGraphics.framework
* CoreMedia.framework
* CoreVideo.framework
* MediaPlayer.framework * Security.framework
* AudioToolbox.framework * libDataManSDK.a

   3.  Go to your project's Info.plist file and add the Privacy - Camera Usage Description or NSCameraUsageDescription. This is required by iOS and is used to display a message explaining the usage of the user's device camera by your application. 

If you plan to use the cmbSDK to do mobile scanning with a smartphone or tablet (with no MX mobile terminal), then the SDK requires the installation of a license key.

Without a license key, the SDK will still operate, although scanned results will be obfuscated (the SDK will randomly replace characters in the scan result with an asterisk character).

Contact your Cognex Sales Representative for information on how to obtain a license key including trial licenses which can be used for 30 days to evaluate the SDK.

After obtaining your license key, add it as a String in your application's Info.plist file, under the key MX_MOBILE_LICENSE.

The cmbSDK has been designed to provide a high-level, abstract interface for supported scanning devices. This includes not only the MX series of mobile terminals, but also for applications that intend to use the mobile device camera as the imaging device. The intricacies of communicating with and managing these devices is encapsulated within the SDK itself: leaving the application to just connect to the device of choice, then using it.

The primary interface between your application and a supported barcode scanning device is the CMBReaderDevice class. This class represents the abstraction layer to the device itself, handling all communication as well as any necessary hardware management (e.g., for smartphone scanning).

Perform the following steps to use the cmbSDK: 

1. Initialize a Reader Device for the type of device you want to use (MX reader or camera reader).

2. Connect the Reader Device.

3. Configure the reader (if necessary).

4. Start scanning. 

Initialization, connection, and configuration generally need to be performed only once in your application, except for the following cases:

• An MX reader can become disconnected (times out from disuse,dead battery,etc.). A method has been provided to handle this case, and is discussed in a later section.
• Your application has been designed to allow the user to change devices.The cmbSDK is explicitly designed to support this: your application simply disconnects from the current device and establishes a new connection to a different device. The provided sample application has been written to explicitly demonstrate this capability. 

The cmbSDK provides two different reader class initializers: one for scanning using an MX mobile terminal (like the MX- 1000 or MX-1502) and another for scanning using the built-in camera of the mobile device (iPhones, iPads, etc). 

Initializing the Reader Device for use with an MX mobile terminal like the MX-1000 or MX-1502 is easy: simply create the reader device using the MX device method (it requires no parameters), and set the appropriate delegate (normally self): 

CMBReaderDevice *readerDevice = [CMBReaderDevice readerOfMXDevice];
[readerDevice setDelegate:self];

The availability of the MX mobile terminal can change when the device turns ON or OFF, or if the lightning cable gets connected or disconnected. You can handle those changes using the following CMBReaderDeviceDelegate method. 

- (void)availabilityDidChangeOfReader:(CMBReaderDevice *)reader;

Barcode scanning with the built-in camera of the mobile device can be more complex than with an MX mobile terminal. The cmbSDK supports several configurations to provide the maximum flexibility. This includes support of optional, external aimers/illumination, as well as the ability to customize the appearance of the live-stream preview.

To scan barcodes using the built-in camera of the mobile device, initialize the CMBReaderDevice object using the readerOfDeviceCameraWithCameraMode static method. The camera reader has several options when initialized. The following parameters are required: 

* CDMCameraMode
* CDMPreviewOption
* UIView

The CameraMode parameter is of the type CDMCameraMode (defined in CDMDataManSystem.h), and it accepts one of the following values: 

• kCDMCameraModeNoAimer: This initializes the reader to use a live-stream preview ( on the mobile device screen ) so the user can position the barcode within the camera’s field of view for detection and decoding. Use this mode when the mobile device does not have an aiming accessory.
• kCDMCameraModePassiveAimer: This initializes the reader to use a passive aimer , which is anaccessory that is attached to the mobile device or mobile device case that uses the built-in LED flash of the mobile device as a light source for projecting an aiming pattern. In this mode, no live-stream preview is presented on the device screen, since an aiming pattern will be projected.
• kCDMCameraModeFrontCamera: This initializes the reader to use the front facing camera of the mobile device, if available (not all mobile devices have a front camera). This is an unusual, but possible configuration. Most front-facing cameras do not have auto focus and illumination, and provide significantly lower resolution images. This option should be used with care. In this mode, illumination is not available. 

All of the above modes provide the following default settings for the reader:

• The rear camera is used.
• The zoom feature isa vailable and a button to control it is visible on the live-streamp review ( if displayed ).
• The simulated hardware trigger is disabled.
• When startScanning() is called, the decoding process is started. ( Seek CDMPreviewOptionPaused for more details.)

Based on the selected mode, the following additional options and behaviors are set: 

• kCDMCameraModeNoAimer ( NoAimer )
• The live-stream preview is displayed when the startScanning() method is called.
• Illumination is available and a button to control it is visible on the live-stream preview.
• If commands are sent to the reader for aimer control, they will be ignored.

• kCDMCameraModePassiveAimer( PassiveAimer )
• The live-stream preview will not be displayed when the startScanning() method is called.
• Illumination is not available and the live-stream preview will not have an illumination button.
• If commands are sent to the reader for illumination control, they will be ignored, since it is assumed in this mode that the built-in LED of the mobile device is being used for the aimer.

• kCDMCameraModeFrontCamera( FrontCamera )
• The live-stream preview is displayed when the startScanning() method is called.
• The front camera is used.
• Illumination is not available, and the live-stream preview will not have an illumination button. o If commands are sent to the reader for aimer or illumination control, they will be ignored. 

The previewOptions parameter (of type CDMPreviewOption, defined in CDMDataManSystem.h) is used to change the reader’s default values or override defaults derived from the selected CameraMode. Multiple options can be specified by OR-ing them when passing the parameter. The available options are the following: 

• kCDMPreviewOptionDefaults: Use this option to accept all defaults set by the CameraMode.
• kCDMPreviewOptionNoZoomBtn: This option hides the zoom button on the live-stream preview, preventing a user from adjusting the zoom of the mobile device camera.
• kCDMPreviewOptionNoIllumBtn: This hides the illumination button on the live-stream preview, preventing a user from toggling the illumination.
• kCDMPreviewOptionHwTrigger: This enables a simulated hardware trigger (the volume down button )for starting scanning on the mobile device. This button only starts scanning when pressed. It does not need to be held like a more traditional purpose-built scanner’s trigger. Pressing the button a second time does not stop the scanning process.
• kCDMPreviewOptionPaused: If using a live-stream preview, when this option is set, the preview will be displayed when the startScanning() method is called, but the reader will not start decoding (i.e. looking for barcodes) until the user presses the on-screen scanning button to actually start the scanning process.
• kCDMPreviewOptionAlwaysShow: This forces alive-stream preview to be displayed, even if an aiming mode has been selected (e.g. CameraMode == kCDMCameraModePassiveAimer ) 

The last parameter of type UIView is optional and is used as a container for the camera preview. If the parameter is left nil, a full screen preview will be used.

Examples:

Create a reader with no aimer and a full screen live-stream preview: 

CMBReaderDevice *readerDevice = [CMBReaderDevice readerOfDeviceCameraWithCameraMode:kCDMCameraModeNoAimer previewOptions:kCDMPreviewOptionDefaults previewView:nil];
readerDevice.delegate = self;

Create a reader with no aimer, no zoom button, and using a simulated trigger: 

CMBReaderDevice *readerDevice = [CMBReaderDevice readerOfDeviceCameraWithCameraMode:kCDMCameraModeNoAimer previewOptions:(kCDMPreviewOptionNoZoomBtn | kCDMPreviewOptionHwTrigger) previewView:nil];
readerDevice.delegate = self;

After initializing the Reader Device and setting a delegate to handle responses from the reader, you are ready to connect using connectWithCompletion: 

// Make sure the device is turned ON and ready
if (readerDevice.availability == CMBReaderAvailibilityAvailable) {
// create the connection between the readerDevice object and device [readerDevice connectWithCompletion:^(NSError *error) {
if (readerDevice.connectionState == CMBConnectionStateConnected) { // Connected successfully
} else {
if (error) {
// handle connection error }
} }];
}

If everything was done correctly, connectionStateDidChangeOfReader in the delegate will be called, where you can check the connection status in your Reader Device's connectionState parameter. It should be CMBConnectionStateConnected, which means that you have successfully made the connection to the Reader Device, and can begin using the Cognex Mobile Barcode SDK. 

After connecting to the scanning device, you may want (or need) to change some of its settings. The cmbSDK provides a set of high-level, device independent APIs for setting and retrieving the current configuration of the device.

Like in the case of initializing the Reader Device, there are some differences between using an MX reader and the camera reader for scanning. These differences are detailed in the following sections. 

The MX family of mobile terminals provides sophisticated device configuration and management, including saved configurations on the device itself. In general, these devices come from Cognex preconfigured for an exceptional out-of- the-box experience with most symbologies and features ready to use.

When custom reconfiguration is desired, this is typically done using either the DataMan Setup Tool, or the DataMan Quick Setup as these tools can be used to distribute saved configurations easily to multiple devices, thereby greatly simplifying configuration management.

However, it is still possible (and sometimes desirable) for the mobile application itself to configure the MX device: 

• You can have multiple scanning applications, each of which requiresa different set of device settings.
• You may simply want to guarantee that the certain options are in a “known” state and not rely on the fact that the device has been preconfigured correctly. 

Much like an MX mobile terminal, the cmbSDK employs a default set of options for barcode reading with the built-in camera of the mobile device, providing a good out-of-box experience. However, there are two important differences to keep in mind:

• The cmbSDK does not implement saved configurations for the camera reader. This means that every time an application that uses the camera reader starts, it starts with its defaults.
• The cmbSDK does not enable any symbologies by default: you as the application programmer must enable all barcode symbologies your application needs to scan. By requiring the application program to explicitly enable only the symbologies it needs, the most optimal scanning performance can be achieved. This concept was more thoroughly discussed in the Overview section. 

Individual symbologies can be enabled using the following method of the Reader Device object: 

-(void) setSymbology:(CMBSymbology)symbology 
enabled:(bool)enabled
completion:(void (^)(NSError *error))completionBlock;

All symbologies used for the symbology parameter in this method can be found in CMBReaderDevice.h.

Examples 

/* Enable QR scanning */
[readerDevice setSymbology:CMBSymbologyQR
enabled:YES completion:^(NSError *error) { if (!error) {
// Success }else{
/* Unsuccessful
probably the symbology is unsupported by
the current device, or there is a problem with the connection between
the readerDevice and MX device
*/
} }];

The same method can also be used to turn symbologies off: 

/* Disable Code 25 scanning */ [readerDevice setSymbology:CMBSymbologyC25
enabled:NO completion:^(NSError *error) { if (!error) {
// Success }else{
// Unsuccessful }
}];

If your reader device is equipped with illumination lights (e.g. LEDs), you can control whether they are ON or OFF when scanning starts using the following method of your Reader Device object: 

-(void) setLightsON:(bool)on
completion:(void (^)(NSError *error))completionBlock;

Keep in mind that not all devices and device modes supported by the cmbSDK allow for illumination control. For example, if using the built-in camera in passive aimer mode, illumination is not available since the LED is being used for aiming. 

The cmbSDK includes a method for resetting the device to its default settings. In the case of an MX mobile terminal, this is the configuration saved by default (not the factory defaults), while in the case of the built-in camera, these are the defaults identified in Appendix B, where no symbologies will be enabled. This method is the following: 

- (void) resetConfigWithCompletion:(void (^)(NSError *error))completionBlock;

Every Cognex scanning device implements DataMan Control Commands (DMCC), a method for configuring and controlling the device. Virtually every feature of the device can be controlled using this text based language. The API provides a method for sending DMCC commands to the device. Commands exist both for setting and querying configuration properties.

Appendix A includes the complete DMCC reference for use with the camera reader. DMCC commands for other

supported devices (e.g. the MX-1000) are included with the documentation of that particular device.
Appendix B provides the default values for the camera reader’s configuration settings as related to the corresponding

DMCC setting.
The following examples show different DMCC commands being sent to the device for more advanced configuration. Change the scan direction to omnidirectional: 

[self.dataManSystem sendCommand:@"DECODER.1D-SYMBOLORIENTATION 0" withCallback:^(CDMResponse *response){
if (response.status == DMCC_STATUS_NO_ERROR) {...}
else
{...} }];

Change the scanning timeout of the live-stream preview to 10 seconds: 

[self.dataManSystem sendCommand:@"DECODER.MAX-SCAN-TIMEOUT 10" withCallback:^(CDMResponse *response){
if (response.status == DMCC_STATUS_NO_ERROR) {...}
else
{...} }];

Get the type of the connected device: 

[self.dataManSystem sendCommand:@"GET DEVICE.TYPE" withCallback:^(CDMResponse *response){
if (response.status == DMCC_STATUS_NO_ERROR) {NSString *deviceType = response.payload; }
else
{...} }];

With a properly configured reader, you are now ready to scan barcodes. This is simply accomplished by calling the startScanning() method from your Reader Device object. What happens next is based on the type of Reader Device and how it has been configured, but in general: 

• If using an MXreader, the user can now press a trigger button on the device to turn the scanner on and read a barcode.
• If using the camera reader, the cmbSDK starts the camera, displays the configured live-stream preview,and begins analyzing the frames from the video stream, looking for a configured barcode symbology. 

Scanning stops under one of the following conditions: 

• The reader found and decodeda barcode.
• The user released the trigger or pressed the stop button on the live-stream preview screen.
• The camera reader timed out with out finding a barcode.
• The application program itself calls the stopScanning() method. 

When a barcode is decoded successfully (the first case), you will receive a CMBReadResults array in your Reader Device's delegate using the following CMBReaderDeviceDelegate method: 

- (void)didReceiveReadResultFromReader:(CMBReaderDevice *)reader results:(CMBReadResults *)readResults;

 The following is an example to simply display a ReadResult after scanning a barcode: 

- (void)didReceiveReadResultFromReader:(CMBReaderDevice *)reader results:(CMBReadResults *)readResults
{
for (CMBReadResult *readResult in readResults.readResults) {
if (readResult.image) {
_ivPreview.image = readResult.image; }
if (readResult.readString) {
_lblCode.text = readResult.readString; }
} 
}

In the example above, _ivPreview is an UIImageView used to display an image of the barcode that was scanned, and _ lblCode is a UILabel used to show the result from the barcode. You can also use the BOOL from readResult.goodRead to check whether the scan was successful or not. 

When a barcode is successfully read, a CMBReadResult object is created and returned by the didReceiveReadResultFromReader:results: method. In case of having multiple barcodes successfully read on a single image/frame, multiple CMBReadResult objects are returned. This is why the CMBReadResults class has an array of CMBReadResult objects containing all results.

The CMBReadResult class has properties describing the result of a barcode read:

• goodRead (BOOL): tells whether the read was successful or not
• readString (NSString): the decoded barcode as a string
• image (UIImage): the image/frame that the decoder has processed
• imageGraphics (NSData): the boundary path of the barcodeas SVG data
• XML (NSData): the raw XML that the decoder returned
• symbology (CMBSymbology): the symbology type of the barcode.This enum is defined in CMBReaderDevice.h.

When a scanning ends with no successful read, a CMBReadResult is returned with the goodRead property set to false. This usually happens when scanning is canceled or timed out.

To enable the image and imageGraphics properties being filled in the CMBReadResult object, you have to set the corresponding imageResultEnabled and/or SVGResultEnabled properties of the CMBReaderDevice object.

To see an example on how the image and SVG graphics are used and displayed in parallel, refer to the sample applications provided in the SDK package.

To access the raw bytes from the scanned barcode, you can use the XML property. The bytes are stored as a Base64 String under the "full_string" tag. Here's an example how you can use a XML parser to extract the raw bytes from the XML property.

NSXMLParser *xmlParser = [NSXMLParser.alloc initWithData:result.XML];
xmlParser.delegate = self;
if ([xmlParser parse]) {
    // the raw bytes will be stored in this variable
    NSData *bytes = [NSData.alloc initWithBase64EncodedString:base64String options:0];
}

Parsing the XML and extracting the Base64 String is done using the NSXMLParserDelegate delegate. Add this delegate and the following methods from it in your ViewController:

#pragma NSXMLParserDelegate
NSString *currentElement;
NSString *base64String;
- (void)parser:(NSXMLParser *)parser didStartElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName attributes:(NSDictionary<NSString *,NSString *> *)attributeDict {
    currentElement = elementName;
}

- (void)parser:(NSXMLParser *)parser foundCharacters:(NSString *)string {
    if ([currentElement isEqualToString:@"full_string"]) {
        base64String = string;
    }
}

By default, the image and SVG results are disabled, which means that when scanning, the CMBReadResults will not contain any data in the corresponding properties.

To enable image results, set the imageResultEnabled property from the CMBReaderDevice class by using the following method: 

[readerDevice setImageResultEnabled:YES];

To enable SVG results, set the imageResultEnabled property from the CMBReaderDevice class by using the following method: 

[readerDevice setSVGResultEnabled:YES];

There may be cases when a device disconnects due to low battery condition or manual cable disconnection. These cases can be detected by the connectionStateDidChangeOfReader callback of the CMBReaderDeviceDelegate.

After you return to your application from inactive state, the reader device remains initialized, but not connected. This means there is no need for reinitializing the SDK, but you will need to re-connect.

Some iOS versions will send a "Availability" notification when resuming the application that the External Accessory is available. You can use this in the CMBReaderDeviceDelegate's method: (void)availabilityDidChangeOfReader:(CMBReaderDevice *)reader. In it, when the reader becomes available, you can connect to it.

For example:

- (void)availabilityDidChangeOfReader:(CMBReaderDevice *)reader
{
    if (readerDevice.availability == CMBReaderAvailibilityAvailable) {
        [readerDevice connectWithCompletion:^(NSError *error) {
            if (error) {
               // handle connection error
            }
        }];
    }
}

Some iOS versions do not report availability change on resume, so you will have to handle this manually. For this, you will have to add an observer for "UIApplicationDidBecomeActiveNotification" and do some checks before connecting, so you don't connect while the reader is already in "connecting" or "connected" state. For example:

- (void)viewDidLoad {
     // add observer for app resume
     [[NSNotificationCenter defaultCenter] addObserver:self
                                                 selector:@selector(appBecameActive)
                                                     name:UIApplicationDidBecomeActiveNotification object:nil];
}
// handle app resume
-(void) appBecameActive {
    if (readerDevice != nil
        && readerDevice.availability == CMBReaderAvailibilityAvailable
        && readerDevice.connectionState != CMBConnectionStateConnecting && readerDevice.connectionState != CMBConnectionStateConnected)
    {
        [readerDevice connectWithCompletion:^(NSError *error) {
            if (error) {
                // handle connection error
            }
        }];
    }
}

The following table lists the various DMCC commands supported by the cmbSDK when using the built-in camera for barcode scanning. 

Appendix A - DMCC for the Camera Reader 

Appendix A - DMCC for the Camera Reader 

The following table lists the defaults the SDK uses on startup for the camera reader. 

Appendix B - Camera Reader Defaults 

Observe these precautions when installing the Cognex product, to reduce the risk of injury or equipment damage:

• To reduce the risk of damage or malfunction due to over-voltage, line noise, electrostatic discharge (ESD), power surges, or other irregularities in the power supply, route all cables and wires away from high-voltage power sources.
• Changes or modifications not expressly approved by the party responsible for regulatory compliance could void the user’s authority to operate the equipment.
• Cable shielding can be degraded or cables can be damaged or wear out more quickly if a service loop or bend radius is tighter than 10X the cable diameter. The bend radius must begin at least six inches from the connector.
• This device should be used in accordance with the instructions in this manual.
• All specifications are for reference purpose only and may be changed without notice.