| 60fba77035ba02b211e352dc1fbbafcbe3583b46 |
|
14-Dec-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Simplification of the Pools implementation.
Now instead of a link list of holder objects the pool is backed by
an array of the max size.
Change-Id: Iad1f4f2766d42e8c438cc8efbc72e1e5756b0baf
/frameworks/base/core/java/android/util/Pools.java
|
| be922dc976b1ce1735dcc0cf49509a2149766c96 |
|
01-Dec-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding pool management via the poolable APIs to some classes.
1. Removed the support for infinite pool size which nobody was using and
does not make sense.
2. Update some classes in ViewGroup to use the poolable APIs.
Change-Id: Ifdb8c10968cd06fe53085ec9d3d649f7c9a944b7
/frameworks/base/core/java/android/util/Pools.java
|
| abae2a1b891772d36d8f781adfcc8969e551691f |
|
28-Nov-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Simplification of the poolable management utils.
Before to implement a pool of objects, the pooled class had to implement an
interface which was leaking the pool management APIs. This requires
hiding APIs - inconvenient at best. Further, each client had to
implement the chaining of pooled instances which means adding a couple
of member variables which are manipulated by the implemented interface
methods. As a consequence the client is aware of how pooling is
implemented which is error prone and breaks encapsulation. Now the
pool objects are responsible for managing pooling state via reusable
wrapper objects and the clients are oblivious of how pooling is done.
Creating a thin cached wrapper for each pooled object has minimal
performance impact while making the code more maintainable. Actually
implementing of the old version of the APIs was taking as much code
as implementing the pooling yourself.
Also clients had to implement a poolable manager whose responsibility
was to create new instances and provide callbacks when an instance
is added to or removed from the pool. Now, the clinet class should
create a static member for the pool and expose obtain/aquire and
release/recycle methods in which it should create a new instance if
the pool did not return one and clear the state of the host when
it is returned to the pool. Updated the JavaDoc with a best practice.
The pooling was composed of several interfaces and classes scattered
over a few files, now all this is in a single small file.
Update all usages of the pooling APIs in the framework.
Also one had to write a poolable
manager which
Change-Id: Ib8dc286040eb3d7cb7d9668ba76fead05cb97647
/frameworks/base/core/java/android/util/Pools.java
|
| 10b4043c99dd93ba4db4f461f0761547170134ca |
|
02-Apr-2009 |
Romain Guy <> |
AI 144014: am: CL 144013 Rename PoolFactory to Pools, to follow the java.util convention (Collections, Arrays.)
Original author: romainguy
Merged from: //branches/donutburger/...
Automated import of CL 144014
/frameworks/base/core/java/android/util/Pools.java
|