CLIENT SERVER SYNCHRONIZATION

AGENDA

Basics of Client Server Synchronization

Synchronization for Trip Planner

Architecture Overview

STRETCH GOAL!

Remember! This step is a stretch goal of the Trip

Planner project. We don’t expect everyone to finish completely.

BASICS OF CLIENT SERVER SYNCHRONIZATION

BASICS OF CLIENT SERVER SYNCHRONIZATION

Main Goal: Client and server should (almost always) have the same data

Changes from the client need to be sent to the server

Client needs to check server for updated information

frequently

TRACKING UNSYNCED CLIENT CHANGES

Changes to local data need to be tracked - need to remember which data has been sent to server successfully and which not

Need to track new, updated and deleted data

DESIGNING THE SYNCHRONIZATION FOR TRIP

PLANNER

TRACKING UNSYNCED CLIENT CHANGES

Potential solution:

• using a lastUpdate timestamp to check which objects

changed since last server sync

• using a serverIdentifier to store server ID and to

check which objects are new locally

• keep a list of deleted objects that need to be synced

SYNCING CHANGES TO THE SERVER

Find all:

• Objects that updated since last synchronization

• Objects that have been created since last

synchronization

• Deletions that haven’t been synchronized yet

→ Generate network request(s) to sync these changes

SYNCING CHANGES FROM THE SERVER

Download trips from the server:

• find trips that exist locally, with server identifier but don’t exist on server → delete them

• find trips that exist locally and are different in

server response → compare which entry is newer

and potentially update local trip

ADVANCED APPROACH

Instead of downloading all trips from server, only download the ones the client doesn’t know about yet

(this is beyond the scope of the project)

ARCHITECTURE OVERVIEW

ARCHITECTURE OVERVIEW

Synchronizer

API Client

Authentication

Core DataClient

Keychain

RemainingApp

ADDITIONAL RESOURCES

ADDITIONAL RESOURCES

Objc.io: Data Synchronization

Objc.io: A Sync Case Study