I wanted to verify some data from a month or two back. I was looking for daily stats and (unless I missed something), I could only get there by going to daily trends, which then displays “today” and swiping back multiple times.
I needed to move back some 45 days which I did by rapidly swiping again and again. The “bubbles indicator” started to appear indicating trends were loading. When I got to my desired day it took minutes to finally display the data.
As an iOS developer myself, I am guessing that each swipe (moving one day) fired off an API request to get the data and moving to the next day did not cancel that request, or close the connection. I noticed, on a typical trend request for hourly data, 32KB is received in about 1.2s (on a 100Mbs connection). Not cancelling or closing the connections, for 45 swipes, causes easily more than a minute delay before the one and only response of interest appears, and might also cause an unnecessary download of data.
Even if I am wrong about the mechanics of the slow response, the slow response is ultimately the problem I am reporting.
Just an FYI - you can navigate to a random day more quickly in Trends by starting in Year, swiping to get to right year, then touching on the Trend bar(s) for the month you want. That will bring up in the month you want, and you can then repeat the process for the day you want,
See my response in the date selection thread. Having said that, this method sure avoids causing the app to make a ton of network requests.
It still requires a year’s worth request, and a month’s worth request just to arrive at the desired date. These cannot be “interrupted” as one cannot tap on the desired portion for navigation until it has been drawn, which requires generating and receiving all the data.
From a developer perspective and (cellular) data consumption perspective, I still think the request cancellation should be implemented.
Having a date picker avoids all of this anyway.