OverlayItem Drawable Any way to get current drawable?

by Wayne Wenthin » Wed, 10 Jun 2009 06:29:51 GMT


Sponsored Links
 I am looking at changing the drawable on an OverlayItem when it is tapped
and then restoring that to its previous state later.   I can't seem to find
a way to extract the current drawable out of the OI.   I have multiple
drawables in the same overlay and would prefer not to split them up.   Is
there something I'm missing here?

--~--~---------~--~----~------------~-------~--~----~



OverlayItem Drawable Any way to get current drawable?

by Mark Murphy » Wed, 10 Jun 2009 07:21:47 GMT


 


You could keep track of your item states outside of the drawables. I
think you can subclass OverlayItem to add whatever additional
information you might want to hold onto.

-- 
Mark Murphy (a Commons Guy)
 http://commonsware.com  |  http://twitter.com/commonsguy 

Need help for your Android OSS project?  http://wiki.andmob.org/hado 

--~--~---------~--~----~------------~-------~--~----~


Sponsored Links


Other Threads

1. Proposal for change to SensorManager thread priority

I hope that this is the best group for this discussion. My concern is
with the variance in the sampling rate that I have observed while
using the Accelerometers. Most other embedded devices that I have
worked with have a mechanism for obtaining samples from the sensors at
a fixed rate.

Digging through the platform source code, it seems that (not
surprisingly), at the low level, in the native code, the OS does
request a fixed sampling rate (40 ms for SENSOR_DELAY_GAME, for
example). But then the SensorManager thread runs with the same
priority as the display, and so there is often some delay in the event
getting back through to the event listener. As a simple experiment, I
rebuilt the Android 1.6 ROM with the priority of the SensorManager
thread increased to THREAD_PRIORITY_URGENT_DISPLAY, and the variance
in my sampling rate was noticeably decreased.

I can see that there may be unintended consequences of raising the
priority of the SensorManager thread. However, I think that there
should be some system in place for requesting the samples from the
sensors in near-real time. The current solution isn't sufficient for
applications that require consistent sampling rates. Even if there was
some way to get the samples through the NDK, maybe some way to bypass
the SensorManager framework and hook right into the Kernel. Right now
this would require some black magic, and I know that discussing doing
anything like this is frowned upon on in these groups, for good
reason.

Anyone have any ideas? Some applications really do need samples from
the sensors to come at a relatively consistent rate, and the current
solution is insufficient. Also, for the sake of keeping this
discussion mildly on topic, we're working under the assumption that we
need samples at a consistent rate, and I would really like to avoid
discussing the assumption itself.

Cheers,
Jordan Frank
--~--~---------~--~----~------------~-------~--~----~

2. Fw: Motorola Droid Teaser Picture

jadi harga prediksi pas di Indo berapa bro Lesjaw?

--~--~---------~--~----~------------~-------~--~----~
Google Groups "Indonesian Android Community [id-android]" group.

To post to this group, send email to id-android@googlegroups.com

To request to subscribe to this group, please visit the following page:
 

3. Android 2.0 on Dev Phone

4. layout preview doesn't work properly when using <style>

5. Htc Hero skip Donut update..

6. Looking for Custom Layout/ViewGroup Tutorial

7. how to read the app package under /data/app