| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The onSharedPreferenceChanged listener will now also be called on
Editor#clear with a null key.
This change is gated behind a flag using the new app compat framework.
Removed the OnSharedPreferencesClear listener interface.
Bug: 119147584
Bug: 138293946
Test: atest android.content.cts.SharedPreferencesTest
Change-Id: Ieea168eb40afb8f1b5830f1541be20d93d6f94b5
|
| |
|
|
|
|
|
|
|
| |
A new interface has been added that provides a way to receive callbacks
when shared preferences are cleared.
Bug: 119147584
Test: android.content.cts.SharedPreferencesTest
Change-Id: Ie74a6db49711bc5228cf75689872ae188af7979c
|
| |
|
|
|
|
|
|
|
|
| |
Clarified that #onSharedPreferenceChanged does not get called after
Editor#clear.
Bug: 117752822
Test: atest cts/tests/tests/content/src/android/content/cts/SharedPreferencesTest.java#testSharedPrefsChangeListenerIsCalledOnCommit
Test: atest cts/tests/tests/content/src/android/content/cts/SharedPreferencesTest.java#testSharedPrefsChangeListenerIsCalledOnApply
Change-Id: I6fd33d13ae706882131dafdfe0d095f9b48a1744
|
| |
|
|
|
|
|
|
|
|
|
| |
Tried to find the right middle ground in between
- not exposing potentially changing implementation details
- being clear on what it is for and what not
- being too alarmist vs. being to weak
Test: compiled
Bug: 69177691
Change-Id: Ifb40e350a18bf72c113229f31e129b7e8fdacd2a
|
| |
|
|
|
|
|
|
| |
The information explains what happens when null is passed
as value parameter
Bug: 24696308
Change-Id: I362c2b1885e882312d1b4b2ff829f8f9f3546301
|
| |
|
|
|
|
|
|
| |
Remove 6-year-old promise to add multi-process support
for SharedPreferences: our docs elsewhere suggest using
a ContentProvider for multi-process preferences instead.
Change-Id: Ic44550ce46fe62ed2c4ab40b6fa7f7090d5b1d7b
|
| |\
| |
| |
| |
| | |
* commit 'fd335f8467259410c0a55733331e10531141e76e':
Remove wrong javadoc comment
|
| | |\ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Contrary to what the comment of SharedPreferences.Editor.putString()
says, a call to putString(key, null) is not equivalent to remove(key),
at least with SharedPreferencesImpl, backed by a HashMap.
Instead, it associates a null item to the key.
Signed-off-by: Romain Vimont <rom@rom1v.com>
|
| |/ /
| |
| |
| | |
Change-Id: I26e7a02a18d802902fca6892bed77b4f98ccf3ee
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
guidelines per request from @deniseamling.
* commit '59f61cc23d47f7ad714cf99be32fd70a66dba84e':
doc: Updated branding guidelines per request from @deniseamling.
Noted that OnSharedPreferenceChangeListener does not store a strong reference to the listener.
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
to the listener.
Because of this, the listener is susceptible to garbage collection unless the
caller preserves a strong reference to it. We suggest that the caller store a
reference to the listener in an instance field of an object that will exist as
long as the listener is needed.
Also fixed code sample formatting in Settings.jd (some lines were overlong).
Docs are staged in:
http://asolovay.mtv:8901/guide/topics/ui/settings.html#Listening
http://asolovay.mtv:8901/reference/android/content/SharedPreferences.html#registerOnSharedPreferenceChangeListener(android.content.SharedPreferences.OnSharedPreferenceChangeListener)
Bug: 10437648
Change-Id: I48f5b87fa2ca7a240661d0cc00114d225819d54d
|
| |/
|
|
|
|
|
| |
Works with both commit and apply.
Bug: 14838826
Change-Id: I86758139aca8fd06123c06544d1901bb394cbf15
|
| |
|
|
|
|
| |
Bug 7892422
Change-Id: Ib898fd0921d57871d4caecb9042c479271c7ad60
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In particular, make it quite clear that the set returned by
getStringSet() must not be modfied by the app, period; and
add a similar caution about the map returned via getAll().
Also, fix a bug that could lead to unexpected data being committed
if the set instance passed to putStringSet() was mutated by the
app after that call (including mutations after commit() was
invoked).
Bug 7312641
Change-Id: If9a1be1b0669ac879ff7a7dc67a8805548ea10cc
|
| |
|
|
| |
Change-Id: I6125315ecdf0f78dd947c514a9944729d723e95d
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
apply() exists.
Merge commit 'ca1db5ae68971779fd8af83c908128849f470ae0'
* commit 'ca1db5ae68971779fd8af83c908128849f470ae0':
Fallback to SharedPreferences$Editor.commit() when no apply() exists.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Gingerbread widened the SharedPreferences.Editor interface, adding an
apply() method. Most people don't implement this interface
themselves, but a couple apps do.
A few spots in the core framework take a SharedPreferences[.Editor]
from apps, which might be a pre-Gingerbread implementation without an
apply() method. This patch makes sure we never depend on the presence
of an apply() method, falling back to commit() if apply() isn't
available.
Change-Id: I32693ac9227a60b694526a26a30234fb17a40581
|
| |\|
| |
| |
| |
| |
| |
| |
| |
| | |
apply" into gingerbread
Merge commit '734d270769c609c7d3a1f2ec46e1d329d9682ab4'
* commit '734d270769c609c7d3a1f2ec46e1d329d9682ab4':
Renaming SharedPreferences$Editor.startCommit to apply
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Also removes the artifical restriction that only one apply() can be in
flight at once. That was old from when I thought it'd end up being
required, but wasn't.
Change-Id: I3540ea8be6e0760d6a51d218186f71655c2f3f55
|
| |\|
| |
| |
| | |
Change-Id: I13df8dc12092c3d2536e12216df9130d5914380a
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Adds a fire-and-forget save method (startCommit) to the
SharedPreferences.Editor, which is the way most people use it anyway.
This commit adds the implementation. The previous commit added the
interface and docs:
previous change: Idf9934b445da1fb72b79f0192218b47c0a7f5a34
git commit: edf32d01316bd3432c023f17747461b08ae36375
In addition, this change:
-- adds a generic "runPendingWorkFinishers" mechanism to
ActivityThread to wait on async operations that are still
in flight and use it for this.
-- ties runPendingWorkFinishers into Activity.onPause,
BroadcastReceiver, and Service.
-- makes sSharedPreferences keyed on name, not File, to avoid
unnnecessary allocations
-- documents and guarantees what thread
OnSharedPreferenceChangeListener callbacks run on
-- makes a few things in frameworks/base use startCommit(), notably
Preference.java (which was ignoring the return value anyway)
Change-Id: I1c8db60ad45643226fe6d246d3e513eeb7bd0ebd
|
| |\|
| |
| |
| |
| |
| |
| |
| |
| | |
into gingerbread
Merge commit '49209cbcef37c4b20c9d0649ba284a51144b3930'
* commit '49209cbcef37c4b20c9d0649ba284a51144b3930':
Start of SharedPreferences$Editor.startCommit()
|
| | |
| |
| |
| |
| |
| | |
No implementation yet, just the interface.
Change-Id: Idf9934b445da1fb72b79f0192218b47c0a7f5a34
|
| |/
|
|
|
|
|
|
|
| |
Added set support to XmlUtils; added Set<String> functions to SharedPreferences.
MultiSelectListPreference allows multiple selection and persistence of
string preferences. Addresses bug 2575634.
Change-Id: Icd56022d444b0ce43cccf819cd7d600fdb00e88a
|
| | |
|
| | |
|
| |
|