After the initial groundwork on the userjs SyncAdapter, it should be straightforward to duplicate the sync functionality to apply to collections Reading lists, as retrieved using the Gather API.
Description
Details
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | Dbrant | T120114 [Mega-epic] Implement Reading lists (nee: collections) on Android. | |||
Invalid | None | T120107 Synchronize user saved pages across devices. | |||
Resolved | Dbrant | T120108 Implement basic Collections, visible only to the current user. | |||
Duplicate | None | T127702 Implement SyncAdapter for Reading lists (nee: Collections) | |||
Resolved | • bearND | T126750 Create classes and tests for interfacing with Gather API. | |||
Resolved | Dbrant | T162619 Create onboarding and promo UI for reading list sync | |||
Resolved | • Charlotte | T165049 Update FAQs with new reading list sync capability | |||
Resolved | Dbrant | T166393 Create app-wide onboarding screens for new users informing them of the reading list sync feature | |||
Resolved | Dbrant | T166394 Create alerts and reminders when reading list sync is turned off for a user |
Event Timeline
Change 346804 had a related patch set uploaded (by Dbrant):
[apps/android/wikipedia@master] [PoC] Synchronize reading lists to user's account.
Change 346804 abandoned by Dbrant:
[PoC] Synchronize reading lists to user's account.
Change 347604 had a related patch set uploaded (by Dbrant):
[apps/android/wikipedia@master] Synchronize reading lists to user's account.
I'm about to dig into the code for the current proposed implementation but I want to be sure we're thinking a few things through adequately now because it may be difficult to change the later (i.e., when the real syncing backend is in place). I don't want to hold things up, but also don't want to make any hasty, ill-considered decisions we'll regret later.
1) Do we want to commit to passing around full lists?
AIUI the current implementation is based on passing around entire reading lists. This is simple but inefficient. Is this the model we want to commit to forever? One promising syncing implementation I've seen described involves sending timestamped create/update/delete/whatever events to the server, then having clients retrieve only new events at the start of a session and reconcile them. Would this be that much harder to implement? (OK, it probably would be awkward at the very least while we're backed by userjs as opposed to a real database.)
2) How will we manage the transition to the new backend, esp. if it expects something other than full lists?
What if we want to change the implementation to something more efficient later? What if the architect(s) of the real syncing backend aren't OK with passing full lists around? Users who never upgrade from a version that uses userjs to sync lists should be fine forever but I'm pretty concerned about how we'll manage the transition in the event the syncing content format changes.
(Edit: Previously considered content format versioning, but that won't be helpful for the transition if the move is to a completely different API, unless we provide for old-style syncing for existing users in the new backend.)
Change 347604 merged by jenkins-bot:
[apps/android/wikipedia@master] Synchronize reading lists to user's account.