Oddly restrictive operator limit on notification condition

[nolan...@mindsea.com]

Hello! The new features look fantastic, congrats on shipping.

I'm curious about one part of a new feature. Looking at https://firebase.google.com/docs/cloud-messaging/http-server-ref#downstream-http-messages-json we see this under the "condition" parameter:

> Supported condition: Topic, formatted as "'yourTopic' in topics". This value is case-insensitive.

> 

> Supported operators: &&, ||. Maximum two operators per topic message supported.

Sure enough, if I want to send a notification to all devices subscribed to any of four tags, sending a condition of e.g. `'A' in topics || 'B' in topics || 'C' in topics || 'D' in topics` gets the response:

> Invalid "condition" field: only support up to 3 conditions

First, it's kinda confusing to specify the maximum in two different units (number of operators vs. number of conditions) between the docs and the error message.

More importantly, this seems like an odd, arbitrarily-low restriction in the number of conditions. Why the limitation? Are there any plans to increase the number of conditions?

Any workarounds I can think of involve either the potential of receiving duplicate messages (POST once to "'A' in topics || 'B' in topics", then POST again to "'C' in topics || 'D' in topics", but now a device subscribed to both 'A' and 'C' gets the message twice) or making ridiculous combinations of topics (I could subscribe to tag 'A' and tag 'AorBorCorD', then I only need the one condition in my POST).

[Tingmui Li]

Hi,

  Thank you for flagging the inconsistency in how we indicate the constraints in doc vs error response. We would take a look and see how to improve this.

  On the workaround, you are correct,

(1) if you send to  "'A' in topics || 'B' in topics", then send to "'C' in topics || 'D' in topics", you would have to handle duplication yourself, e.g., flagging it in the client so that the second messages won't be displayed

(2) a different way to create the topics so that you would have fewer conditions.

  Can you elaborate your use cases? This will help us to understand how people are using this, which in turn enable us to evaluate the need to increase the number of conditions.

Thanks

Tingmui

[Mitzky Ogasahara]

Hi,

I'm not the topic owner, but I encountered this limitation last week. My use case is...

1) In my app, users can subscribe multiple topics related to areas, e.g. "LA", "NY", "Chicago", "Houston", etc...

2) When some incidents occur related to multiple areas, push notifications are delivered to subscribers. Of course, they can be related to three or more areas.

3) So, conditions may be "LA in topics || NY in topics || ...", but I can set only three topics.

When topics are subscribed by many users and messages are delivered to many topics, the limitation of "3 conditions" is not disired.

For Android devices, notifications can be deduped. However, for iOS devices(APNs), I think I cannot dedupe them.

2016年6月16日木曜日 8時41分17秒 UTC+9 Tingmui Li:

[Andy Raines]

I'm also having a similar problem as described by Mitzky.  Specifically we have a lot of sports teams which our users can follow, and when content is tagged with the sports teams we want to be able to send a single notification to anyone who is a member of that team.  As users can be members of many teams, we don't want to duplicate information.

[nolan...@mindsea.com]

Thanks for the reply! Our use case is the same as the others who have responded: we have many regions, or many sports teams, that a user can opt in to or out of receiving notifications for. Tags seem like a natural fit here: each region and each team has its own tag, and users update their tag registrations. Some notifications apply to multiple regions and/or multiple teams, and sometimes a notification applies to more than three tags, so suddenly tags don't look so hot. But part of the appeal of Firebase is not having to stand up our own server somewhere to manage stuff like this.

[Oleg Kosuchin]

Our use case is similar to some already mentioned. However I thought to give a bit broader account:

We have a service that sends push notifications if there is a goal in the football match. Say there is a match between the team A and team B and the player X scores a goal. In this case I want to notify a user who follows either team A, or team B, or a player X and has enabled Goal notifications in the app (there may be more choices - Game start, Game end, red card etc). My query would look like this:

“'Goals' in topics && ('teamA' in topics || 'teamB' in topics || 'player' in topics)"

However with the current limitation this wouldn’t be possible.

Since the above situation is the real use case we are facing, it would be great if this could be addressed by Firebase. Is it necessary to have this limit at all? Can it at least be increased to a more manageable number than 2 operators? 

Thanks!

Best regards,

Oleg

[Rodolfo hernandez]

Hi. I'm facing the same scenario where handling only 2 conditional operators drive us to look for workarounds like create topic that implies a condition. 

Is there any attempt to raise the number of conditional operators in the near future ?

Thanks.

[m...@andreashultgren.se]

Any update on this? Our use case is basically the same as everyone else's; we have articles which have one or more tags and users who may subscribe to any number of tags. Handling this ourselves is a pain, so this limit is the only thing preventing us from switching to firebase.

Den torsdag 16 juni 2016 kl. 01:41:17 UTC+2 skrev Tingmui Li: