Bug 714657 - Persist earliest next sync in Android Account data rather t... #207
Conversation
ghost
assigned 
|
Not quite true. Account should hold attributes that are specific to the account: the sync key, the server. Prefs holds attributes that are specific to some (account, fennec, …) tuple. This is one such thing. Consider if the same Android account is syncing with Nightly and Beta. By storing the next sync timestamp in the account, you're ensuring that only one of them will get to sync. In general we should be using prefs for anything that's not "pretty much immutable". |
|
I'm not sure I agree with you re: what should be stored in Account and what should not, but I really don't have full picture re: multiple Fennecs, multiple profiles, etc so I won't move on that now. I've rewritten this to correctly wipe the user prefs (there were encoding bugs) and to wipe the global prefs too (since we only support one account right now, we can always wipe the global prefs on new account creation). Device tests are good for me. I would like to verify this doesn't break migrating settings during profile migration (cluster URL and sync ID), and I am confident it won't, but my Fennec is borked so it will have to wait. |
| @@ -176,22 +176,61 @@ public static long decimalSecondsToMilliseconds(Integer decimal) { | |||
| return (long)(decimal * 1000); | |||
| } | |||
|
|
|||
| public static byte[] sha1(String utf8) | |||
| protected static byte[] sha1(String utf8) | |||
There was a problem hiding this comment.
While we're touching this, can we make utf8 final?
|
Sorry this took a while, this looks fine for band-aiding using global prefs. r+ from me. Is there a bug for making prefs to support multiple firefox instances? |
|
Please correct the title of this pull req. |
|
Chenxia: Bug 761682 covers reorganizing prefs. |
…use usernameFromAccount in Utils.getPrefsPath.
…inting to Bug 761682.
...han "sync.prefs.global" Shared Preferences.
Long term sync.prefs.globals should go away, and certainly next sync
is Account specific, so this seemed the right thing to do. I made
next sync an Account datum because we want to access it without
invoking the full Account Manager callback needed to retrieve encoded
username and server URL.