当前位置: 首页 > 工具软件 > SyncML > 使用案例 >

android syncml,android - SyncML (sync or update?) - Stack Overflow

鲁展
2023-12-01

I'm faced with another dilemma, with regards to synchronizing (or updating?) data across to the server, from a mobile device (using Android).

I've looked into SyncML as the standard for doing this, but my big concern is that we plan on syncing a large amount of data across (not just 1 record), and probably only doing it once, twice or at most 3 times a day, or maybe not even once a day - all dependant on certain circumstances.

The other thing - the device or server will still be able to function properly without having to sync across. The sync would just be an update, essentially.

From reading up on the SyncML specs, it applies more to syncing across small pieces of data, and at a very fast interval (ie. every 5-15 minutes, but I guess can be regulated by the user). At any rate, the synchronization process is more involved, and important for both the device and the server (more so the device, I guess).

Here's a quote from the documentation that got me thinking:

2.2.3 Data synchronization SyncML is oriented towards synchronization of

small independent records, as the

modied records are transmitted

entirely. This is adequate for address

entries, short messages and similar

data. On the primary target of SyncML,

mobile devices, most data is of this

type. The devices must be able to keep

track which of their records have been

changed. Each record is identied by a

unique ID, so con icts can be detected

quite simple. As the record ID's may

not be arbitrarily chosen but

automatically created, mapping between

server and client ID's is dened in

the protocol. Mapping is always

managed by the server. When the client

receives a new item from the server,

he can send a map update command to

tell the server what ID he assigned to

the item. Now the server uses the

client ID in all his messages.

So, I guess my question is whether we should continue to look into SyncML for this, or built an in-house solution - maybe something more tailored to delivering large pieces of data across, which can define it as well?

 类似资料: