Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Message is not showing! #1092

Closed
master8 opened this issue Jan 5, 2020 · 25 comments · Fixed by #1550
Closed

Message is not showing! #1092

master8 opened this issue Jan 5, 2020 · 25 comments · Fixed by #1550
Assignees
Labels
api: inappmessaging type: bug Something isn't working

Comments

@master8
Copy link

master8 commented Jan 5, 2020

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
Copy link
Contributor

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
Copy link

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
Copy link

aguatno commented Jan 8, 2020

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
Copy link
Author

master8 commented Jan 14, 2020

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

@aguatno
Copy link

aguatno commented Jan 14, 2020

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

Screenshot from 2020-01-14 20-36-33

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

@master8
Copy link
Author

master8 commented Jan 14, 2020

@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
Copy link

aguatno commented Jan 14, 2020

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.

@aguatno aguatno added type: bug Something isn't working and removed needs-attention labels Jan 14, 2020
@master8
Copy link
Author

master8 commented Jan 14, 2020

Thank you!

@aguatno
Copy link

aguatno commented Jan 14, 2020

Here's the bug#147662257 for your reference.

@Buthrakaur
Copy link

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

@aguatno
Copy link

aguatno commented Feb 20, 2020

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
Copy link

hameno commented Feb 20, 2020

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
Copy link

aguatno commented Feb 20, 2020

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

@Snivy102
Copy link

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
Copy link

smlima commented Feb 21, 2020

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
Copy link

@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
Copy link
Contributor

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
Copy link

Viraj7009 commented May 1, 2020

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

@JasonAHeron
Copy link
Contributor

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 JasonAHeron self-assigned this May 4, 2020
@JasonAHeron
Copy link
Contributor

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

@JasonAHeron
Copy link
Contributor

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

@Viraj7009
Copy link

@JasonAHeron awesome. Looking forward to it. Thanks

@JasonAHeron
Copy link
Contributor

This will be fixed in our next release 19.0.7

@Viraj7009
Copy link

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

@JasonAHeron
Copy link
Contributor

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

@firebase firebase locked and limited conversation to collaborators Jun 12, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api: inappmessaging type: bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.