Attempt to use dictionary facilitor without invoking
preference manager. Instead use account from settings only when
things are being reset/changed. Discussion forked from ag/591663
Overall, the idea here is to maintain an account information
inside dictionary groups. Reset the dictionary groups if
account changes (the way we do for locale). Since only user
history dictionary is currently affected, the check to reset user
history dictionary also includes the check to verify the account.
For other things remain the same.
SettingsValues holds the current account (and is updated if prefs change
due to change in account settings). The updated settings are then
propagated to dictionary facilitator via LatinIME#loadSettings.
Bug:18104749,18469539
Change-Id: I553e776e7ea125d0fb7a1fe70a4c7eb0b2277fb8
Add API to ExpandableBinaryDictionary to dump content
from a given dictionary. We use this for dumping data
for sync process.
Refactored UserHistoryDictionaryTests to scrap out the util
methods for testing. These utility methods would be used
for testing sync + user dictionary code in LatinIMEGoogleTests
Bug:18106539
Change-Id: I357f9192ea1bd69a526d0b620c25616a2e8e9d5b
UserHistoryDictionary currently uses locale to determine the
UserHistoryDictionary on the filesystem. With this change we
use the account name as well. Thus each UserHistoryDictionary
would following the following spec:
UserHistoryDictionary.<locale>.<account>.dict.
In case no account is selected, we default to the existing
spec:
UserHistoryDictionary.<locale>.dict
Example
UserHistoryDictionary.en_US.testaccount@example.com.dict
Bug: 18104749
Change-Id: Iab031e166b55cf2ded68275a7e9be22475737b37
clearAndFlushDictionary() was needed when dictionaries are constructed
in java side. All expandable dictionaries now use native code; thus,
this method is same to clear() and no longer needed.
Bug: 13755213
Change-Id: Ifd836e64f8ff807930f7cd2319b103b65e8fce70
Dan Zivkovic
Jatin Matani
Keisuke Kuroyanagi
Jean Chalard
Tadashi G. Takaoka
Ken Wakasa
Yuichiro Hanada