-
-
src/Lunr/Vortex/GCM/GCMResponse.php (Diff revision 1) In the case of Android the endpoint is the device ID, no?
-
src/Lunr/Vortex/GCM/GCMResponse.php (Diff revision 1) MPNS uses ERROR for 400. I don't really see the necessity to introduce a new error enum. Invalid input is not usually something the user can influence since it would be a bug in our generators. They could opt to not use our generators and supply it themselves, but then they'd have details in the logs anyway.
-
src/Lunr/Vortex/GCM/GCMResponse.php (Diff revision 1) This says nothing to the user. We want the error message in the logs, not (only) the number.
-
-
src/Lunr/Vortex/GCM/GCMResponse.php (Diff revisions 1 - 2) The documentation hints at those messages already being available in the error response. I guess it would be best to fetch them from there rather than creating our own ones.
Change Summary:
It fetches the error message from the gcm response. There are some cases that gcm returns a 200 code although there are failures. In those cases it adds the errors in the field results in the returned json. This patch it parses these errors and logs them. Rebased against master
Change Summary:
cleaner review
Diff: |
Revision 4 (+708)
|
---|
-
-
src/Lunr/Vortex/GCM/GCMResponse.php (Diff revision 4) you effectively decode the result twice. I think it would make more sense to decode it in the constructor and always work with the decoded one, no?
-
src/Lunr/Vortex/GCM/GCMResponse.php (Diff revision 4) I don't really understand the usecase of this. Can you elaborate?
-
src/Lunr/Vortex/GCM/GCMResponse.php (Diff revision 4) nitpick. I think if you split out the foreach it becomes a little more readable
-
-
-
-
tests/statics/Vortex/gcm_response.txt (Diff revision 4) Can you run that through a pretty printer? :)
-
Change Summary:
changes based on the last review
Diff: |
Revision 5 (+651)
|
---|