Do czego służy „requestCode” w PendingIntent?

Tło:

Używam PendingIntent do alarmów za pośrednictwem AlarmManager.

Problem:

Na początku pomyślałem, że aby anulować poprzednie, muszę podać dokładny requestCode, którego użyłem wcześniej do uruchomienia alarmu.

Ale potem dowiedziałem się, że się myliłem, ponieważ API anulowania mówi:

Usuń wszystkie alarmy z dopasowaną intencją. Każdy alarm dowolnego typu, którego intencja pasuje do tego (zgodnie z definicją filterEquals (Intent)), zostanie anulowany.

patrząc na „ filterEquals ”, dokumentacja mówi:

Określ, czy dwie intencje są takie same, na potrzeby rozwiązania intencji (filtrowania). Oznacza to, że ich działanie, dane, typ, klasa i kategorie są takie same. Nie porównuje to żadnych dodatkowych danych zawartych w intencjach.

więc nie rozumiem, do czego służy „requestCode” ...

Pytanie:

Do czego służy „requestCode”?

Co się stanie, jeśli utworzę wiele alarmów z tym samym „requestCode”? czy mają pierwszeństwo?

1. requestCode służy do późniejszego pobrania tej samej oczekującej instancji intencji (do anulowania itp.).
2. Tak, przypuszczam, że alarmy będą się wzajemnie unieważniać. Chciałbym zachować unikalne kody żądań.

Chcę tylko dodać do odpowiedzi @Minhaj Arfin

1- requestCode służy do późniejszego uzyskania tego samego oczekującego zamiaru (do anulowania itp.)

2 - Tak, zostaną one zastąpione, o ile określisz tego samego odbiorcę w swoim zamiarze, który określisz w swoim PendingIntent

przykład:

Intent startIntent1 = new Intent(context, AlarmReceiverFirst.class);
PendingIntent pendingIntent1 = PendingIntent.getBroadcast(context, 0, startIntent1, 0);

Intent startIntent2 = new Intent(context, AlarmReceiverSecond.class);
PendingIntent pendingIntent2 = PendingIntent.getBroadcast(context, 0, startIntent2, 0);

Z powyższego przykładu nie będą się nadpisywać, ponieważ odbiornik jest inny (AlarmReceiverFirst i AlarmReceiverSecond)

Intent startIntent2 = new Intent(context, AlarmReceiverSecond.class);
PendingIntent pendingIntent2 = PendingIntent.getBroadcast(context, 0, startIntent2, 0);

Intent startIntent3 = new Intent(context, AlarmReceiverSecond.class);
PendingIntent pendingIntent3 = PendingIntent.getBroadcast(context, 0, startIntent3, 0);

Z powyższego przykładu będą się nadpisywać, ponieważ odbiornik jest taki sam (AlarmReceiverSecond)

w moim przypadku chcę otworzyć tę samą czynność z dwoma różnymi intencjami, więc jeśli w zasobniku są dwa lub więcej FCMS, jeden z nich otworzy tylko inne nie, więc zmieniłem kody żądań oczekujących zamiarów, a następnie zadziałało.

 PendingIntent pendingIntent =
                            PendingIntent.getActivity(this, **Some unique id for all GCMS** /* Request code */, intent,
                                    PendingIntent.FLAG_ONE_SHOT);

Jedną z ważnych rzeczy, requestCodektóre będą poważnym problemem w Twojej aplikacji, są widżety. widżety nie będą działać po ponownym uruchomieniu telefonu, jeśli requestCodesą takie same. Oznacza to, że element pendingIndentustawiony w remoteViewswidgecie musi mieć ustawiony unikalny kod żądania, zwykle widgetId towarzyszący liczbie.

W rzeczywistości dokumentacja jasno określa, do czego służy kod żądania:

Jeśli naprawdę potrzebujesz wielu różnych obiektów PendingIntent aktywnych w tym samym czasie (na przykład jako dwóch powiadomień, które są wyświetlane w tym samym czasie), musisz upewnić się, że jest w nich coś innego, aby powiązać je z różnymi PendingIntents. Może to być dowolny z atrybutów Intent uwzględnianych przez Intent # filterEquals (Intent) lub różne liczby całkowite kodu żądania dostarczone do getActivity (Context, int, Intent, int), getActivities (Context, int, Intent [], int), getBroadcast ( Context, int, Intent, int) lub getService (Context, int, Intent, int).

Ponieważ wydaje się, że nadal nie jest to takie jasne, spróbuję wyjaśnić:

Kiedy chcesz użyć PendingIntentobiektu, nie tworzysz go po prostu. Przeciwnie, można uzyskać jedną z systemu przy użyciu PendingIntentmetody statyczne ( getActivity, getBroadcast, getServiceetc). System przechowuje kilka instancji PendingIntent i daje Ci jedną. To, który z nich daje, zależy od parametrów wejściowych przekazanych do tych metod pobierających. Te parametry wejściowe to: Contexttj. Docelowy odbiorca zamiaru, Intentużycie requestCodei flags. Kiedy przekazujesz ten sam Context, ten sam requestCodei ten sam zamiar (co oznacza zamiar filterEqualsz inną intencją), otrzymujesz ten sam PendingIntentobiekt. Chodzi o to, że system chce mieć jak najmniej PendingIntentobiektów, więc ma tendencję do ponownego wykorzystywania istniejących, w jak największym stopniu.

Na przykład masz dwa powiadomienia kalendarza dla dwóch różnych dat. Po kliknięciu jednego z nich chcesz, aby Twoja aplikacja otworzyła się zgodnie z datą tego powiadomienia. W tym scenariuszu masz ten sam Contextcel, a Intentobiekt, który przekazujesz różni się tylko DANE_DODATKOWE (które określają datę, która powinna być otwarta). Jeśli podasz to samo requestCodeprzy zdobywaniu PendingIntentprzedmiotu, otrzymasz ten sam PendingIntentprzedmiot. Tak więc, tworząc drugie powiadomienie, Intentzastąpisz stary obiekt nowym EXTRA_DATA i otrzymasz dwa powiadomienia wskazujące tę samą datę.

Jeśli chcesz mieć dwa różne PendingIntentobiekty, tak jak powinieneś w tym scenariuszu, requestCodepodczas uzyskiwania PendingIntentobiektu należy określić inny .