A timer thread and url fetch thread in same activity.

by Droid » Fri, 20 May 2011 04:57:45 GMT


Sponsored Links
 I am having problems with a timer that should fetch http results from
the web every 5 minutes.
I having problems with two threads - often I cannot even turn them off
or keep the timer going without upsetting the apple cart.

Should I start using wait() and notify(), a separate service or
continue trying to get them to be friends with each other in the same
activity. At present its all very badly behaved and I feel as though I
am juggling with marbles.

-- 



Re: A timer thread and url fetch thread in same activity.

by TreKing » Fri, 20 May 2011 05:06:37 GMT


 



Just saying you're using two threads is a red flag. What apple cart?



Use a handler to schedule a message to go off in 5 minutes. When that
message is delivered, use an AsyncTask to do the fetch and handle the
results when it completes.

No raw threads necessary.

-------------------------------------------------------------------------------------------------
TreKing < http://sites.google.com/site/rezmobileapps/treking> ; - Chicago
transit tracking app for Android-powered devices

-- 


Sponsored Links


Other Threads

1. Android Dev Phone 1

Thought this would be the best place to post this, as the Dev Phone is
clearly not for typical users.  However, on any of the pages with
information about the Dev Phone 1, I don't see whether it supports the
Android Market.  Seems like it should be a simple question, so I'll
post it as a yes/no.

Using an Android Dev Phone 1 on at&t, will I have access to the
Android Market on the phone?

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

2. SurfaceFlinger and HW integration.

I have a few questions regarding integration of an accelerated capability
into Android.
I understand that Android must draw to surfaces in Software. In our
environment we can create a buffer that can be drawn to both by Hardware and
software, but it is one of our components that must allocate the memory in
order to do this.
I've been looking at some various components in SurfaceFlinger that may be
of help (or possibly red-herrings) and have a few questions:
- Do *all* surfaces which can be drawn to instances of one particular class
and if so which one? (I'd like to hook in our own memory surface class at
this point rather than a raw memory allocation). Is there a single point for
which this allocation is done?
- Does a layer have a 1:1 correspondence with a drawable Surface? Or are
multiple Surfaces placed into a Layer?
- Presumably multiple layers are just composited to the final buffer in
their Z order?
- What's the GPUHardware class for? - is it there just for chip access
arbitration or debugging (It looked for example like the allocator was only
used if the debug.egl.hw property were set). Is this needed if arbitration
is handled through EGL/GL?
- Is it true that for surfaces only one allocator will be used either GPU,
/dev/pmem or heap in that order? Under what circumstances is /dev/pmem
needed?
- Is the 8Mb SurfaceFlinger allocation per process or a one-off for the
system?
- Presumably there is only one compositor (running in a system thread)? When
a surface is allocated is it done through the applications thread or the
thread that looks after the composition? (Is there an accompanying call
somewhere to map memory from one process into another?)
- When the compositor is refreshing the display what mechanisms is it using
to access buffers that are in a different address space?
- On the off-chance is there any porting documentation related to surface
flinger and how it works?

Many Thanks.

--~--~---------~--~----~------------~-------~--~----~
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: 

3. Tmobile Android touch screen not working after 2 minutes broswing.

4. touch hanging

5. audio recording to split (small) files without dropping or overlapping samples

6. cannot build android x86 on Mac

7. Porting issue- sdk1.0 in omap2430