Obtaining custom notification header in Android

Messaging Service Push Notifications
21

Hi, @milen-marinov
Can you please provide minimal example to reproduce? Please include your AndroidManifest file and Activity where you obtain the headers.

Regards,
Maksym

22

Hi @Maksym_Khobotin,

As my app is open source, you can use it directly to reproduce the issue from this branch: https://github.com/HelpAPaw/Android/tree/obtain_push_headers
When a push notification is opened it launches the main activity SignalsMapActivity. I check the intent extras on line 105.
Let me know if you need further info!

23

Thanks for information. That is enough. I will try to reproduce your issue and let you know once I find the solution.

Regards,
Maksym

24

Hi, @milen-marinov
I’ve downloaded your project and checked it. Everything works fine.
I added log where you receive the intent extras

36
36870×245 41 KB

And then precisely followed the steps you have described. I sent the notification like this:

25
251106×657 151 KB

And I received the expected response:

28

How do you send the notification? If you change your header extras from “Compose Push” window, do you save the changes before sending new push notification?
There should be the popup:

09

And you should “Save and send” it.

Best regards,
Maksym

25

Hi Maksym,

That’s very interesting. If I send push notifications from the console (the way you described) the extras in the activity are updated correctly every time! However, when I send the pushes from another instance of the same app through the SDK the bug in question is reproduced!
The pushes are sent from this method.
Would you be so kind to take a look and let me know if I do something wrong there?
If everything is correct in my code, can you try to reproduce the issue? What I do is:

  1. On device/simulator A tap the “Add new signal” button in the bottom right
  2. Enter some number for title and tap send
  3. Device/simulator B receives the notification (both should be in/have the same location)
  4. Tap the notification

Expected result:
signalId should be updated every time a new notification is opened

Actual result:
signalId remains fixed on the value of the first notification

Thanks a lot for your help!

26

Hi Milen,

I was able to reproduce the issue. The problem appears when I send push through SDK. We are now working to resolve this issue. Internal ticket: 19105.

Best regards,
Maksym

1 Like
27

Issue is fixed and will be published to maven central with a new version of Android SDK during next week

Anton

1 Like
28

Hi @milen-marinov

Fix for this scenario is now available in version 5.3.0 of Android SDK, please verify. Apologies for the inconveniences it may have caused.

Anton

29

Hi @anton-govorushkin,

Thanks for the update! Unfortunately, the problem still persists in SDK v5.3.0. You can check again with my project and the same scenario - just update the backendless dependency to the new version.

Best,
Milen

30

Hi, @milen-marinov

I checked the same scenario with your project and backendless version 5.3.0 and it works fine for me. I follow the next steps:

  1. Update backendless version to 5.3.0
  2. Add log to initFragment() method of SignalsMapActivity
  3. Run the app
  4. Send push through SDK with signalId value = 1
  5. Send another push through SDK with signalId value = 2
  6. Open first notification and receive the signalId header value “1”
  7. Open the second notification and receive the signalId header value “2”

SignalsMapActivity:

private void initFragment() {
    Log.i("TAG", "RESULT: " + getIntent().getStringExtra(Signal.KEY_SIGNAL_ID));
    ...
}

Notification push:

int counter = 0;
PublishOptions options = new PublishOptions();
Map<String, String> headers = new HashMap<>();
headers.put("signalId",String.valueOf(counter++));
options.setHeaders(headers);

Backendless.Messaging.publish("default", "TEST MESSAGE", options, new AsyncCallback<MessageStatus>() {
    @Override
     public void handleResponse(MessageStatus response) {
         Log.i("TAG", response.toString());
     }

    @Override
     public void handleFault(BackendlessFault fault) {
         Log.e("TAG", fault.getMessage());
     }
});

Please double-check the version of backendless library. If you use Android Studio, run File -> Sync Project with Gradle Files.

Best regards,
Maksym

31

Hi @Maksym_Khobotin,

I checked again with the setup you have specified and the behaviour of the v5.3.0 SDK is not the same as before - it’s even stranger :slight_smile: It looks like there is a buffer that keeps old notification values and in each debug session you start receiving all old values one by one until you reach the new ones. To demonstrate what I mean here is the log from 3 separate debug sessions:

*** Debug session 1
2019-07-13 17:10:33.972 3916-3916/? E/TAG: RESULT: null <— Launch without notification
2019-07-13 17:11:07.603 3916-3916/? E/TAG: RESULT: A70E4957-E6AB-3F03-FFE6-A3C886EFB600 <— Value from old notification #1
2019-07-13 17:12:24.352 3916-3916/? E/TAG: RESULT: B1B3B5E6-55E5-DCFD-FFD1-7C8657E4EE00 <— Value from old notification #2
2019-07-13 17:14:28.374 3916-3916/? E/TAG: RESULT: 4BBA5804-91BE-882C-FF3E-7EBE320C0900 <— Value from old notification #3
2019-07-13 17:16:00.482 3916-3916/? E/TAG: RESULT: e5 <— Value from new notification #1
2019-07-13 17:16:36.690 3916-3916/? E/TAG: RESULT: e6 <— Value from new notification #2
*** Debug session 2
2019-07-13 17:19:03.900 5715-5715/org.helpapaw.helpapaw E/TAG: RESULT: null <— Launch without notification
2019-07-13 17:19:39.761 5715-5715/org.helpapaw.helpapaw E/TAG: RESULT: A70E4957-E6AB-3F03-FFE6-A3C886EFB600 <— Value from old notification #1
2019-07-13 17:20:15.782 5715-5715/org.helpapaw.helpapaw E/TAG: RESULT: B1B3B5E6-55E5-DCFD-FFD1-7C8657E4EE00 <— Value from old notification #2
2019-07-13 17:20:58.939 5715-5715/org.helpapaw.helpapaw E/TAG: RESULT: 4BBA5804-91BE-882C-FF3E-7EBE320C0900 <— Value from old notification #3
2019-07-13 17:21:23.816 5715-5715/org.helpapaw.helpapaw E/TAG: RESULT: e5 <— Value from new (now old) notification #1
2019-07-13 17:21:58.509 5715-5715/org.helpapaw.helpapaw E/TAG: RESULT: e6 <— Value from new (now old) notification #2
2019-07-13 17:22:27.865 5715-5715/org.helpapaw.helpapaw E/TAG: RESULT: 1CD05027-376F-C7D4-FF29-A65541C4ED00 <— Value from new notification #1
2019-07-13 17:23:13.641 5715-5715/org.helpapaw.helpapaw E/TAG: RESULT: E7CF1D7E-9CDA-A769-FF22-90180035C400 <— Value from new notification #2
*** Debug session 3
2019-07-13 17:23:58.153 6397-6397/org.helpapaw.helpapaw E/TAG: RESULT: null <— Launch without notification
2019-07-13 17:24:48.760 6397-6397/org.helpapaw.helpapaw E/TAG: RESULT: A70E4957-E6AB-3F03-FFE6-A3C886EFB600 <— Value from old notification #1
2019-07-13 17:25:29.642 6397-6397/org.helpapaw.helpapaw E/TAG: RESULT: B1B3B5E6-55E5-DCFD-FFD1-7C8657E4EE00 <— Value from old notification #2
2019-07-13 17:34:25.022 6397-6397/org.helpapaw.helpapaw E/TAG: RESULT: 4BBA5804-91BE-882C-FF3E-7EBE320C0900 <— Value from old notification #3
2019-07-13 17:34:57.100 6397-6397/org.helpapaw.helpapaw E/TAG: RESULT: e5 <— Value from new (now old) notification #1
2019-07-13 17:35:27.488 6397-6397/org.helpapaw.helpapaw E/TAG: RESULT: e6 <— Value from new (now old) notification #2
2019-07-13 17:36:00.232 6397-6397/org.helpapaw.helpapaw E/TAG: RESULT: 1CD05027-376F-C7D4-FF29-A65541C4ED00 <— Value from new (now old) notification #1
2019-07-13 17:39:00.963 6397-6397/org.helpapaw.helpapaw E/TAG: RESULT: E7CF1D7E-9CDA-A769-FF22-90180035C400 <— Value from new (now old) notification #2
2019-07-13 17:40:58.422 6397-6397/org.helpapaw.helpapaw E/TAG: RESULT: B5DACE3F-2A05-E1AE-FF7D-AEF105BFC300 <— Value from new notification #1
2019-07-13 17:41:57.617 6397-6397/org.helpapaw.helpapaw E/TAG: RESULT: 9432CCBC-F232-EDB6-FF56-BE2542091800 <— Value from new notification #2

Let me know if you need more info to replicate this behaviour!

Best,
Milen

32

Hi, @milen-marinov

I cannot reproduce such behaviour. Can you please try to create a new sample project and repeat your scenario to make sure the problem is not with your project’s (HelpAPaw) logic.
If the problem is reproduced in a new project, send me the project to let us help you with this issue.

Best regards,
Maksym

33

Hi @Maksym_Khobotin,

Just so I know where to look - did you try to reproduce the bug with my project or with another one?

Best,
Milen

34

Hi, @milen-marinov

I tried to reproduce your issue with your project with no success.
I suppose that your issue may be caused by the specific logic of your application. And it would be nice if you could try to reproduce the scenario with sample project without any additional logic to confirm that problem is on our side, not your.

Also did you try to reproduce my last scenario with backendless version 5.3.0?

Best Regards,
Maksym

35

Hi @Maksym_Khobotin,

Yes, I am using SDK v5.3.0. Today I checked again but unfortunately the app still behaves the same way:

  1. When I first launch the app no extras are delivered
  2. When I tap to open a notification it receives the extras from the first notification that was opened since the app was installed
  3. When I tap to open another notification it receives the extras from the second notification that was opened since the app was installed
  4. This behaviour continues until all previous notification extras have been delivered yet another time. Then the app starts receiving the extras from the current notifications. If I start another session the new notification extras are added to this list.
  5. I need to delete all app data and the app itself to start clean (i.e. receive the extras from the notification that was opened) only to repeat this whole behaviour between debug sessions.

It just looks like Backendless SDK delivers the extras for the wrong notification. I will try to reproduce that behaviour in a new project when time allows it (which unfortunately will not be very soon). In the mean time I will be happy if you could test this some more as my app doesn’t store and doesn’t set intent extras so I really don’t see how it could be responsible for this!

Best Regards,
Milen

36

Hi, @milen-marinov

Thanks for the detailed information. I will try to reproduce it again with the steps you have described above. And let you know once I get the results.

Best Regards,
Maksym

37

Hi, @milen-marinov

I tried to reproduce your issue one more time - and everything works fine for me. I followed the next steps:

  1. First launch the app, no extras.
  2. Open the first-ever notification with first extras.
  3. Repeat step 2 several times, receive correct extras.
  4. Close application, force-stop it for sure and open again.
  5. Open notification and receive correct extras for it.

Also I tried to close app and open notification with closed app. Works fine.
Also I noted that when I reopen the app and click on notification, the SignalsMapActivity is not recreated and initFragment() method is not called.

Maybe it’s some side effect that is not visible at first glance.

If you have the opportunity, please provide the sample project with your issue.

Best Regards,
Maksym

38

Hi @Maksym_Khobotin,

Thanks a lot for checking again!
I did some more debugging and found something interesting!
I created a service that inherits from BackendlessFCMService and overrides public boolean onMessage(Context appContext, Intent msgIntent ). In that method I confirmed that the received msgIntent indeed receives the correct push notification headers. Stepping through BackendlessFCMService I verified that everything goes well up until the end of fallBackMode where the notification is sent with a PendingIntent that contains an Intent holding the correct extras. The strange thing happens after that when I open the notification. App’s main activity is launched with an Intent that contains extras from an old notification. It looks like the delivered Intent is not the same as the one that is packed in the notification’s PendingIntent. Any idea what might be the reason for such behaviour?

P.S. Just to make sure we are testing with the same environment - I’m testing on physical devices with Android 9.

Best Regards,
Milen Marinov

39

I think I got the answer! It looks like the Android system reuses PendingIntents but doesn’t handle well equal Intents with different extras: https://stackoverflow.com/questions/18049352/notification-created-by-intentservice-uses-always-a-wrong-intent/18049676#18049676
In a debug session I changed this line:
https://github.com/Backendless/Android-SDK/blob/271f2a559c14cfdd9c6ca979e953e95c1beef036/src/com/backendless/push/BackendlessFCMService.java#L187
from:
PendingIntent contentIntent = PendingIntent.getActivity( context, notificationId * 3, notificationIntent, 0 );
to:
PendingIntent contentIntent = PendingIntent.getActivity( context, notificationId * 3, notificationIntent, PendingIntent.FLAG_UPDATE_CURRENT );
and the problem disappeared!
If this is the case indeed it will explain the hard-to-reproduce nature of the problem since Intent reuse is probably dependent on a lot of factors (system version, free RAM, etc.)

Can you check the implications of such a change and let me know if and when you are going to do it?

Best Regards,
Milen Marinov

40

Hi Milen,

Thank you for the investigation and sharing your finding with us. We will definitely look into it from our side and let you know.

Regards,
Mark

1 Like