OK sounds like something more fundamental is wrong here… I’d recommend removing request calls until you have something that runs without crashing, then add requests / functionality one bit at a time and test your app each time to better identify the source of the error.
Chris are you able to see any response data coming back for this request in the network log before the app crashes? We’re seeing a json parsing error so wondering if there’s either an issue with the json or it perhaps isn’t matching the swagger exactly, the parsing is different between ios and android so it could be that the same data only causes an issue on one of them…
So what it looks like is, the issue was on the back end. On iOS, it allows me to loosely return values without json encoding them (all the time). Android/Java is not as loose with that practice. So I’ll have to strictly encode all of my return types or wrap my http code in a http_response object. I was typing this while your message popped up. Thanks for the help guys.
Now I’m having a problem running two consecutive API calls in the OnCreate event. I’ve even tried call one API in the 200 of the first one. It still crashes. Could someone look at the error: Build ID: 1046870064235387574
Chris I have to recommend what we did last time and encourage you to try troubleshooting using the network log, adding/removing functionality etc to see if you can identify the source of the issue first - given that the problem was at your backend last time I’d ask you to do whatever you can to eliminate that as a possible cause again here.
So I took the api that works and dropped it in the same page twice, everything works.
I copied and pasted the code from the api that works and dropped it in the file of the api that fails, overwriting the other code…still the API fails. It’s like it doesn’t like the file name or something.
Does this tell you anything???
I see this is marked as closed, but a helpful footnote to future devs who reference this issue.
The second reason my API calls were failing on Android and not iOS was because I had APIs that were originally going to to be POSTs, but I changed them to GETs. But Stoplight doesn’t allow you to delete Response Body values, so Dropsource still sees them. For whatever reason, iOS is smart enough to ignore the response body if your API still returns an http response, which is were I ended up return my API data. Unfortunately, Android isn’t this smart, so if it sees you initially had a Response Body, it will always expect a response body and cause your API to fail. In that case, you must delete your API and create a new one from scratch. It’s the only way to get rid of that initial Response Body. Then Dropsource no longer sees it as well. Took me 2 days to figure this out. Hope this cuts someone else’s curve.
Hi Chris, thanks for the update, am sure this will be helpful to someone else.
I’m not quite following when you say Stoplight doesn’t allow you to remove response body values as I’m fairly sure I’ve done that before, would you mind indicating what part of the Stoplight interface you’ve found that in? If Stoplight is not producing the result you need you also always have the option of editing the exported JSON file directly before uploading it into Dropsource rather than linking directly to the Stoplight url or whatever.
I suspect part of the issue here might have been changing POST to GET, because Dropsource will likely treat that as different requests (you can have different requests with the same name / path but different methods) which would make it messy when you update your API in Dropsource rather than deleting and replacing it, you’d essentially end up with a load of redundant deleted endpoints.
And FYI the post had been marked as resolved before you posted the second issue but even when it’s resolved you’re more than welcome to post additional info, new visitors will be able to see and learn from it…
The Stoplight interface I am speaking of is the Endpoint UI. I have not been able to delete a body response once one is provided. If you have documentation as to how this is done, please share. The reason I do not manipulate the json file that is created is beacuse I would have to do it every time I generate a new json file. So it’s just easier to delete the endpoint and creat another one. This issue is a bit of a one off, so it shouldn’t be that big of a deal.
Is this the area you’re referring to?
If you click the type currently selected it will be removed, or you can remove it in the JSON Schema tab. If you’re using the newer version of Stoplight I’m less familiar with that but I’d hope there’s a way to remove items from the response body since that’s a pretty typical task people will be carrying out.
In this section, yes, you can remove a response type. It’s the section right above, the “Response Body” area is where you cannot remove items once you provide them in that section.
Request Body? That section works the same for me - you just need to click Edit first.
SMH, okay I see. Thanks.
It isn’t the most intuitive interface tbh, I haven’t had much of a go on their new version but might be worth a look…