One way to reduce memory, storage, and communication bandwidth requirements is by choosing an appropriate format for the data and compressing the data. OData and other protocols support JSON serialization, or you can implement your own serialization for communicating and storing data. JSON serialization reduces the size of the data sent over the wire when compared to XML formats, which can reduce transmission costs. Compressing data sent between the server and the device is also a useful way to minimize data transfer costs when using slow and/or expensive network connections such as GPRS or 3G (when compared to cheaper and faster Wi-Fi connection).
However, serialization—particularly for the compressed JSON format and XML format—consumes processor resources. You must balance the communication cost and the processor load factors when you choose a protocol or data format.
Note: The Microsoft OData Client Library (beta) for Windows Phone 7 does not support JSON serialization. You must use the Atom Pub format with this proxy component.
In addition to simply retrieving and uploading data, mobile devices often have a requirement to perform synchronization between data stored on the device and data stored on the server.
Synchronization must take into account occasional connectivity with the network, transmission errors, conflicts between the two data stores due to concurrent updates, and the correct application of keys and relationships between relational data rows on the database server. Synchronization is also often required between types of data that are not relational in nature. This may include log files, media files, or other types of information.
However, before you decide to implement synchronization, consider whether the additional effort it requires can be avoided by applying a simpler pattern. In particular, bi-directional synchronization can be difficult to implement. You may decide to use the Ledger design pattern where, when a conflict occurs, the server or the client version overrides conflict, the content is duplicated, or the user specifies values to resolve the conflict. Alternatively, you may decide
to implement synchronization tokens to simplify your design. For information about patterns for moving and synchronizing data, see “Data Patterns” on MSDN (http://msdn.microsoft.com/en-us/library/ff648502.aspx).
Alternatively, consider using a framework that implements synchronization if a suitable one is available. An example is the Microsoft Sync Framework, which is described in the following section.