Debugging iOS Device Development

Device client and Unwired Server troubleshooting tools for diagnosing Apple iOS development problems.

Client-Side Debugging

Problems on the device client side that may cause client application problems:

Unwired Server connection failed.
Data does not appear on the client device.
Physical device problems, such as low battery or low memory.

To find out more information on the device client side:

If you have implemented debugging in your generated or custom code (which Sybase recommends), turn on debugging, and review the debugging information. See Developer Guide: iOS Object API Applications about using the MBOLogger class to add log levels to messages reported to the console.
Check the log record on the device. Use the individual entity class getLogRecords method, or assemble a query using the SUPQuery class and call the database class getLogRecords method.

This is a sample log format (depending on your query):
```
<header> [level]
                code
                component
                entityKey
                level
                message
                operation
                requestId
                timestamp
```
This log format generates output similar to:
```
2010-06-22 10:54:28.927 SAPSimpleApps2[91202:207] [INFO]
    [SAPTest.m:295] entity has a log record:
                code = 200,
                component = SalesOrder,
                entityKey = 500151,
                level = 3,
                message = Successful,
                operation = changeFromData,
                requestId = 33416006,
                timestamp = 2010-06-22 03:54:22 -0700
```
- code – log record code numbers sent by Unwired Server, based on HTTP return codes.
  - Replication synchronization codes:
    200 – success.
    
    500 – failure.
  - Message synchronization codes:
    200 – success.
    
    401 – the client request included invalid credentials, or authentication failed for some other reason.
    
    403 – the client request included valid credentials, but the user does not have permission to access the requested resource (package, mobile business object—MBO, or operation).
    
    404 – the client tried to access a nonexistent package or MBO.
    
    405 – there is no valid license to check out for the client.
    
    409 – back-end EIS is deadlocked.
    
    412 – back-end EIS threw a constraint exception.
    
    500 – an unexpected (unspecified) server failure.
    
    503 – back-end EIS is not responding or the connection is terminated.
- eisCode – a value specific to the EIS backend, if any. Typically defaults to blank or 0 (zero); can be set via result checker.
- entityKey – if this log record refers to a particular row in an MBO table, this field contains a string representation of the primary key for the row.
- component – if this log record refers to a particular row in an MBO table, this field contains the name of the MBO.
- level – the log level currently set. Values include: 1 = Trace, 2 = Debug, 3 = Info, 4 = Warn, 5 = Error, and 6 = Fatal.
- message – the reason for the log record, for example, an error from the server when attempting to process a client replay request for a create, update, and delete operation.
- messageID – unique log record ID.
- operation – for log records written by Unwired Server, the operation (such as create, update, and delete) that caused this log record to be written.
- requestId – for log records written by Unwired Server, the ID of the replay request that caused this log record to be written.
- timestamp – the date and time the log record was created.
If you have implemented onConnectionStatusChange for message synchronization in CallbackHandler, the connection status between Unwired Server and the device is reported on the device. See the Developer Guide: iOS Object API Applications for CallbackHandler information. The status reported on the device includes:
- 1 – device is connected.
- 2 – device is not connected.
- 3 – device is not connected because of flight mode.
- 4 – device is not connected because no network coverage.
- 5 – device is not connected and waiting to retry a connection.
- 6 – device is not connected because roaming was set to false and device is roaming.
- 7 – device is not connected because of low space.
For other issues, you can use tracing on the device side to trace Client Object API activity. Sybase Unwired Platform supports three levels of tracing:
- 1 = Tracing is disabled
- 3 = SQL Trace without payload
- 5 = SQL Trace with payload (values displayed)
There are two ways to enable tracing on the client side:
- Via Sybase Control Center through the Applications folders:
  1. Click on the Applications folder in the Unwired Platform Cluster frame.
  2. In the Applications tab, select the application you wish to enable tracing for.
  3. Select the Application Connections tab and select the user you wish to enable tracing for.
  4. Click on the Properties button to open the Application Connection Properties window.
  5. Click on Device Advanced to display advanced connection properties.
  6. Change the value of the Device Level Trace property to the appropriate level.
  7. Click OK to save your changes.
- Via code by calling the appropriate API. In the SUPConnectionProfile class, there are two APIs that can be used:
- ```
- (void) enableTrace:(BOOL)enable
- (void) enableTrace:(BOOL)enable withPayload:(BOOL)withPayload
```
  The application in the initialization code can invoke these APIs to enable/disable tracing:
```
SUPConnectionProfile *cp = [SUP101SUP101DB getConnectionProfile];

// To enable trace of client database operations (SQL statements, etc.)
[cp enableTrace:YES];

// To enable trace of client database operations with values also displayed
[cp enableTrace:YES withPayload:YES];

// To disable trace of client database operations
[cp enableTrace:NO];

// To enable trace of message headers sent to the server and received from the server
// (this replaces the MBODebugLogger and MBODebugSettings used in earlier versions of SUP)
[cp.syncProfile enableTrace:YES];

// To enable trace of both message headers and content, including credentials
[cp.syncProfile enableTrace:YES withPayload:YES];

// To disable messaging trace
[cp.syncProfile enableTrace:NO];
```
Note: Once the trace level is set, the application must be restarted for the tracing to take effect. SQL tracing (level 3 and 5) can cause significant performance degradation, so it should be used with caution. SQL tracing should only be enabled via Sybase Control Center long enough for the device application to capture relevant tracing. When finished, you should shut down the application and relaunch it to run with tracing disabled.

Server-Side Debugging

Problems on the Unwired Server side that may cause device client problems:

The domain or package does not exist.
Authentication failed for the synchronizing user.
The operation role check failed for the synchronizing user.
Back-end authentication failed.
An operation failed on the remote, replication database back end, for example, a table or foreign key does not exist.
An operation failed on the Web Service, REST, or SAP back end. You can find detailed messages in the log record.

To find out more information on the Unwired Server side:

Check the Unwired Server log files.
For message-based synchronization mode, check the SUPBridge and JMSBridge logs.