so I've made an Android application which retrieves data from an API using Volley Framework with a GET request. The problem is that the first request that I make takes around 10 seconds to respond and then if I relaunch the app this same request only takes like 2-3 seconds. If I wait like 2 hours then I restart the app it again takes 10 seconds. I was wondering why this first request takes so long.
Thanks for your answers
Thanks to Ivan Wooll I found the problem.
As explained in this answer, I'm using Azure App Service and by default the website is taken down after 20 minutes of inactivity and it has to restart after that, that's why the first request takes so long.
Related
I'm making a cricket live score android application. I bought an API for that and started working on my app. The API response is in JSON. I am able to send the request to the server and get data in JSON. I am also able to show that data in my app but the thing is, in cricket, data can change at any time. There's no fixed time for changes in data so I want to listen for changes in data. I tried it by myself but failed. So, I basically wrote code to fetch data every 10 seconds. Now I'm able to fetch and show fresh data but still, there's a problem. Since I'm fetching data every 10 seconds, my app is consuming a lot of memory and because of that, my app crashes after a point of time. Mostly when the heap reaches somewhere around 180 MB.
Can you please help to find out an efficient way of refreshing data of my android app because I believe using this much memory is not a good idea.
Thanks to #rb612 because he told me to try WebSocket. Using WebSocket, I can't listen for changes but I can refresh data every 1000 milliseconds which makes my data almost real-time sync. I just did a few other things like storing variable locally as much as possible.
I'm using Retrofit and OkHttpClient to build a Rest API on Android.
Some time ago, i had noticed the very first request made by the api always take way longer to process than all others... At begining i didn't care because it was an acceptable time.
But suddenly the request time jumped to 60 SECONDS
All this time is waste client side, since monitoring the server i see that the processing time takes less than 1 seconds...
I was wondering what change I made that could cause such high impact, then I realized that i changed the connection timeout of OkHttp.
I had changed the value from 10 seconds to 60 seconds just for testings...
I made some experiments setting the connectTimeout to many others values and ALWAYS the first request takes the time sighly above the timeout
Does anyone know what may cause this weird behavior? how to solve it?
PS. I needed to test the api on a desktop and this problem didnt occur, i mean it is only happening on android devices [i tried several] what is the cause?
https://medium.com/inloopx/okhttp-is-quietly-retrying-requests-is-your-api-ready-19489ef35ace
It is likely failing on the first few requests and timing out. OkHTTP is automatically retrying.
builder.retryOnConnectionFailure(false);
Try turning off the auto retry and see what happens.
https://www.reddit.com/r/gfycat/comments/5y2dkm/psa_for_android_devs_how_to_work_around_ipv6/
It is likely an ipv4 vs ipv6 problem. This code prioritizes ipv4 addressses.
You could configure an EventListener in your OkHttpClient and use that to see how the time is spent.
I am making a mobile application and I need to have the current time. However, I don't want to depend on the user's phone time since it can be changed to whatever they want. Is it a good practice to fetch from a server its local time every minute or similar interval?
P.S: The app will use the time to show if a shop is open or closed so I don't mind about different timezones, I only need the time in the server's timezone.
Depending on the need of the application. If your application would require a connection from the internet, then yes. You can also put that in case there is an issue catching the online time, you can just take the user's time.
From personal experience I never had issues that the user would want to change their phone time, but there have been a few exception.
To use server times is fine. But based on that making decisions on data (shop open/not) is not a good practice. Whenever you make an api call, get the status if its closed or not. This will avoid user side data issues
If you want to show this information on a single shop page, fetch the time difference between current time and closing time from the server. This will help you to maintain the status on app side. this should not be for a very long time. You can use this solution if the difference is less than 10 or 15 mins.
My code was working fine initially, then All of a sudden I'm not able to display posters on my app. I'm getting this particular error.
I've removed almost all while(true) loops. Please help.
You are probably making too many API requests.
From the TMDB.org FAQ:
We currently rate limit requests to 30 requests every 10 seconds.
You should make sure your app never uses more than that. How you implement this is up to you, but you could keep track of a request counter that:
decrements every time you make a request
resets to 30 or so every ten seconds
only allows requests to continue if it is positive
In general, you should try to query the API as little as possible: cache results in your app as much as you can.
My app periodically refresh data by pointing the api. Right know this process is every 3 minutes. Thats mean that every 3 minutes app, points to api requests and calculating data.
What is the best time value between refreshing points? Somewhere i ready that good is every 30 minutes.
I focusing right now on battery life and looking for the best solution.
Thanks.
Exact answer for this question depends entirely on how important is "refresh" for your app to work stably. I haven't checked the c2dm approach.
Few steps can be followed to improve performance and battery
1) Stop your periodic refresh when application is in background
2) Follow the design tips thats been given here.
3) Its better to give user a choice regarding Refresh timer with 10, 20 , 30 minutes as choice in your app settings (optional).
You can use Google's C2DM to notify the device of new information instead of polling for it. Yes 3 minutes is too soon, use 30.