I’m working on an app where users need to create and modify data while offline. When they get back online, this data should automatically sync with the server. This works similar to how email apps handle drafts - you can compose messages without internet and they get sent once connectivity returns.
Right now I have one SyncAccount with a SyncAdapter that runs once per day. I want to add another sync process that handles the offline-to-online data transfer. My question is about using ContentResolver.addPeriodicSync for this second sync operation.
Do I need to create a separate authority for the new sync? Would this mean I have to use different database tables? Or is there a way to run two independent sync processes that both work with the same database?
Another approach worth considering is implementing a priority-based sync mechanism within your existing SyncAdapter. I’ve found this works well when dealing with different types of data that need varying sync frequencies. You can maintain separate queues or flags in your database to track what needs syncing - one for your regular daily operations and another for pending offline data. The trick is to check connectivity status and process the offline queue first when network becomes available, then handle your regular sync operations. This eliminates the complexity of managing multiple sync authorities while ensuring your offline data gets priority treatment. You might also want to implement exponential backoff for failed offline sync attempts to avoid draining battery on poor connections.
You don’t necessarily need separate authorities for multiple sync operations. I’ve handled similar scenarios by using the same authority but differentiating sync types through extras in the sync bundle. When calling addPeriodicSync, you can pass different extras to distinguish between your daily sync and your offline-data sync. Your SyncAdapter’s onPerformSync method receives these extras, allowing you to branch the logic accordingly. This approach keeps everything using the same database and content provider while giving you distinct sync behaviors. The key is structuring your sync adapter to handle multiple sync types based on the bundle extras rather than creating entirely separate sync infrastructure.
honestly i’d just use the same authority but trigger manual syncs for the offline stuff. when your app detects network is back, call requestSync() immediately instead of waiting for the periodic one. way simpler than managing two seperate sync processes imo