-
Notifications
You must be signed in to change notification settings - Fork 21
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
feat: add shouldPush
to contentTypes messages
#235
Closed
Closed
Changes from 5 commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
16c6549
feat: add shouldPush method to ContentCodec interfaces and each codec…
36c872d
feat: add shouldPush property to DecodedMessage class
2410b10
feat: add shouldPush parameter to sendWithContentType and prepareMess…
f774147
feat: add shouldPush test for content types
7450a4c
feat: add shouldPush parameter to sendEncodedContent and prepareEncod…
ccceabe
chore: update shouldPush parameter
bbe2696
feat: add shouldPush parameter to sendEncodedContent and prepareEncod…
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kele-leanes I think here instead of calling
model.shouldPush
maybe you can copy how the test does itthen it would be
message.shouldPush
Or something along these lines to get the push without having to make changes to the iOS sdk directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To do that I need to make
MessageV2
andcodecRegistry
public and add keyMaterial to model which is not currently sentThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and making this method
async/await
would add more complexity where this method is calledThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no issue with
MessageV2
andcodecRegistry
being public. @nakajima do you have any thoughts?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
besides that, since the codec registry in RN lives on the JS side, the
MessageV2.encode
method can not access the codecs from RN.e.g: If I register a custom codec, which returns
true
from the shouldPush method, the native side can’t get this flag.Is the reason why I suggest sending the value encoded as in this PR or sending it as a part of a
SendOption
objectThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding the behavior in iOS,
shouldPush
is already established and calculated based on theCodecTypes
existing on the iOS side. However, in React Native (RN),CodecTypes
are generated and stored on the JavaScript side. Consequently, the determination of this flag should occur on the JS side and then communicated to iOS. I've devised two solutions:Include the
shouldPush
value as part of theEncodedContent
using the proto, similar to how we currently send the fallback. This value can then be decoded and set when aMessageV2
is created. (Link to PR)Send the
shouldPush
value as a plain Boolean, as proposed in this PR, and include it as an optional part of theSendOption
.The latter approach deviates from the convention of maintaining methods as similar as possible across platforms.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gotcha! Thanks for explaining.
So I don't think we should do (1) - it muddies the protocol, and the protos are shared across all of the platforms as well as sent over the network.
More of a long-term question/not blocking this PR, but why is this the case? Is there a reason we can't push that down to the native platform?
So the issue is that we are deriving
shouldPush
from the non-encoded content, however the SDK is structured so that only the encoded content is sent down today, which means iOS is unable to derive shouldPush? If so, then does that mean RN Android has the same issue and would also benefit from this?It seems like we have no choice with the current design but to do the
sendOption
thing even if it's a little ugly. Another question - given thecontentType
is in theSendOptions
already, would it be feasible to have iOS construct the codec based on the content type, and then determine theshouldPush
value from that? That way we are not giving app developers a way to setshouldPush
directly.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not fully aware of the impact of this change, but the structure of a
contentType
has methods that you can not pass down to the native platform. This would solve our issuesWe are not able to construct the codec since the
contentType
resides on the JS side. Specifically the custom ones. When the platform (in this case iOS) is trying to get the codec from acontentTypeId
it searches throughout the generics codecs which are on the native side.These changes must be added to the Android as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. In that case it seems that adding
shouldPush
to theSendOptions
is the only way for now. Perhaps we can name it something that makes it clear that it is internal-use only, like__shouldPush
or something.Long-term, there will probably be more cases like this where the RN SDK wants some functionality from the iOS SDK that we don't actually want to expose publicly. I wonder if it makes sense to define an iOS type/interface that is internal-use only, that we don't document or provide any guarantees about publicly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resolved in ccceabe