Service with timer

by » Mon, 27 Apr 2009 22:07:32 GMT

Sponsored Links
 I have a service running that has a Timer. The Timer schedules a
TimerTask to run at a certain interval. The TimerTask simply display's
a notification. In theory it all sort of works but I find it very

The notifications only occur when the device is not sleeping. Also
sometimes it seems as though the Timer is only counting time when the
device is not asleep. If I leave the device asleep for 15 minutes then
wake it up after a minute or two I will get 4 notifications in a row.
All the ones that should have been displayed periodically over the
last 15 minutes.

Am I handling this situation the correct way? Is a timer the correct
way to do this? How can I make the device wake from sleep and display
the notifications at the correct intervals?

public class GameScoreService extends Service {

    Timer timer = null;

        private void startService() {

                timer = new Timer();

                timer.scheduleAtFixedRate(new getNewScores(), 5000, 180000);

        class getNewScores extends TimerTask {
                public void run() {

                        ...perform notification

    public void onStart(Intent intent, int startId) {

        super.onStart(intent, startId);



Service with timer

by » Mon, 27 Apr 2009 22:44:02 GMT

 Well after a bit more research I think I have concluded that my
initial approach was way off. I am now changing it to use an
AlarmManager instead. Can someone please explain AlarmManagers to me a
bit better.

Previously this is how my app worked.

Add an item to a database.
Launch service.
Service starts a Timer that runs a TimerTask every 5 minutes.
TimerTask = For every row in the database
  If certain conditions are met, fire off a notification.
  If other conditions are met, delete that row
If there are now rows left, stop the service and timer.

So how is the best way to now implement it with an AlarmManager. I
have just set it up as follows.
Add an item to a database.
Start AlarmManager that runs every 5 minutes
Broadcastreceiver = For every row in the database
  If certain conditions are met, fire off a notification.
  If other conditions are met, delete that row
If there are now rows left, cancel the AlarmManager

This seems to work ok. Now I no longer need to run the service I
previously was using at all. What I want to know is how long will the
alarm keep running? Until it is explicitly canceled? Until the device
is rebooted? What if my app is closed?

Basically I just want to know if I am tackling this problem in the
correct manner.


On Apr 27, 8:48pm, "" <>


Sponsored Links

Other Threads

1. Best way to format text on android surface?

I want to have more control over the display of text on a surface than I know 
how to do.

I want to be able to zoom in and out, scroll vertically and horizontally, and 
use different size fonts.

Would I do this with RelativeLayout or is there a better way?

Is there an example code somewhere that shows how to do some or all of this?

I expect that the profusion of devices entering the market this fall will 
increase the need to adjust layouts to multiple screen sizes.  So I would like 
to avoid fixed placement to specific screen locations.

What I am seeking here is an idea how to approach this problem in Android.



2. What is Donut?

I've been having some twitter exchanges with JBQ and reading around the various 
articles and I think I understand what donut is so I'm throwing it out to the 
list so we can clear anything up.

There is not one Donut but two. (Mmmmm... Donuts)

One is the codename for the next release (i.e. donut release), One is the 
branch in the git repo (i.e. donut tree). The feature set and version number 
for the donut release has not been fixed. The features in the donut tree and 
candidates for the donut release but are not guaranteed to be part of the donut 

As for a donut release version number, JBQ seems to think that "System V" is 
unlikely but anything is possible :).

So; If you're using one of the donut sdks from the open source build you are 
using the donut tree and so it has candidate features, you are not using the 
donut release (because the shape and sprinkles for donut release have not been 
finalise), so some features may not make the cut.

The other thing to remember is that OEMs and carriers get their hand in so even 
if a feature in donut tree does make it into donut release the OEM or carrier 
may remove it before consumers get a chance to take a bite.

Does anyone think this isn't right?


P.S. As I understand things Romains' comment about "donut is not 2.0" should be 
read as "At the point in time when the comment was made donut tree does not 
contain just contain features for a donut release, and 2.0 has not been decided 
upon as the version number for the donut release. In the future the donut 
release may be given the 2.0 version number, but that has not been decided upon 
so *at this point in time* donut is not 2.0".

* Written an Android App? - List it at *

Funky Android Limited is registered in England & Wales with the
company number 6741909. The registered head office is Kemp House,
152-160 City Road, London, EC1V 2NX, UK.

The views expressed in this email are those of the author and not
necessarily those of Funky Android Limited, it's associates, or it's


3. How Refresh Updated Contacts in list view using Base adapter

4. Dialer

5. link to an existing app in the market

6. why binder report transaction failed

7. Is there any APIs for retrieving the phone call infomation?