Как прошлые тревоги доставляются AlarmManager? - PullRequest
1 голос
/ 12 декабря 2010

У меня есть вопрос об установке будильника в AlarmManager.Я нашел что-то в документах, которые я не понял (см. Ниже).Я хотел бы установить 10 будильников, которые поочередно вызывают тихий и обычный режим звонка, все с разным временем срабатывания.Теперь устройство засыпает и снова становится активным после того, как все 10 аварийных сигналов устарели.Затем AlarmManager немедленно передает сигнал тревоги?Будет ли это только 10-й (как насчет режима звонка)?

Интервалы тревоги доставляются с дополнительными данными типа int, называемыми Intent.EXTRA_ALARM_COUNT, которые указывают, сколько прошлых событий тревоги было накоплено в этомнамеренная трансляция.Повторяющиеся сигналы тревоги, которые не были доставлены из-за того, что телефон спал, могут иметь число больше единицы при доставке.

Ответы [ 2 ]

3 голосов
/ 06 февраля 2011

Одна вещь, которая является наиболее неизвестной (главным образом потому, что документация Android сообщает, что ее «не используется в данный момент» ), заключается в том, что PendingIntent не будет повторно использоваться, если requestCode отличается.Поэтому вместо этого создайте PI с кодом запроса 0:

    PendingIntent pendingIntent = PendingIntent.getService(context, 0, intent, 0); 

. Вы можете реализовать счетчик и сделать что-то вроде:

    PendingIntent pendingIntent = PendingIntent.getService(context, counter, intent, 0); 

Я знаю, что это будет работать для доставленных SMS /отправленные уведомления PendingIntents, где у вас возникает та же проблема: если PendingIntent используется повторно и у вас есть более 1 ожидающего уведомления, вы не будете знать, для какого SMS это было.Но велики шансы, что это также сработает для выдающейся тревоги PendingIntent.

Надеюсь, это поможет.

2 голосов
/ 12 декабря 2010

Из того, что я понимаю, при планировании тревоги с помощью диспетчера тревог вы должны предоставить экземпляр PendingIntent.

Существует два типа тревог, которые проснутся и сработают, даже если телефон спит или заблокирован, и те, которые не будут.

Кроме того, если вам нужно было запланировать 10 вещей одновременно, AlarmManager заменит существующее запланированное отложенное намерение новым, если вы не выполняли другие намеренные действия. Когда я использую сигналы тревоги, я всегда использовал базу данных sqlite для постановки в очередь заданий, которые я хотел выполнить по какому-то расписанию. Оттуда я планировал по одному сигналу за раз, потому что все они выполняли одно и то же намерение, когда зуммер отключился.

Дополнительный EXTRA_ALARM_COUNT вступит в игру, если у вас запланирован повторяющийся сигнал тревоги, и он несколько раз гаснет, когда пользовательское устройство спит. Когда телефон проснется, он воспроизведет все, что было поставлено в очередь в прошлом. В этом случае ваше ожидающее намерение сработает и будет иметь значение, сколько раз ваш Alarm был пропущен, потому что он был создан с типом RTC или ELAPSED_REALTIME при вызове метода set.

Вот пример того, как я обычно взаимодействую с AlarmManger

protected void scheduleNext(Context context) {
    AlarmManager alarmManager = getAlarmManager();
    Intent intent = new Intent(MyIntent.ACTION_DO_WORK);
    PendingIntent pendingIntent = PendingIntent.getService(context, 0, intent, 0); 

    String where = Queue.SCHEDULED_DATE + "= (select min(" + Queue.SCHEDULED_DATE + ") from queue where " + Queue.COMPLETED_DATE + " is null)";
    Cursor cursor = context.getContentResolver().query(Queue.CONTENT_URI, Queue.PROJECTION, where, null, null);

    if (cursor.moveToFirst()) {
        int id = cursor.getInt(cursor.getColumnIndex(Queue._ID));
        long when = cursor.getLong(cursor.getColumnIndex(Queue.SCHEDULED_DATE));
        alarmManager.set(AlarmManager.RTC_WAKEUP, when, pendingIntent);
    }   

    cursor.close();
}
...