Message is not showing!

[master8]

Hi, I have a similar problem issue 977 with two activities. Message is not showing on second activity after first has destroyed.

I suppose, there is a problem with calling FirebaseInAppMessaging.clearDisplayListener() in FirebaseInAppMessagingDisplay.onActivityDestroyed without checking which activity has destroyed (current or previous). As a result, the app can skip messages.

I use firebase-inappmessaging-display:19.0.2

Reproducible example here

Steps:

1. Get example app's Instance ID
2. Close example app
3. send test in-app message from firebase console
4. open app (open FirstActivity)
5. FirstActivity open SecondActivity
6. FirstActivity has finished.
7. SecondActivity still opened.
8. The message was received but not showing.

Logcat report:

2019-12-24 13:01:07.241 17432-17432/com.master8.experimentalproject D/FIAM.Display: Created activity: com.master8.experimentalproject.FirstActivity
2019-12-24 13:01:07.292 17432-17432/com.master8.experimentalproject D/FIAM.Display: Started activity: com.master8.experimentalproject.FirstActivity
2019-12-24 13:01:07.292 17432-17432/com.master8.experimentalproject I/FIAM.Headless: Setting display event listener
2019-12-24 13:01:07.295 17432-17432/com.master8.experimentalproject I/FIAM.Headless: went foreground
2019-12-24 13:01:07.295 17432-17432/com.master8.experimentalproject D/FIAM.Headless: Event Triggered: ON_FOREGROUND
2019-12-24 13:01:07.295 17432-17432/com.master8.experimentalproject D/FIAM.Display: Resumed activity: com.master8.experimentalproject.FirstActivity
2019-12-24 13:01:07.297 17432-17533/com.master8.experimentalproject I/FIAM.Headless: Forcing fetch from service rather than cache. Test Device: true | App Fresh Install: true
2019-12-24 13:01:07.297 17432-17533/com.master8.experimentalproject I/FIAM.Headless: Recoverable exception while reading cache: /data/user/0/com.master8.experimentalproject/files/fiam_impressions_store_file (No such file or directory)
2019-12-24 13:01:07.300 17432-17533/com.master8.experimentalproject I/FIAM.Headless: Fetching campaigns from service.
2019-12-24 13:01:07.322 17432-17432/com.master8.experimentalproject I/FIAM.Headless: Removing display event listener
2019-12-24 13:01:07.322 17432-17432/com.master8.experimentalproject D/FIAM.Display: Pausing activity: com.master8.experimentalproject.FirstActivity
2019-12-24 13:01:07.352 17432-17432/com.master8.experimentalproject D/FIAM.Display: Created activity: com.master8.experimentalproject.SecondActivity
2019-12-24 13:01:07.389 17432-17432/com.master8.experimentalproject D/FIAM.Display: Started activity: com.master8.experimentalproject.SecondActivity
2019-12-24 13:01:07.389 17432-17432/com.master8.experimentalproject I/FIAM.Headless: Setting display event listener
2019-12-24 13:01:07.392 17432-17432/com.master8.experimentalproject D/FIAM.Display: Resumed activity: com.master8.experimentalproject.SecondActivity
2019-12-24 13:01:07.524 17432-17432/com.master8.experimentalproject D/FIAM.Display: Stopped activity: com.master8.experimentalproject.FirstActivity
2019-12-24 13:01:07.526 17432-17432/com.master8.experimentalproject I/FIAM.Headless: Removing display event listener
2019-12-24 13:01:07.526 17432-17432/com.master8.experimentalproject D/FIAM.Display: Destroyed activity: com.master8.experimentalproject.FirstActivity
2019-12-24 13:01:07.681 17432-17533/com.master8.experimentalproject I/FIAM.Headless: Successfully fetched 1 messages from backend
2019-12-24 13:01:07.682 17432-17533/com.master8.experimentalproject D/FIAM.Headless: Updating contextual triggers for the following analytics events: []
2019-12-24 13:01:07.690 17432-17533/com.master8.experimentalproject D/FIAM.Headless: Decoding message: # com.google.firebase.inappmessaging.MessagesProto$Content@533ba749
    banner {
      background_hex_color: "#3ca9ff"
      body {
        hex_color: "#ffffff"
        text: "\320\242\320\265\320\272\321\201\321\202 \321\201\320\276\320\276\320\261\321\211\320\265\320\275\320\270\321\217"
      }
      title {
        hex_color: "#ffffff"
        text: "\320\227\320\260\320\263\320\276\320\273\320\276\320\262\320\276\320\272"
      }
    }

[google-oss-bot]

I found a few problems with this issue:

• I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
• This issue does not seem to follow the issue template. Make sure you provide all the required information.

[avadnerkar]

Seconding this. onDestroy of FirstActivity is called after onStart of SecondActivity, resulting in "Setting display event listener" -> "Removing display event listener" instead of "Removing display event listener" -> "Setting display event listener" when transitioning from FirstActivity to SecondActivity.

[aguatno]

Hi @master8 thanks for providing the mcve. I'm going to run the sample, and I'll immediately let you know as soon as I get an update.

[master8]

Hi @aguatno do you have any news? Can I help you with anything?

[aguatno]

Hi @master8 thanks for waiting. I tried to run your code, but the message was received by the app:

Could it be possible to show us the actual result in a form of video or screencast? Thank you :)

[master8]

@aguatno It's strange! Can you share me your logs?

This video record shows case with two Activites and message wasn't show:
https://drive.google.com/open?id=1k14TTF-p-AiCDj8jTmnOb90Veh7ttV2h

But if I use only one Activity everyting is ok:
https://drive.google.com/open?id=19JYqawrdNbOBe7lwQ0pigG0jYEkN1OXR

[aguatno]

Hi @master8 thanks for the videos. I was now able to reproduce the issue (just missed step#1). This looks like a bug, the second activity did not received the pop up message, but logcat shows a successful data fetched from backend.

I have filed an internal ticket to have this bug discussed internally by our engineers. I'll keep you posted once I've heard from them.

[master8]

Thank you!

[aguatno]

Here's the bug#147662257 for your reference.

[Buthrakaur]

Hello @aguatno , sorry for a noob question, but where can I find status of the bug#147662257, please?

[aguatno]

Sorry for the delay here. Our engineering team said that this is basically WAI (working as intended), what we used to do in this case was completely crash the app, because now the FIAM UI references an activity that doesn't exist anymore. I think the solution here would be to somehow set the new activity to be the "parent" of the UI.

[hameno]

The real solution would be to either:

1. re-display messages that have not been acknowledged/manually closed by the user
2. allow developers to mark activities as "unusable" and trigger messages in the next activity, common use-case would be a login or splash activity.
   https://firebase.google.com/docs/in-app-messaging/modify-message-behavior?platform=android#temporarily_disable_in-app_messages cannot be used for that, as it will not trigger events at a later stage, right?
3. let the inappmessage dialog be their own activity, then it should not matter anyway

[aguatno]

@hameno Our team is still looking for the best approach on this case. I'll forward your suggestion to the team. Thanks

[Snivy102]

Ya it seems like In-App Messaging just flat-out does not work well with apps that have SplashScreens/LoginActivities because the event display listener is removed by the time the user reaches the Activity that we actually want to show the In-App Message (aka MainActivity). Works fine if there is no SplashScreen/LoginActivity because MainActivity would be the "Launcher" activity, and the event display listener would not be removed because there is no closing of one activity and transitioning to a new activity like there would be when using SplashScreen/LoginActivity.

I use both a SplashScreen and a WelcomeScreen in my app, so by the time the user gets to MainActivity I can't even use triggerEvent("main_activity_opened") (for example) because the event display listener has been removed twice.

[smlima]

Yeah, I'm also facing the same sort of issue.
It would be great if we could force the setting of the listener, and/or setting the main activity as the listener one. ie, not caring about receiving messages on Splash/Login screens, but starting listening as soon as the Main Activity is shown

[Viraj7009]

@aguatno is there any solution for this issue? I'm also facing the same issue. Is there a work around for this issue? Thanks

[JasonAHeron]

Hey folks, we are aware of this and I am currently working on a solution. Yeah the issue is exactly as you folks describe, the way we hook into the activity lifecycle doesn't work well for apps with splash screens. The problem is that not doing this has resulted in callbacks referencing dead activities and crashing apps. I am going to be prioritizing investigating this issue this week.

[Viraj7009]

Hi @JasonAHeron were you able to get around this issue and find some work around that works?

[JasonAHeron]

Howdy again, this is definitely on my radar but not my highest priority issue right now. I will likely start digging in either sometime this week or next. I'll update this bug when I do

[JasonAHeron]

Update here. I am able to reproduce this issue consistently and will begin working on a fix.

[JasonAHeron]

I have a prototype fix for this issue. I'll aim to have this fix available in the next release.

[Viraj7009]

@JasonAHeron awesome. Looking forward to it. Thanks

[JasonAHeron]

This will be fixed in our next release 19.0.7

[Viraj7009]

Thanks @JasonAHeron Looking out for the release. Do we have an approximate release date for 19.0.7?

[JasonAHeron]

We are targeting tomorrow but no promises. O(days) though.