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
Bug #7480719
This change also adds the alias "color" for the attribute "fgcolor".
This change also unifies HTML colors parsing between the Html class
and StringBlock for consistency.
Change-Id: I696a6e080387901d88e9baf7cb989b892f14b9db
This sequence of operations would prevent the background from
changing:
setBackgroundResource(R.something)
setBackgroundColor(aColor)
setBackgroundResource(R.something)
The last call would be no-oped.
Change-Id: I436a33599c88e35f6f36bdd63e9c256c9219e052
TTS input limit is now publicly available from getMaxSpeechInputLength()
static method.
Bug: 7456118
Change-Id: Ib2afbb7202ad9dc15895f322fbd1480a5f1f7278
FindBugs description:
There is an apparent recursive loop at IntProperty.java
in method set(Object, Integer)
This method unconditionally invokes itself. This would seem
to indicate an infinite recursive loop that will result in a stack overflow.
Change-Id: I2f52dd3689198cb948925aa65dd9c95be7888fe7
Fix to allow requestLayout() during layout needs to disable
the "currently doing layout" flag while it processes the requests
that came in during layout to allow these initial requests to go
through unhindered.
Change-Id: Ied5ff1589224792f153cc10f65e004f14724523d
ACQUIRE_CAUSES_WAKEUP is supposed to be ignored if combined with
PARTIAL_WAKE_LOCK. Instead it was being carried out for any values
of the WakeLock level.
This change reverts behavior to closely match
previous releases of the framework by only honoring
ACQUIRE_CAUSES_WAKEUP for screen wake lock levels. The only
difference being that in previous releases ACQUIRE_ could have been
combined with PROXIMITY_SCREEN_OFF_WAKE_LOCK (it never was) and
now such a combination will ignore the ACQUIRE_ flag.
Bug 7532258 fixed.
Change-Id: I46e848d8fd1b57e54c63141bf3d4f353986b5bdf
* commit '0b64976f19a3f03f80dfcd80b8894299d4dc71d7':
Revert "NumberPicker should adjust min and max when displayed values are set." (a.k.a. Santa is back)
* commit '0ee790408e19a2a820a080a8b4ad3af63d3a5eca':
Revert "NumberPicker should adjust min and max when displayed values are set." (a.k.a. Santa is back)
* commit '1586168302f79d10e85a5aeed7b486c4244cc98e':
Revert "NumberPicker should adjust min and max when displayed values are set." (a.k.a. Santa is back)
* commit 'e9812bae0e0ce08bd232dc2371fdb959e4f7a318':
Revert "NumberPicker should adjust min and max when displayed values are set." (a.k.a. Santa is back)
Previously, onLoadLanguage was executed without minding synthesis queue.
Now onLoadLanguage is queued item, so it won't be executed before the items
on the queue (previously TTS could receivecall to onLoadLanguage
while synthesizing in completly different language).
I've divided SpeechItem into ControlSpeechItem and UtteranceSpeechItem.
Utterance one dispatches callbacks about synthesis progress.
Bug: 7510063
Bug: 5351864
Change-Id: Ibd156b3cecb190e5c07c4451e61121127b54d51e
Previously, getLanguage returned language set on the TTS service side.
In most cases client wants to receive value that was set on the Client side
(value that was set by last call to the setLanguage). That's true, for
example, for android settings app.
This is not an issue if there's only one client, or when all clients use the same
language. In that cases, service and client languages are in sync.
But if there are multiple clients using different languages, getLanguage might
return values that were not set by the client - and that's not what most of clients expect
to happen.
Change-Id: I5fd8313725e677c20fb2a84a087fc7555897bd30
ITextToSpeechService.setCallback (service rpc call) is no longer
executed on UI thread.
I kept OnInitListener.onInit being called on the UI thread. It's
not specified explicitly, but I don't want to introduce subtle
bugs.
+bonus import fix.
Bug: 6540404
Change-Id: I0136e7efeb374b605ed29ee8b3f550ec2bd2c356
This reverted change was adjusting the min and max values for the NumberPicker
which is not desirable since it changes behavior and it will be possible for
an app that works on the current platform to crash on an older one. Also the
adjustment was not implemented correctly.
Updated the documentation to clarify the reltionship between the min value,
max value, and the displayed values array.
Bug:7518172
This reverts commit a1410e6789
Change-Id: I109f1b1f54c1e609941243cabab9241871b6b12b
ImageWallpaper runs on the main thread now and doesn't need to add
callbacks on different threads or lock against concurrent access.
Bug 7326921 fixed.
Change-Id: I6097e1dff8af743a4fb81b697efee0e02667125b