| 776abc24cdd18610232a50b997cce3cffa74609b |
|
07-Mar-2014 |
Adam Lesinski <adamlesinski@google.com> |
Uses VMRuntime.newUnpaddedArray for ideal array sizes
Bug:13028925
Change-Id: I0a9301248b10a339afbdc5e4ffe3310ac4fa1fb7
/frameworks/base/core/java/android/util/LongSparseArray.java
|
| ebb47950f21d3c41955a591000dfb1f195e746fe |
|
21-Nov-2013 |
Newton Allen <newt@google.com> |
Fix javadoc typo in SparseArray.
Change-Id: Ie69b2cf96dae95b6ebe7b7797d3755749aec9f35
/frameworks/base/core/java/android/util/LongSparseArray.java
|
| 5771302ca13c31cb85f17bc58da8f6f8227c9b85 |
|
08-Sep-2013 |
Flavio Lerda <flerda@google.com> |
Document the order of values returned by keyAt().
The values returned by keyAt() are currently guaranteed to be in
ascending order. This is helpful to users of the API to be able to make
assumptions about the keys and values when iterating over one of the
sparse array implementations.
This commit adds documentation about this.
Change-Id: I3d7eb78e115ce174f1167b83904b44bf5120b223
/frameworks/base/core/java/android/util/LongSparseArray.java
|
| 3e82ba1a67b0c756ab6a289985f4cfc53725b311 |
|
16-Jul-2013 |
Dianne Hackborn <hackbod@google.com> |
Make ArrayMap public! :)
Also do some tweaking of the various container classes
to synchronize them with the support lib and make it
easier to copy code between the two.
And update activity/fragment to use ArrayMap.
Change-Id: I3cfe82392a17119dfc72c3d9961f64e1914f42be
/frameworks/base/core/java/android/util/LongSparseArray.java
|
| b993f41eb2f165425dfdf0f93ea0b1e354eca837 |
|
13-Jul-2013 |
Dianne Hackborn <hackbod@google.com> |
Update SparseArray docs to be more informative.
Change-Id: I5d8d17d46a69ccdcf6b29f93be3d44addd80ab61
/frameworks/base/core/java/android/util/LongSparseArray.java
|
| f4bf0ae2a7c2d9d92c5c8abdb82baa53b4c9ccda |
|
21-May-2013 |
Dianne Hackborn <hackbod@google.com> |
New ArrayMap class.
This is a new kind of key/value mapping that stores its data
as an array, so it doesn't need to create an extra Entry object
for every mapping placed in to it. It is also optimized to reduce
memory overhead in other ways, by keeping the base object small,
being fairly aggressive about keeping the array data structures
small, etc.
There are some unit and performance tests dropped in to some
random places; they will need to be put somewhere else once I
decided what we are going to do with this for the next release
(for example if we make it public the unit tests should go in
to CTS).
Switch IntentResolver to using ArrayMap instead of HashMap.
Also get rid of a bunch of duplicate implementations of binarySearch,
and add an optimization to the various sparse arrays where you can
supply an explicit 0 capacity to prevent it from doing an initial
array allocation; use this new optimization in a few places where it
makes sense.
Change-Id: I01ef2764680f8ae49938e2a2ed40dc01606a056b
/frameworks/base/core/java/android/util/LongSparseArray.java
|
| 9c1d2980f2c7c73f098d551499c4fd48cdc96b4d |
|
10-Feb-2012 |
Dianne Hackborn <hackbod@google.com> |
Clean up and expose LongSparseArray.
Change-Id: I15ba98d65e790ba45391cc7714f60b6e7de6ebfc
/frameworks/base/core/java/android/util/LongSparseArray.java
|
| 8f1bfe1a7cef702fd74e5405443e9fdb7c5e7556 |
|
06-Mar-2010 |
Adam Powell <adamp@google.com> |
ListView#getCheckItemIds() deprecated for ListView#getCheckedItemIds().
ListView#getCheckedItemIds() now works more reliably.
/frameworks/base/core/java/android/util/LongSparseArray.java
|
| fdbf6a7eac39a23e0e910c29678fe00d4eb56c99 |
|
19-Jun-2009 |
Romain Guy <romainguy@android.com> |
Fixes #1922373. Resolves a case of keys collision in Resources' cache.
The Resources class keeps a cache of known resources. The keys used by the
cache are stored as int primitives. For any given drawable resource, a key
is built thusly:
TypeValue.assetCookie << 24 | TypedValue.data
In the case of a plain color drawable, assetCookie always equals -1, that
is 0xFF once right-shifted and the data contains the color value. Which
means the key for the following two colors is the same:
0xFF000000
0x00000000
Because of the int storage and the use of the (constant in this case)
asset cookie, the alpha channel of a color is ignored. That means that
if you first load an opaque black color (0xFF000000), subsequent loads
of a totally transparent black color (0x00000000) will give you an
opaque black color.
A workaround is to use a transparent color that is not black,
0x00000001 for instance. Note that this issue would arise with any color
and any opacity level.
The solution to fix this issue is simply to change the cache to use
longs instead of ints to represent the keys. A key thus becomes:
TypedValue.assetCookie << 32 | TypedValue.data
This allows us correct storage of all colors at the cost of a few bytes.
The tradeoff is that we can keep caching ColorDrawable, which is
definitely worth it.
/frameworks/base/core/java/android/util/LongSparseArray.java
|