-
Notifications
You must be signed in to change notification settings - Fork 754
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
Allow sending any JSON with JsonArrayRequest and JsonObjectRequest #419
Milestone
Comments
jpd236
added a commit
to jpd236/volley
that referenced
this issue
Jul 1, 2021
These conflict with pre-existing constructors - since the request argument is nullable, existing code which passes in null requests is no longer invoking an unambiguous constructor. See google#419 for more details and a workaround. These constructors were added in google#406 and have not yet been included in a public release, so they are safe to remove.
jpd236
added a commit
to jpd236/volley
that referenced
this issue
Jul 1, 2021
These conflict with pre-existing constructors - since the request argument is nullable, existing code which passes in null requests is no longer invoking an unambiguous constructor. See google#419 for more details and a workaround. These constructors were added in google#406 and have not yet been included in a public release, so they are safe to remove.
jpd236
added a commit
to jpd236/volley
that referenced
this issue
Jul 1, 2021
These conflict with pre-existing constructors - since the request argument is nullable, existing code which passes in null requests is no longer invoking an unambiguous constructor. See google#419 for more details and a workaround. These constructors were added in google#406 and have not yet been included in a public release, so they are safe to remove.
jpd236
added a commit
that referenced
this issue
Jul 7, 2021
…420) These conflict with pre-existing constructors - since the request argument is nullable, existing code which passes in null requests is no longer invoking an unambiguous constructor. See #419 for more details and a workaround. These constructors were added in #406 and have not yet been included in a public release, so they are safe to remove.
You Can Create Cstm Here JSONArray posting And in response a JsonObject
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Prior to #406, JsonArrayRequest required JSONArray request bodies, and JsonObjectRequest required JSONObject request bodies. Nothing should couple the request type and response type, so it's reasonable to want to send JSONObjects and get back JSONArray, or vice versa. However, the new constructors can end up breaking compilation of existing code which depend on Volley, since the request argument is nullable and thus ambiguous if null is provided. For example, code like:
compiles fine with the current Volley production release, but suddenly fails to compile here since the compiler doesn't know whether this corresponds to the JSONObject or JSONArray constructor.
I don't see a great, backwards-compatible fix for this. Adding a factory method or builder isn't sufficient because subclassing the request is fairly common too (e.g. to populate custom headers). We could just reorder the arguments in one of them, but that would just make for a more confusing API.
So I think for the short term, we should just revert back to what was in place before. Longer term, if/when we make breaking API changes, we can consider improvements here.
The workaround is to extend JsonRequest directly, e.g.:
or just avoid using these classes entirely - they're not that complex, and you're probably better off using a strongly-typed JSON object instead.
The text was updated successfully, but these errors were encountered: