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
|