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
This CL fixes the following compiler warnings.
- Indirect access to static member
- Access to a non-accessible member of an enclosing type
- Parameter assignment
- Method can be static
- Local variable declaration hides another field or variable
- Value of local variable is not used
- Unused import
- Unused private member
- Unnecessary 'else' statement
- Unnecessary declaration of throw exception
- Redundant type arguments
- Missing '@Override' annotation
- Unused '@SuppressWarning' annotations
Bug: 18003991
Change-Id: Icfebe753e53a2cc621848f769d6a3d7ce501ebc7
No behaviour changes.
Unified the overloaded FusionDictionary::add method to always take an
isPossiblyOffensive argument.
Bug: 11031090
Change-Id: I5741a023ca1ce842d2cf10d4f6c926b0efabaa78
Some were never closed, other closed twice. This change
makes all Cursor instances behave, having the #close()
call in a finally{} clause, and puts the burden of closing
the cursor squarely on the creator rather than in the
called methods.
There is however one exception that is beyond the scope
of this change: UserDictionarySettings have a Cursor
member, it's never closed, and fixing the problem is not
obvious. This change adds a TODO for now.
It's not very clear if this change actually helps with
bug#12670151, but it may be related and it's a good
think to do anyway.
Bug: 12670151
Change-Id: I87cc44387e7dee3da1488671b93a28d9d73f7dc0
...to avoid catching fire when the Contacts or User dictionary
providers crash and burn.
Bug: 10200036
Change-Id: I73e9d126ce6d34ebc7e6ac03d94af1c12dde7eda
This is about as ad-hoc as it gets, but then again, what we want
is probably as ad-hoc as it gets.
All URL boxes I know of double as search bars, and not adding
automatic spaces there sucks (e.g. in Chrome URL bar).
And in other boxes actually you don't want to add a space if
it looks like a URL. QSB isn't even a search box, and it behaves
like this.
So I think this is actually the right answer to the problem.
Bug: 7062925
Change-Id: Ib09472b34644fd5bf2dc84bb97cedeeba28bcd02
Stop storing an int in each of the different class types, and
just store a string in the top class.
Change-Id: I2af1832743e6fe78e5c1364f6d9cc21252bf5831
This only returns stuff, but it doesn't change yet how the data
is really passed. It merely adds a way of getting the same data.
Later, the old way will be removed.
Change-Id: If3a064de362175fc5a6781b7a97b65d8730aaf3c
