feat(fcm): Enable fid and deprecate token for Send API#1211
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces support for Firebase Installation IDs (FIDs) as message targets in the FCM SDK, deprecating registration token fields in favor of FIDs across the Message and MulticastMessage classes. Feedback indicates that the current implementation of MulticastMessage.getMessageList() fails to preserve the relative order of tokens and FIDs, which violates the API contract requiring response order to match the input order. Additionally, the class-level documentation for MulticastMessage needs to be updated to reflect the new combined limit of 500 for tokens and FIDs.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces support for Firebase Installation IDs (FIDs) as message targets across the messaging API, including the Message and MulticastMessage classes. It deprecates registration tokens in favor of FIDs, updates validation logic to enforce a single target type per message, and adjusts multicast processing to handle a combined limit of 500 targets. A review comment suggests clarifying the MulticastMessage Javadoc to accurately reflect that responses are ordered by tokens first followed by FIDs, rather than strictly by the interleaved addition order.
| * <p>This class and the associated Builder retain the order of tokens and FIDs. Therefore | ||
| * the order of the responses list obtained by calling {@link BatchResponse#getResponses()} | ||
| * on the return value of {@link FirebaseMessaging#sendMulticast(MulticastMessage)} | ||
| * corresponds to the order in which targets were added to the | ||
| * {@link MulticastMessage.Builder}. If both tokens and FIDs are provided, tokens are | ||
| * processed first, followed by FIDs. |
There was a problem hiding this comment.
The Javadoc states that the response order corresponds to the order in which targets were added to the builder. However, the implementation groups tokens first and then FIDs (as noted in the subsequent sentence), which means the response order will not match the addition order if tokens and FIDs were interleaved. The documentation should be clarified to reflect that the order is preserved within each group (tokens then FIDs).
| * <p>This class and the associated Builder retain the order of tokens and FIDs. Therefore | |
| * the order of the responses list obtained by calling {@link BatchResponse#getResponses()} | |
| * on the return value of {@link FirebaseMessaging#sendMulticast(MulticastMessage)} | |
| * corresponds to the order in which targets were added to the | |
| * {@link MulticastMessage.Builder}. If both tokens and FIDs are provided, tokens are | |
| * processed first, followed by FIDs. | |
| * <p>This class and the associated Builder retain the order of tokens and FIDs. Therefore | |
| * the order of the responses list obtained by calling {@link BatchResponse#getResponses()} | |
| * on the return value of {@link FirebaseMessaging#sendMulticast(MulticastMessage)} | |
| * corresponds to the order of tokens followed by the order of FIDs as they were added to the | |
| * {@link MulticastMessage.Builder}. If both tokens and FIDs are provided, tokens are | |
| * processed first, followed by FIDs. |
There was a problem hiding this comment.
Such statement is included at the end as "If both tokens and FIDs are provided, tokens are processed first, followed by FIDs."
1 participant
This change deprecates
token(inMessage) andtokens(inMulticastMessage) as message targets, transitioning support tofid(Firebase Installation ID) andfidsas the primary targets instead.