1

In my app i am using AlarmManagerto start service every week on a specific time. But in some cases instead of waiting another 7 days I need to call the service on the next day. Because of that I'm not using reapeating alarm but instead in the started service I'm creating new Alarm and set it to a specific date. Something like this:

public class AlarmService extends Service {
@Override
public int onStartCommand(Intent intent, int flags, int startId) {

    //do something 

    //setting new alarm
    AlarmManager alarmMng = (AlarmManager)getSystemService(Context.ALARM_SERVICE);
    Intent i = new Intent(this,AlarmService.class);
    PendingIntent alarmIntent = PendingIntent.getService(this, 0, i, 0);
    Calendar c = Calendar.getInstance();
    if(something) alarmMng.set(AlarmManager.RTC_WAKEUP, c.getTimeInMillis()+1000*60*60*24,alarmIntent);
    else alarmMng.set(AlarmManager.RTC_WAKEUP, c.getTimeInMillis()+1000*60*60*24*7,alarmIntent);
    return START_STICKY;
}

@Nullable
@Override
public IBinder onBind(Intent intent) {
    return null;
}

Everything works fine but I wonder if this is good way to do it. Is it a good idea to create new alarm from service that was just called by one? Is it considered bad programming practice? If so how else should I handle it?

matip
  • 794
  • 3
  • 7
  • 27

1 Answers1

2

Is it considered bad programming practice?

No - this is a fine use case for creating alarm events. If you look at the documentation, use of AlarmManager is intended to send events to your app even if it is not running. Receiving those events in a Service that then schedules another alarm event is perfectly fine. The rest of my answer is intended to explain how to answer the other question you ask:

Is it a good idea to create new alarm from service that was just called by one?

To determine if you need a Service really depends on the "do something" portion of your code more than setting the alarm. For example, you might be fine using a IntentService or even a BroadcastReceiver.

EDIT: In other words, you will need a background process to handle this. Determining the appropriate background process (Receiver or Service) depends on how much processing needs to be done. Generally, setting an alarm all by itself could probably be handled in a Receiver but if it takes too long to process (e.g. more than 10 seconds) you will get an ANR (Application Not Responding) crash. That's when you need a service.

END EDIT..

This is a good post about services: Service vs IntentService

Specifically, the concern you should have is if your service is called multiple times, you should probably include code to cancel any previous alarms created by it, before setting a new alarm.

EDIT: Also, you are not "creating a new service" or "new alarm" each time. Services will have onStartCommand called each time an intent is sent to it (by the AlarmManager or by any other means). A new instance is not created unless it is not already instantiated.

Community
  • 1
  • 1
Jim
  • 10,172
  • 1
  • 27
  • 36
  • Well "do something" is mostly displaying notification – matip Sep 15 '16 at 01:02
  • I think he meant to schedule the service with the alarm itself. That alarm will starts the service, where the alarm itself is initialized within the service . – Plain_Dude_Sleeping_Alone Sep 15 '16 at 12:14
  • Yes, that's what I meant. I wanted to know if it's even a good practice to schedule new alarm from service started by alarm – matip Sep 15 '16 at 12:57
  • I'm not sure if you are seeing this as "alarm events" sent as an Intent to your app. And the service will only have a single instance. I edited my answer. Hope it helps. – Jim Sep 15 '16 at 22:03