Documentation Issues and Updates for Sybase Mobile SDK

• Release Bulletin
• Supported Hardware and Software
• Developer Guide: iOS Object API Applications
• Tutorial: iOS Object API Application Development

[[SDMLogger instance] displayLogsWithLevel:DebugLoggingLevel forQueryOperation:GreaterEqual];

• Immediately update the cache with Apply merge of operation input/output – this can be used for CUD operations where the MBO attributes map one-to-one with corresponding values in the EIS (no EIS generated IDs or side-effects on MBO attributes). For example:
  1. The MBO Developer edits the Contact MBO officePhoneNumber attribute, and the Update operation requires Unwired Server to send fname, lname, city, state, and so on attributes that have not been changed on the client.
  2. Unwired Server recognizes that only officePhoneNumber has changed, and updates the cache correspondingly if the EIS operation executes without error.
• (Legacy) Apply results to the cache – used primarily to support Create operations where the EIS generates the business ID for the new entity. Sybase Unwired Platform requires the EIS developer to provide a create method that returns all the attributes of the MBO that the Unwired Server normally sees from the read/load operation. This allows Unwired Server to insert the real business ID into the MBO instead of a temporary one manufactured on the client (generateKey) as a placeholder. When Unwired Server synchronizes the newly created MBO back to the client, it contains the real EIS defined ID field, and the client can update its remote copy by matching the surrogate key.
• Immediately update the cache with Apply output of ENTITY READ operation – applies to any operation type, and also applies to graphs of related MBOs and shared read operations. For example:
  1. The MBO Developer wants to change the ShipDate attribute on the SalesOrder MBO for a customer in a SalesOrder -> LineItems object graph, then submit the Update operation.
  2. The EIS recognizes that due to product availability, some of the line items cannot be delivered on that date, so only some of the LineItem MBOs are modified as a result.
  3. Unwired Server recognizes that the Update operation succeeds (but this is the "normal" Update operation that has not been modified to actually return MBO values, much less the whole tree of SalesOrder->LineItem).
  4. Unwired Server recognizes an ENTITY READ operation associated with the Update operation takes the SalesOrder.ID as input and executes the entity read operation that returns the updated SalesOrder and LineItems information from the EIS.
  5. Using the shared read feature, Unwired Server updates the cache for both parent and child MBO values in the graph.
• Invalidate the cache – the cache is unaffected in terms of what is in the cache database (CDB), but Unwired Server internally marks the cache partition to which the affected MBO belongs as invalid. The next time a client tries to synchronize values of this partition Unwired Server refreshes the cache by performing the load operation. If the cache is very finely partitioned, this can be the equivalent to the ENTITY READ approach: apply the operation and then perform an EIS read to update the cache. If the load operation takes a specific ID and returns a single MBO record, then these are equivalent. If the MBO partition is larger scale (Customer by State for example), then a lot of MBOs are invalidated and the cache refresh (all customers in State=CA) is a more expensive operation.
• None – the cache is not updated after an operation. If there is a one hour refresh policy, changes are not reflected in the cache (or the device) until that hour expires and Unwired Server refreshes the cache. If the policy is DCN, the cache is not updated until the EIS sends a DCN message reflecting the changes.

• Step 3 – You do not need to explicitly save synchronization parameter changes, as this is done when you add them, as described in step 2 of the topic.
• This note –
  Note: If you do not save the synchronization parameters, no data is downloaded to the device even if there are default values set for those synchronization parameters. Call the save method for all synchronization parameters and for all MBOs when the application is first started. Do this after application registration and the first synchronization.

• Android and BlackBerry –

  SUP101DB.getConnectionProfile().setProperty("allowConcurrentWrite", "true"); 

• iOS –

  [ [SUP101DB getConnectionProfile]  setBoolean:@"allowConcurrentWrite"
        :YES]; 

• WindowsMobile –

  SUP101DB.GetConnectionProfile().SetProperty("allowConcurrentWrite", "true"); 

• 1 = Tracing is disabled
• 3 = SQL Trace without payload
• 5 = SQL Trace with payload (values displayed)

• Via Sybase Control Center through the Applications folders:
  1. Click on the Applications folder in the Sybase 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 for your platform:
  • iOS – 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];
    

  • Android and BlackBerry – in the ConnectionProfile class, there are two APIs that can be used:

    - enableTrace(boolean enable)
    - enableTrace(boolean enable, boolean with Payload)

    The application in the initialization code can invoke these APIs to enable/disable tracing:

    ConnectionProfile *cp = SUP101DB.getConnectionProfile();
    
    // To enable trace of client database operations (SQL statements, etc.)
    cp enableTrace(true);
    
    // To enable trace of client database operations with values also displayed
    cp enableTrace(true, true);
    
    // To disable trace of client database operations
    cp enableTrace(false);
    

  • Windows and Windows Mobile – in the ConnectionProfile class, there are two APIs that can be used:

    - EnableTrace(bool enable)
    - EnableTrace(bool enable, bool withPayload)

    The application in the initialization code can invoke these APIs to enable/disable tracing:

    ConnectionProfile cp = SampleDB.GetConnectionProfile();
    
    // To enable trace of client database operations (SQL statements, etc.)
    cp.EnableTrace(true);
    
    // To enable trace of client database operations with values also displayed
    cp.EnableTrace(true, true);
    
    // To disable trace of client database operations
    cp.EnableTrace(false);