Can I make multiple API requests in the same page in an Android application? Whenever I have multiple requests, the app crashes.
Hi Chris, yes you can make multiple requests in one page so I’d look at your logic to identify the source of the issue. Our troubleshooting tips include what I do when I have issues with requests:
Sue, my APIs themselves are working as I’m using the the same API in production on my iOS app. The issue I’m having is, whenever I add a second API request in a page on Android, the app crashes once I run it on my Android device. Android documentation says you have to invoke threading the run mutiple API requests. Something more granular I won’t be able to do in the editor. Is there any API documentation specific to Android and it’s lifecycle.
You don’t need threading to run multiple requests, only for very particular types of processing, and we don’t support control over threading in Dropsource in any case. If you can explain what functionality you are trying to achieve with your requests maybe we can advise.
Are you perhaps nesting API requests within eachother based on success/failure?
Would you share some screenshots of the process you are attempting to use in the editor for these multiple API calls?
After my getStatuses request is made and returns a 200 (successful), I attempt to run the getProfileMedia request and the Android device stops working. It only does this whenever there is more than one api request made. Regardless of where the request is made.
Does the 2nd API request use information that’s coming to the app in the 1st API request’ response? If so, understand that the 2nd API request is being triggered immediately after the 1st request. It is not going to wait for the response from the 1st api request to arrive. That’s what the success/failure events are for (triggering only when a response is received). In the code on the backside, this is triggered as a code “block” and the success/failure events are triggered whenever the response arrives. The rest of the operations outside the success/failure events are going to happen without waiting for that response.
If your 2nd API request is assuming the values it needs for its parameters are provided because the response to the 1st API request has already received a response back, that won’t be true and you will incur what’s known as a “race condition” which can give unexpected results since the time it takes to receive a API response is variable so sometimes it might work and other times it won’t if the response takes a little longer to arrive.
Recommendation: If the 2nd API request isn’t the exact same call as the 1st API request, you can include the 2nd request in the success event of the 1st API request. Then you can guarantee that the parameter values needed for the 2nd API request have arrived before this API Request is triggered. This is known as chaining. It’s not the best practice implementation here but it’s an option that can be performed. The best practice would be that the 1st API request provides the backend with the info it needs to complete the 2nd API requests intended actions.
The requests are totally independent of each other.
let’s run a test here…
Would you move the 2nd API request to the success event of the 1st API request. This will help highlight if 2 API calls occurring at the same time is causing a disruption.
I have tried this, the Android device errors out.
You can absolutely run a request in the success event of another request, I have an app I’m working on right now that does exactly that. The issue must be either in your second request, or in something you’re doing with the data in the first one. Does the second one accept any parameters? If so where are they coming from?
I’m passing an Device variable, one variable. The exact same thing that’s working flawlessly for me on my IOS project. I’ve attempted to run this request by itself in the OnCreate and the OnStart events. No matter where I place it, it crashes the app. The only thing that’s working is the API that populates my dynamic list. As I said, one API request per page. I’m sure it’s working for you Sue, so please someone tell me what I’m doing wrong.
Chris we are trying to help here, we just need you to work with us to locate the source of the error. As a next step I’d recommend either testing the value of the device variable right before you run the request (e.g. using a toast), or using the network log to check what value that parameter is being passed when the request actually runs - that will let us eliminate required data as the issue.
I wasn’t insinuating that you were not, my apologies if that came off the wrong way. I have done the toast thing, and the lone parameter which is the device variable ID is there. It’s the same property that’s used in the lone API that’s working on the page.
I can pull the source code and test in Android Studio to see what error is being committed. May I have a Build ID to test and the instructions from initial app launch to navigate to the app crash?
Buid ID: 1046810192329135082
Are you able to test the two requests separately from one another, i.e. run the second one without running the first one? It’s essentially a case of eliminating possible problems…
Interesting suggestion there Sue. The app crashed when I removed the api that populates the dynamic list, and swapping it out for one that should return a profile photo. It still crashes. Bizarre! Only my the API that returns my dynamic list works.
Would you please provide the requested instructions from initial app open to app crash?
Open the app, sign up, and as soon as it redirects to the home page, it will crash.