Allow increased frequency of In-App Messaging fetches from server

[aranda-adapptor]

What feature would you like to see?

According to the documentation, messages are only fetched from the server to the client once per day. This is a significant roadblock to using messages for certain situations, such as informing users of a service outage. If the client has already been run that day, it won't fetch again and any new messages can only be shown the next day. Other modules such as Remote Config and Realtime Database are fetched much more frequently than this. It would be understandable if there was a minimum period like 30 or 60 minutes (in production), but a whole day seems excessive. Also if there was a "test mode" that allowed even more frequent fetching (similar to Remote Config), that would make the feature much simpler to test.

https://firebase.google.com/docs/in-app-messaging/get-started?platform=android#send_a_test_message

How would you use it?

The fetch frequency could be configured either in the Firebase console, or when the app is initialised (similar to Remote Config).

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[argzdev]

Thanks for the feature request, @aranda-adapptor. While I’m unable to promise any timeline for this, if others find this useful, adding a thumbs up on this feature can help our engineers prioritize adding this to the roadmap.

[RiverboatGambler]

I only just realized with this thread how ineffective Firebase InApp Messages are. I'm going to write my own replacement. It does nobody any good if it takes 24 hours to get out an important notice to their users. I was hoping to use these messages to communicate information about critical bugs and fixes. It would appear a better solution would be to use Firestore and custom views