There are many ways to fix this problem but this is the most
direct way. Removing a view from the cache when any animation
is started will ensure it won't be used again, and will be garbage
collected when it's possible. Since views are created on demand
anyway, a new one will just get created when needed, and that's
it.
Bug: 9400128
Change-Id: I4945d2859d642e79694d51ae90cf4f5bde9a5f1d
This patch does two things:
- If there is no URL to download new data from, then the
Refresh button is not shown.
- Even if for some reason refresh starts for a client for
which there is no URL, loading correctly finishes.
Bug: 9388602
Change-Id: I3fd9214da50faa4b59d0bd3e775293dd34f07547
This is a bit of a shot in the dark, as I really don't see how this
can happen, but this should fix it in the correct way no matter
how it's actually happening.
Bug: 9301836
Change-Id: I472865b7a78883942c9fd46773238c23788674f8
It turns out giving them in the right order is not enough, you
also have to actually give them a numeric priority.
Bug: 9165928
Change-Id: I2ecff38f65b70746feeeeb0ed2cc86a586a35363
The default implementation for preferences refuses to
cache the views for custom preferences at all. We can
do it, but the system won't do it for us, so this does it.
This makes the screen scrolling smooth again.
Incidentally it also fixes the bug where the button may
not animate on the first element.
Bug: 8882722
Bug: 8883108
Change-Id: I9b2306ac4bf93761a808ebfee3477a65f017cddf
This is an optimization. It also happens to work around what
seems to be a framework bug in JB MR1 / MR1.1.
Bug: 8771179
Change-Id: I62cc7acdc8656d75f8a50c068c4e9d8c6ceb74a0
This ensures the thread does not run uselessly (it is even terminated when
the progress bar exits the screen).
Bug: 7600384
Change-Id: I09117a6f763b574b9b3266f36ba3da4720dc9224
Clicking on a button that is animating-out is only done by
mistake. Better make them unclickable.
Also, interrupt an out-in animation if it has been preempted.
Bug: 7600384
Change-Id: Ic4700cda46a894ea580bc67ee7bef885ecf1d3bc
This adds a number to the extension.
Note that for DownloadManager to keep this, the server
needs to send it a mime type it does not recognize. Right
now, it does not recognize application/json so it's okay,
but we'd do well to remove the content/type header from
the server to prevent problems.
Bug: 8467516
Change-Id: Ic484f66ac3f67c36f59f2c0bcb8c7fdeb6e8590d
Handling buttons directly in the preference causes large
problems of code readability and interface. It's better to
have a class to manage the buttons and their animations
separately. This is feature-equivalent, and mostly
delegates stuff for now.
Bug: 7600384
Change-Id: Ia8da0ec68ffac84fc1d65e1760539a87a73fa776
The life span of this object is actually the life span of the interface.
It should not be static.
Also, we'll have a few other things to store in there soon.
Bug: 7600384
Change-Id: I708019e9ee53653e83a1e52c8e76326c3e39bcf3
This preference is not a DialogPreference any more, as it doesn't
ever display a Dialog.
Bug: 7600384
Change-Id: Ia5965617c83d3cb964010f9b40d833065dccef60
What do you mean "Can't happen"?
It happens all the time - the empty string is the default ID, and it
needs to be updated like everyone else.
Bug: 8651858
Change-Id: I5a2f2ebb5b2ef08b27f26be8fb2c3d2f231ebcfc
Upon invoking the settings of the dictionary pack with an unknown
client, we now launch an intent to ask the client to make itself known.
This change also includes the code that receives this intent and
acts upon it.
Bug: 8492879
Change-Id: I2c6496dea845646961ecafcf64e282cb93ee91dc
