Making Changes to Application Initialization

Make changes to the application to allow it to initialize as required in 2.1 ESD #3.

Set the login credentials for login and database synchronization.

SUPConnectionProfile *sp = [SUPSampleSUPSampleDB getSynchronizationProfile];  
[sp setUser:@"supAdmin"];
[sp setPassword:@"supPwd"];

After you complete the registration, the server exchanges settings from the application connection template with the device. In most circumstances, you do not need to set additional properties for the application in the synchronization profile. If you need to override some of the properties from the template you can do so through the synchronization profile.
```
[sp setServerName:@"relayservername.com"];
[sp setNetworkProtocol:@"networkProtocol"];
[sp setPortNumber:portNumber];
```
Login and subscribe to the server using the credentials set up in step 1. In an MBS application, subscribe causes data to be pushed to the client from the server. For RBS, it allows the server to clean up client-specific information proactively (for example, synchronization parameters when they are no longer required). The server is typically configured to remove inactive artifacts after a certain period of time. With an RBS subscribe, no data is pushed to the device, it is only used for administrative purposes.
```
[SUP101SUP101DB onlineLogin]; 
[SUP101SUP101DB subscribe]; 
```
Determine the mode of synchronization to exchange data with the server. In RBS, you can perform synchronization synchronously or asynchronously. Synchronous means that the calling thread is blocked until the synchronization is complete whereas asynchronous synchronization leverages a background thread. Synchronization consists of upload (sending up the operation replay) and download (pulling down the new/changed data) phases. If you invoke the asynchronous API to perform synchronization, the appropriate callbacks are invoked to inform you of its completion.
```
[SUP101SUP101DB synchronize];  // synchronous API  
[SUPSampleSUPSampleDB beginSynchronize];  // asynchronous API 
```
Determine the mode of operation replay. As with synchronization, operation replay can be processed by the server in a synchronous or asynchronous manner.Synchronous means that the synchronization session that uploads the operation replay waits for its completion before initiating the download phase to pull down data, including the result and status of the operation replay. Asynchronous replay means the synchronization session immediately goes to the download phase after the operation replay is successfully queued.

For an MBS application migrating to RBS, asynchronous replay is closer in behavior. You can implement this behavior in the synchronization API that has an uploadOnly parameter. By setting this parameter to true, the synchronization session skips the download phase, and only the operation replay is sent to the server. However, that is not to say that you should always use asynchronous replay. You should make the decision based on the business use case instead of the behavior of the previous implementation.

You only need to set the asynchronous replay flag once.
```
[sp setAsyncReplay:NO];  // Synchronous replay
[SUP101SUP101DB synchronize];  // Synchronous synchronization
```
When the synchronize method returns, the operation replay has completed and the data/result is on the client side database. You can also use the asynchronous synchronization API:
```
[sp setAsyncReplay:NO];  // Synchronous replay
[SUP101SUP101DB beginSynchronize];  // Asynchronous synchronizaiton
```
The onSynchronize callback with a SUPSynchronizationStatus_FINISHING status is fired when the synchronization has completed. At this point, the operation replay has completed and the data/result is on the client side database. To leverage asynchronous replay, use the API that supports the uploadOnly parameter.
```
[sp setAysncReplay:YES];  // Asynchronous replay
[SUP101SUP101DB beginSynchronize:syncGroups withContext:userContext withUploadOnly:YES];
```
With the AsyncReplay flag turned on, the client object API calls the onSynchronize callback method with an SUPSynchronizationStatus_ASYNC_REPLAY_UPLOADED status after the upload phase, followed by an SUPSynchronizationStatus_FINISHING status. No data is pulled down to the device database as there is no download phase.
Note: Control returns immediately, without the replay results synchronized to the client. The beginSynchronize method is a nonblocking call. The following callback from the SUPDefaultCallbackHandler is invoked as the synchronization session progresses.
```
(SUPSynchronizationActionType)onSynchronize:(SUPObjectList*)syncGroupList withContext:(SUPSynchronizationContext *)context
```
Note: In later versions of the Mobile SDK, the uploadOnly parameter is available with the synchronous API.

It is not recommended to initiate synchronization without the uploadOnly parameter set to YES due to a race condition. You cannot predict if the download phase pulls down data/results pertaining to the operation replay. If there are multiple operation replays being uploaded, some may complete and get downloaded. When the batch of uploaded operation replays is completed, the server sends a notification triggering the onSynchronize callback with SUPSynchronizationStatus_ASYNC_REPLAY_COMPLETED. A synchronization is automatically initiated to pull down the data/result. You can allow this synchronization to continue or abort it by returning CANCEL to the onSynchronize callback associated with this synchronization. This onSynchronize callback has SUPSynchronizationStatus_STARTING.

In some use cases, you may perform a full (upload and download) synchronization.
Handle the callbacks associated with the completed operation replay if appropriate. Typically, you use these callbacks in your application to signal to the UI layer that the data/result are now available or pending status is to be turned off.
- - (void)onReplayFailure:(id)entityObject
- - (void)onReplaySuccess:(id)entityObject