Android what is pendingintent

PendingIntent in Android Application Development

Let’s say you want to take shower. But you want to shower after you brush my teeth and eat breakfast. So you know you wont be showering until at least 30–40 minutes. You still have in your head that you will need to prepare my clothes, then walk up to the stairs back to the bathroom and then shower.

However this will happen until 30–40 minutes have passed. Then you now have an pendingIntent to shower. And it is pending for 30–40 minutes.

The moral of the story is this, PendingIntent is an intent that will perform at a later time or in other words PendingIntent specifies an action to take in future. The main differences between a pendingIntent and regular intent is pendingIntent will perform at a later time where Normal/Regular intent starts immediately.

There are many action that can be done with pendingIntent like sending email, attaching a photo to an email even start a activity, services or send Broadcast like a regular intent.

A pendingIntent wraps a regular intent that can be passed to a foreign application (like AlarmManger or NotificationManager etc..) where you are granting that application the right to perform the action. Normally a pendingIntent is used with AlarmManager or NotificationManager.

PendingIntent must need a regular intent to be created. But Regular intent does not require pendingIntent.

A pendingIntent uses the following method to handle different types of intent like

PendingIntent and its workflow

First of all you need to create an intent with required information for creating pendingIntent. Then the created pendingIntent will be passed to a target application (like AlarmManager, NotificationManager etc) using target application services. Then the target application will send the intent exists in pendingIntent by calling send on pendingIntent.

Let’s get into some code now. We’ll create an Intent and wrap it into a PendingIntent:

So we created an intent, wrapped it inside a PendingIntent. Let’s go through the arguments passed to getActivity().

this (context) — This is the context in which the PendingIntent should start the activity.

1 (requestCode) — This is private code for the sender. In case of cancelling the pendingIntent we will need this code.

intent(intent) — Explicit intent of the activity to be launched.

flag : — One of the PendingIntent flag that we’ve used in the above example is FLAG_UPDATE_CURRENT.

There are many other flags also. All are discussed below.

If described pendingIntent already exists then current one should be cancelled before generating new one.

You can use this when you are changing the extra data in the intent by cancelling the previous intent. This flag will ensure that only the given new data will be able to launch it. If assurance is not issue Then FLAG_UPDATE_CURRENT can be used.

If described pendingIntent already exists then keep it and replace with extra data with what is in this new intent.

If you don’t care that any entities that received your previous intent then you can use this.

This pendingIntent can be used only once.

This pendingIntent should be immutable.

Now let’s see a better usage of pendingIntent with AlarmManager.

We get the alarm manager to which we passed the pendingIntent and specify it to go off in 3 seconds. So after 3 seconds Alarm Manager will send the intent exists in pendingIntent by calling send on pendingIntent. And the intent will start a activity named SomeAcitvity(). This will must be happened weather our application is running or not. Because the responsibility of starting SomeActivity() we gave to alarm manager through pendingIntent.

Also we can send broadcast through pendingIntent using alarm manager at a specific time of the day for sync data or any work you wish required for your application. In this case you have to create a Broadcast receiver for catching the intent and for doing your work.

So hopefully you understood how an Intent can be passed to other application via PendingIntent for execution. Hope that helps!

Источник

All About PendingIntents

PendingIntent s are an important part of the Android framework, but most of the available developer resources focus on their implementation details — a “reference to a token maintained by the system” — rather than their usage.

Since Android 12 includes important changes to pending intents, including a change that requires explicitly deciding when a PendingIntent is mutable or immutable, I thought it would be helpful to talk more what pending intents do, how the system uses them, and why you might occasionally want a mutable PendingIntent .

What is a PendingIntent?

A PendingIntent object wraps the functionality of an Intent object while allowing your app to specify something that another app should do, on your app’s behalf, in response to a future action. For example, the wrapped intent might be invoked when an alarm goes off, or when the user taps on a notification.

A key aspect of pending intents is that another app invokes the intent on your app’s behalf. That is, the other app uses your app’s identity when invoking the intent.

In order for the PendingIntent to have the same behavior as if it were a normal Intent , the system triggers the PendingIntent with the same identity as it was created with. In most situations, such as the alarm and notifications, this is the identity of the app itself.

Let’s take a look at the different ways our apps can work with PendingIntent s and why we might want to use them in these ways.

Common case

The most common, and most basic, way to use a PendingIntent is as the action associated with a notification:

We can see that we’re constructing a standard type of Intent that will open our app, and then simply wrapping that in a PendingIntent before adding it to our notification.

In this case, since we have an exact action we know we want to perform, we construct a PendingIntent that cannot be modified by the app we pass it to by utilizing a flag called FLAG_IMMUTABLE .

After we call NotificationManagerCompat.notify() we’re done. The system will display the notification, and, when the user clicks on it, call PendingIntent.send() on our PendingIntent , starting our app.

Updating an immutable PendingIntent

You might think that if an app needs to update a PendingIntent that it needs to be mutable, but that’s not always the case! The app that creates a PendingIntent can always update it by passing the flag FLAG_UPDATE_CURRENT :

We’ll talk about why one may want to make a PendingIntent mutable in a bit.

Inter-app APIs

The common case isn’t only useful for interacting with the system. While it is most common to use startActivityForResult() and onActivityResult() to receive a callback after performing an action, it’s not the only way.

Imagine an online ordering app that provides an API to allow apps to integrate with it. It might accept a PendingIntent as an extra of its own Intent that’s used to start the process of ordering food. The order app only starts the PendingIntent once the order has been delivered.

In this case the ordering app uses a PendingIntent rather than sending an activity result because it could take a significant amount of time for the order to be delivered, and it doesn’t make sense to force the user to wait while this is happening.

We want to create an immutable PendingIntent because we don’t want the online ordering app to change anything about our Intent . We just want them to send it, exactly as it is, when the order’s arrived.

Mutable PendingIntents

But what if we were the developers for the ordering app, and we wanted to add a feature that would allow the user to type a message that would be sent back to the app that called it? Perhaps to allow the calling app to show something like, “It’s PIZZA TIME!”

The answer to this is to use a mutable PendingIntent .

Since a PendingIntent is essentially a wrapper around an Intent , one might think that there would be a method called PendingIntent.getIntent() that one could call to get and update the wrapped Intent , but that’s not the case. So how does it work?

In addition to the send() method on PendingIntent that doesn’t take any parameters, there are a few other versions, including this version, which accepts an Intent :

This intent parameter doesn’t replace the Intent that’s contained in the PendingIntent , but rather it is used to fill in parameters from the wrapped Intent that weren’t provided when the PendingIntent was created.

Let’s look at an example.

This PendingIntent could be handed over to our online order app. After the delivery is completed, the order app could take a customerMessage and send that back as an intent extra like this:

The calling app will then see the extra EXTRA_CUSTOMER_MESSAGE in its Intent and be able to display the message.

Important considerations when declaring pending intent mutability

⚠️ When creating a mutable PendingIntent ALWAYS explicitly set the component that will be started in the Intent . This can be done the way we’ve done it above, by explicitly setting the exact class that will receive it, but it can also be done by calling Intent.setComponent() .

Your app might have a use case where it seems easier to call Intent.setPackage() . Be very careful of the possibility to match multiple components if you do this. It’s better to specify a specific component to receive the Intent if at all possible.

⚠️ If you attempt to override the values in a PendingIntent that was created with FLAG_IMMUTABLE will fail silently, delivering the original wrapped Intent unmodified.

Remember that an app can always update its own PendingIntent , even when they are immutable. The only reason to make a PendingIntent mutable is if another app has to be able to update the wrapped Intent in some way.

Details on flags

We’ve talked a bit about a few of the flags that can be used when creating a PendingIntent , but there are a few others to cover as well.

FLAG_IMMUTABLE : Indicates the Intent inside the PendingIntent cannot be modified by other apps that pass an Intent to PendingIntent.send() . An app can always use FLAG_UPDATE_CURRENT to modify its own PendingIntents

Prior to Android 12, a PendingIntent created without this flag was mutable by default.

⚠️ On Android versions prior to Android 6 (API 23), PendingIntent s are always mutable.

🆕 FLAG_MUTABLE : Indicates the Intent inside the PendingIntent should allow its contents to be updated by an app by merging values from the intent parameter of PendingIntent.send() .

⚠️ Always fill in the ComponentName of the wrapped Intent of any PendingIntent that is mutable. Failing to do so can lead to security vulnerabilities!

This flag was added in Android 12. Prior to Android 12, any PendingIntent s created without the FLAG_IMMUTABLE flag were implicitly mutable.

FLAG_UPDATE_CURRENT : Requests that the system update the existing PendingIntent with the new extra data, rather than storing a new PendingIntent . If the PendingIntent isn’t registered, then this one will be.

FLAG_ONE_SHOT : Only allows the PendingIntent to be sent once (via PendingIntent.send() ). This can be important when passing a PendingIntent to another app if the Intent inside it should only be able to be sent a single time. This may be related to convenience, or to prevent the app from performing some action multiple times.

🔐 Utilizing FLAG_ONE_SHOT prevents issues such as “replay attacks”.

FLAG_CANCEL_CURRENT : Cancels an existing PendingIntent , if one exists, before registering this new one. This can be important if a particular PendingIntent was sent to one app, and you’d like to send it to a different app, potentially updating the data. By using FLAG_CANCEL_CURRENT , the first app would no longer be able to call send on it, but the second app would be.

Receiving PendingIntents

Sometimes the system or other frameworks will provide a PendingIntent as a return from an API call. One example is the method MediaStore.createWriteRequest() that was added in Android 11.

Just as a PendingIntent created by our app is run with our app’s identity, a PendingIntent created by the system is run with the system’s identity. In the case of this API, this allows our app to start an Activity that can grant write permission to a collection of Uri s to our app.

Summary

We’ve talked about how a PendingIntent can be thought of as a wrapper around an Intent that allows the system, or another app, to start an Intent that one app created, as that app, at some time in the future.

We also talked about how a PendingIntent s should usually be immutable and that doing so doesn’t prevent the app from updating its own PendingIntent objects. The way it can do so is by using the FLAG_UPDATE_CURRENT flag in addition to FLAG_IMMUTABLE .

We’ve also talked about the precautions we should make — ensuring to fill in the ComponentName of the wrapped Intent — if a PendingIntent is necessary to be mutable.

Finally, we talked about how sometimes the system, or frameworks, may provide PendingIntent s to our app so that we can decide how and when to run them.

Updates to PendingIntent were just one of the features in Android 12 designed to improve app security. Read about all the changes in the preview here.

Want to do even more? We encourage you to test your apps on the new developer preview of the OS and provide us feedback on your experiences!

Источник

Полный список

— подробно разбираемся с PendingIntent
— используем AlarmManager

Перед тем, как продолжить тему виджетов, нам надо будет знать две темы: PendingIntent и AlarmManager.

С PendingIntent мы уже мельком встречались при работе с уведомлениями (Notifications) в Уроке 99. Вспомним, как создается этот объект. Мы создаем обычный Intent с нужными нам параметрами. Затем мы создаем PendingIntent каким-либо из методов: getActivity, getBroadcast, getService. Здесь имя метода определяет, какой тип объекта будет вызван с помощью нашего Intent. Ведь мы сами, когда отправляем Intent, явно говорим системе, что хотим вызвать: startActivity, sendBroadcast, startService.

Методы создания PendingIntent одинаковы по параметрам и требуют на вход:

context – тут все понятно.
requestCode – в хелпе почему-то написано «currently not used». Но при этом использовать их вполне можно. Это своего рода ключи, чтобы отличать один PendingIntent от других при необходимости.
intent – этот Intent будет впоследствии использован для вызова activity/broadcast/service (в зависимости от метода создания)
flags – флаги, влияющие на поведение и создание PendingIntent

Создавая и передавая другому приложению PendingIntent (с Intent внутри), мы предоставляем ему возможность и полномочия отправлять Intent от нашего имени. В этом уроке мы будем работать с PendingIntent. Увидим, что при создании есть свои нюансы, и разберемся, как можно использовать флаги и requestCode.

Вторая тема урока – AlarmManager. Это планировщик, которому можно передать PendingIntent и сказать, когда именно надо будет его использовать. В общем, что-то типа будильника. Там особо не о чем говорить, поэтому рассмотрим его совсем кратко.

PendingIntent

Создадим пример, в котором будем создавать различные PendingIntent и использовать их в Notifications. Результатом выполнения будет вызов BroadcastReceiver, в котором будем логировать входящую информацию.

Project name: P1191_PendingIntent
Build Target: Android 2.3.3
Application name: PendingIntent
Package name: ru.startandroid.develop.p1191pendingintent
Create Activity: MainActivity

Добавим строки в strings.xml:

Это наш Receiver, в который будут падать Intent из PendingIntent. В нем мы читаем Intent и выводим в лог action и один параметр из extra-данных. Не забудьте прописать этот класс в манифесте.

Только две кнопки.

Метод createIntent создает Intent с указанными параметрами.

Метод sendNotif создает уведомление с указанными ID и PendingIntent.

Метод compare выводит в лог результат сравнения Intent и PendingIntent. Для Intent используем метод filterEquals, который сравнивает Intent по action, data и пр., игнорируя extra-данные .

В onClick1 мы, используя все эти методы, будем создавать различные комбинации, и смотреть, что получается. Сейчас мы там создаем пару Intent и PendingIntent и просто сравниваем их, нигде не используя. В качестве флагов и requestCode мы пока используем нули.

В onClick2 пока ничего не пишем.

Все сохраним и запустим приложение.

Жмем Button1, смотрим лог.

intent1 = intent2: false
pIntent1 = pIntent2: false

Видим, что Intent-ы не равны (т.к. у них различается параметр action). А PendingIntent не равны потому, что их Intent не равны между собой.

Давайте теперь сравняем основные части Intent. Перепишем onClick1:

action будут равны, а Extra отличается. Сохраним, запустим. Жмем Button1:

intent1 = intent2: true
pIntent1 = pIntent2: true

Теперь метод filterEquals говорит нам, что Intent равны. Напомню – это потому, что этот метод не учитывает данные в Extra. PendingIntent получились равны, потому что (по версии filterEquals) равны их Intent. Этот момент надо четко понять, т.к. он очень сильно влияет на создание новых PendingIntent.

Попробую расписать алгоритм, как я его понимаю. Когда приложение создает PendingIntent, система его хранит в себе. При этом, Intent создаваемого PendingIntent сравнивается с Intent уже существующих PendingIntent. Если есть PendingIntent с Intent равным Intent создаваемого PendingIntent, то создаваемый PendingIntent получит этот существующий Intent. А Intent, с которым мы его пытались создать будет отброшен.

Т.е. в нашем случае мы создали pIntent1 с intent1, система его хранит. Далее мы создаем pIntent2 с intent2. Система проверяет существующие PendingIntent, и видит, что есть pIntent1 с intent1, и этот intent1 равен intent2. И ваш созданный pIntent2, теперь содержит intent1. А intent2 выкинут. pIntent1 при этом, разумеется, также остается со своим intent1. Просто теперь один Intent будет использоваться двумя PendingIntent-ами.

Можно сказать, что дефолтное поведение дает нам полную копию существующего PendingIntent, вместо создаваемого, если их Intent-ы равны без учета extra-данных.

Давайте убедимся в этом. Перепишем onClick1:

Будем создавать разные Intent, использовать их в PendingIntent и отправлять уведомления.

Все сохраним и запустим. Жмем Button1. Появились два уведомления.

Жмем первое (Title 1), смотрим лог:

onReceive
action = action 1
extra = extra 1

Все верно. Что помещали в intent1, то и получили в результате срабатывания pIntent1.

Жмем второе (Title 2) уведомление:

onReceive
action = action 2
extra = extra 2

Также все верно. Что помещали в intent2, то и получили в результате срабатывания pIntent2.

Теперь сделаем action одинаковым

Сохраняем, запускаем. Жмем Button1. Жмем первое уведомление:

onReceive
action = action
extra = extra 1

Жмем второе уведомление и наблюдаем в логах разрыв шаблона такое:

onReceive
action = action
extra = extra 1

При втором уведомлении сработал pIntent2, в который мы помещали intent2 c другим extra. Но получили мы extra из intent1. Причины описаны выше. Система увидела, что intent1 равен intent2 (без учета данных в Extra) и созданному pIntent2 дала intent1.

Это дефолтное поведение системы, но, к счастью, мы можем на него повлиять. Для этого и нужны флаги и requestCode, которые передаются в метод создания PendingIntent.

Флаги

Определимся с формулировкой. Фраза «создаваемый PendingIntent похож на существующий» означает, что равны (без extra) Intent-ы двух этих PendingIntent.

FLAG_CANCEL_CURRENT

Если система видит, что создаваемый с таким флагом PendingIntent похож на существующий, то она отменит (удалит) существующий.

Сохраняем, запускаем, жмем Button1, жмем первое уведомление. В логах ничего. pIntent1 был отменен системой в момент создания pIntent2, т.к. они похожи, а pIntent2 содержал флаг FLAG_CANCEL_CURRENT. И т.к. первое уведомление было создано с использованием pIntent1, оно ничего и не сделало.

Жмем второе уведомление.

onReceive
action = action
extra = extra 2

pIntent2 отменил pIntent1, но сам остался и выполнился.

FLAG_UPDATE_CURRENT

Этот флаг включает поведение, обратное дефолтному. Если система видит, что создаваемый с таким флагом PendingIntent похож на существующий, то она возьмет extra-данные Intent создаваемого PendingIntent и запишет их вместо extra-данных Intent существующего PendingIntent. Проще говоря, существующий PendingIntent будет использовать Intent из создаваемого.

Сохраняем, запускаем, жмем Button1, жмем первое уведомление. В логах:

onReceive
action = action
extra = extra 2

Видим, что pIntent1 использовал intent2 вместо intent1. Жмем второе уведомление :

onReceive
action = action
extra = extra 2

Данные из intent2. Получилось, что в обоих PendingIntent использовался intent2.

FLAG_ONE_SHOT

PendingIntent с этим флагом сработает лишь один раз. Сначала сделаем пример без флага. Перепишем onClick1:

Будем использовать один PendingIntent в обоих уведомлениях.

Сохраняем, запускаем, жмем Button1, жмем первое уведомление. В логах:

onReceive
action = action
extra = extra 1

жмем второе уведомление:

onReceive
action = action
extra = extra 1

Все логично. Оба уведомления использовали один pIntent1 с intent1.

Теперь используем флаг:

Этот флаг отменит PendingIntent после первого применения.

Сохраняем, запускаем, жмем Button1, жмем первое уведомление. В логах:

onReceive
action = action
extra = extra 1

Все ок, pIntent1 сработал. Жмем второе уведомление – в логах ничего. pIntent1 не сработал. Система увидела FLAG_ONE_SHOT и отменила PendingIntent после первого вызова. Т.е. PendingIntent с таким флагом может быть использован только один раз.

FLAG_NO_CREATE

PendingIntent не будет создан, если среди существующих нет похожего.

Перепишем onClick1 и onClick2

Сохраняем, запускаем. Жмем Button2, в логах:

pIntent2 is null

pIntent2 не создался, т.к. не было создано похожих PendingIntent. Дальнейшие нажатия будут возвращать тот же результат.

Теперь нажмем Button1, а затем Button2:

pIntent1 created
pIntent2 created

После создания pIntent1, получилось создать и pIntent2 (т.к. похожий pIntent1 существовал). Зачем нужен такой флаг? Единственное, что мне приходит в голову – с его помощью можно проверить существование в системе определенного PendingIntent. Если такой PendingIntent существует, то он вам и вернется (здесь действует дефолтное правило), а если не существует – то получим null.

Как оно там внутри работает

Наверняка назрели вопросы типа: где в системе хранятся эти PendingIntent, как долго они хранятся и когда отменяются (удаляются)?

К сожалению, не знаю. Самому было бы интересно узнать.

В последнем примере:

Если создать pIntent1, закрыть Activity, открыть Activity и создать pIntent2, то он создастся.
Если создать pIntent1, убить процесс, открыть Activity и создать pIntent2, то он создастся.
Если создать pIntent1, переустановить приложение, открыть Activity и создать pIntent2, то он не создастся.

Т.е. переустановка приложения точно скидывает все созданные в нем PendingIntent.

Если есть какие-нить мысли или ссылки на этот счет, пишите на форуме.

Отмена

Вы всегда можете вручную отменить любой PendingIntent методом cancel.

Все сохраним, запустим, жмем Button1. Появилось уведомление. Теперь жмем Button2. pIntent1 отменился. Но при этом, заметьте, уведомление спокойно продолжает себе висеть. Ему неважно, живой его PendingIntent или нет.

Нажимаем на уведомление и видим, что в логах ничего не происходит, т.к. PendingIntent был отменен.

requestCode

Что делать, если у нас есть Intent-ы, различающиеся только extra-данными, и нам все-таки нужно получить разные PendingIntent с ними? Можно использовать requestCode. При их использовании PendingIntent не будут считаться похожими, даже при равных Intent.

Используем requestCode = 1 для pIntent1 и 2 для pInten2.

Сохраняем, запускаем, жмем Button1. В логах:

intent1 = intent2: true
pIntent1 = pIntent2: false

Intent-ы равны, а PendingIntent-ы (благодаря requestCode) – нет.

Жмем первое уведомление

onReceive
action = action
extra = extra 1

Жмем второе уведомление

onReceive
action = action
extra = extra 2

Все сработало, как и ожидалось. Никто ни у кого Intent-ы не менял. Все остались при своих.

Есть еще вариант как сделать разные PendingIntent. Он подходит, если у вас в Intent не используется поле data. Туда можно поместить какие-то свои бессмысленные Uri, содержащие ID, которые просто будут разными, чтобы Intent-ы, а следовательно и PendingIntent-ы получились разными.

Либо можно, чтобы весь Intent преобразовывался в Uri и помещался в data. Делается это так:

Метод toUri преобразует Intent со всем его содержимым и всеми параметрами в строку. parse преобразует строку в Uri. Теперь даже если основные параметры Intent-ов будут одинаковы, то разное содержимое extra-данных сделает полученные Uri разными. И Intent-ы будут отличаться по полю data.

AlarmManager

Разобрались с PendingIntent. Взглянем на AlarmManager. Как я уже написал, да и как понятно из названия объекта, он отвечает за то, чтобы срабатывать по расписанию. «Срабатывать» означает использовать ваш PendingIntent, который вы ему отправите.

Два основных метода: set и setRepeating. Они позволяют запланировать, соответственно, разовое и повторяющееся событие.

Рассмотрим пример. Перепишем методы:

В onClick1 создадим два разных PendingIntent. Первый отправим методом set. На вход метод требует тип «будильника», время срабатывания (в милисекундах) и PendingIntent.

Типы будильника бывают следующие: ELAPSED_REALTIME, ELAPSED_REALTIME_WAKEUP, RTC и RTC_WAKEUP. В чем отличие между ними?

Те, название которых начинается с RTC, ориентируются на системное время. И время запуска таких будильников надо указывать относительно System.currentTimeMillis. Т.е. это RTC и RTC_WAKEUP.

Те, название которых начинается с ELAPSED_REALTIME, ориентируются на время от начала загрузки оси (включения устройства). Время запуска таких будильников надо указывать относительно SystemClock.elapsedRealtime(). Т.е. это ELAPSED_REALTIME и ELAPSED_REALTIME_WAKEUP.

Те, в названии которых есть WAKEUP, при срабатывании будут выводить устройство из спячки. Т.е. это ELAPSED_REALTIME_WAKEUP и RTC_WAKEUP.

Тут надо не путать спячку с выключенным экраном. Экран может быть выключен, но устройство вовсю будет работать. А когда задач нет устройство уходит в спячку, вырубая процессор для экономии энергии. Если будильники с типом не WAKEUP должны сработать, а устройство в это время спит, то их запуск откладывается до пробуждения. А WAKEUP-будильники разбудят устройство.

Вернемся к методу set. Используем здесь тип RTC, а, значит, время запуска (второй параметр метода) указываем относительно системного времени. Укажем текущее время + 4 секунды. Т.е. будильник сработает через 4 секунды после текущего времени создания. А когда он сработает, он выполнит pIntent1 (третий параметр метода).

Второй будильник ставим методом setRepeating. Он похож на set, только позволяет задать еще период повтора срабатывания. Для примера используем здесь тип ELAPSED_REALTIME. С таким типом время запуска мы должны указать, через сколько милисекунд после старта системы сработает будильник. Мы берем время уже прошедшее со старта (SystemClock.elapsedRealtime()), тем самым получая текущее время, и прибавляем к нему 3 секунды. Период повтора (третий параметр метода) сделаем равным 5 секунд. При срабатывании будет выполнен pIntent2.

Т.е. после того, как мы нажмем кнопку у нас установятся два будильника.

Первый – однократный, через 4 секунды от текущего времени, pIntent1.

Второй – повторяющийся каждые 5 сек., с первым запуском через 3 секунды от текущего времени.

В onClick2 мы будем выключать второй будильник, чтобы он у нас не работал вечно. Для этого выполняем метод cancel с указанием PendingIntent, который используется в будильнике.

Все сохраняем, запускаем приложение. Жмем Button1. В логах наблюдаем, как начали срабатывать будильники. Секунд через 20 жмем кнопку Button2, движуха в логах прекратилась. Смотрим логи:

07:55:22.380: start
07:55:25.450: onReceive
07:55:25.450: action = action 2
07:55:25.459: extra = extra 2
07:55:26.430: onReceive
07:55:26.430: action = action 1
07:55:26.430: extra = extra 1
07:55:30.499: onReceive
07:55:30.499: action = action 2
07:55:30.499: extra = extra 2
07:55:35.429: onReceive
07:55:35.429: action = action 2
07:55:35.429: extra = extra 2
07:55:40.450: onReceive
07:55:40.450: action = action 2
07:55:40.450: extra = extra 2

Второй будильник сработал через 3 секунды после старта и далее срабатывал каждые 5 сек, пока мы его не выключили методом cancel. А первый сработал один раз, через 4 секунды. Все, как и задумывалось.

Есть еще метод setInexactRepeating. Он аналогичен методу setRepeating, но периодичность его срабатывания не всегда точно такая, какую вы указали. Он может подстраивать запуск вашего будильника под будильники, которые будут выполнены примерно в то же время. Сделано это для экономии энергии, чтобы не будить два раза устройство, если оно спит. Судя по хелпу погрешность запуска может быть значительной, так что используйте аккуратнее.

Расскажу еще несколько полезных фактов из жизни будильников.

Если вы запланируете будильник с просроченным временем запуска – он выполнится сразу же.

После перезагрузки устройства все будильники стираются.

Если вы попытаетесь создать два разных будильника на основе одного или похожих PendingIntent, то сработает только второй, а первый будет удален при создании второго.

Создаем похожие PendingIntent и запланируем их в два разных будильника – через 2 и 4 секунды.

Сохраняем, запускаем. Жмем Button1. В логах видим:

8:04:03.740: action = action

8:04:03.750: extra = extra 1

Видим, что пришел Intent из pIntent1, который мы использовали для первого будильника, но пришел он через 4 секунды. Что произошло? Выше мы уже рассмотрели, что произойдет при создании похожих PendingIntent — второй будет использовать Intent первого. Кроме того AlarmManager определил, что pIntent1 (используемый в первом будильнике) и pIntent2 (используемый во втором) похожи, и решил, что негоже иметь разные будильники, с одинаковыми PendingIntent. И оставил нам только последний созданный будильник, т.е. второй.

Как решить проблему одинаковости PendingIntent, мы уже рассмотрели выше. Повторяться не буду.

Тема вроде несложная для понимания, но достаточно сложная для объяснения. Все аспекты и варианты рассмотреть в одном уроке трудновато, поэтому если у вас остались какие-либо вопросы, то самым лучшим способом получить ответы на них будут тесты.

На следующем уроке:

— обрабатываем нажатия на виджет

Присоединяйтесь к нам в Telegram:

— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.

— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование

— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня

— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме

Источник